Utiliser services-config.yaml

Lorsque vous utilisez le gestionnaire de services Linux simplifié pour effectuer une migration, Migrate to Containers crée un fichier d'artefact : services-config.yaml. Utilisez ce fichier pour contrôler l'initialisation de l'application sur un conteneur déployé.

Par exemple, après avoir migré le conteneur, modifiez le fichier services-config.yaml pour contrôler l'initialisation de l'application comme suit :

  • Supprimer des applications du fichier
  • Ajouter des applications au fichier
  • Modifier les propriétés d'initialisation d'une application

Vous trouverez ci-dessous un exemple de fichier 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

Dans ce fichier :

  • env : spécifie les variables d'environnement au niveau global ou au niveau de l'application. Si vous spécifiez la même variable d'environnement au niveau global et au niveau de l'application, la variable d'environnement au niveau de l'application est prioritaire.

    • Pour les variables d'environnement définies au niveau global, utilisez env pour spécifier une paire name/value. Les noms peuvent contenir des lettres ASCII, des chiffres et le trait de soulignement. Les noms ne peuvent pas commencer par un chiffre.

    • Pour les variables d'environnement définies au niveau de l'application, utilisez env pour spécifier une paire name/value. Vous pouvez également utiliser envfile pour spécifier le chemin d'accès à un fichier texte contenant des lignes au format suivant :

      # Comments allowed
KEY=VALUE

      Si le fichier texte contient une définition de variable d'environnement qui duplique celle spécifiée par env, c'est la variable spécifiée par env qui est prioritaire.

  • applications : spécifie la liste des applications à démarrer lorsque vous déployez le conteneur et définit les propriétés d'initialisation de l'application.

    • name : spécifie le nom de l'application.

    • type spécifie le type de l'application, comme suit :

      • forking : exécute le fichier spécifié par start sans duplication. L'exécutable du service doit être dupliqué. Nous vous recommandons de définir également pidfile.

      • exec : fork pour exécuter le service. Le service est considéré comme démarré après l'appel de exec sur l'exécutable.

      • simple : identique à exec. Un service simple se comporte différemment de la définition systemd, car il attend à la fois fork et exec au lieu de fork.

      • notify : même chose que pour exec, à ceci près que pour systemd, la variable d'environnement NOTIFY_SOCKET n'est pas définie, et les appels sd_notify systemd ne fonctionneront donc pas.

      • oneshot : le service est considéré comme démarré après l'appel de exec sur l'exécutable. L'état est error si le service se termine avec un code d'erreur différent de 0.

    • Commandes prestart, start, poststart et status pour le service.

      Pour démarrer un service, Migrate to Containers exécute les commandes prestart (le cas échéant), puis la commande start et enfin les commandes poststart (le cas échéant). Si une commande échoue et que vous n'avez pas configuré la commande pour utiliser ignore_errors, le service est arrêté et un message d'erreur s'affiche dans l'état du service.

      Les commandes permettant d'effectuer des opérations spécifiques sur l'application se présentent sous la forme suivante :

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

      Où :

      • command-type : spécifie le type de commande : prestart, start, poststart ou status.

        Pour start, vous pouvez avoir une commande unique, sauf si type vaut oneshot.

        Si type=forking ou type=oneshot, les commandes poststart sont exécutées après le fork de la commande start. Sinon, elles sont exécutées immédiatement après l'exécution de la commande start.

      • command : spécifie la commande à exécuter pour effectuer l'opération.

      • shell (facultatif) : par défaut, toutes les commandes sont exécutées dans l'interface système /bin/sh. Vous pouvez éventuellement définir shell sur /bin/bash.

      • ignore_errors (facultatif) : si true, un code de sortie de la commande normalement considéré comme un échec est enregistré, mais la commande est considérée comme ayant réussi. La valeur par défaut est false.

        Par défaut, Migrate to Containers définit ignore_errors sur true pour tous les exécutables systemd incluant le préfixe "-".

      • ignore_environment_variables (facultatif) : si la valeur vaut true, la substitution de variable d'environnement n'est pas appliquée. La valeur par défaut est false.

        Par défaut, Migrate to Containers définit ignore_environment_variables sur true pour tous les exécutables systemd incluant le préfixe ":".

    • pidfile : spécifie le fichier pid contenant l'ID de processus du service utilisé pour vérifier si le processus est toujours en cours d'exécution.

    • chdir : spécifie le répertoire de travail du processus démarré.

    • user : spécifie le nom de l'utilisateur sous lequel le nouveau processus est lancé.

    • group : spécifie le nom du groupe sous lequel le nouveau processus démarre.

    • timers : spécifie la liste des minuteurs de l'application. L'application est activée chaque fois que l'un des minuteurs spécifiés est écoulé.

      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 : spécifie le nom du minuteur.

      • on_calendar : spécifie la liste des événements d'agenda pour le minuteur.

        • cron : heure spécifiée utilisant le format Cron. Exemple :

          cron: 0 0 * * *
