Last week I was a host of October Nexus Live and attended DevOpsDays Vancouver. In both events Sonatype Nexus and CLM were present as part of a devops pipeline and I got to chat with many people that use Nexus or would probably get a lot of benefits from doing so…
In the Nexus Live event John Nagro and Tom McLaughlin from HubSpot detailed how they are using Nexus as a repository for their development and release components. They found that they need to be able to quickly create another virtual machine as part of their build infrastructure to react to changes in datacenter locations and other parameters. To facilitate that they have created a Puppet module that can install Nexus. The module is available on puppet forge ready for you to use. In addition the source is available on GitHub and John and Tom are looking forward to your contributions. They shared a lot of further interesting details about their Nexus use case and the scale they are working at. Go and check out the recording for more information.
Kyle Allan from RiotGames also hung out with us and reminded us of the Chef cookbook for Nexus he is maintaining, which is also available on GitHub. Both the Puppet module and the Chef cookbook are used for installing and configuring Nexus as part of a devops pipeline.
When it comes to configuring Nexus and generally interacting with it from the outside in an automated fashion, it is best to use the Nexus REST API either directly in your script or the Java API wrapper. A great collection of examples of using the REST API is the nexus_cli Ruby gem also available from GitHub and authored by RiotGames.
The REST API as well as plain HTTP based downloads are also what comes in handy for the more common Nexus use cases that support a devops scenario – as a repository. Nexus is certainly great to have in your build pipeline just for the mere proxying of components from the Central Repository and others and the resulting simplification and tremendous performance gains. But the best benefits occur when you get your build to deploy the production components into Nexus repositories. Your configuration management tool like Puppet, Chef or Ansible can then pick it up from there via the REST API. Alternatively you could use a YUM repository in Nexus, if your production platform uses RPMs.
Both of these scenarios were quite common with the various people I met at DevOpsDays, Vancouver. I presented an ignite talk in which I argued that the devops pipeline should take security and license characteristics of all the jars and other components used in your application into consideration when pushing to production. Just like a failing integration test stops deployment, a known security issue in one of your dependencies or a problematic license should stop deployment too. In the demo session I showed the attendees how the data from Sonatype CLM exposed in your Eclipse IDE, your Jenkins CI server and your Nexus staging setup can greatly help you with this and how easy it is to configure your policies for your components and adapt them to the specific parts of your devops pipeline.
There was a lot of agreement visible in the audience and other talks about web application security and hackers lead me to believe that considering what you know about component vulnerabilities should impact how you deploy applications in a devops fashion.