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 they need to quickly create another virtual machine as part of their build infrastructure to react to changes in data center 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 many 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 and plain HTTP based downloads are also useful 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 scenarios were common with the various people I met at DevOpsDays, Vancouver. I presented an ignite talk in which I argued that the DevOps pipeline should consider the security and license characteristics of all the jars and other components used in your application 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 led me to believe that considering what you know about component vulnerabilities should impact how you deploy applications in a DevOps fashion.
Manfred is a former author, trainer, and community advocate at Sonatype. He speaks regularly at conferences such as JavaOne, OSCON, DevOpsDays. He is a long time open source developer and contributor.
Explore All Posts by Manfred MoserTags
Code 3x Faster with Less False Positives
Build, test, and launch secure applications without rework. Explore how the Sonatype platform can enhance productivity and security.