Desplegar GitLab para activar los pipelines CI/CD en OCI

Arquitectura

Esta arquitectura de referencia tiene dos opciones de despliegue: un despliegue independiente y un despliegue distribuido.

Autónomo (<1,000 usuarios)
La arquitectura independiente es la opción más sencilla para GitLab. Despliega todos los componentes de GitLab en una única instancia de Compute en el arrendamiento de OCI. Si necesita servir hasta 1,000 usuarios y no tiene requisitos de disponibilidad estrictos, una solución independiente con copias de seguridad frecuentes es adecuada para muchas organizaciones. Un solo arrendamiento puede alojar más de un servidor GitLab. El siguiente diagrama ilustra esta arquitectura de referencia:

Descripción de la ilustración deploy_gitlab_sa.png
Distribuido (1000-2000 usuarios)
La solución distribuida es una arquitectura de varios niveles que separa los distintos componentes de un servidor GitLab dedicado en instancias separadas, cada una asignada para realizar una tarea específica. Específicamente, la arquitectura distribuida tiene un servidor PostgreSQL dedicado, Redis Server, Gitaly Server y una instancia de supervisión Prometheus, que son todos necesarios para un despliegue de GitLab totalmente funcional. Por recomendación de GitLab, este despliegue distribuido admite aproximadamente 2,000 usuarios. Tiene un rendimiento mayor que el despliegue independiente y una mayor tolerancia a fallos debido a algunos despidos incorporados. Sin embargo, el despliegue distribuido no está muy disponible.

Descripción de la ilustración deploy_gitlab_dist.png

Estas arquitecturas tienen los siguientes componentes:

Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los demás dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región. Las instancias desplegadas como parte de estas arquitecturas de referencia de GitLab entran en un único dominio de disponibilidad.
Red virtual en la nube (VCN) y subredes
VCN es una red definida por software que se configura en una región de OCI. Las VCN se pueden segmentar en subredes, que pueden ser específicas de una región o de un dominio de disponibilidad. Las subredes específicas de cada región y de cada dominio de disponibilidad pueden coexistir en la misma VCN. Una subred puede ser pública o privada. Puede desplegar esta arquitectura de GitLab en una VCN existente que contenga una subred pública y privada o configurarla para crear una VCN con las subredes necesarias.
- Subred de host de base
  La subred de host bastion es una subred pública dedicada que contiene la instancia de host bastion. El host bastion es un componente opcional de esta arquitectura y no es necesario si GitLab está conectado directamente a Internet o subred pública.
- Subred de equilibrador de carga
  La subred equilibrador de carga es una subred pública dedicada que contiene el equilibrador de carga.
- Subred privada de GitLab
  La subred privada de GitLab contiene los dos servidores GitLab, los servidores Gitaly, Redis Server, Postgres Server, Prometheus-Grafana (monitoring) Server y cualquier ejecutor de GitLab opcional.
Equilibrador de carga
El equilibrador de carga contiene la IP orientada al público utilizada para conectarse a las instancias de GitLab. Si desea un nombre de dominio personalizado para la instancia de GitLab, registre la dirección IP del equilibrador de carga con el proveedor de DNS. El equilibrador de carga utiliza una política de comprobación de estado de robo redondo para supervisar los servidores GitLab.
Computar
Para GitLab, sólo se crea una única instancia de GitLab Server Compute. Para la arquitectura distribuida, se crean un total de ocho instancias informáticas. Cada una de estas instancias proporciona los siguientes servicios:
- Servidores GitLab
  La aplicación basada en web principal de GitLab se instala en los dos servidores GitLab. La administración de GitLab se realiza en estas instancias y el equilibrador de carga actúa como frontend.
- Servidor PostgreSQL
  Almacena información de base de datos persistente para la aplicación GitLab. Por ejemplo, los usuarios, permisos, problemas u otros metadatos se almacenan en la base de datos PostgreSQL.
- Servidor Redis
  La aplicación GitLab utiliza Redis como backend de base de datos no persistente para información de trabajo, metadatos y trabajos entrantes.
- Gitaly Servers
  El servicio Gitaly proporciona almacenamiento de archivos para repositorios Git. Todos los archivos que forman parte de un repositorio en GitLab se almacenan en los servidores Gitaly. Se crean dos instancias de Gitaly para demostrar un nivel de capacidad adicional. Puede personalizar qué servidor almacena los datos de un proyecto concreto por posición.
- Servidor PostgreSQL
  GitLab almacena información de base de datos persistente en el servidor PostgreSQL. Algunos ejemplos de datos persistentes incluyen usuarios, permisos, problemas y otros metadatos del proyecto.
