3 estrategias para implementaciones de producción automatizadas con Docker

Docker es una herramienta de desarrollo popular, ya que simplifica el inicio de instancias aisladas de su aplicación con una configuración reproducible. También se puede utilizar en producción, donde garantiza que las implementaciones en vivo sean idénticas a su entorno de desarrollo.

Poner un contenedor en producción no siempre es tan sencillo como ejecutar docker run en su máquina local. No es una gran idea enviar manualmente imágenes a un registro, conectarse a un host Docker remoto e iniciar sus contenedores. Esto depende de la intervención humana, por lo que requiere mucho tiempo y es propenso a errores.

En esta guía, veremos tres estrategias diferentes que puede usar para facilitar la automatización de las implementaciones de Docker y mantener una configuración uniforme. Estos enfoques se pueden programar como parte de una canalización de CI para iniciar nuevos contenedores cada vez que cambie su código. Deberá crear sus imágenes de Docker y enviarlas a un registro como primera etapa de su secuencia de comandos, luego use una de las técnicas a continuación para extraer la imagen e iniciar contenedores en su entorno de producción.

1. Redacción de Docker sobre SSH

Docker Compose le permite iniciar varios contenedores con un solo comando. Además, Compose se configura a través de un archivo YAML que le ayuda a cambiar la versión y garantiza implementaciones reproducibles.

Es posible que ya haya utilizado Compose como herramienta de desarrollo local. Debe crear un docker-compose.yml archivo en su directorio de trabajo, luego agregue uno o más services que definen los contenedores para empezar:

version: 3
services:
  app:
    image: example.com/app:latest
    ports:
      - 80:80
  database:
    image: mysql:8.0
    expose:
      - 3306

Una vez que tenga un archivo Compose, use docker-compose up -d comando para lanzar sus contenedores. Si modifica el archivo, repita el comando para aplicar sus cambios. Compose actualizará o reemplazará los contenedores para lograr el nuevo estado declarado.

Agregando el --pull flag indica a Compose que intente obtener imágenes actualizadas antes de iniciar los contenedores. También puede usar --force-recreate para forzar la creación de nuevos contenedores, incluso si su configuración subyacente no ha cambiado.

¿Cómo se relaciona todo esto con las implementaciones de producción? Significa que puede usar Compose como parte de su canalización de CI para iniciar sin esfuerzo contenedores que satisfagan el estado que declara en su docker-compose.yml expediente. Ejecutando docker-compose up -d --pull en cada tubería le dará un conjunto de contenedores, cada uno de los cuales ejecuta la última versión de su imagen.

Hay varias formas de implementar este método. La ruta más simple y segura es instalar Docker y Compose en su host de producción y luego conectarse a través de SSH. Deberá usar la configuración de su proveedor de CI para almacenar las credenciales de SSH como variables accesibles para su canalización. Luego configuraría el cliente SSH en su tubería, copiaría docker-compose.yml archivo a su host remoto y ejecute el  docker-compose up comando.

Aquí hay una secuencia de comandos de muestra:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo $SSH_PRIVATE_KEY | ssh-add -
echo $SSH_HOST_KEY > ~/.ssh/known_hosts
scp docker-compose.yml:[email protected]:/home/ci-user/docker-compose.yml
ssh -t [email protected] docker-compose up -d

Alternativamente, podría usar contextos de Docker para ejecutar el binario Compose localmente, dentro del entorno de su canalización. Esto requeriría que expusiera el socket de Docker en su host remoto; como esto puede ser un riesgo para la seguridad, el enfoque generalmente es menos favorable en situaciones en las que también se podría usar SSH.

Si sigue este método, tendrá que instalar Docker y Compose en el host que ejecuta sus canalizaciones. Dentro de su secuencia de comandos de canalización, se registraría y seleccionaría un contexto de Docker que apunte a su host de producción remoto. Los detalles de la conexión deberán proporcionarse como variables establecidas en el panel de configuración de su proveedor de CI. Con el contexto seleccionado, ejecutaría docker-compose up -d en el entorno de su canalización, pero vea el comando ejecutado contra el servidor remoto.

2. Uso de una plataforma como servicio (PaaS)

La adopción de una oferta de plataforma como servicio (PaaS) es otro enfoque para ejecutar contenedores Docker en producción. Puede alojar el suyo propio con soluciones como Dokku o elegir una oferta alojada como Amazon ECS, DigitalOcean App Platform o Heroku.

Una PaaS abstrae la complejidad de crear imágenes, mantener configuraciones detalladas y aprovisionar sus propios hosts de Docker. Puede usar Git para enviar directamente su repositorio a la plataforma o ejecutar un comando CLI para cargar sus cambios. PaaS maneja la creación de contenedores a partir de sus activos de origen, Dockerfiles o archivos de configuración específicos de la plataforma.

Las soluciones PaaS son una excelente manera de conectarse rápidamente con una interacción práctica mínima de Docker. Son fáciles de integrar en su canalización de CI y la mayoría de los principales proveedores ofrecen scripts de muestra para que pueda comenzar. Sin embargo, es posible superar una PaaS, lo que podría significar que debe repensar su infraestructura en el futuro.

Los pasos para automatizar la implementación en la plataforma elegida variarán según el proveedor. Si está utilizando Dokku o un PaaS similar con integración de Git, su secuencia de comandos de CI podría ser tan simple como dos líneas:

git remote add dokku [email protected]:app-name
git push dokku master

