Usar services-config.yaml

Cuando usas el administrador de servicios de Linux simplificado para realizar una migración, Migrate to Containers crea un archivo de artefacto nuevo, 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 a fin de realizar lo siguiente:

  • Quitar aplicaciones del archivo
  • Agrega aplicaciones al archivo
  • Edita 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, se especifica lo siguiente:

  • env: Especifica las variables de entorno a nivel global o a nivel de la aplicación. Si especificas la misma variable de entorno a nivel global y de aplicación, la variable de entorno a nivel de aplicación tendrá prioridad.

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

    • Para las variables de entorno establecidas a nivel de la aplicación, usa env a fin de especificar un par name/value. También puedes usar envfile para especificar la ruta de acceso a un archivo de texto que contiene 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, la que especifica env tiene prioridad.

  • applications: Especifica la lista de aplicaciones que se inician cuando implementas el contenedor y establece las propiedades de inicialización de la aplicación.

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

    • type Especifica el tipo de aplicación, como una de las siguientes opciones:

      • forking: Ejecuta el archivo que especifica start sin bifurcar. Se espera que el ejecutable del servicio se bifurque. Te recomendamos que también configures pidfile.

      • exec: Bifurca el servicio para ejecutarlo. El servicio se considera iniciado después de que se llama a exec en el ejecutable.

      • simple: Igual que exec. Un servicio simple se comporta de manera diferente a la definición systemd porque espera por fork y exec, en lugar de fork.

      • notify: Igual que exec, excepto que, para systemd, la variable de entorno NOTIFY_SOCKET no se establece, por lo que las llamadas sd_notify systemd no funcionan.

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

    • Los comandos prestart, start, poststart y status para el servicio.

      Para iniciar un servicio, Migrate to Containers ejecuta los comandos prestart (si los hay), el comando start y, por último, los comandos de poststart (si corresponde). Si un comando falla y no configuraste el comando para usar ignore_errors, el servicio se detendrá y verás un mensaje de error en el estado del servicio.

      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

      Aquí:

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

        Para start, puedes tener un solo comando, a menos que type sea oneshot.

        Si es type=forking o type=oneshot, los comandos poststart se ejecutan después de la bifurcación del comando start. De lo contrario, se ejecutarán de inmediato después de ejecutar el comando start.

      • command: Especifica el comando que se ejecutará para realizar la operación.

      • shell (opcional): De forma predeterminada, todos los comandos se ejecutan en la shell /bin/sh. De forma opcional, puedes establecer shell en /bin/bash.

      • ignore_errors (opcional): Si es true, se registra un código de salida del comando que suele considerarse un error, pero se considera que el comando se realizó de forma correcta. El valor predeterminado es false.

        De forma predeterminada, Migrate to Containers establece ignore_errors en true para cualquier ejecutable systemd que incluya el prefijo "-".

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

        De forma predeterminada, Migrate to Containers establece ignore_environment_variables en true para cualquier ejecutable systemd que incluya el prefijo ":".

    • pidfile: Especifica el archivo pid que contiene el ID de proceso del servicio que se usa para verificar si el proceso todavía se está ejecutando.

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

    • user: Especifica el nombre de usuario en el que se inicia el proceso nuevo.

    • group: Especifica el grupo de usuario en el que se inicia el proceso nuevo.

    • timers: Especifica la lista de temporizadores de la aplicación. La aplicación se activará cada vez que transcurra cualquiera de los cronómetros 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 de calendario para el temporizador.

        • cron: Se refiere a una hora especificada mediante 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: Se refiere a una hora especificada mediante el formato de duración. Por ejemplo:
        duration: 30m
        duration: 1sec
        
      • on_service_start: Especifica una lista de duraciones en relación con el momento en que el estado de la aplicación cambia a activo.

        • duration: Se refiere a una hora especificada mediante el formato de duración.
      • on_service_stop: Especifica una lista de duraciones en relación con el momento en que el estado de la aplicación cambia a inactivo.

        • duration: Se refiere a una hora especificada mediante 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 para los directorios creados en /run/.

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

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

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

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

      Cada una de estas propiedades tiene las siguientes opciones:

      • mode: Especifica el modo de archivos. El valor predeterminado es 0755, que corresponde a acceso de lectura y ejecución para todos y acceso de escritura para el propietario.
      • preserve: Si es false, el directorio se limpia cuando se detiene el servicio. El valor predeterminado es true.

Agrega un servicio a tu archivo services.yaml o quítalo

Puedes agregar o quitar un servicio de tu archivo services.yaml si lo editas de forma manual. Cuando agregas un servicio nuevo, debes propagar los siguientes campos:

  • name
  • type
  • start

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

Agregar un servicio

Para agregar 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, navega al atributo applications:

    version: v1beta1
    env:
     - name: KEY1
     ...
    applications:
    
  3. Agrega el servicio deseado en la línea que se encuentra debajo del atributo applications, que comienza con el campo name, seguido de los otros campos obligatorios y opcionales apropiados para tu aplicación:

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

    Si el archivo services.yaml ya tiene definiciones de servicios en el atributo applications, puedes agregar un servicio nuevo que comience con el campo name en la línea debajo de la última entrada del servicio anterior:

    version: v1beta1
    env:
     - name: KEY1
     ...
    applications:
    - name:
      type:
      start:
    - name:
      type:
      start:
        ...
    
  4. Guarde el archivo services.yaml.

Quita 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, navega al atributo applications:

    version: v1beta1
    env:
     - name: KEY1
     ...
    applications:
    ...
    
  3. Quita el servicio deseado a partir del campo name, seguido de los otros campos obligatorios y opcionales apropiados para tu aplicación. Por ejemplo:

    Antes de quitar el servicio, haz lo siguiente:

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

    Una vez que se haya quitado el servicio, haz lo siguiente:

    version: v1beta1
    env:
    - name: KEY1
      ...
    applications:
    - name:
      ...
    
  4. Guarde el archivo services.yaml.