Jenkins, Web application server and Nexus

[Martin]

If I use Nexus OSS as a repository manager, the normal for code goes to production system is something like below:

1) Jenkins grabs code from Perforce or GIT server
2) Jenkins retrieves dependencies from Nexus
3) Jenkins test and build the project
4) The build is deployed to Nexus from Jenkins
5) Web application server, i.e. JBoss Application Server or Apache Server grabs code from Nexus, for production service.

In this flow, the build in Jenkins doesn't directly go or deploy to Web server, but first parked at Nexus, and goes to Web server.

Is this understanding right? I would appreciation an explanation for this cycle.

[Jeff]

I don't know anything about JBoss, but Apache (Tomcat) doesn't 'grab' anything.  You have to push the build to the server either using the tomcat manager API or use some other mechanism (SCP, wget, etc.) to otherwise grab the WAR file and get it onto the server.

Jenkins has the 'deploy war/ear to a container' plugin to facilitate this, but it requires (in the case of tomcat) the manager application to be installed and configured.  If your production environment is like ours, they will not install the manager application so it is either copied/configured manually or you can script it via a provisioning tool (SaltStack, Chef, Ansible, Puppet, etc.) and there are numerous ways to do it through any of those tools.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5ff2816c-3d23-42f4-bfde-103e7f8626fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jeff Vincent
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent

[Brent Atkinson]

Hi Martin,

The way you describe is similar to approaches I have seen before. However, as Jeff said, how you would do this is a matter of what you are looking to achieve and how you have setup your processes and environments.

Given how you describe [5] I assume you may be manually configuring from some sort of deployment script? Other organizations may use their build pipeline to automatically deploy built and tested artifacts to one or more environments (like qa, preview, production).

They key idea to the type of configuration you are talking about is ensuring that you can't put code into production without it being checked in, built off a developer's machine, unit and integration tests pass, and whatever else your organization treats as pre-release requirements.

HTH,

Brent

-- 

[Martin]

Hi, Jeff:

What do you mean by the "manager application" in the description of "manager application to be installed and configured"? Is it Nexus? Thanks.

[Martin]

Hi, Brent:

     You are basically right. I am adding a Nexus component to the pipeline and trying to figure out what role and how it should play in the pipeline.  Thanks. 

On Thursday, August 20, 2015 at 7:47:45 PM UTC-4, Brent Atkinson wrote:

Hi Martin,

The way you describe is similar to approaches I have seen before. However, as Jeff said, how you would do this is a matter of what you are looking to achieve and how you have setup your processes and environments.

Given how you describe [5] I assume you may be manually configuring from some sort of deployment script? Other organizations may use their build pipeline to automatically deploy built and tested artifacts to one or more environments (like qa, preview, production).

They key idea to the type of configuration you are talking about is ensuring that you can't put code into production without it being checked in, built off a developer's machine, unit and integration tests pass, and whatever else your organization treats as pre-release requirements.

HTH,

Brent

On Thu, Aug 20, 2015 at 7:12 PM, Martin <ling...@gmail.com> wrote:

If I use Nexus OSS as a repository manager, the normal for code goes to production system is something like below:

1) Jenkins grabs code from Perforce or GIT server
2) Jenkins retrieves dependencies from Nexus
3) Jenkins test and build the project
4) The build is deployed to Nexus from Jenkins
5) Web application server, i.e. JBoss Application Server or Apache Server grabs code from Nexus, for production service.

In this flow, the build in Jenkins doesn't directly go or deploy to Web server, but first parked at Nexus, and goes to Web server.

Is this understanding right? I would appreciation an explanation for this cycle. 

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsub...@googlegroups.com.

[Brent Atkinson]

He means the Apache Tomcat manager app. It provides the means to programmatically deploy to Tomcat. JBoss has similar  functionality exposed through its management services, though you may have to enable/secure it. This assumes your server lives longer than a deployment, which is not how everyone does it.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e1a17020-6646-49db-b8d8-b95d30c11886%40googlegroups.com.

[Jeff]

If (as an example) you are running Ubuntu 12.04 or 14.04, you would install 'tomcat7-admin'  (`sudo apt-get install tomcat7-admin).  Then there is a file /var/lib/tomcat7/conf/tomcat-users.xml that configures the users allowed to authenticate to the admin (via UI or API endpoint) to manage the applications deployed to Tomcat.  The url for the manager application would be something like:

http://<yourserver>:8080/manager/html

See https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html for details on using/configuring it.

WIthout a manager API or interface, you somehow need to get the WAR file to the server.  If using tomcat (as an example) on Ubuntu the typical path (if installed via the apt package system) would be /var/lib/tomcat7/webapps.  Dropping the WAR file in there would cause it to automatically deploy/redeploy.  Again, I'm not familiar with JBoss but I imagine it is similar.

At my previous company, Jenkins published the WAR file version to our GoCD pipeline.  It would then go to Nexus and pull that version of the WAR, create and RPM (CentOS based distro), push the RPM to a central repository, update Chef Data Bags and then initiate the Chef update which would pull the new RPM onto the server and push the WAR to the right folder.

At my current company we are using GoCD with SaltStack to update the Salt pillar files for the application.  WHen we run the salt state.highstate command, the system detects a change to the WAR file, pulls it directly from Nexus and drops it into the tomcat webapps folder (after it does a stop tomcat, clean old war folder/file, restart tomcat).  It also provisions tomcat if needed and updates any application specific properties files or settings.

Hope that was clear. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0EKvu%3DdnAw8PLHvUtcHQCPxd3bYVLYBtMKXS9Sk4xVd8g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Martin]

Hi, Jeff:

Very helpful! So it looks like between my Jenkins and Nexus, I also need a GoCD? Have never used it, but good to learn about it.

Thanks,

[Jeff]

You can do a lot with Jenkins so you dont need GoCD.  We are using GoCD because I think it does  better job at visualizing and managing deployment pipelines (post-build) and provides idempotent revisions which we use as a rollback solution.  In other words, pipelines are versioned and if done right you can go back in time and rerun any step with the exact settings used previously.

if you don't need or care about that and the complexity is not too crazy, stick with Jenkins.  What Jenkins does very well is the implicit Maven build dependences and all the other tool and  plug in integrations to get your initial build artifacts, source/coverage analysis such as SonarQube etc. and unit test reporting.

Good luck!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/eec54af3-4923-4bd5-b168-7ce1e15ce9c0%40googlegroups.com.

[Martin]

Thanks, Jeff. Very insightful.

[James Green]

The only point I'd make is you don't really want Jenkins to "know" about your servers individually to deploy to them. Perhaps for staging purposes, but given the elasticity in the world of production machines you probably want to "pull" using a script on your production instances from your repo manager like Nexus. Puppet can do this. Another option is to container(ise) your builds and then use orchestration onwards.

The key is that Jenkins probably doesn't know about production boxes. There might be many, and they may well fluctuate.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPJK9%3D%2BtMhFu-e3AYo0fviLNOVEYdAyVkT5d2j5_SSzHU39%2B-g%40mail.gmail.com.