Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Cloud Dish: Provisioning Nexus Repository Manager and Nexus IQ Server

DZone's Guide to

The Cloud Dish: Provisioning Nexus Repository Manager and Nexus IQ Server

Read on to learn how one dev team was able to create reusable cookbooks with Chef that could be used to install and configure their applications easily.

· Cloud Zone
Free Resource

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

Joseph and Christian - The Cloud Dish

At my company, Sonatype, our Integrations team was tasked with developing reference deployments of Nexus Repository Manager and Nexus IQ Server as part of our cloud initiative. The first platforms we were to create deployments for included AWS and Docker.

We started with AWS and decided to leverage CloudFormation to create the deployments. CloudFormation templates are great, but we soon discovered that a single template can get a little unwieldy when configuring a VPC, Blobstore, and other resources along with the application. To modularize our templates, we broke them into Stacks. This helped quite a bit.

As we began to fill out the Application Stack, things became unwieldy again. Installing and configuring the Nexus Repository Manager in the “User-Data” portion of our Application Stack was extremely complex and very unreadable. Installing AWS tools, Java, and Nexus Repository Manager along with creating directories and writing several configuration files via CloudFormation bash strings was error-prone and not maintainable. And, we had to wait several minutes for a CloudFormation Stack to fail to get feedback, make corrections, then try again.

Developing installation scripts in this manner was very cumbersome, time-consuming, and produced quite a few headaches. We were not looking forward to doing the same on other platforms, using their specific syntax. We needed a better solution.

Introducing Chef

One of our engineers, Christian Fernau (co-author of this post), had experience with Chef and suggested it as a solution to the problem. Christian explained that we would be able to simplify our deployments with one reusable cookbook for each application and install it across many platforms, minimizing duplication, by simply bootstrapping chef-solo to run the cookbook recipe, then uninstalling chef after it was done with the installation and configuration. Write once, install anywhere.

An added benefit of this approach is the ability to test our cookbooks using Chef’s Test Kitchen.

Developing the Chef Nexus Repository Manager Cookbook

Being a noob, Chef turned out to be easy to learn. Chef recipes are concise and easy to read and understand. There are great online tutorials on chef.io and there are existing recipes in the Chef Supermarket for many of the tasks we needed to perform.

Installing the ChefDK on our workstations included the Test Kitchen and many of tools needed to create, package, and test cookbooks. The Test Kitchen can be configured to run different test cases on the various platforms we wish to support. This allowed us to develop our installation scripts locally while practicing TDD to write our recipes. Developing locally with a test-driven approach, we were able to quicken our pace while increasing reliability.

Once we were satisfied that our cookbook installed and configured our application as desired, we were ready to bake it into our CloudFormation Application Stack.

Our New Application Stack Template

Leveraging our new Nexus Repository Manager cookbook, the CloudFormation Application Stack template shrunk dramatically. The Application Stack template now consists only of AWS specifics to launch our instances with a small portion dedicated to bootstrapping chef and running our Nexus Repository Manager cookbook recipe.

Write Once, Install Anywhere

To prove out of our “write once, install anywhere” theory, we moved on to creating a Docker image of the Nexus Repository Manager. Leveraging our new Nexus Repository Manager cookbook enabled us to reduce our Dockerfile to mainly ENV variables, eliminating the bash scripts, with a small portion dedicated to simply installing Chef, running the cookbook recipe, then removing Chef. InstallingChef then removing it when it completed the installation and configuration of the Nexus Repository Manager negated any change to the Docker image size.

With our theory proven, we applied the same techniques to Nexus IQ Server, creating Chef Nexus IQ Server cookbook recipes that we baked into CloudFormation templates and Dockerfiles, to create AWS and Docker deployments of Nexus IQ Server.

Parting Thoughts

Leveraging Chef to install Nexus Repository Manager and Nexus IQ Server worked out as promised. We were able to create reusable cookbooks that can be used to install and configure Nexus Repository Manager and Nexus IQ Server with little more than bootstrapping Chef and running our installation recipes.

Being able to develop our installation scripts locally allowed us to quicken our pace while increasing reliability with a fairly low learning curve.

With our new cookbooks in hand, we will soon be installing our applications on other platforms with minimal effort, duplication, and headache.

Our Chef Nexus Repository Manager and Chef Nexus IQ Server cookbooks have been open sourced to allow the Nexus community to get cooking with of our recipes.

This article was co-authored by Joseph Cava and Christian Fernau.

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

Topics:
deployments ,cloud ,chef ,docker

Published at DZone with permission of Derek Weeks, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}