cron: @daily

      • on_startup : spécifie une liste de durées (en fonction du moment où vous déployez votre conteneur).

        • duration : heure spécifiée utilisant le format de durée. Exemple :
        duration: 30m
duration: 1sec

      • on_service_start : spécifie une liste de durées, par rapport au moment où l'état de votre application devient actif.

        • duration : heure spécifiée utilisant le format de durée.

      • on_service_stop : spécifie une liste de durées, par rapport au moment où l'état de votre application devient inactif.

        • duration : heure spécifiée utilisant le format de durée.

    • Utilisez les propriétés suivantes pour spécifier les paths aux répertoires créés avant le démarrage du service :

      • runtime_directories : spécifie la liste des paths aux répertoires créés dans /run/.

      • state_directories : spécifie la liste des paths aux répertoires créés dans /var/lib/.

      • cache_directories : spécifie la liste des paths aux répertoires créés dans /var/cache/.

      • logs_directories : spécifie la liste des paths aux répertoires créés dans /var/log/.

      • configuration_directories : spécifie la liste des paths aux répertoires créés dans /etc/.

      Chacune de ces propriétés utilise les options suivantes :

      • mode : spécifie le mode de fichier. La valeur par défaut est 0755, ce qui correspond à un accès en lecture et en exécution pour tous, et un accès en écriture pour le propriétaire.
      • preserve : si false, le répertoire est nettoyé lorsque le service est arrêté. La valeur par défaut est true.

Ajouter ou supprimer un service dans votre fichier services.yaml

Vous pouvez ajouter ou supprimer un service de votre fichier services.yaml en le modifiant manuellement. Chaque fois que vous ajoutez un service, vous devez renseigner les champs suivants :

  • name
  • type
  • start

Pour en savoir plus sur les champs obligatoires et facultatifs d'un service, consultez la définition services.yaml ci-dessus.

Ajouter un service

Pour ajouter un service à votre fichier services.yaml, procédez comme suit :

  1. Ouvrez votre fichier services.yaml dans un éditeur de texte pour le modifier.

  2. Dans services.yaml, accédez à l'attribut applications :

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

  3. Ajoutez le service souhaité sur la ligne située sous l'attribut applications, en commençant par le champ name, suivi des autres champs obligatoires et facultatifs correspondant à votre application :

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

    Si votre fichier services.yaml contient déjà des définitions de service sous l'attribut applications, vous pouvez ajouter un service commençant par le champ name sur la ligne située sous la dernière entrée du service précédent :

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

  4. Enregistrez votre fichier services.yaml.

Supprimer un service

Pour supprimer un service de votre fichier services.yaml, procédez comme suit :

  1. Ouvrez votre fichier services.yaml dans un éditeur de texte pour le modifier.

  2. Dans services.yaml, accédez à l'attribut applications :

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

  3. Supprimez le service souhaité en commençant par le champ name, suivi des autres champs obligatoires et facultatifs correspondant à votre application. Exemple :

    Avant la suppression du service :

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

    Une fois le service supprimé :

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

  4. Enregistrez votre fichier services.yaml.