Cómo Instalar GitLab Runner En Vultr Kubernetes Engine

Introducción

GitLab Runner es un sistema de software de código abierto que ejecuta trabajos de CI/CD y envía los resultados a GitLab. La aplicación del corredor está instalada y configurada en la máquina que desea usar para las compilaciones. Cada proyecto en GitLab puede tener sus propios corredores, y cada corredor es un contenedor que se puede iniciar y detener según lo necesite.

Kubernetes es un sistema de software de código abierto que automatiza la implementación, el escalado y el mantenimiento de aplicaciones en contenedores. Funciona agrupando contenedores de aplicaciones en unidades lógicas para el acceso y la gestión.

El corredor de GitLab en Kubernetes se usa para administrar proyectos de CI/CD. Este tutorial explica cómo instalar GitLab Runner en Vultr Kubernetes Engine.

requisitos previos

Para seguir este tutorial, necesita lo siguiente:

A GitLab cuenta
un desplegado Clúster Vultr Kubernetes Engine con al menos 3 nodos
los kubectl CLI instalado y configurado en su máquina
cliente timón instalado localmente en su máquina
Git instalado en su máquina

Configuración de GitLab Runner

Obtenga los detalles del corredor de GitLab. Estos son la URL del corredor y el token. El token se usa para autenticar al corredor en GitLab. En el directorio de su proyecto, obtenga los detalles de Ajustes > CI/CD > corredores página de configuración, como se muestra a continuación.

Copie la URL del corredor y el token de registro y guárdelos para una configuración posterior del corredor de GitLab.

Instale Runner en Vultr Kubernetes Engine (VKE)

Para implementar el corredor en su clúster de VKE, debe configurar el acceso al clúster. Esto se hace usando un kubeconfig expediente. El archivo kubeconfig se usa para proporcionar acceso a los servidores API de Kubernetes. es usado por kubectl y otros componentes de Kubernetes para encontrar el servidor API adecuado y autenticarse.

Obtenga el archivo kubeconfig para su clúster de VKE.
- En su cuenta Vultr, navegue hasta Productos > Kubernetes > {Su clúster} > Descripción general .
- Haga clic en el Descargar configuración botón en la parte superior derecha del tablero.

Ejecute el siguiente comando para acceder a su clúster de VKE:

                          
                            $ kubectl --kubeconfig={PATH TO THE VKE CLUSTER CONFIG FILE} get nodes

Rendimiento esperado:

                          
                            NAME                         STATUS   ROLES    AGE   VERSION

gitlab-runner-1e796f3ba099   Ready    <none>   18d   v1.24.4

gitlab-runner-4c11d4f0a353   Ready    <none>   18d   v1.24.4

gitlab-runner-4ca2d1cacafb   Ready    <none>   18d   v1.24.4

Cree un espacio de nombres llamado gitlab-runner usando kubectl como se muestra a continuación:
```
                          
                            $ kubectl --kubeconfig={PATH TO THE VKE CLUSTER CONFIG FILE} create namespace gitlab

                          
                        
```
Se utiliza un espacio de nombres para aislar recursos dentro de un único clúster de Kubernetes. Para example, puede usar espacios de nombres para implementar varias aplicaciones en el mismo clúster sin interferir entre sí. Esto ayuda con el mantenimiento y futuras actualizaciones.

Obtenga una copia del gráfico de Helm de GitLab Runner ejecutando el siguiente comando:

                          
                            git clone https://gitlab.com/gitlab-org/charts/gitlab-runner.git

O bien, ejecute el siguiente comando si está utilizando una clave ssh.

                          
                            git clone [email protected]:gitlab-org/charts/gitlab-runner.git

Navegue al repositorio clonado y configure su GitLab Runner en el values.yaml archivo de la siguiente manera:

                          
                            ## GitLab Runner Image



image: registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v15.3.0



## Specify a imagePullPolicy for the main runner deployment



imagePullPolicy: IfNotPresent



## Timeout, in seconds, for liveness and readiness probes of a runner pod.

probeTimeoutSeconds: 300



## The GitLab Server URL (with protocol) that want to register the runner against

##

gitlabUrl: https://gitlab.com/



## The Registration Token for adding new Runners to the GitLab Server. 

##

runnerRegistrationToken: "Token"

## For RBAC support:

rbac:

  create: true



  ##

  rules:

   - resources: ["configmaps", "pods", "pods/attach", "secrets", "services"]

     verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]

   - apiGroups: [""]

     resources: ["pods/exec"]

     verbs: ["create", "patch", "delete"]



## Configuration for the Pods that the runner launches for each new job

##

runners:



  config: |

    [[runners]]

      [runners.kubernetes]

        namespace = "{{.Release.Namespace}}"

        image = "
                            
                              ubuntu
                            
                            :16.04"

NOTA para evitar el Readiness probe failed error, configure el templatesdeployment.yaml archivo de la siguiente manera:

                          
                              livenessProbe:

      ...

      initialDelaySeconds: 300

      ...

  readinessProbe:

      ...

      initialDelaySeconds: 300

      ...

Después de configurar Helm Chart, implemente el corredor con el siguiente comando:

                          
                            helm --kubeconfig={PATH_TO_VKE_CLUSTER_CONFIG FILE} install --namespace <NAMESPACE> gitlab-runner -f <PATH_TO_CONFIG_VALUES_FILE>  gitlab/gitlab-runner

Rendimiento esperado:

                          
                            NAME: gitlab-runner

LAST DEPLOYED: Thu Nov 17 17:22:08 2022

NAMESPACE: gitlab

STATUS: deployed

REVISION: 1

TEST SUITE: None

NOTES:

Your GitLab Runner should now be registered against the GitLab instance reachable at: "https://gitlab.com/"



Runner namespace "gitlab" was found in runners.config template.

Dónde:

<NAMESPACE> es el espacio de nombres de Kubernetes.
<PATH_TO_CONFIG_VALUES_FILE> es la ruta al gráfico de timón. En este caso, *.tgz expediente.

Verifique el estado del pod o la implementación ejecutando el siguiente comando:

                          
                            kubectl --kubeconfig={PATH_TO_VKE_CLUSTER_CONFIG FILE} describe pods gitlab-runner --namespace=<NAMESPACE>

Rendimiento esperado:

                          
                            ...

Events:

  Type    Reason     Age   From               Message

  ----    ------     ----  ----               -------

  Normal  Scheduled  30s   default-scheduler  Successfully assigned gitlab-b/gitlab-runner-85d94848d7-zs5q9 to gitlab-runner-4c11d4f0a353

  Normal  Pulling    30s   kubelet            Pulling image "registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v15.3.0"

  Normal  Pulled     25s   kubelet            Successfully pulled image "registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v15.3.0" in 4.909922707s

  Normal  Created    25s   kubelet            Created container gitlab-runner

  Normal  Started    25s   kubelet            Started container gitlab-runner

Para comprobar si se han iniciado los pods, vaya a GitLab bajo los corredores de GitLab registrados. El corredor se mostrará como se muestra en la siguiente figura.

Conclusión

Ha terminado de instalar GitLab Runner en el clúster Vultr Kubernetes Engine (VKE) mediante Helm Chart. Ahora puede administrar sus proyectos de CD/CI utilizando el corredor que acaba de instalar.

Título del artículo Nombre (opcional) Correo electrónico (opcional) Descripción

Enviar sugerencia