Nexus OSS – Introducción e instalación en Ubuntu 22

18/02/2024 / Linux

Nexus es quizás el principal repositorio de artefactos (ej: APT, Composer, Conan, CPAN, Docker, ELPA, Git LFS, Go, Helm, Maven, npm, NuGet, p2, PyPi, R, Raw, RubyGems, o Yum), disponible en versión gratuita Open Source (Nexus OSS) y versión profesional de pago (Nexus PRO). Además, Nexus nos ofrece la posibilidad de crear repositorios Proxy (remotos) así como grupos de repositorios, gestión del almacenamiento, autenticación y autorización, y muchas opciones más para facilitar su administración. En este Post te cuento cómo instalar Nexus OSS 3.43.0 sobre Ubuntu Server 22 LTS, así como algún otro detalle de Nexus para que empieces a trabajar con él.

Instalación de Nexus OSS 3.43.0 sobre Ubuntu Server 22 LTS

Partimos de una máquina virtual con Ubuntu Server 22 LTS instalado, y un disco secundario montado sobre /opt/nexus. La recomendación es de un mínimo de 2 Cores y 4 GB de RAM, aunque para un entorno de laboratorio y pruebas, con menos recursos funcionará también.

Crearemos un usuario para la cuenta de servicio de Nexus. Nos aseguraremos de que utiliza la shell /bin/bash (comprobar en /etc/passwd).

sudo useradd -m nexus

Instalaremos la máquina virtual de Java, en particular Nexus requiere Java 8 JRE. En el siguiente ejemplo, se muestra cómo instalar la versión de Oracle Java 8 JRE (también podemos utilizar OpenJDK), que descargaremos desde: Java – Descargar JRE

sudo mkdir /opt/jdk
sudo tar -zxf jre-8u351-linux-x64.tar.gz -C /opt/jdk
sudo update-alternatives --install /usr/bin/java java /opt/jdk/jre1.8.0_351/bin/java 100
java -version

El siguiente paso es descargar e instalar Nexus. En nuestro caso, vamos a instalar la versión 3.43.0 de Nexus OSS sobre /opt/nexus/3.43.0, pero crearemos un enlace desde /opt/nexus/current, que nos facilitará posteriores subidas de versión de Nexus. Para más info: Sonatype – Nexus Repository Manager 3 Download

cd /tmp
wget http://download.sonatype.com/nexus/3/nexus-3.43.0-01-unix.tar.gz
tar -xvzpf nexus-3.43.0-01-unix.tar.gz 

sudo mkdir -p /opt/nexus/3.43.0
sudo mv nexus-3.43.0-01/* /opt/nexus/3.43.0/
sudo mv nexus-3.43.0-01/.install4j/ /opt/nexus/3.43.0/
sudo ln -s /opt/nexus/3.43.0/ /opt/nexus/current

sudo chown -R nexus:nexus /opt/nexus/

Iniciaremos sesión con el usuario nexus, y configuraremos en su perfil (~/.bash_profile) la variable NEXUS_HOME que la añadiremos al PATH. Cargaremos los cambios (con source), y probaremos a arrancar Nexus.

sudo su - nexus
vi ~/.bash_profile

export NEXUS_HOME=/opt/nexus/current
export PATH=$PATH:$NEXUS_HOME/bin

source ~/.bash_profile
nexus start
nexus status
nexus stop

exit

Si nos encontramos con algún error, podemos buscar más detalle en los siguientes logs:

less /opt/nexus/sonatype-work/nexus3/log/nexus.log

Crearemos el script e inicio de systemd (nexus.service).

sudo vi /etc/systemd/system/nexus.service

Incluiremos el siguiente contenido en su interior, y guardaremos los cambios.

[Unit]
Description=nexus service
After=network.target

[Service]
Type=forking
LimitNOFILE=65536
ExecStart=/opt/nexus/current/bin/nexus start
ExecStop=/opt/nexus/current/bin/nexus stop
User=nexus
Restart=on-abort 

[Install]
WantedBy=multi-user.target

Configuraremos el servicio/demonio de Nexus para que arranque al inicio (con el arranque del sistema), y lo arrancaremos manualmente para comprobar que está todo OK:

sudo systemctl daemon-reload
sudo systemctl enable nexus.service

sudo service nexus start

Realizado esto, accederemos a Nexus con un navegador y nos conectaremos con el usuario admin para cambiar su contraseña. Para ello, hay que tener en cuenta que Nexus por defecto escucha en el puerto tcp-8081, y que la contraseña del usuario admin se genera de forma aleatoria durante la instalación, por lo que deberemos recuperarla para poder entrar (en la siguiente pantalla captura se muestra cómo Nexus indica el fichero que contiene la password de admin).

Lo siguiente que vamos a hacer es configurar un NGINX como Proxy inverso, escuchando en el puerto tcp-80 (también se podría configurar con HTTPS). Para ello, lo primero es instalar el NGINX.

sudo apt update && sudo apt install nginx -y

Creamos el fichero de configuración de NGINX para Nexus.

sudo vi /etc/nginx/sites-available/nexus

Este sería su contenido.

server {
   listen        80 default_server;

   client_max_body_size 1G;

   location / { 
      proxy_pass http://127.0.0.1:8081/;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

Creamos un enlace simbólico para habilitar la nueva configuración que acabamos de crear, y se borra el default.

sudo ln -s /etc/nginx/sites-available/nexus /etc/nginx/sites-enabled/nexus
sudo rm /etc/nginx/sites-enabled/default

Para finalizar habilitamos el servicio de NGINX y lo reiniciamos.

sudo systemctl enable nginx
sudo systemctl restart nginx
sudo systemctl status nginx

Con esto habremos conseguido Instalar Nexus OSS 3.43.0 sobre Ubuntu Server 22 LTS con un NGINX como Proxy inverso escuchando sobre HTTP (tcp-80). Para más información:

Conceptos básicos de Nexus

En Nexus podemos crear repositorios, para nuestros artefactos. Cada repositorio que creeemos, será de un tipo (ej: PyPi), que seleccionaremos en el momento de la creación, además de que pueden ser Hosted, Proxy, o Group, como comentamos más adelante. Importante, podemos dar permisos diferentes sobre cada repo, no sólo que sean repos públicos o privados, sino también permisos más granulares y en función de qué usuarios.

Además, en Nexus podemos crear almacenamientos (Blob Storage) que básicamente consiste seleccionar un directorio del Filesystem (también podría ser un almacenamiento remoto S3) que posteriormente podremos asociar a uno (o varios) repositorios, lo que nos resultará de ayuda en el futuro para diferentes tareas de mantenimiento, por ejemplo, cuando tengamos un problema de espacio en disco.

Lo habitual cuando necesitemos un repo para almacenar nuestros artefactos, como regla general, suele ser lo siguiente:

  • Crear un almacenamiento para cada repo que necesitemos. Podemos utilizar el mismo nombre para el almacenamiento y el repo, y que así sea más sencillo de administrar.
  • Crear un repo Hosted, del tipo que necesitemos (ej: PyPi para librerías Python), donde subiremos y se almacenarán nuestras librerías. Lo suyo es que este repo sea privado, y sólo se puedan subir librerías mediante procesos de CI/CD, por ejemplo, con una Pipeline de Jenkins.
  • Crear un repo Proxy, del tipo que necesitemos (ej: PyPi para librerías Python), que apunte a los repos remotos públicos. Este repo, será privado, y permitirá resolver artefactos (ej: librerías) de terceros.
  • Crear un repo Group, del tipo que necesitemos (ej: PyPi para librerías Python), que agrupe o incluye los dos repos que acabamos de crear, el Hosted y el Proxy. Este repo podría ser público (si hablamos de un entorno de red acotado y seguro, claro), y sería del que los usuarios y procesos se descargan las librerías (se suben al Hosted, y se descargan del Group). Esto es muy útil, primero poque apuntando a un único repo, podemos resolver tanto las librerías que hemos subido para compartir, como también las dependencias que puedan tener de librerías de otros repos (públicos o no). Pero además, da mucha flexibilidad, pensando en futuros procesos de migración. Por ejemplo, si queremos migrar a otro servidor Nexus, podemos copiar el repo Hosted al nuevo servidor Nexus, y cuando esté, simplemente sustituir el repo Hosted por uno Proxy, hasta que finalmente lo podamos eliminar. Pero como este, hay otros muchos casos que nos podemos encontrar, y en los que esta organización nos será de gran ayuda.

Otro detalle importante de los repos, es si permitimos sobrescribir (redeploy) los artefactos. En el caso de Producción, es fundamental que no se permita sobrescribir artefactos, ya que da lugar a situaciones en las que algunos usuarios o servidores podrían tener una copia antigua de una versión, y otros una copia más actualizada de la misma versión, y en esos escenarios depurar errores es una auténtica locura. Podemos aceptar permitir sobrescribir (redeploy) en entornos previos, pero en Producción es un riesgo alto.

Podemos crear Roles, y asignarles Privilegios, teniendo en cuenta que hay Privilegios asociados a un repo en particular, y otros más globales asociados a todos los repos de una misma tecnología (ej: PyPi). Luego, podemos crear usuarios y asignarles uno o varios Roles.

Con estas directrices, ya podríamos crear nuestros repositorios en Nexus, y empezar a utilizarlos. Podremos subir artefactos desde la propia Web de Nexus, con Scripts, con herramientas de terceros, etc., igualmente para descargarlos. En general es bastante sencillo e intuitivo.

Despedida y Cierre

Hasta aquí llega este Post de Nexus, una herramienta fundamental en muchos stacks de CI/CD de muchas compañías, pero también para otros propoósitos, como repositorios Proxy de Python, R, APT, o como Registro de imágenes Docker.

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.