El script agrega su servidor Dokku como un control remoto de Git y aumenta el contenido del repositorio. Dokku creará automáticamente una imagen a partir de su Dockerfile e iniciar instancias de contenedor. Deberá agregar la clave pública SSH de su servidor CI a Dokku para que esto funcione; de lo contrario, su script de CI no podrá autenticarse en la plataforma.

3. Orquestación con Kubernetes/Docker Swarm

Podría decirse que el uso de un orquestador como Kubernetes o Docker Swarm es la forma más común de ejecutar instancias de contenedores en vivo. Estas herramientas están diseñadas específicamente para implementar y escalar contenedores en entornos de producción.

Los orquestadores eliminan las complejidades de la gestión de la infraestructura, lo que le permite concentrarse en su aplicación y sus componentes. De manera similar a Docker Compose, adoptan un enfoque declarativo para la configuración del estado en el que se define cómo debería ser el estado final. El orquestador determina la secuencia correcta de acciones para lograr ese estado.

Kubernetes es el orquestador más popular. Una forma de interactuar con los clústeres de Kubernetes es con Kubectl, la herramienta oficial de administración de la CLI. Kubectl le permite aplicar archivos de manifiesto en formato YAML que definen los recursos del contenedor para crear en su clúster.

Aquí hay un manifiesto simple que crea una única instancia de contenedor:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: example.com/image:latest

Puede usar Kubectl para aplicar este manifiesto a un clúster:

kubectl apply -f manifest.yaml

Los cambios posteriores al archivo se aplican repitiendo el comando. Kubernetes realiza automáticamente las acciones necesarias para lograr el nuevo estado declarado.

Esto convierte a Kubernetes en una excelente opción para implementaciones de producción automatizadas. Puede usar kubectl apply dentro de sus canalizaciones para tomar los manifiestos en su repositorio y aplicar el estado declarado a su clúster. Al crear una nueva etiqueta de imagen para cada confirmación, Kubernetes extraería esa imagen e iniciaría nuevos contenedores para la implementación.

Para configurar esto, debe proporcionar el contenido de un archivo de configuración de Kubeconfig como una variable de canalización. Esto le da a Kubectl las credenciales para usar en su conexión de clúster. El binario local de Kubectl operaría contra su clúster remoto.

Docker Swarm es otra opción de orquestación que viene integrada con Docker. Puede configurar una pila Swarm usando el mismo docker-compose.yml archivo como se describió anteriormente. Luego, se podrían usar enfoques de implementación similares, ya sea conectándose al host Swarm a través de SSH o usando un contexto de Docker para modificar el destino de los archivos binarios locales de Docker.

Los orquestadores son mucho más complejos que usar Compose simple o un PaaS administrado. En el caso de Kubernetes, debe aprender nuevas abstracciones, terminología y formatos de archivo de configuración antes de poder implementar sus contenedores. Sin embargo, los clústeres también le brindan capacidades adicionales que facilitan el mantenimiento de las aplicaciones a largo plazo. Puede escalar fácilmente réplicas en varios hosts, incorporar redundancia y agregar registros y métricas.

Por lo tanto, la orquestación es la mejor opción para sistemas más grandes que ejecutan varios contenedores. Eso no significa que la atención de la industria que están recibiendo las herramientas deba hacer que use Kubernetes para cada implementación. Compose o PaaS serán más fáciles de configurar, razonar y mantener para casos de uso más pequeños en los que esté menos preocupado por la escalabilidad y el bloqueo del proveedor.

Resumen

Hemos analizado tres formas diferentes de ejecutar contenedores como cargas de trabajo de producción. Los detalles de implementación variarán según la estrategia elegida, la cadena de herramientas de soporte y el entorno de CI, por lo que hemos omitido una descripción precisa de cómo puede configurar la automatización como parte de su flujo de trabajo. Sin embargo, los tres se pueden integrar fácilmente en una canalización de CI que se ejecuta cada vez que fusiona o inserta su código.

La orquestación con una herramienta como Kubernetes se ha convertido rápidamente en el método preferido para implementaciones escalables de sistemas que ejecutan varios contenedores. Si bien puede simplificar enormemente el funcionamiento de los servicios para los que está diseñado, también conlleva una importante curva de aprendizaje y gastos generales de mantenimiento, por lo que no debe lanzarse sin considerar alternativas.

Los sistemas más pequeños formados a partir de unos pocos componentes pueden ver mejores resultados al usar Compose para iniciar contenedores con una configuración reproducible en un host Docker existente. Esto brinda algunos de los beneficios de Kubernetes, como la configuración declarativa, sin la complejidad adicional. Puede "incorporarse fácilmente" a la orquestación más adelante agregando la compatibilidad con Docker Swarm a su archivo Compose existente, lo que le permite iniciar múltiples réplicas distribuidas de contenedores.

Finalmente, las opciones de plataforma como servicio aceleran la implementación de aplicaciones sin tener que pensar en detalles granulares del contenedor. Estos servicios ofrecen la perspectiva de una automatización completa de la infraestructura a partir de una configuración mínima. Sin embargo, pueden ser restrictivos a largo plazo, así que piense en cómo crecerá su solución con el tiempo antes de comprometerse.

Al implementar cualquier contenedor en producción, también deberá considerar el alojamiento de imágenes y la inyección de configuración. Puede utilizar un servicio de registro público para que sus imágenes estén disponibles en su entorno de producción. Alternativamente, puede ejecutar su propio registro privado y proporcionar credenciales como parte de su canalización de CI. Los valores de configuración generalmente se proporcionan como variables de entorno que puede definir en la pantalla de configuración de su proveedor de CI.