Cómo usar Cron con sus contenedores Docker

La ejecución de tareas en segundo plano según una programación es un requisito estándar de los servicios de backend. La configuración era simple: definirías tus actividades en tu servidor crontab y llámalo un día. Echemos un vistazo a cómo puede utilizar cron mientras usa Docker para la implementación.

La contenedorización de servicios aumenta la productividad de los desarrolladores. Al mismo tiempo, puede dejarlo preguntándose cómo es el administrador de sistemas tradicional acerca de la asignación de conceptos de Docker. Tiene varias opciones al usar cron con contenedores Docker y los exploraremos a continuación en orden de idoneidad. Antes de continuar, asegúrese de haber creado una imagen de Docker de su aplicación.

Usando el Crontab del anfitrión

En su forma más simple, siempre puede usar el cron instalar el host que ejecuta Docker Engine. Asegurarse cron está instalado y luego modificar el archivo del sistema crontab como normal.

puedes usar docker exec para ejecutar un comando dentro de un contenedor existente:

*/5 * * * * docker exec example_app_container /example-scheduled-task.sh

Solo funcionará si puede estar seguro del nombre del contenedor de antemano. Por lo general, es mejor crear un nuevo contenedor que exista únicamente para realizar la tarea:

*/5 * * * * docker run --rm example_app_image:latest /example-scheduled-task.sh

Cada cinco minutos, su sistema cron la instalación creará un nuevo contenedor Docker usando la imagen de su aplicación. Docker ejecutará el archivo /example-scheduled-task.sh script dentro del contenedor. El contenedor será destruido (--rm) una vez finalizado el guión.

Usando Cron dentro de sus contenedores

Usando el anfitrión crontab Detiene la contenedorización de Docker ya que las tareas programadas requieren una configuración manual en el sistema. Tendrás que asegurarte cron se instala en cada host que implemente. Si bien puede ser útil en el desarrollo, debe intentar integrar cron en sus servicios Dockerized siempre que sea posible.

Las imágenes base de Docker más populares no incluyen el cron demonio de forma predeterminada. Puedes instalarlo dentro de tu archivo Dockerfile y luego registre su aplicación crontab.

Primero, crea un nuevo archivo crontab archivo en su base de código:

*/5 * * * * /usr/bin/sh /example-scheduled-task.sh

Luego, edita tu archivo Dockerfile instalar cron y registra el tuyo crontab - así es como puede hacerlo con una imagen basada en Debian:

RUN apt-get update && apt-get install -y cron
COPY example-crontab /etc/cron.d/example-crontab
RUN chmod 0644 /etc/cron.d/example-crontab &&
    crontab /etc/cron.d/example-crontab

Instalamos cron y copia nuestro código base crontab en /etc/cron.d directorio. A continuación, debemos cambiar los permisos en los nuestros. crontab para asegurarse de que sea accesible para cron. Finalmente, usa el archivo crontab comando para dar a conocer el archivo cron demonio.

Para completar esta configuración, deberá cambiar el comando o el punto de entrada de la imagen para iniciar el archivo cron daemon cuando los contenedores comienzan a ejecutarse. No puedes lograr esto con un archivo RUN fase en el tuyo Dockerfile porque estos son pasos temporales que no persisten más allá de la fase de creación de la imagen. El servicio se iniciaría dentro del contenedor temporal utilizado para crear la capa, no en los contenedores finales que ejecutan la imagen completa.

Si la única actividad de su contenedor es realizar cron - del que hablaremos más tarde - puedes agregar ENTRYPOINT ["cron", "-f"] para usted Dockerfile para iniciarlo como un proceso de primer plano. Si necesita mantener otro proceso en primer plano, como un servidor web, debe crear un script de punto de entrada dedicado (p. Ej. ENTRYPOINT ["bash", "init.sh"]) y añadir service cron start como un comando dentro de ese archivo.

Separación de Cron de los servicios de aplicaciones

La implementación de la configuración descrita en la sección anterior proporciona una solución más robusta que la del host crontab. Añadiendo el archivo cron Demonio a contenedores que sirven su aplicación asegura que cualquier persona que use su imagen de Docker automáticamente tendrá tareas programadas.

