I'm working with Jenkins servers in three different environments:Development-Staging-Production.
We work out the kinks in our Jenkins jobs in dev, test them in stage, and then finally move them to production. We do that be either replicating the job in the GUI (cut and paste) or tarring up the job directory and moving it to the next environment via the command line.
I'm wondering if the move option can be done with the service accounts that run these jobs. I can see the user account directories and config files under /var/lib/jenkins/users. What I don't see are the security settings that get applied to the user from the "Configure Global Security" screen in the GUI.
For these service accounts, we have the minimal authorization of READ on Global and READ and BUILD on Jobs.
What I'd like to be able to do is prove a service account in dev and then promote it to Stage and Prod from the command line vs having to manually recreate the account in the GUI for each upstream environment. If the API key could also be moved along with it that would be great.
Any thoughts or ideas?
User permissions are in config.xml under the Jenkins root folder, in section <authorizationStrategy>
This file contains other global settings, so just copying it would not be advisable
Just a wild thought, but why not use a master-slave config and trigger builds on the desired remote machine based on some "environment" parameter. You can also look through the plugins section to see if you can find something useful such as the:
node label parameter which allows to define and select the label for the node where you want the build to run
copy to slave that facilitates copying files to and from a slave
That way you'll only have one job configuration which can be executed on different environments without too much hustle.
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 around 100 linux servers that need to be added to a Jenkins master. The situation here is I need to add them by Copy Existing Node and the Jenkins master should not be shutdown/restart.
I don't want to do it manually for a hundred times. Is there any automation way to handle such request. Thank you in advance.
You could script this (self-automate). The Jenkins agent configuration files are located in the nodes subdirectory in the Jenkins home directory. You'd create a sub-directory for each node and inside that put a config.xml file for that nodes configuration. I recommend that you shutdown your Jenkins server while doing this, we've observed Jenkins deleting things when doing this while it is running. Use an existing agent's config.xml file for a template. Assuming all of your servers are configured the same, you need only update the name and host tags, which can be automated using sed.
Update with zero-downtime:
CloudBees has a support article for creating a node using the Rest API. If you'd prefer to use the Jenkins CLI, here's an example shell script. Neither of these approaches will require restarting Jenkins.
I have a jenkins setup with multiple users which are logging in with Active Directory plugin. This is useful so that each user can access his own tasks.
However each user also has different permissions on the local network, such as access to different folders etc. I have noticed that the permissions given to each task is not linked to the user but to the account under which the slave is running as service. Is there a way to change that so that the task is executed on the slave under the credential (and hence permissions) of the user?
Thank you
The problem is: there is only one slave process running the different job assigned to that server by the Jenkins master.
So the slave itself runs as one user (generally, a dedicated account or a system account).
Since you can get the user id as environment variable (with a plugin like JENKINS Build User Vars Plugin), you might consider configuring the job in order for it build step to "run as" the user who triggered the build.
See for instance the JENKINS Authorize Project plugin.
However, as mentioned this answer:
The "Authorize Project" plugin does not change the OS level user that is running commands.
It only sets the Jenkins user that is running the job and any downstream jobs, using Jenkins authentication (whatever it might be).
So you are left with build step with runas or su -c commands in order to be sure that your task does run with the right user.
I had the similar issue and I can recall for managing more control on projects I used role strategy plugin and setup global security using LDAP servers (Active directory should also be ok).
And I used authorized project plugin.
Have a look and I hope it should solve your purpose. Let me know on comment section for any clarification.
you can partially fix your problem this way:
install the slave as a service using the Java Web Start method and JLNP
go to Services control panel in windows
under Properties -> Connection replace the local system connection with a specific user
rebooted the service
This at least gives you the ability to use one account instead of system.
I have recently started to mess about with Jenkins and am unsure how to deploy my web app to a basic server. I've gotten into the Pipeline (https://jenkins.io/doc/book/pipeline/) and it seems like a fantastic way to work.
Where I'm a bit stuck is in two spots:
Once my repo is in my workspace within Jenkins, how do I prep it so I am only deploying the files necessary for the application? For example, I don't need my src/ directory or my Vagrantfile when I'm deploying things.
How do I deploy my app to the server? I see examples all over the place, but I am getting a bit lost since there seems to be so many ways to do this. I'm assuming scp or something like that...?
To build off of #2, is there a way to deploy web apps as transactions (in one shot) rather than file-by-file?
Please let me know if I can provide any information for potential answers!
I can't speak to your specific use case but a common way to do this is the build-and-deploy model, where you will have 2 Jenkins jobs. The "build" job will check out from source, run build commands such as maven or make, and lastly will "archive" the build artifacts. The latter is an option under the 'post-build actions' tab at the bottom.
In the "deploy" job, you will grab the artifacts of your choice. You can fetch a single file, all of them, and everything in between. This requires use of the 'Copy Artifact' plug-in and it allows you to copy files generated by other jobs. Now you can run your usual deploy script in the 'Execute Command' box. Most command line paradigms are supported out of the box such as setting environment variables.
The instructions above assume that you want to run your application off of a host that you've provisioned as a Jenkins slave.
Use artifacts as mentioned by Paul Back, or a 3rd party artifactory server as in video
This is always tricky and error-prone. Why not spin up a fresh server with new release (humanly verified once)
Jenkins & Ansible is the answer here. This is how I deploy to production, since I am in no need to use anything like Docker (too many issues with particular app) so have to run the app natively. Quick example would be
You monitor a specific branch in gitlab / github or whatever else and then call a webhook on push / merge etc on that branch, at this point you deal with anything you need to do by running a playbook on the jenkins job that monitors that branch (jenkins).
in my case jenkins and ansible run on the same server. Jenkins runs the ansible playbook that does whatever I need to do.
for example with ansible, I copy certain files that need to be there, run configs / change filenames etc. setup nginx, run composer,
you get the point.
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.