- Servidor Redis
  La aplicación GitLab utiliza Redis como backend de base de datos no persistente para información de trabajos, determinados tipos de metadatos y trabajos entrantes.
- Servidor Prometheus + Grafana (supervisión)
  Prometheus + Grafana Server es un servidor de supervisión de sistemas y servicios. Recopila métricas de destinos configurados a intervalos determinados, evalúa expresiones de regla, muestra los resultados y puede disparar alertas cuando se observan condiciones especificadas.
- Corredores
  Los ejecutores de GitLab son máquinas dedicadas que trabajan con GitLab CI/CD para ejecutar trabajos en un pipeline. Normalmente se despliegan en el entorno de GitLab después de que las instancias de GitLab estén activas, en ejecución y probadas. No se crean como parte del despliegue.
Almacenamiento de objetos
El despliegue distribuido crea una serie de cubos de almacenamiento de objetos en el arrendamiento de OCI, diseñados para almacenar varios tipos de datos asociados a los proyectos de GitLab, incluidas las copias de seguridad.

Recomendaciones

Utilice las siguientes recomendaciones como punto de inicio al desplegar GitLab para activar los pipelines CI/CD en Oracle Cloud Infrastructure. Sus requisitos pueden diferir de la arquitectura descrita aquí.

Unidades de computación

Esta arquitectura utiliza una imagen del sistema operativo Oracle Linux y admite todas las familias de unidades informáticas, estándar o flexibles. GitLab recomienda los siguientes parámetros de configuración para el despliegue autónomo y distribuido:

Autónomo

Servicio

Configuración

Servidor GitLab

4 OCPU, 8-GB RAM

Runners de GitLab (N opcional)

1 OCPU, CARNERO DE 4 GB

Distribuido

Servicio

Configuración

Servidor Bastion (opcional)

1 OCPU, RAM DE 2 GB

Servidores GitLab (2)

4 OCPU, CARNERO DE 8 GB

PostgreSQL

1 OCPU, CARNERO DE 8 GB

Redis

1 OCPU, CARNERO DE 4 GB

Gitaly (1 necesario, 2 opcional)

2 OCPU, 16-GB RAM

Nodo de supervisión

1 OCPU, CARNERO DE 2 GB

Corredores de GitLab (N opcional)

1 OCPU, CARNERO DE 4 GB

GitLab recomienda estas configuraciones, pero puede personalizarlas en el momento del despliegue.

VCN
Al crear VCN y subredes, utilice bloques CIDR que no se superpongan con ninguna otra red (en OCI, su centro de datos local u otro proveedor de nube) a la que desea configurar conexiones privadas. Los bloques CIDR de VCN se pueden editar después de la creación.

Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Seguridad
Utilice Oracle Cloud Guard para supervisar y mantener la seguridad de sus recursos en OCI de forma proactiva. Cloud Guard utiliza recetas de detectores que puede definir para examinar sus recursos para detectar deficiencias de seguridad y para supervisar a los operadores y usuarios para realizar actividades de riesgo. Cuando se detecta cualquier actividad incorrecta o insegura, Cloud Guard recomienda acciones correctivas y ayuda con esas acciones, en función de las recetas de respuesta que pueda definir.

Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta definida por Oracle de políticas de seguridad que se basan en las mejores prácticas. Por ejemplo, los recursos de una zona de seguridad no deben ser accesibles desde Internet público y deben cifrarse mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, OCI valida las operaciones contra las políticas de la receta de zona de seguridad y niega las operaciones que violen cualquiera de las políticas.
Corredores
Puede desplegar ejecutores de GitLab en la misma subred privada que las instancias de GitLab existentes o en una VCN o subred dedicada.

Consideraciones

Tenga en cuenta los siguientes puntos al desplegar esta arquitectura de referencia.

