Nexus: An Open source Repository

Nexus is a Sonatype Artifactory repository manager [OSS]. It allows you to store, distribute, and retrieve build artifacts whenever it’s required. Using Nexus, developers can easily access and deploy build artifacts in an organization from a single location. What’s more, they can be easily distributed.

It is mostly used for hosting Apache Maven, and currently supports formats like Docker, Maven, npm, NuGet, Ruby Gems, Yum proxy/host, Apt*, R*, Raw, P2* and more.

Nexus is available in Nexus OSS and Nexus Pro versions. Nexus Pro has features like LDAP, Auth tokens, Runtime storage expansion/migration, Advanced repository health check, custom component metadata and deploy to npm and docker groups.

In my blog today, I’m going to walk you through what Nexus is made up of.

First, let’s take a look at the directory structure of Nexus.

Directory Structure:

bin: It contains Nexus startup script and related configuration files.

etc: It contains all the configuration files.

lib: It contains binary libraries.

Public: It contains public resources of the application.

System: it contains all the components and plugins.

Data Directory:

The default location of data directory is ../Sona type-work/nexus3. It includes subdirectories that contain all the components, repositories, configurations, and other data of the repository manager.

The subdirectories are:

Blobs/:

It is the default location of the blob store, provide a fully qualified path when creating a new blob store, it may not end up in this directory.

Cache/:

It contains information on currently cached Karaf bundles [Karaf can be used as a standalone container supporting wide range of applications and technologies].

Db/:

It contains the orient db databases which are the primary storage for our repository manager’s metadata.

Elastic search/:

It contains the currently configured state of Elasticsearch [Elasticsearch allows us to store, search and analyze huge volumes of data quickly].

Health-check/:

It contains cached reports from the repository health check feature.

Keystores/:

It contains the automatically generated key used to identify our repository manager.

Log/:

It contains several log files information regarding various running repository manager.log files found in this directory include:

• nexus.log: It is a main repository application log, log messages having standard log output fields like date/time, log level, class, and message.
• request.log: It is used to log http access requests to a running container manager. This log messages contain information like client host, user and HTTP request attribute including status code, bytes, and user-agent header.
• jvm.log: It contains JVM stdout, stderr and thread dump messages.
• Karaf.log: It contains messages specific to the repository manager startup. This log having a subdirectory called tasks. It contains separate, uniquely named [by date, time, and task name] log output files for each task that is run.

tmp/:

It can be used for temporary storage.

Nexus provides for the three different kinds of repositories:

Proxy:

A repository that is linked to a remote repository, Nexus configured with the Apache snapshots and central proxy repositories. Any request for a component is verified against the local content of the proxy repository, if a local component is not found the request is forwarded to the remote repository.

Hosted:

It is hosted by the repository manager and configured with the third party, releases, and snapshots.

Group:

It has its own access point and a combined repository of locally published and remotely cached components.

Now that you are familiar with what Nexus can provide, allow me to explain the benefits of Nexus.

Benefits of Nexus:

• Nexus allows us to proxy, collect, and manage our dependencies so that we are not focused constantly on collection of jars.
• We can deploy artifacts into Nexus with their version controls like snapshot in Maven.
• We need to install our artifacts by just using mvn install command, it can download all the dependencies from artifact repo. These are organized and available for all the team members.
• Nexus can be integrated with any CI/CD tool like Jenkins, Bamboo etc. Pipelines can publish and retrieve versioned apps and their dependencies.
• We can block any uploads that we don’t want thanks to Nexus.
• We can restrict access to Nexus repositories for users by roles and user permissions.

Allow me to explain further with the help of two interesting case studies.

Case study I: Deploy Maven artifacts into Nexus repo

• Developers can pull the code in to scm repository GitHub/bitbucket.
• We can use maven clean install command for creating artifacts like jar, war, and ear.
• Here, we need to integrate nexus with the maven. Whenever we can pass maven goals, it’s first read pom.xml file.
• We need to update Nexus URL details [snapshots and releases] under the distribution management section in pom.xml file and credential details need to update in the settings.xml file.
• Maven can check all the dependencies in local repository initially, if not available in local it will search in maven central repository, if not available in central it will search in remote repository [nexus] based on the details provided in pom.xml file.
• We will use a proxy server for securely uploading and pulling the artifacts from remote repository.
• We can integrate nexus with the CI/CD tools like Jenkins, bamboo etc.

Case study II: Deploy Docker images into Nexus repo

• Developers commit the code into Bitbucket repo.
• They create a repository in Nexus for docker images, while creating, select the http connector at specified port and mentioned the port number.
• They write the docker file for creating the docker images.
• They create a docker image with the docker file

docker build -t <Docker file path>

• They need to login to nexus repo with docker.

docker login <nexus repo url path>

• They match the image with repository.

docker tag <image Id or image Name> <nexus-hostname>:<repository-port>/<image>:<tag>

• They push the docker image to Nexus repo.

docker push <nexus-hostname>:<repository-port>/<image>:<tag>

Here are the steps you should follow for Nexus installation in Linux machine:

Login as a root user.

sudo su -

cd /opt

yum install tar wget -y

wget http://download.sonatype.com/nexus/3/nexus-3.15.2-01-unix.tar.gz

tar -zxvf nexus-3.15.2-01-unix.tar.gz

mv /opt/nexus-3.15.2-01 /opt/nexus

Create a Nexus user.

useradd nexus

Give the sudo access to Nexus user.

$ visudo

nexus ALL=(ALL) NOPASSWD: ALL

Change ownerships and permissions.

chown -R nexus:nexus /opt/nexus

chown -R nexus:nexus /opt/sonatype-work

chmod -R 775 /opt/nexus

chmod -R 775 /opt/sonatype-work

Open /opt/nexus/bin/nexus.rc file and uncomment run_as_user parameter and set as nexus user.

vi /opt/nexus/bin/nexus.rc

run_as_user="nexus"

Create Nexus as a service.

ln -s /opt/nexus/bin/nexus /etc/init.d/nexus

Switch to Nexus user.

su - nexus

Enable and start Nexus.

sudo systemctl enable nexus

sudo systemctl start nexus

I hope my blog has acquainted you with the workings of Nexus! Reach out to us with your feedback about this blog and visit us at Nitor Infotech to learn more about us.