Usar services-config.yaml

Cuando usas el gestor de servicios de Linux simplificado para realizar una migración, Migrate to Containers crea un nuevo archivo de artefacto, services-config.yaml. Usa este archivo para controlar la inicialización de la aplicación en un contenedor implementado.

Por ejemplo, después de migrar el contenedor, edita el archivo services-config.yaml para controlar la inicialización de la aplicación:

• Quitar aplicaciones del archivo
• Añadir aplicaciones al archivo
• Editar las propiedades de inicialización de una aplicación

A continuación, se muestra un ejemplo de archivo services-config.yaml:

version: v1beta1
env:
  - name: KEY1
    value: VALUE1
  - name: KEY2
    value: VALUE2
applications:
    - name: nginx
      type: forking
      envfile: /path/to/file.txt
      env:
        - name: KEY3
          value: VALUE3
      start:
      - cmd: /usr/sbin/nginx -g 'daemon on; master_process on;'
      pidfile: /run/nginx.pid
    - name: ssh@
      type: simple
      start:
      - cmd: /usr/sbin/sshd -i $SSHD_OPTS
        ignore_errors: true
      runtime_directories:
        mode: "0755"
        paths:
          - /run/sshd
        preserve: true
    - name: suitecrm
      type: exec
      start:
      - cmd: /etc/init.d/suitecrm start
      status:
        cmd: /etc/init.d/suitecrm status
    - name: phpsessionclean
      type: oneshot
      start:
        - cmd: /usr/lib/php/sessionclean
      timers:
        - name: phpsessionclean.timer
          on_calendar:
            - cron: 09,39 * * * *
    - name: mariadb
      type: notify
      prestart:
        - cmd: /usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld
        - cmd: /bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
        - cmd: /bin/sh -c "[ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"
      start:
      - cmd: /usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION
      poststart:
        - cmd: /bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
        - cmd: /etc/mysql/debian-start
      user: mysql
      group: mysql

En este archivo:

• env: especifica variables de entorno a nivel global o de aplicación. Si especificas la misma variable de entorno tanto a nivel global como a nivel de aplicación, tendrá prioridad la variable de entorno a nivel de aplicación.

  • En el caso de las variables de entorno definidas a nivel global, usa env para especificar un par name/value. Los nombres pueden contener letras ASCII, dígitos y el carácter de guion bajo. Los nombres no pueden empezar por un dígito.

  • En el caso de las variables de entorno definidas a nivel de aplicación, usa env para especificar un par name/value. También puedes usar envfile para especificar la ruta a un archivo de texto que contenga líneas con el siguiente formato:

    # Comments allowed
    KEY=VALUE

    Si el archivo de texto contiene una definición de variable de entorno que duplica una especificada por env, tendrá prioridad la especificada por env.

