nexus-operator

Table of Contents

• Nexus Operator
  • Pre Requisites
  • Quick Install
    • Openshift
    • Clean up
  • Networking
    • Use NodePort
    • Network on OpenShift
    • Network on Kubernetes 1.14
    • TLS/SSL
  • Persistence
    • Minikube
  • Service Account
  • Red Hat Certified Images

Nexus Operator

A Nexus OSS Kubernetes Operator based on Operators SDK

Pre Requisites

• kubectl installed
• Kubernetes or OpenShift cluster available (minishift, minikube or crc also supported)
• Cluster admin credentials to install the Operator

Quick Install

The installation procedure will create a Namespace named nexus and a Nexus 3.x server for you:

make install

You can then edit or customize the installation as you pleased, just run:

kubectl edit nexus

If you're running on Kubernetes, edit the Nexus resource to add a valid host for the Ingress to work.

Openshift

If you're running the Operator on Openshift (3.11 or 4.x+) it's also necessary to configure a Security Context Constraints (SCC) resource.

This is necessary because the Nexus image requires its container to be ran as UID 200. The use of default SCC resources in Openshift results in a failure when starting the pods, as seen in Issue #41.

Valid SCC resources can be found at the examples/ directory. You must associate the SCC with the ServiceAccount in use. In the commands below it is assumed you'll be using the default ServiceAccount created when deploying a new Nexus CR.

For persistent configurations:

$ oc apply -f examples/scc-persistent.yaml

For volatile configurations:

$ oc apply -f examples/scc-volatile.yaml

Note: you must choose one or the other, applying both will result in using the one applied last.

Once the SCC has been created, run:

$ oc adm policy add-scc-to-user <SCCName> -z <ServiceAccountName>

This command will bind the SCC we just created with the ServiceAccount being used to create the Pods.

If you're using a custom ServiceAccount, replace "<ServiceAccountName>" with the name of that account. If you're not using a custom ServiceAccount, the operator has created a default one which has the same name as your Nexus CR, replace "<ServiceAccountName>" with that.

In future versions the Operator will handle this for you.

Clean up

Considering that you ran the install command above, to remove the operator completely from your cluster, just run:

make uninstall

Networking

There are three flavours for exposing the Nexus server deployed with the Nexus Operator: NodePort, Route (for OpenShift) and Ingress (for Kubernetes).

Use NodePort

You can expose the Nexus server via NodePort by setting the following parameters in the CR:

apiVersion: apps.m88i.io/v1alpha1
kind: Nexus
metadata:
  name: nexus3
spec:
  (...)
  networking:
    expose: true
    exposeAs: "NodePort"
    nodePort: 31031

It's not the recommended approach, but fits whatever Kubernetes flavour you have.

Network on OpenShift

On OpenShift, the Nexus server can be exposed via Routes. Set the following parameters in the CR:

apiVersion: apps.m88i.io/v1alpha1
kind: Nexus
metadata:
  name: nexus3
spec:
  (...)
  networking:
    expose: true

Network on Kubernetes 1.14+

On Kubernetes, we leverage from an Ingress to expose the Nexus service:

apiVersion: apps.m88i.io/v1alpha1
kind: Nexus
metadata:
  name: nexus3
spec:
  (...)
  networking:
    expose: true
    exposeAs: "Ingress"
    host: "nexus.example.com"

Please note that host is a required parameter when exposing via Ingress. Just make sure that that the host resolves to your cluster.

If you're running on Minikube, take a look in the article "Set up Ingress on Minikube with the NGINX Ingress Controller"

TLS/SSL

For details about TLS configuration check out our TLS guide.

Persistence

Minikube

On Minikube the dynamic PV creation might fail. If this happens in your environment, before creating the Nexus server, create a PV with this template: examples/pv-minikube.yaml. Then give the correct permissions to the directory in Minikube VM:

$ minikube ssh
                         _             _            
            _         _ ( )           ( )           
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __  
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ sudo chown 200:200 -R /data/pv0001/

$ ls -la /data/
total 8
drwxr-xr-x  3 root root 4096 Apr 26 15:42 .
drwxr-xr-x 19 root root  500 Apr 26 20:47 ..
drwxr-xr-x  2  200  200 4096 Apr 26 15:42 pv0001

Service Account

It is possible to use a custom ServiceAccount to perform your Deployments with the Nexus Operator via:

• spec.serviceAccountName (string): ServiceAccountName is the name of the ServiceAccount used to run the Pods. If left blank, a default ServiceAccount is created with the same name as the Nexus CR.

Important: the Operator handles the creation of default resources necessary to run. If you choose to use a custom ServiceAccount be sure to also configure Role and RoleBinding resources.

Red Hat Certified Images

If you have access to Red Hat Catalog, you might change the flag spec.useRedHatImage to true. You'll have to set your Red Hat credentials in the namespace where Nexus is deployed to be able to pull the image.

In future versions the Operator will handle this step for you.