Sin embargo, esto todavía resulta en una mezcla de preocupaciones. Sus contenedores tienen dos responsabilidades: primero, proporcionar la funcionalidad de la aplicación y, segundo, mantenerla cron vivo y realizar tareas programadas. Idealmente, cada contenedor debería proporcionar una unidad específica de funcionalidad.

Siempre que sea posible, debes hacer el tuyo cron actividades en un contenedor separado para su aplicación. Si está creando un backend web, eso significaría un contenedor para proporcionar su servidor web y otro que se ejecuta cron en primer plano.

Sin esta separación, no podrá utilizar un orquestador como Docker Swarm o Kubernetes para ejecutar múltiples réplicas de su aplicación. Cada contenedor funcionaría por sí solo cron daemon, lo que provoca que las tareas programadas se ejecuten varias veces. Esto se puede mitigar mediante el uso de archivos de bloqueo asociados con un volumen Docker compartido. Sin embargo, es más manejable abordar el problema desde su raíz e introducir un contenedor dedicado para cron demonio.

En general, querrá que ambos contenedores se basen en la imagen de Docker de su aplicación. Cada uno de ellos necesitará conexiones a los volúmenes y redes de Docker de su servicio. Esto asegurará cron El contenedor tiene un entorno idéntico al contenedor de la aplicación, con la única diferencia del proceso de primer plano.

Esta no es una regla estricta y rápida; en algunos proyectos, las tareas programadas pueden ser scripts triviales que funcionan independientemente del código base. En ese caso, el cron El contenedor puede usar una imagen base mínima y eliminar conexiones innecesarias a recursos periféricos.

Una forma de configurar un archivo cron contenedor sería usar docker-compose. Definirías el archivo cron contenedor como servicio extra. Puede utilizar la imagen base de la aplicación anulando el comando de punto de entrada para iniciar el archivo cron demonio. Utilizando docker-compose También facilita la conexión del contenedor a cualquier volumen compartido y red que necesite.

version: "3"
 
services:
  app:
    image: demo-image:latest
    volumes:
      - data:/app-data
  cron:
    image: demo-image:latest
    entrypoint: /bin/bash
    command: ["cron", "-f"]
    volumes:
      - data:/app-data
 
volumes:
  data:

Usando el ejemplo anterior, un contenedor sirve nuestra aplicación usando el punto de entrada predeterminado en la imagen. Asegúrate de que lo haga no iniciar el cron ¡demonio! El segundo contenedor anula el punto de entrada de la imagen que se ejecutará cron. Mientras la imagen todavía tenga cron instalado y tuyo crontab configurado, puede utilizar docker-compose up para ver su solicitud.

Uso de trabajos cron de Kubernetes

Finalmente, echemos un vistazo a un ejemplo simple de ejecución de tareas programadas dentro de Kubernetes. Kubernetes viene con su propio CronJob recurso que puede utilizar en sus archivos de manifiesto.

No es necesario instalar cron en su imagen o configure contenedores especializados si usa Kubernetes. Presta atencion a CronJob es un recurso beta que puede cambiar en futuras versiones de Kubernetes.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: my-cron
  namespace: my-namespace
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: my-container
              image: my-image:latest
              command: ["/bin/bash", "/my-cron-script.sh"]
          restartPolicy: OnFailure

Aplique el archivo de manifiesto anterior a su clúster para crear un nuevo archivo cron trabajo que se realizará /my-cron-script.sh dentro de su recipiente cada cinco minutos. La frecuencia se da como regular cron definicion de schedule escriba el recurso spec.

Puedes personalizar el archivo ConcurrencyPolicy para comprobar si Kubernetes permite que sus obras se superpongan. El valor predeterminado es Allow pero se puede cambiar a Forbid (evita comenzar nuevos trabajos cuando ya existe uno) o Replace (finaliza un trabajo existente tan pronto como comienza uno nuevo).

El uso del recurso de Kubernetes integrado es la forma recomendada de administrar las tareas programadas dentro de los clústeres. Puede acceder fácilmente a los registros de trabajos y no tiene que preocuparse por preparar sus contenedores para su uso con cron. Solo necesita producir una imagen de Docker que contenga todo lo que necesita para ejecutar sus tareas. Kubernetes gestionará la creación y destrucción de instancias de contenedores de acuerdo con la programación especificada.