Resources Blog Nexus in OpenShift

Nexus in OpenShift

Ever since we got the Nexus Repository Manager certified for use in OpenShift I get a lot of questions about what that means and how to use it. To that end I wanted to share how I have been dipping my own toes into this water to better understand how to answer these questions myself.

The first thing to understand about OpenShift is that, in a nutshell, it's enterprise Kubernetes. So I was excited when I learned about Minishift! Minishift is an open source application forked from minikube and provides is a VM that acts as a single node cluster for OpenShift development. I hit a few bumps along the way to getting minishift running so I thought I'd write a blog that might spare others some of the lessons I learned the hard way.

First, the easiest way to install minishift is from a package manager! I originally followed the instructions and only after having dug deeper into the documentation trying to make things work did I even come across this info. I'm on a Mac and I use Homebrew so I'll show that but if you're on a Linux box it should translate well enough.

brew cask install minishift

That wasn't so hard, why could't the instruction just say that up front? Ok, so maybe some of that was my impetuousness, had I followed the right links this much is pretty clear. All excited I fired up minishift to try the quickstart page to prove things were working. But there is an expectation that the command line tool installed, doh! Back to Homebrew.

brew install openshift-cli

Ok, so now I have everything I need and can get through the quickstart page! Now to start playing with Nexus. For this, my impetuousness came out again and my eyes got big as I found this Openshift Demos project on Github. Naturally I went straight for the CI/CD Demo as it is a complete, modern, example of how containers are built, tested and deployed and looks like this:

The readme file say you need 8GB of memory to run this so I stopped my minishift environment and restarted it (after shutting most everything else down to free up memory) like this:

minishift start --cpus 2 --memory 8GB

It's important to follow the setup instructions to get thingsd configured and pre-populated which is coincidentally when I found the right page on how to install minishift. Here they are for convenience.

minishift addons enable xpaas oc login $(minishift ip):8443 -u developer 

Pre-pull the images to make sure the deployments go faster:

minishift ssh docker pull openshiftdemos/nexus:2.13.0-01 minishift ssh docker pull openshiftdemos/gogs:0.11.29 minishift ssh docker pull openshiftdemos/sonarqube:6.5 minishift ssh docker pull openshift/jenkins-2-centos7 minishift ssh docker pull openshift/jenkins-slave-maven-centos7 minishift ssh docker pull

Now, we can follow the steps to prep the environment and see the power of kubernetes as it spins everything up and wires it together.

oc new-project dev --display-name="Tasks - Dev" oc new-project stage --display-name="Tasks - Stage" oc new-project cicd --display-name="CI/CD" 

Jenkins needs to access OpenShift API to discover slave images as well accessing container images. Grant Jenkins service account enough privileges to invoke OpenShift API for the created projects:

oc policy add-role-to-user edit system:serviceaccount:cicd:jenkins -n dev

oc policy add-role-to-user edit system:serviceaccount:cicd:jenkins -n stage

Clone down the github repo and cd into the directory so we can run the last command to see the magic.

oc process -f cicd-template.yaml | oc create -f - -n cicd

Now you have Git, SonarQube, Nexus RM all running on a container platform doing builds in Jenkins slaves that are themselves container images. There is a lot to dissect and learn from in here all while you become familiar with an OpenShift like environment.

It's worth pointing out that when your Jenkins slave is in a container it never has a pre-populated .m2 folder for maven builds which is just one reason why it is so important to have Nexus doing the caching to keep the builds fast.

It's still nexus 2 for now and not our certified Nexus 3 container but I've been in contact with the project maintainer and we've agreed to collaborate on bring it up to a Nexus 3 image. I also intend to extend the test phase to include the a lifecycle scan in a future blog post so stay tuned.

Picture of Curtis Yanko

Written by Curtis Yanko

Curtis Yanko is a Sr Principal Architect at Sonatype and a DevOps coach/evangelist. Prior to coming to Sonatype Curtis started the DevOps Center of Enablement at a Fortune 100 insurance company and chaired a Open Source Governance Committee. When he isn’t working with customers and partners on how to build security and governance into modern CI/CD pipelines he can be found raising service dogs or out playing ultimate frisbee during his lunch hour. Curtis is currently working on building strategic technical partnerships to help solve for the rugged devops tool chain.