Desplegar en k8s desde GitLab CI

Índice de contenidos

• 1. Entorno
• 2. Introducción
• 3. Vamos al lío
• 4. Conclusiones

1. Entorno

Este tutorial está escrito usando el siguiente entorno:

• Hardware: Slimbook Pro 2 13.3″ (Intel Core i7, 32GB RAM)
• Sistema Operativo: LUbuntu 18.04
• Kubernetes 1.11.1
• GitLab Community Edition 11.1.4

2. Introducción

En este tutorial ya vimos los primeros pasos con GitLab CI y lo sencillo que era crear un pipeline y desplefarlo en el propio servidor a través de docker-compose; en esta ocasión vamos a ver cómo integrar GitLab con un clúster de Kubernetes para desplegar cualquier aplicación contenizada en Docker.

Para seguir el tutorial necesitas tener corriendo una instancia de GitLab y otra de Kubernetes.

3. Vamos al lío

A partir de la versión 10 de GitLab se proporciona una nueva opción en cada proyecto dentro de la sección CI/CD (Operations a partir de GitLab 11) que se llama «Kubernetes», si pinchamos sobre ella veremos algo como esto.

Pinchando en la opción «Add Kubernetes cluster», nos ofrece dos opciones: la primera crearlo en la nube de Google Cloud y la segunda, utilizar un clúster existente.

En nuestro caso vamos a utilizar el clúster que creamos en el anterior tutorial así pulsamos en «Add existing cluster», con lo que se muestra en el siguiente formulario:

A continuación describimos cada uno de ellos y el valor que tenemos que insertar:

• Kubernetes cluster name: simplemente es el nombre que le queremos dar al clúster para poder identificarlo ya que permite incluir más de uno por proyecto. Ponemos el nombre que queramos, por ejemplo, k8s
• API URL: se trata de la URL de acceso al API Kubernetes (no confundir con el acceso al dashboard de Kubernetes), será del tipo. https://api.k8s.tudominio.org
• CA Certificate: cuando creamos el clúster de Kubernetes se crea un secreto que almacena el certificado y el token de acceso. Para recuperarlos lo más sencillo es acceder al dashboard de Kubernetes y desde el namespace de default ir a la sección «Secrets». El secreto que nos interesa tiene un nombre del tipo default-token-xxxxx, al pulsar sobre él se muestra su contenido pulsando en el icono con forma de ojo. En este campo del formulario tenemos que copiar el contenido de «ca.crt» incluyendo los líneas —–BEGIN CERTIFICATE—– y —–END CERTIFICATE—–
• Token: desde el mismo secreto que el anterior encontramos el contenido de este campo dentro de «token».
• Project namespace: es un campo opcional pero si es recomendable que establezcamos un nombre, por ejemplo, el mismo nombre de proyecto. Esto no implica que se vaya a crear ese namespace en Kubernetes de forma automática; lo tendremos que crear de forma manual con el comando: $> kubectl create namespace nombre_namespace

Finalmente aplicamos los cambios pulsando en «Save changes» y ya tenemos hecha la integración entre GitLab y nuestro clúster de Kubernetes lo que nos va a proporcionar una serie de nuevas variables de entorno relacionadas que poder utilizar en nuestro pipeline.

• KUBE_URL: nos devuelve el valor introducido dentro del campo «API URL».
• KUBE_TOKEN: nos devuelve el valor introducido dentro del campo «Token».
• KUBE_NAMESPACE: si lo hemos especificado nos devuelve el valor del campo «Project namespace», si no lo calcula como –
• KUBE_CA_PEM_FILE: nos devuelve el path a un fichero que contiene la información introducida dentro del campo «CA Certificate»
• KUBECONFIG: nos devuelve el path a un fichero que contiene la información de configuración que se tiene que utilizar para poder lanzar comandos con kubectl, incluyendo el «CA Certificate».

Ahora vamos a ver cómo podemos utilizar esta integración para el despliegue de nuestras aplicaciones. Dentro del pipeline definimos un nuevo stage que se va a ejecutar con Docker a partir de una imagen de alpine, donde vamos a descargar la herramienta kubectl y la vamos a configurar con el acceso a nuestro clúster gracias a la variable KUBECONFIG. Hecho esto podemos ejecutar cualquier comando contra nuestro clúster desde la imagen de docker, lo normal será hacer la ejecución del deployment, el service y el ingress apropiados a las características de nuestra aplicación. Este podría ser un ejemplo de stage:

run:
  image: alpine:3.7
  stage: run
  environment:
    name: ${CI_COMMIT_REF_SLUG}
    url: http://${CI_COMMIT_REF_SLUG}-${CI_PROJECT_PATH_SLUG}.tudominio.org
  only:
    - /^release.*$/
    - master
    - develop
  script:
    - apk update  && apk add --no-cache curl grep
    - curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
    - chmod +x ./kubectl && mv ./kubectl /usr/local/bin/kubectl
    - mkdir -p ${HOME}/.kube
    - cat ${KUBECONFIG} > $HOME/.kube/config
    - kubectl version
    - cd manifests/
    - kubectl apply -f deployment.yaml
    - kubectl apply -f service.yaml
    - kubectl apply -f ingress.yaml
    - kubectl rollout status -f deployment.yaml
    - kubectl get all,ing -l app=${CI_COMMIT_REF_SLUG} --namespace=${CI_PROJECT_PATH_SLUG}
  tags:
    - docker

Fíjate como en este stage automáticamente creamos el entorno asociado a la rama con la que estemos trabajando y como hacemos un rollout para ver los cambios que se producen y un get final para dejar constancia en el log del resultado final del stage.

4. Conclusiones

Como ves GitLab no deja de ofrecernos mejoras y ventajas para llevar nuestros proyectos a producción en Kubernetes desde la definición del pipeline. Y recuerda que estamos usando la versión Community.

Cualquier duda o sugerencia en la zona de comentarios.

Saludos.