• applications: especifica la lista de aplicaciones que se iniciarán al implementar el contenedor y define las propiedades de inicialización de la aplicación.

  • name: especifica el nombre de la aplicación.

  • type especifica el tipo de aplicación, que puede ser uno de los siguientes:

    • forking: ejecuta el archivo especificado por start sin bifurcación. Se espera que el ejecutable del servicio cree un fork. Te recomendamos que también definas pidfile.

    • exec: bifurcación para ejecutar el servicio. Se considera que el servicio se ha iniciado después de que se haya llamado a exec en el ejecutable.

    • simple: igual que exec. Un servicio simple se comporta de forma diferente a la definición systemd porque espera tanto a fork como a exec en lugar de a fork.

    • notify: es igual que exec, excepto que, en el caso de systemd, no se define la variable de entorno NOTIFY_SOCKET, por lo que las llamadas sd_notify systemd no funcionan.

    • oneshot: el servicio se considera iniciado después de que se llame a exec en el archivo ejecutable. El estado es error si el servicio se cierra con un código de error distinto de 0.

  • prestart, start, poststart y status.

    Para iniciar un servicio, Migrate to Containers ejecuta los comandos prestart (si los hay), después el comando start y, por último, los comandos poststart (si los hay). Si falla un comando y no lo has configurado para que use ignore_errors, el servicio se detendrá y verás un mensaje de error en su estado.

    Los comandos que se usan para realizar operaciones específicas en la aplicación tienen el siguiente formato:

      command-type: 
        cmd: command
        shell: /bin/sh
        ignore_errors: false
        ignore_environment_variables: false

    Donde:

    • command-type: especifica el tipo de comando como prestart, start, poststart o status.

      En el caso de start, solo puedes usar un comando, a menos que type sea oneshot.

      Si se trata de type=forking o type=oneshot, los comandos poststart se ejecutan después de que se bifurque el comando start. De lo contrario, se ejecutarán inmediatamente después de ejecutar el comando start.

    • command: especifica el comando que se debe ejecutar para realizar la operación.

    • shell (Opcional): De forma predeterminada, todos los comandos se ejecutan en el shell /bin/sh. También puedes definir shell como /bin/bash.

    • ignore_errors (opcional): si true, se registra un código de salida del comando que normalmente se considera un error, pero se considera que el comando se ha ejecutado correctamente. El valor predeterminado es false.

      De forma predeterminada, Migrar a contenedores asigna el valor ignore_errors a true a cualquier ejecutable systemd que incluya el prefijo "-".

    • ignore_environment_variables (opcional): si true, no se aplica la sustitución de variables de entorno. El valor predeterminado es false.

      De forma predeterminada, Migrate to Containers asigna ignore_environment_variables a true a cualquier ejecutable systemd que incluya el prefijo ":".

  • pidfile: especifica el archivo PID que contiene el ID de proceso del servicio que se usa para comprobar si el proceso sigue en ejecución.

  • chdir: especifica el directorio de trabajo del proceso iniciado.

  • user: especifica el nombre de usuario con el que se inicia el nuevo proceso.

  • group: especifica el nombre del grupo en el que se inicia el nuevo proceso.

  • timers: especifica la lista de temporizadores de la aplicación. La aplicación se activará cuando se agote el tiempo de cualquiera de los temporizadores especificados.

    version: v1beta1
    env: []
    Applications:
    - name: service_name
      type: service_type
      start:
        - cmd: service_exec_command
      timers:
        - name: timer_name
          on_calendar:
            - cron: realtime_time
          on_startup:
            - duration: monotonic_time
          on_service_start:
            - duration: monotonic_time
          on_service_stop:
            - duration: monotonic_time
    

    • name: especifica el nombre del temporizador.

    • on_calendar: especifica la lista de eventos del calendario del temporizador.

      • cron: una hora especificada con el formato cron. Por ejemplo:

        cron: 0 0 * * *
        cron: @daily
        

    • on_startup: especifica una lista de duraciones (en relación con el momento en que implementas el contenedor).

      • duration: hora especificada con el formato de duración. Por ejemplo:

      duration: 30m
      duration: 1sec
      

    • on_service_start: especifica una lista de duraciones relativas al momento en que el estado de tu aplicación cambia a activo.

      • duration: hora especificada con el formato de duración.

    • on_service_stop: especifica una lista de duraciones relativas al momento en que el estado de tu aplicación cambia a inactivo.

      • duration: hora especificada con el formato de duración.

  • Usa las siguientes propiedades para especificar paths en los directorios que se crean antes de iniciar el servicio:

    • runtime_directories: especifica la lista de paths de los directorios creados en /run/.

    • state_directories: especifica la lista de paths de los directorios creados en /var/lib/.

    • cache_directories: especifica la lista de paths de los directorios creados en /var/cache/.

    • logs_directories: especifica la lista de paths de los directorios creados en /var/log/.

    • configuration_directories: especifica la lista de paths de los directorios creados en /etc/.

    Cada una de estas propiedades tiene las siguientes opciones:

    • mode: especifica el modo del archivo. El valor predeterminado es 0755, que corresponde al acceso de lectura y ejecución para todos, y al acceso de escritura para el propietario.
    • preserve: si false se limpia el directorio cuando se detiene el servicio. El valor predeterminado es true.

Añadir o quitar un servicio del archivo services.yaml

Puedes añadir o quitar un servicio de tu archivo services.yaml editándolo manualmente. Cada vez que añadas un servicio, debes rellenar los siguientes campos:

• name
• type
• start

Para obtener más información sobre los campos obligatorios y opcionales de un servicio, consulta la services.yamldefinición anterior.

Añadir un servicio

Para añadir un servicio a tu archivo services.yaml, sigue estos pasos:

1. Abre el archivo services.yaml en un editor de texto para modificarlo.

2. En services.yaml, vaya al atributo applications:

   version: v1beta1
   env:
    - name: KEY1
    ...
   applications:
   

3. Añade el servicio que quieras en la línea que hay debajo del atributo applications empezando por el campo name, seguido de los demás campos obligatorios y opcionales que correspondan a tu aplicación:

   version: v1beta1
   env:
    - name: KEY1
    ...
   applications:
   - name:
     type:
     start:
       - cmd:
     ...
   

   Si tu archivo services.yaml ya tiene definiciones de servicio en el atributo applications, puedes añadir un nuevo servicio empezando por el campo name en la línea que hay debajo de la última entrada del servicio anterior:

   version: v1beta1
   env:
    - name: KEY1
    ...
   applications:
   - name:
     type:
     start:
   - name:
     type:
     start:
       ...
   

4. Guarda el archivo services.yaml.

Quitar un servicio

Para quitar un servicio de tu archivo services.yaml, sigue estos pasos:

1. Abre el archivo services.yaml en un editor de texto para modificarlo.

2. En services.yaml, vaya al atributo applications:

   version: v1beta1
   env:
    - name: KEY1
    ...
   applications:
   ...
   

3. Elimina el servicio que quieras, empezando por el campo name, seguido de los demás campos obligatorios y opcionales que correspondan a tu aplicación. Por ejemplo:

   Antes de que se haya retirado el servicio:

   version: v1beta1
   env:
   - name: KEY1
     ...
   applications:
   - name:
     type:
     start:
       - cmd:
   - name:
     ...
   
   

   Una vez que se haya quitado el servicio:

   version: v1beta1
   env:
   - name: KEY1
     ...
   applications:
   - name:
     ...
   

4. Guarda el archivo services.yaml.