Nexus Repository Manager. This article describes how to use and install the Nexus Repository Manager.
What is a Repository Manager
An repository manager allows to store and retrieve build artifacts. The most popular examples for repository manager are Maven Central Repository and jcenter at Bintray, which you can use to retrieve your dependencies for a Maven build.
What is Nexus?
A Nexus installation brings you such a repository for your company. So you can host your own repositories, but also use Nexus as a proxy for public repositories. With such a proxy the time to receive an artifact is reduced and it saves bandwidth. Nexus allows you to host your private build artifacts. Nexus is available as commercial and Open Source distribution.
Installation of Nexus
In order to install the open source version of Nexus you need to visit Nexus OSS and download the TGZ version or the ZIP version. Currently the latest version is 3.5.0-02.
In order to extract the archive use
# tar -xvf latest-unix.tar.gz
To start Nexus, after extracting, the nexus script must be executed with a start parameter in the nexus folder:
# cd /NEXUS_FOLDER/nexus/bin/ # ./nexus start
And in case you want to stop Nexus you just have to write stop instead of start:
# cd /NEXUS_FOLDER/nexus/bin # ./nexus stop
Configuration of Nexus
Once the nexus repository manager has been started, its web interface can be accessed under this URL:
http://localhost:8081/nexus/
The Nexus contains some repositories by default:
User Settings
The login can be found in the top right corner. The default user is admin and the password is admin123.
After logging in the credentials can be changed in the profile settings.
Creating a repository
We want to have a separate repository for our p2 artifacts. This can be created like this:
- Login to the nexus http://localhost:8081/nexus/
with User admin and password admin123.
- Click on Repositories on the left hand side.
- Select Add.. ▸ Hosted Repository and use the following data:
Example: Configuring Nexus as a Docker repo
What we will do:
– create a private (hosted) repository for our own images
– create a proxy repository pointing to Docker Hub
– create a group repository to provide all the above repos under a single URL
I suggest you to create a new blob store for each new repo you want to create. That way, the data for every repo will be in a different folder in /nexus-data (inside the Docker container). But this is not mandatory for it to work.
By default, the Docker client communicates with the repo using HTTPS. In my use case I had to configure it with HTTP, because we didn’t have the certificate nor the knowledge on how to obtain it.
Important to notice: the Docker repo requires 2 different ports. We are going to use 8082 for pull from the proxy repo and 8083 for pull and push to the private repo.
I had some problems with slightly older versions of Docker, so I strongly suggesting you to start with the version that I’ve tested with, that is 1.12.3.
private repo
A repository for Docker images that your team creates.
Create a new Docker (hosted) repository and configure it like:
proxy repo
A repository that proxies everything you download from the official registry, Docker Hub. Next time you download the same dependency; it will be cached in your Nexus.
Create a new Docker (proxy) repository and configure it like:
group repo
This will group all the above repos and provide you a single URL to configure your clients to download from to.
Create a new Docker (group) repository and configure it like:
You can create as many repos as you need and group them all in the group repo.
This step is actually optional to use Nexus 3 as a Docker repository, because we can stick to pulling and pushing to the proxy and hosted repositories as will be discussed later.
Configuring your clients and projects to use your Nexus repos
To interact with your repo, the first thing is to configure the Docker daemon in your machine to accept working with HTTP instead of HTTPS.
How exactly to do this config depends on your operating system, so you should check dockerd documentation. On RHEL I did it putting this content in /etc/docker/daemon.json:
{
 "insecure-registries": [
   "your-repo:8082",
   "your-repo:8083"
 ],
 "disable-legacy-registry": true
}
You have to restart the daemon
# systemctl restart docker
Now we have to authenticate your machine to the repo with:
# docker login -u admin -p admin123 your-repo:8082 # docker login -u admin -p admin123 your-repo:8083
This will create an entry in ~/.docker/config.json:
{Â Â Â Â Â Â Â
"auths": {
              "your-repo:8082": {
                     "auth": "JNWSDHBehfb2WcSwW+"
              },
              "your-repo:8083": {
                      "auth": "JNWSDHBehfb2WcSwW+"
              }
}
To pull images from your repo, use (notice port 8082 being used):
# docker pull your-repo:8082/httpd:2.4-alpine
To push your own images to your repo, you have to tag the image with a tag that points to the repo. This is strange to me, since I was trying to think about Docker tags the same way I do about Git tags, but they seem be somewhat different (notice port 8083 being used):
# docker tag your-own-image:1 your-repo:8083/your-own-image:1 # docker push your-repo:8083/your-own-image:1
To pull your own images from the repo, you can use:
# docker tag your-own-image:1 your-repo:8082/your-own-image:1
or
# docker tag your-own-image:1 your-repo:8083/your-own-image:1
Both ports will work. I suspect that is because using port 8083 will connect directly to the hosted repo, whilst using port 8082 will connect to the group repo, which contains the hosted repo. I suggest you to stick to port 8083 to avoid duplicate images in your machines. If you chose to stick with port 8083 to pull your own images, you probably could skip creating the group repo, if you prefer.