Rendimiento
Todas las formas de cálculo por defecto iniciadas como parte de esta arquitectura siguen las recomendaciones proporcionadas en la documentación de GitLab. Sin embargo, si un nodo de partículas necesita más recursos, puede escalar las formas de cálculo. La arquitectura distribuida tiene un rendimiento más alto que un despliegue independiente. Las arquitecturas tienen las siguientes opciones de métricas de rendimiento esperadas.
Seguridad
Excepto para el equilibrador de carga y el host bastion, si está presente, todos los componentes de la arquitectura GitLab están en subred privada. Las instancias de Compute de la arquitectura distribuida tienen activado el firewall, con iptables activado y solo los puertos necesarios abiertos para activar la comunicación entre los nodos.
Disponibilidad
El equilibrador de carga despliega los servidores GitLab como un par y los equilibra. Todas las instancias se despliegan en un único dominio de disponibilidad. Esta arquitectura de referencia también crea varios cubos de almacenamiento de objetos para almacenar varios tipos de datos. Object Storage es un servicio regional y no está vinculado a ninguna instancia o dominio de disponibilidad de Compute específico. Puede acceder a datos desde cualquier lugar dentro o fuera del contexto de OCI, siempre que tenga conectividad a Internet y pueda acceder a uno de los puntos finales de Object Storage. Este despliegue utiliza un gateway de servicio para conectarse a los cubos de almacenamiento de objetos. Un gateway de servicio permite la conectividad a los puntos finales públicos de Object Storage desde direcciones IP privadas en subredes privadas
Copias de seguridad y restauración
El despliegue distribuido crea un cubo de Object Storage para almacenar copias de seguridad y define todos los valores de configuración necesarios para cargar datos en ese cubo. También crea un trabajo cron en la instancia primaria del servidor de GitLab, que crea copias de seguridad diarias de los datos de GitLab, carga en el cubo y almacena una copia en la máquina. El archivo gitlab-secrets.json contiene datos confidenciales y no está incluido en esta copia de seguridad. Le recomendamos que mantenga una copia del directorio /etc/gitlab o del archivo /etc/gitlab/gitlab-secrets.json en un lugar seguro que existe fuera de este despliegue por parte de un administrador. Tenga en cuenta si desea realizar copias de seguridad más frecuentes y definir políticas de retención adecuadas en el cubo de Object Storage.
```
## Run a backup everyday at 1am.
0 1 * * * sudo gitlab-backup create
 
## Run a separate backup for configuration settings (creates a tar archive in /etc/gitlab/config_backup)
0 2 * * * sudo gitlab-ctl backup-etc
```
Puede realizar una copia de seguridad no sólo de los datos de GitLab, sino de todo el servidor de GitLab. El servicio de volumen en bloque de OCI permite realizar copias de seguridad de volumen en bloque automáticamente en un programa y retenerlas en función de la política de copia de seguridad seleccionada. Para obtener más información, consulte la documentación de copias de seguridad basadas en políticas.
Costo
El costo de esta arquitectura está relacionado con cualquier infraestructura desplegada de OCI, como instancias informáticas, equilibrador de carga de red y almacenamiento de datos, además de cualquier compra de licencias de GitLab. Para obtener más información sobre el costo de los servicios de OCI, consulte la página Lista de procedimientos en la nube de Oracles.
URL pública
Puede utilizar el proveedor de DNS para asociar la dirección IP pública de la instancia de GitLab a un nombre de dominio personalizado. En la arquitectura distribuida, la URL personalizada debe estar asociada a la dirección IP pública del equilibrador de carga. Puede definir el nombre de dominio de URL externa en el momento del despliegue y, a continuación, asociar la URL a la dirección IP en el despliegue de GitLab después. Siempre puede cambiar la URL personalizada después del hecho.

Desplegar

El código Terraform para esta arquitectura de referencia está disponible como pila de ejemplo en Oracle Cloud Infrastructure Resource Manager. También puede descargar el código de GitLab y personalizarlo para adaptarlo a sus requisitos específicos.

Desplegar mediante la pila de ejemplo en Oracle Cloud Infrastructure Resource Manager:
1. Haga clic en.
  Si aún no está conectado, introduzca las credenciales de arrendamiento y usuario.
2. Seleccione la región en la que desea desplegar la pila.
3. Siga las instrucciones y peticiones de datos en pantalla para crear la pila.
4. Después de crear la pila, haga clic en Acciones de Terraform y seleccione Plan.
5. Espere a que se complete el trabajo y revise el plan.
  Para realizar cualquier cambio, vuelva a la página Detalles de Pila, haga clic en Editar Pila y realice los cambios necesarios. A continuación, vuelva a ejecutar la acción Plan.
6. Si no son necesarios otros cambios, vuelva a la página Detalles de Pila, haga clic en Acciones de Terraform y seleccione Aplicar.
Desplegar mediante el código Terraform en GitLab:
1. Vaya a GitLab.
2. Clone o descargue el repositorio en su computadora local.
3. Siga las instrucciones del documento README.

Explorar más

Obtenga más información sobre el despliegue de GitLab para activar los pipelines CI/CD en Oracle Cloud Infrastructure.

Revise estos recursos adicionales: