We are using Hudson as a CI tool. At present we are needed to use Jenkins, to deploy the build to Stage, Prod environment. What is the best aproach we should follow.
I know about promote buld plugin, but the issue is authentication. I want whevener we need to promote a build to deploy to Stage or Prod, it should ask for netqwork credential first. And then the promote job should execute the Batch command using the creadential supplied. At present, the promote plugin, runs using the credentials which the Tomcat server is configured to run.
Same issue with Build Pipeline plugin.
I want only dev or even hudson admin also should not be able to execute the promote build unless credential supplied. (We have windows 2008 r2 OS)
Can you please help me in resolving the issue. so that basically whenever a user click on Promote build to QA\Stage\Prod the plugin should ask for credential or should use the logged on users credential and execute the batch script using the logged users credential only and not by using the credentials of the account with which the tomcat server is configured.
Can you please help me?
Please suggests us the best aproach for making automated build on prod\stage.
For deployment I normally use SSH, Private/Public keys takes care of the authentication problems normally associated with running commands on other servers.
SSH is normally associated with unix based systems, but it does support windows.
Finally, I would recommend considering decoupling your build system (jenkins) from the system performing the deployment by using an intermediate repository. See the following answer for more details:
Jenkins : how to check out artifact from Nexus and Deploy on Tomcat-
Related
Context Simple Jenkins CD
I wrote a small app (spring boot) along with a Jenkins CD pipeline.
The (simple) declarative pipeline does the following:
build
unit tests
integration tests
deploy
Since spring boot generates a single artifact ("foo.jar" uber-jar), deployment simply "scp's" to the artifact to the production box (using jenkins ssh plugin).
The "ci/cd" setup presupposes that "production box" already has its config file. (e.g in spring boot, application.yml).
The Wrinkle
The setup works fine when the app does not require any configuration change.
However, if developers change code to require a "configuration change" (e.g. add a new port, password, etc), I do not want to auto deploy.
(Nor do I want to update the servers configuration, i.e. slip in "port=8443" , without admins "actively knowing" the change.)
Instead, I want to "flag administrators", "action required on your end", i.e. and have them actively add the config value (e.g. port or password) before deploying.
Question
What's the Jenkins-native way to "tell" admins "you must update your config before deploying new version of the application" ?
Any other recommendations?
Thanks in advance
Jenkins is here to automate your CI/CD, so the best approach would be to update the config file with another jenkins step or within the deploy step.
Now if you cannot automate this part, but we still want to be in an ideal world, a good practice is to deploy your artifact not to production but to a binary repository (Nexus or Artifactory) first. Then you could tell admins that the artifact is ready to be deployed.
The actual message you could send to admins could be an email or a slack with a template message that tells them that a new artifact is available and recall them how deployment must be proceed
https://wiki.jenkins.io/display/JENKINS/Email-ext+plugin
https://wiki.jenkins.io/display/JENKINS/Slack+Plugin
I have a local Jenkins server running on one of my spare computers (win10). Note that it is not behind any sort of a server and hence is only available within my local network. I have set it up so that it does the continuous fetch from my remote git repo and builds the artifacts and archives them for a successful build. I would like to publish these archives to my AzureDevops Release pipeline. How do I do this? (And yes I have looked through all the tutorials but they assume that I have Jenkins running on a VM somewhere on the cloud).
So far I have had no luck with the tutorials on the web since I donot really have a URL to this instance of Jenkins since it is only available on my local network. I cannot really build these artifacts on a remote Jenkins server, so I am really restricted to using this solution for running the builds.
I am looking to have these archives that Jenkins builds be directly available within my Azure DevOps release pipeline, on every successful build. Thanks for the help!
So since nobody else has answered this I am going to detail what I ended up doing (maybe not the best of the approaches but it works for my setup, suggestions are welcome!).
To interface with the Azure DevOps platform from a local machine you will need to configure a self-hosted agent (based on your specific OS), which will allow you to trigger builds, archive and upload the build artifacts to the Azure DevOps platform. This way you also donot have to poll for SCM changes too (which I think is not that elegant sometimes).
1. So you will need to go through the setup as outlined here for you local self-hosted agent:
Windows: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
Linux: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops
MacOS: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=azure-devops
NOTE: I have chosen to run the agent as service on windows for my setup
2. Next setup your Jenkins build job how you normally would, with your usual repo access setup. Things to keep in mind are following:
Under "Build Triggers", select the Poll SCM option, but make sure that the schedule is blank, this will make sure that the trigger from your post-commit hook from the agent works. Example setup shown below:
Under "Post-build Actions", make sure that you are archiving the artifacts as required. Example shown below:
3. Now time to setup your project's "Jenkins Service Connection", this can be accessed from the Project Settings tab on the bottom left of you project view in Azure DevOps. Note that this basically helps you self-hosted agent to locate and communicate with the Jenkins instance running locally (or an other network accessible location!). Go under Pipelines -> Service Connections and a new service connection for Jenkins. Note that the trick here is to use the URL for the connection as seen by you local self-hosted agent, which means it can be just any IP (including localhost) that the agent can access normally. Username and password are the same as the ones you setup in Jenkins. Example shown below:
NOTE: You can try to do "Verify and Save" but it will throw an error, so ignore the error or just go ahead and "Save without verification". Also you will have to do this per project, unlike the self-hosted agent setup which is per machine.
4. Now you just need to configure your build pipeline to give jobs to the right agent and pointing to the right service end-point. Now under you build pipeline settings use the agent pool that has the self-hosted agent(s) which can access your build servers. And choose the Jenkins connection that you just created in the above step. The rest of the setup is identical to how you would normally setup your project's build pipeline. An example would be as follows:
NOTE: The key here is the correct "Job name" (this should be the same as the one you have setup in you Jenkins build server instance) and the correct "Jenkins service connection".
5. The rest is straight forward in the sense that you just now need to make sure that you have a step to "Download artifacts" (NOT necessary if you donot want the artifacts on the DevOps platform) & "Publish Artifacts" (this is needed for your release pipeline to see that build artifact and to trigger it too if you want), after your jenkins queue job step. Make sure to setup the correct job directories for download from you local self-hosted agent. Example setup for both the steps:
NOTE: If you are having trouble with the paths for download and publish refer to this link for predefined variables for the self-hosted agents: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
6. Now in your release pipeline you should be able to add the artifact sources from you build pipeline. Example shown below:
Now you should be able to get the local artifacts in the cloud on the Azure DevOps platform, in case you cannot use the build agents provided by Microsoft for any reason!
As part of QA pipeline(in Jenkins), goal is to automate provisioning and configuration of a VM to run the QA tests.
Jenkins pipeline can trigger Terraform code to automate provisioning of VM and ansible code for configuration of a VM, but, issues like rollback, error handling is not easy unless we use some vendor specific template like AzureResourceManager template.
So, with Jenkins pipeline,What should be the best approach to provision and configure a VM in Azure cloud? we write pipeline scripts for jenkins pipeline...
As the goal is to know the best approach to automate provisioning and configuration of a VM to run the QA tests so I would go with simple jenkins pipeline script by leveraging Azure CLI commands in it.
To be precise, I would just add an Azure service principal to Jenkins credential. And then write simple Jenkins pipeline script by having 'withCredentials([azureServicePrincipal('SERVICEPRINCIPALCREDENTIALID')])' and then by using 'sh' part to have Azure CLI command to provision and configure VM. For illustration related to this you may refer https://learn.microsoft.com/en-us/azure/jenkins/execute-cli-jenkins-pipeline#add-azure-service-principal-to-jenkins-credential.
Regarding the issues like rollback and error handling when going with the approach of having Jenkins pipeline that triggers Ansible code (with or without using ARM templates) that can automate provisioning and configuration of a VM to run the QA tests, (you might already be aware of this but wanted to let you know that) for certain types of tasks you may write custom modules that can leverage the error handling functionality and in few scenarios you may leverage 'failed_when' option. Also you may leverage 'blocks' functionality by which you can define a set of tasks to be executed in the rescue: section. This 'blocks' functionality specially should help in enabling us to get the things rolled back.
Hope this helps!! :)
We're currently evaluating CI servers and Travis CI caught our eye since it is a hosted solution. I haven't been able to find any information about it being able to deploy to Scalr though. Has anyone had any luck setting this up? I found information about using Jenkins to deploy to Scalr but I'd rather not go with Jenkins.
Thanks.
Deploying an application upon a Travis CI build success if functionally similar to deploying one upon a Jenkins success. All you need to do is to hook in to Scalr through its API when you build succeeds.
Using Travis CI, you can't really run arbitrary post-build shell scripts (unlike Jenkins). This makes integration a bit more complicated than using Jenkins (with Jenkins you just use the Scalr Command Line Tools to call the Scalr API), but it remains feasible.
All you need to do is have Travis CI send a notification to a Webhook Endpoint to a webapp you control (host that on your cloud infrastructure, or on e.g. Heroku), and have that webapp call the Scalr API.
Disclaimer: I work at Scalr.
I need to execute few of the Jenkins jobs such as "Release to Production" through Jenkins UI using logged on user credential. The reason is, we have separate Support Team Members, who have access to the production boxes and not the Dev team members. So, in order to deploy any code base to production, all the Windows Deploy Commands (ex, create, update files, folder etc.) needs to be run with specific user credential who has access to the Production Box. So that even the Dev team members who don't have access to the Production box but are Jenkins Admin, execute the same job should result in failure due to "Access Denied". The job should succeed only if its been run by Support Team members with their credential.
I tried using parameterized plugin but couldn't able to pass the Password successfully to the batch file which contains MSDeploy instructions. Even the Jenkins console log displays the parameter passed in its console output, which is a security issue.
I checked Role based security plugin, but that doesn't help me much. I just need a plugin which should ask for user to provide their credential before start building the Job and should use the user credential to get the job executed, so that my MSDeploy command will be able to deploy the code on Production boxes, when the Support team member build that Job using their credential. I wish there was support for impersonation.
Right now all the Jenkins Jobs are getting executed using the service account which the Tomcat service is configured to run with on which Jenkins is hosted.
Any help would be appreciated.
Just in case there is any confusion a Jenkins job will always run as the same OS user. The Matrix based security applies to users who log into the Jenkins server and controls features like creating or launching jobs.
You could configure the job to use a set of generic production credentials and then prevent your developers from invoking the job.
Perhaps a better approach would be to separate the process that builds the code from the one that deploys the code. The following diagram (Taken from the xebia-france project) demonstrates how some of my favourite tools Rundeck and Nexus can be integrated with Jenkins.
Finally, I highly recommend reading the following link:
Using Rundeck and Chef to build devops tool chains
Hi I know I'm coming late on this thread, but I just fell on this issue and had a hard time solving it, so I thought I might just share what I managed to set-up.
First things first: if you want to run a Jenkins job "as a specific user" (with all the correct habilitations) the easiest way is to run a Jenkins SLAVE as this user.
Then you might very well stumble into the following: you probably want to run serveral slaves on the same windows machine as windows services. This is very fine, as long as each slave has his own Remote root directory and probably have a specific "label" too.
Once you managed to run your slave as a windows service, launch the service console (run services.msc). Edit the newly created service properties, go to Log On tab. Select "Log on as: This account" and enter your account credentials.
Cheers :)
You can utilize the built in windows runas or Powershell InvokeCommand cmdlet and -Credential to run - Both these would store the username/password in plain text - So do think about the risks, but this gives you flexibility.
I'm surprised this doesn't have a better answer of set an agent on another machine to run as another service and define agent as a special "type" which picks up the jobs - Something along those lines is what I would expect but I haven't seen an implementation like that in Jenkins (I'm new to Jenkins so was looking for an answer and found this thread).
Something else that could be considered for someone more familiar with Jenkins is when you set the custom path to MSBuild could you set that to runas /user:... msbuild.exe perhaps? I don't have an extra Jenkins server currently to try that on.