rsync es una popular utilidad de sincronización de archivos que utiliza un algoritmo eficiente para minimizar el consumo de ancho de banda. Una de las funciones comunes de rsync es implementar la creación de un sitio web en un servidor de producción remoto. Aquí se explica cómo combinar la versatilidad de rsync con la automatización proporcionada por las canalizaciones de CI de GitLab.
Ejecutores de canalización
GitLab CI admite varios tipos de ejecutores de canalización. Estos definen el entorno en el que se ejecutará su trabajo. El shell ejecutor es el predeterminado y se ejecuta sin sistema operativo en la máquina host. Permite que sus canalizaciones usen cualquier comando disponible en el host sin configuración adicional. Como las distribuciones de Linux más populares se envían con rsync instalado, es fácil familiarizarse con este enfoque.
Desafortunadamente, el shell ejecutor no proporciona un fuerte aislamiento y puede contaminar el entorno de su host con el tiempo. Una mejor alternativa es docker ejecutor, que activa un nuevo contenedor Docker para cada trabajo de CI. Todos los trabajos se ejecutan en un entorno limpio que no puede afectar al host.
El inconveniente aquí es que las imágenes base de Docker generalmente no incluyen rsync o ssh . Incluso imágenes oficiales del sistema operativo como ubuntu:latest enviar como compilaciones mínimas sin estos comandos. Esto crea una secuencia de comandos de canalización un poco más complicada para agregar las dependencias y rsync tus archivos.
Aquí le mostramos cómo agregar rsync a su canalización. Asegúrese de tener un GitLab Runner basado en Docker disponible antes de continuar. También supondremos que tiene un proyecto de GitLab que está listo para usar.
Preparándose
Necesitará un par de claves SSH disponible si utilizará rsync para conectarse a un host SSH remoto. Puede generar claves públicas y privadas ejecutando ssh-keygen -t rsa . Copie la clave pública en el servidor al que se conectará.
A continuación, copie la clave privada generada en su portapapeles:
cat ~/.ssh/id_rsa | xclip -selection c
Dirígete a tu proyecto de GitLab y haz clic en "Configuración" en la parte inferior del menú de navegación izquierdo. Haga clic en el elemento "CI/CD" en el submenú. Desplácese hacia abajo hasta la sección "Variables" en la página resultante.
Haga clic en el botón azul "Agregar variable". Asigne un nombre a su nueva variable en el campo "Clave". Estamos usando SSH_PRIVATE_KEY . Pegue su clave privada en el campo "Valor", incluido el ----BEGIN inicial y final -----END líneas.
Agregar la clave como una variable de CI le permite hacer referencia a ella en su canalización más adelante. Se agregará al agente SSH en los contenedores que cree su canalización.
Agregar su archivo de canalización
GitLab CI ejecuta trabajos basados en el contenido de un .gitlab-ci.yml archivo en su repositorio. GitLab encontrará automáticamente este archivo y ejecutará la canalización que define cuando envíe cambios a sus sucursales.
deploy:
stage: deploy
image: alpine:latest
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
Este .gitlab-ci.yml contiene un trabajo que usa rsync para sincronizar el contenido del directorio de trabajo con /var/www/html en example.com servidor. Utiliza el alpine:latest Imagen de Docker como entorno de compilación. La canalización fallará actualmente porque rsync no está incluido en la imagen de Alpine.
Instalando SSH y rsync
Alpine es una buena base para el trabajo porque es una imagen ligera con pocas dependencias. Esto reduce el uso de la red mientras GitLab extrae la imagen al comienzo del trabajo, lo que acelera su canalización. Para que rsync funcione, agregue SSH y rsync a la imagen y luego inicie el agente SSH y registre la clave privada que generó anteriormente.
deploy:
stage: deploy
image: alpine:latest
before_script:
- apk update && apk add openssh-client rsync
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
OpenSSH y rsync se instalan usando la apk de Alpine gerente de empaquetación. Se inicia el agente de autenticación SSH y se agrega su clave privada a través de ssh-add . GitLab inyecta automáticamente el SSH_PRIVATE_KEY variable de entorno con el valor que definiste en la configuración de tu proyecto. Si usó una clave diferente en la pantalla de variables de GitLab, asegúrese de ajustar su canalización en consecuencia.
Gestión de verificación de host
SSH solicita confirmación de forma interactiva la primera vez que se conecta a un nuevo host remoto. Esto es incompatible con el entorno de CI, donde no podrá ver ni responder a estas indicaciones.
Hay dos opciones disponibles para solucionar este problema:deshabilite las comprobaciones estrictas de la clave del host o registre su servidor como un host "conocido" con anticipación.
Para la primera opción, agregue la siguiente línea al before_script de su canalización :
- echo "Host *ntStrictHostKeyChecking no" >> ~/.ssh/config
Si bien esto funciona, es un riesgo potencial de seguridad. No recibiría ninguna advertencia si un atacante obtuviera el control del dominio o IP de su servidor. El uso de la verificación de clave de host le permite verificar que la identidad del control remoto es lo que espera que sea.
Puede agregar el control remoto como un host conocido de forma no interactiva conectándose a él en su propia máquina fuera de su canalización. Inspeccione su ~/.ssh/known_hosts y busque la línea que contiene la IP o el nombre de host del control remoto. Copie esta línea y use el procedimiento anterior para agregar una nueva variable de GitLab CI. Nombre esta variable SSH_HOST_KEY .
Ahora, actualice su before_script sección con la siguiente línea:
- echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts
Ahora, podrá conectarse al servidor sin recibir ningún mensaje de confirmación. Envíe su código a su repositorio de GitLab y observe cómo se completa su canalización.
Mejoras adicionales
Esta canalización es un ejemplo simple de cómo comenzar con SSH y rsync en un entorno dockerizado. Hay oportunidades para mejorar aún más el sistema al incluir los pasos de preparación en una etapa de compilación dedicada que construye una imagen de Docker que puede reutilizar entre canalizaciones.
El .gitlab-ci.yml también se beneficiaría de un mayor uso de variables. Abstracción del nombre de host del servidor remoto (example.com ), directorio (/var/www/html ), y usuario (user ) en las variables de CI de GitLab ayudaría a mantener el archivo limpio, evitaría que los navegadores de repositorios casuales vean detalles ambientales y le permitiría cambiar los valores de configuración sin editar su archivo de canalización.
Resumen
El uso de rsync en canalizaciones GitLab CI requiere una pequeña configuración manual para formar un entorno de compilación que tenga las dependencias que necesita. Debe inyectar manualmente una clave privada SSH y registrar el servidor remoto como un host conocido.
Aunque las imágenes Docker de la comunidad están disponibles que muestran SSH y rsync sobre las imágenes base populares, en última instancia, le dan menos control sobre su compilación. Está ampliando la cadena de suministro de su tubería con una imagen en la que no necesariamente puede confiar. Comenzar con una imagen base del sistema operativo y agregar lo que necesita lo ayuda a tener confianza en sus compilaciones.