When Maven Repository Managers (MRM) first appeared on developers’ radar, everyone using them immediately saw the benefits. Right off the bat, MRMs replaced cobbled together solutions like shared drives or local Maven repositories copied and exposed via http.
Since its release four years ago, Sonatype Nexus has grown to support many repository formats. And most users of build tools including Gradle, Leiningen, SBT and Ant/Ivy have started to realize the numerous benefits of using a repository manager.
Using an MRM has become accepted best practice for Maven users.
We know how components from the Central Repository have become critical to your development efforts. We also know that you need to trust those components. Part of that trust is knowing that hackers don’t have visibility into the components you download or that they compromise components using a man-in-the middle or Cross Build Injection (XBI) attack.
We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager. Given the tremendous growth of Central, and the fact that modern applications are largely built from OSS components, this capability is likely to be leveraged by many organizations. SSL has become the standard mechanism for protecting web traffic – across the spectrum of Ecommerce, banking, health care, and so on. Providing SSL support for Central means that your components are no longer susceptible to man-in-the-middle attacks that could compromise the component. SSL also eliminates the potential for a hacker to gain visibility into your organization by tracking the components that you download for your development initiatives.
As of Nexus Pro 2.2 (available now), SSL is now the default connectivity option for Nexus Pro users. Because we take security of the ecosystem seriously, we aren’t stopping there, we’re making SSL connectivity to Central available to you even if you aren’t using Nexus Pro.
In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes. For the first 60 days all donations will go to the Apache Software Foundation. After that, the donations will go to other open source foundations such as Eclipse. Sonatype will provide a donation on behalf of Nexus Pro customers since we’ve included SSL access to all Pro customers automatically.
If you happen to be using Nexus OSS (any version), support for the SSL token is included already. I’ve already reached out to the Artifactory and Archiva teams and they are working on the changes necessary to enable SSL to Central – we’ll let you know when that support is enabled. If you’re not using a repository manager at all, what are you waiting for?
If you are an existing Nexus Pro customer, you can download the latest release from the support page.
If you would like to make a donation to the open source community and get SSL access, you may do so here.
The an upcoming release of Nexus OSS will have full support for Yum repositories. Sebastian Herold, with gracious support from IS24, has developed and contributed his code and time to integrate his Nexus Yum Plugin into the Nexus 2.x line. We have heard from many Nexus users, who are heading down the path of continuous delivery, that Yum support in Nexus to deliver RPMs to production servers is a critical requirement. Several of our customers have been using Sebastian’s plugin for quite some time and have been impressed and so we’re really excited about the integration of Yum functionality into Nexus OSS!
Some of you might be interested in using our Yum support to facilitate application deployment to staging and production networks. A lot of companies that deploy Java and other technologies end up packaging applications as RPMs and deploying them through Yum on Redhat or Centos because it provides a really easy way to manage, deploy, and rollback software packages in production. It is much easier to tell Operations to deploy RPMs than it is to draw up a series of instructions for installing Jetty or Tomcat from a tarball. To support these use cases, we’re going to invest some of our time developing more documentation and training to support developers that need to adapt applications to deployments that depend on this Yum integration.
While Nexus is primarily used to support application development, this Yum support can be used on its own as a way to cache and simplify Yum repository configuration and package data. We’ll also be building out more examples of how Nexus can be integrated with infrastructure management tools such as chef and puppet.
Features of the Nexus Yum Support
As we integrate this feature into Nexus proper, here is the current list of features. We expect this support to evolve over time, but here’s what the plugin provides now.
- Expose an existing Maven repository as an RPM repository – Use a Maven repository, hosted in Nexus, containing RPMs as if it is a Yum repository. This leverages the virtual repository mechanism in Nexus which allows you to use Maven tooling to deploy RPMs into a Maven repository but still allow Yum clients to interact with the repository using the protocol it understands.
- Automated Refresh of Repository Data – Yum repositories are automatically updated if you upload/deploy/delete a new RPM into Nexus. In a traditional RPM repository you have to run createrepo to refresh repository metadata. With Nexus this is all taken care of automatically.
- Full group support so that you can logically group a set of Yum repositories behind a single URL. If your infrastructure relies on a number of remote RPM repositories you can consolidate OS configuration to point to a single Yum repository that can aggregate multiple repositories into one.
- Versioned views on repositories: http://your.nexus/nexus/service/local/yum/repos/releases/1.2.3/ gives you a Yum repository with all packages in version 1.2.3 in repository releases. This particular feature is a game-changer for companies that release software using RPM as a delivery mechanism.
- Alias Definitions for Specific Versions eg. production=1.2 and testing=2.0 and access them via the alias: http://your.nexus/nexus/service/local/yum/repos/releases/testing/ and http://your.nexus/nexus/service/local/yum/repos/releases/production/ to get constant repository URLs for your servers. A new release is then applied to the server by setting the alias to a new version.
- createrepo Nexus Tasks Types – Create Yum createrepo tasks manually via web interface. Multiple createrepo tasks on the same repository are merged.
- Full Integration with Nexus Staging – Use Yum group repositories as target of staging repositories (Nexus Pro). Stage RPM artifacts to development environments configured to pull artifact from Nexus repository groups./li>
You can find the source for the Nexus Yum Plugin in our Github Repository. We would love your feedback as we still have time to make changes and improvements before the Nexus Yum Plugin is integrated into Nexus OSS proper.
Note: This post was inspired by Manfred’s post “You don’t do repository driven development? Where have you been?”. It immediately made me think of Star Trek…
When I roll up to a new client in desperate need of build help, there’s always a chance I’ll have a “Scotty moment” – a moment when I pick up the mouse and attempt to ask an Apple II to synthesize transparent Aluminum. (“Computer, bring up the repository and scan for vulnerabilities.”) If you don’t get the reference, I’ll walk you over to IMDB and point you towards the movie Star Trek IV. In Star Trek IV, James T. Kirk and company travel back in time to 1986 in a “bird of prey” to rescue a humpback whale which is being summoned by a mysterious alien probe in the year 2286. Leonard Nimoy directed Star Trek IV and it had a comedic “fish out of water” feeling to it that made it appeal to a wider audience.
Companies all over the place are trying to convert existing deployment scripts over to automated systems like Puppet and Chef. Many of the systems I’ve seen in the past few months have very complex codebases, builds that take 40 minutes to execute, and deployments that span hundreds of VM instances on public clouds like Amazon EC2 or private clouds using technologies like VMWare. Tools like Puppet and Chef are emerging as market leaders and the shift to large-scale automation is being driven by increasingly heterogeneous applications architectures and the arrival of open source “cloud APIs” such as Openstack.
In other words, everyone is scaling horizontally and everyone needs a repeatable, automated process to set up instances, deploy software, and perform tasks that were previously manual. Everyone seems to agree that the boundary between development and operations requires automation – it is time to stop wasting good operations and development talent on manual deployments. This trend is called Devops, and in this article I’m going to talk about where Nexus should fit into your automation effort.