I am setting up develop environment for java project.
And my team decide to use Jenkins for CI, and AWS EC2(linux) for server.
I succeeded to make an war file by jenkins job.
But, I can't find a way how to copy war file to EC2, and restart tomcat server on EC2.
I googled about it using "jenkins ec2 deploy", but in fail.
somebody help me!
Step 1. Install Jenkins plugin
Open your favorite browser and navigate to Jenkins. Log in and select “Manage Jenkins” followed by “Manage Plugins”. Select the “Available” tab, locate the “Deploy to container” plugin and install it.
Step 2. Edit tomcat-users.xml
In order for Tomcat to accept remote deployments, you have to add a user with the role manager-script. To do so, edit the file ../conf/tomcat-users.xml and add the following line:
<user username="deployer" password="deployer" roles="manager-script" />
Step 3. Edit the Jenkins job
Back in Jenkins, go to your job and select “Configure”. Next, scroll down to the bottom of the page to the “Post-build Actions”. Select the option “Deploy war/ear to a container” from the “Add post-build action” dropdown button. Fill in the new fields.
Step 4. Run the Job project and verify the end results
Schedule a build for your job in Jenkins. If you check out the log file you should see one or more lines near the end indicating that the war file has been deployed.
If you check the logfiles in Tomcat (catalina.out) you should also see that your application has been succesfully deployed.
Lastly, if you point your browser to the URL and context path you’ve specified in the job configuration in Jenkins (e.g., http://your-server:8080/mywebapp), you should be able to open your freshly deployed application.
Credits to Jdev.it
More info can be found here
With EC2 (or any other deployment practice too), first determine your production servers are going to be mutable or immutable.
[Mutable]
The servers will be running forever, and you perform on-going updates as explained in the blogpost mentioned above (elizabetht) for Java war, or many other ways for different languages/platform.
[Immutable]
The servers are re-created (vs. upgraded) by automation mechanism such as scripting, or using config. mgmt tools like Puppet/Chef/Ansible or vendor specific initialization mechanism like AWS Userdata/Docker dockerfile/Vagrant vagrantfile, or using many other provisioning tools.
Generally speaking databases or queues should be Mutable category, and all other compute nodes are better be Immutable category. The benefits of Immutable category are a lot including easy HA, disaster recovery and also enables Blue/Green deployment and much more.
Related
How to copy .war file of tomcat 7 and 8 to EC2 instances placed in auto scaling group without any downtime. I want to replace the existing .war file with latest one in each and every servers in the target group/scaling group. How to configure my Jenkins for this.
Thank you
Once they are in an auto-scaling group, you will not be able to modify files directly on the server. Changing something on one server will not be mirrored on the other servers, and even if you changed all the currently running servers manually, those changes will not be rendered by any servers implemented by auto-scaling actions.
This can be solved by many methods, such as using "AWS Code Deploy."
You may also be able to configure something in your auto-scaling configuration via an "EC2 User-Data script" that will run on each server when it is created. That script could check out Git's latest code, or pull S3's latest build artifact and then launch the app.
You will simply mark the current instances as "unhealthy" when you have an upgrade ready to deploy and wait for the "Auto-Scaling" community to replace them with new, modified instances automatically.
I'm just getting started with Jenkins and I have a few doubts that must be silly, but I'm stuck at it.
After I build my project Jenkins save the build file in some specific path?
Using Ranorex for automation test, is it better to put my files locally on the server or push them to a repository?
Note: I just start tried to use this, at this moment I can check for changes at BitBucket, build the file, build the Ranorex test and run the test.
Jenkins is quite a versatile application that allows system setup to specific needs and requirements of the test project. So i'd say go with the way that seems most logical/easiest. It's kind of a learning process as well so you will be able to understand the working flow of Jenkins itself.
But to answer your 2 questions:
1) By build files i believe you mean the test reports? - For this I actually use the Jenkins UserContent folder. This requires the "Copy to slave" plugin to be installed. With this you will get an additional Post-build Action where you can specify the files that will be copied over to the UserContent folder. But don't forget to specify a common layout for the naming of report files through the Ranorex run parameters ("/rf"). The UserContent folder actually acts as a web server and you can directly link the URLs for email reports. (eg. "http://Jenkins-server.com/UserContent/Regression-Client-Test-#1.html")
2) This totally depends on the system setup. But i can give you an example on how our system is currently set up. So we have Jenkins which runs on a Linux machine. It is only used to manage and run the tests and the actual machine does not include the automation test project. Then we have the test machine which runs on Windows and holds the actual automation tests. This machine is connected to Jenkins through the Slave functionality. So basically when someone starts a test job Jenkins from the Linux machine sends a command to the slave to start the automated tests. When the test run has finished post-build actions take over and copy the report files from the Slave machine to the Linux machines UserContent folder.
Now when talking about the test project management. It's a good idea to use a gir repository which will add another layer of somewhat "security". But if you have a small team (or you are the only test developer) then there is no actual need for it. You just copy the project to the test machine to a specified folder whenever needed/updated and you are ready to run it.
Regards,
Martin
I read about archiving JENKINS_HOME in the wiki
(https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins)
but didnt exactly tell me how to archive it, was looking for any type of assistance
I found this
How to move Jenkins from one PC to another?
which is great but have some open ended questions and cant comment due to my low rank.
thanks!
You just have to zip your Jenkins home folder and copy it to the new server (the new Jenkins instance must be stopped).
Next, starts the new Jenkins instance and check you can access the new URL.
Once Jenkins is started, go to the Manage Jenkins/Configure system menu and update the Jenkins URL:
It should be enough to move your Jenkins stuff to the new server.
I would like to know, how to copy the "Post Build Activity" setting to all other builds in the same Jenkins server.
Example :
I have 100 or more builds are running in the Jenkins server.
Recently I have installed "Work Space Cleanup" plugin in the Jenkins Server
Now I have to enable/set the "Work Space Cleanup" property which is there in "Post Build Activity" for all 100 builds.
I am looking out for a common place in Jenkins to update the setting which intern updates the same setting for all 100 builds.
Thanks in advance.
Regards,
Bhupal.
Depending on what you require Configuration Slicing plugin has removed the support for the exact plugin you're asking for, but it would probably be possible to make a batch file, python script or something that removes the files wanted and then slice it among the projects.
When you are saying builds, i assume you mean to say projects/jobs. When you create a job, the configuration is stored in config.xml which is present on Jenkins server under the following path:
/path_to_jenkins_setup/jobs/job_name/config.xml
Just open the file and find the relevant portion that you need to replicate in other jobs. Create a script to copy the relevant portion to all jobs' config.xml.
Don't forget to restart Jenkins after making the changes. Alternatively, you can reload your changes by clicking on Reload Configuration from Disk which is present in Jenkins > Manage Jenkins section.
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx