Binary Repository Manager - Informe de análisis técnico

Autor Olivera Lucas.

Abstract

Desde el equipo de arquitectura notamos la necesidad de disponer de un Binary Repository Manager (BRM) o Repositorio de gestión de binarios. Un BRM es un espacio donde se almacenan, gestionan y comparten los binarios, artefactos, librerías, packages, etc. Los BRM públicos más conocidos pueden ser Maven, npm, nuget, entre otros. Notamos la necesidad de contar con BRM privado para poder compartir aquellas librerías comunes de la empresa, en pos de mejorar la performance de desarrollo y no tener código o módulos enteros duplicados en los distintos proyectos.

La empresa ya cuenta con un BRM denominado Baget, que se encuentra desplegado en ARO. Baget es un proyecto open source que admite packages provenientes de .Net. Pueden encontrar el repositorio en git.

Baget no cumple con los estándares de seguridad necesario para exponerlo públicamente, lo que provoca que no podamos realizar procesos de automatización, integración y despliegue continuos. Por lo que surge este análisis, donde se buscó el reemplazo adecuado.

En el presente análisis se plantean 3 candidatos. Nexus Repository, Azure Artifacts y GitHub Packages. Siendo este último el seleccionado como nuestro repositorio de artefactos.

Análisis

Para el presente análisis se tuvo en cuenta las siguientes características.

1. Seguridad
2. Integridad
3. Automatización
4. Disponibilidad
5. Preció
6. Documentación y usabilidad

Seguridad

El repositorio debe contener el nivel de seguridad que:

1. Permita exponer el repositorio
2. Administre los usuarios
3. Autenticación de usuarios
4. Integración con LDAP o Azure AD

Nexus Repository: La versión de Nexus pro permite conectarse con LDAP, por lo que es posible realizar la autenticación y autorización a través de active directory. Además posee un administrador de usuarios en el cual se permite generar usuarios y asignarle permisos específicos.

Azure Artifacts: Nativamente se integra con Azure Active Directory. Es necesario la plataforma de Azure Devops para la gestión de accesos al repositorio. Se integra nativamente con visual studio para la gestión de autenticación y autorización.

GitHub Packages: Permite conectarse con Azure Active Directory, Andreani tiene gran tiempo utilizando la integración y los procesos de alta de usuario y gestión están automatizados.

En este apartado, consideramos que la mejor opción es Azure Artifacts ya que se integra con Azure AD nativamente, pero es necesario que los usuarios sean dados de alta en Azure Devops lo cual puede significar un impacto en el costo. En segundo lugar, Github debido a que no implica un gasto extra a la empresa, los usuarios ya están dentro de su plataforma.

Integridad

En este apartado, el repositorio de artefactos debe albergar packages de distintas tecnologías. Lo que se busco en este punto es que sea compatible con las tecnologías que forman parte de la empresa.

1. Nuget
2. Maven y/o Gradle
3. NPM
4. PiP
5. Docker Registry
6. Go

Siendo las primeras tres, de esta lista, las excluyentes del análisis.

Nexus Repository: Nexus es compatible con múltiples tecnologías. Es compatible con las mencionadas en la lista y además podemos destacar Helm, R, Powershell, Conda, Ruby, entre otros.

Azure Artifacts: Azure es compatible con Nuget, Maven, Python, NPM

Por otro lado, Azure dispone de Azure Container Registry para almacenar imágenes de Docker.

GitHub Package: Al igual que Azure, GitHub ofrece un conjunto de repositorios acotado.

Docker, Ruby, npm, Maven, Gradle, Nuget.

Para esta categoría, podemos decir que el mejor es Nexus, ya que posee una amplia gama de repositorios y cumple con los requerimientos excluyentes, la segunda opción es Azure Artifacts ya que tiene la opción de guardar package universales.

Automatización

Los procesos de despliegue de las librerías deben ser compatibles con los GitHub Actions debido a que es el lugar donde se almacenarán y se ejecutarán los procesos de integración continua.

Nexus Repository: Nexus dispone de APIS para manipular sus repositorios, por lo que la carga de un package es posible si Nexus se encuentra publico y el cliente posee un api-key con permisos de escritura en el repositorio deseado. Además, dispone de pipeline predefinidos para la integración con GitHub Actions

Azure Artifacts: Azure dispone de pipeline por defecto para la integración con GitHub Actions, por lo tanto, es posible incluirlo en cualquier proceso de integración.

GitHub Package: La publicación de package con Actions es posible, además son componentes de la misma plataforma por lo que su integración es nativa.

En esta categoría, la opción ganadora es GitHub Package ya que es nativo a la plataforma de integración que tenemos por defecto en la empresa. En segundo lugar, no hay un ganador ya que ambos cumplen los requerimientos.

Disponibilidad

Para la categoría de disponibilidad necesitamos que el repositorio presente alta disponibilidad, ya que la caída de la disponibilidad significaría no poder compilar el código, lo que provocaría que los desarrolladores no puedan continuar trabajando y bloquearía la salida a producción de algún aplicativo.

Nexus Repository: Nexus dispone de high availability clustering en su versión PRO, a su vez dispone la opción de ser multi-cloud (en sus nuevos features). Cabe destacar que Nexus debe ser instalados en servidores propios, lo que significaría disponer de un partner para brindarnos soporte en los procesos de despliegue y alta disponibilidad de la herramienta.

Azure Artifacts – GitHub Package: ambos son soluciones cloud por lo que Microsoft asegura la alta disponibilidad.

En esta categoría podemos decir que la implementación de Nexus y el grado de madures que se requiere para disponibilizar la herramienta en HA, lo convierte en una opción costosa. Por otro lado, las demás herramientas al ser solución nube, el mantenimiento y la disponibilidad es garantizada por el proveedor, en este caso Microsoft.

Precio

Nexus Repository pro: $120/user/año. https://www.sonatype.com/products/pricing

Azure Artifacts: 2 GB Free, $2/ extra GB. + $6/ user/mes https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/

GitHub Packages: Con GitHub Enterprise, témenos 50GB y 100GB de transferencia de datos. $0.25/ extra GB y $0.5/ extra transfer data https://github.com/features/packages

Debido a lo que ya tenemos contratado, se puede decir que GitHub Packages es la mejor opción en esta categoría

Documentación y usabilidad

En esta categoría se busca que la herramienta sea fácil de usar y gestionar a su vez que cuente con documentación respaldatoria.

Nexus Repository: posee una interfaz UI donde además de permitir ver los repositorios, packages que posees, permite realizar todas las configuraciones necesarias de seguridad y gestión de la herramienta. Por el lado de la documentación, este cuenta con una buena documentación

Azure Artifacts: La UI de Azure Artifacts se encuentra embebida en Azure Devops, donde se nos permite ver los paquetes publicados, información de cómo conectarnos a los “feeds” y configurar políticas y permisos en los respectivos “feeds”. La documentación de la herramienta no es buena.

GitHub Packages: La UI de esta herramienta es muy limitada, cumple con la visualización de los packages, pero el resto de configuraciones se encuentran dispersas por la plataforma lo que hace un poco complicado el uso. Por otro lado, la documentación no es basta, hay pocos ejemplos y poca información de cómo funciona y como sacarle provecho.

Conclusión

Podemos concluir este análisis remarcando que las tres herramientas cumplen con todas las expectativas y categorías que se plantearon en este análisis, por lo que la decisión de una herramienta se da principalmente por valor monetario y gap de adopción. Sin embargo, consideramos que Nexus Repository es la mejor opción pensando en largo plazo, ya que es una plataforma que podemos instalar y administrar dentro de la empresa, además que ofrece diversos features que no se analizaron en estas categorías y que le da un valor agregado a la herramienta. Para finalizar el informe, se define GitHub Packages como BRM de la empresa, ya que cumple con todas las categorías analizadas y ya se encuentra adquirido por la empresa en la licencia Enterprise de GitHub