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.