Fichier de configuration de déploiement

Le fichier de configuration de déploiement définit les artefacts à télécharger dans l'instance et l'emplacement où ils doivent être copiés. Le fichier de configuration spécifie également la séquence de commandes de déploiement.

Le fichier de configuration est écrit en YAML. Le fichier peut être inséré ou fourni en tant que référence d'artefact générique lors du déploiement du groupe d'instances.

Les administrateurs DevOps peuvent utiliser le fichier de configuration du déploiement pour les actions suivantes :

  • Spécifier les ensembles d'applications et leur emplacement de stockage dans l'instance de calcul cible.
  • Indiquer les étapes requises pour déployer une application.
  • Spécifier les variables d'environnement définies par l'utilisateur ou intégrées requises pour le déploiement.

Structure du fichier de configuration du déploiement

Voici la structure de base du fichier de configuration du déploiement :

{
version:     
component:   
env: 
    variables:        
timeoutInSeconds:  
files:  
  - source:
    destination:                              
steps:                              
  - stepType: Command 
    name:
    command:
    runAs:
    timeoutInSeconds:
  - stepType: Command 
}

Voici la liste des paramètres de configuration du déploiement et leur description :

Paramètre Description
version Numéro de version du fichier de spécification. La valeur doit être 1.0.
component Valeur de composant. La seule valeur prise en charge est deployment.
shell Facultatif. Indique l'interpréteur de commandes à utiliser au niveau global de la spécification de déploiement. Cette valeur peut être remplacée au niveau de l'étape. Les valeurs autorisées sont /bin/sh et bash. Si aucune valeur n'est spécifiée, la valeur par défaut, bash, est utilisée.
env: variables

Variables d'environnement définies par l'utilisateur disponibles pour les exécutables ou la commande bash qui s'exécutent dans le cadre du déploiement.

Exemples : key1: static-value, key2: ${PASSED_FROM_PIPELINE}

Des variables intégrées peuvent également être utilisées. Pour éviter les conflits, les variables intégrées portent le préfixe OCI_DEVOPS.

Les variables intégrées sont les suivantes :

  • OCI_DEVOPS_PIPELINE_ID
  • OCI_DEVOPS_STAGE_ID
  • OCI_DEVOPS_DEPLOYMENT_ID

env est un paramètre facultatif.

env: vaultVariables Facultatif. La clé doit être une chaîne conforme aux variables d'environnement POSIX. La valeur doit être un identificateur Oracle Cloud (OCID) de clé secrète dans la chambre forte. La chambre forte et le pipeline de déploiement doivent se trouver dans la même location. La location doit disposer d'une politique permettant aux ressources du pipeline de déploiement d'accéder à la clé secrète.

La portée de cette variable est l'exécution du fichier de spécification de déploiement et elle est disponible pour toutes les étapes du fichier. La valeur de ces variables est extraite de la chambre forte et mise à disposition en tant que variable d'environnement pour toutes les étapes du fichier de spécification de déploiement.

files

Indique les artefacts définis dans le pipeline de déploiement qui doivent être copiés et l'emplacement de l'instance de calcul cible vers lequel les copier. Ce paramètre est facultatif.

L'utilisateur configuré, ocarun, est par défaut propriétaire du répertoire spécifié et il doit disposer des autorisations d'écriture et d'exécution (chmod u+wrx). Si le dossier de destination n'existe pas, le déploiement DevOps le crée. Pour ce faire, ocarun (ou l'utilisateur configuré) doit disposer des autorisations d'écriture et d'exécution sur le répertoire parent du répertoire de destination spécifié.

Par exemple, si vous définissez le répertoire de destination dans le fichier de configuration du déploiement en tant que /var/services/accountService, vous devez fournir à l'utilisateur configuré les autorisations d'écriture et d'exécution sur /var/services et l'autorisation d'exécution sur /var.

files: source

Indique l'emplacement source des artefacts. La source peut faire référence à un fichier ou à un dossier. Si la source est un fichier, celui-ci est copié dans le dossier défini dans la destination. S'il s'agit d'un dossier, le contenu de celui-ci est copié dans la destination. La source utilise un chemin relatif, dont la racine est le dossier racine d'un ou de plusieurs artefacts.

Spécifiez le nom complet de l'artefact, y compris l'extension de type de fichier. Par exemple, si le fichier dans la source est test.sh, le chemin de l'artefact doit être test.sh ou folder-name/test.sh si le fichier se trouve dans un dossier.

Par exemple, si l'artefact général spécifie un seul fichier, run.sh, ce fichier est téléchargé dans le dossier racine (/) de la source. Si l'artefact général est une archive, par exemple app_pkg.zip, la racine du contenu de l'archive est le dossier racine.

files: destination Indique le dossier cible dans lequel le fichier ou le dossier source doit être copié. DevOps pour OCI recommande de considérer la destination en tant que répertoire intermédiaire pour le code de production, car le contenu du répertoire de destination est remplacé lors de chaque déploiement.

Dans l'exemple de spécification de déploiement suivant, deux répertoires sont mentionnés. Le répertoire de destination est /var/ocarun_staging/app1_staging_folder et le répertoire de production, var/ocarun_prod/main_app.

steps Indique la liste des étapes qui sont exécutées de manière séquentielle pendant le déploiement. Chaque étape est exécutée en tant que processus distinct dans l'instance. Toutes les variables d'environnement intégrées et définies par l'utilisateur spécifiées sont transmises au processus.
steps: name Nom défini par l'utilisateur de l'étape.
steps: command

Exécutable ou commande de l'interpréteur de commandes.

Si le paramètre files est spécifié dans le fichier de configuration, le chemin de l'exécutable est un chemin absolu, par exemple /genericArtifactDemo/start.sh. Si le paramètre files n'est pas spécifié, le chemin relatif est utilisé pour spécifier l'emplacement de l'exécutable. Le chemin relatif fait référence au dossier de travail du déploiement. Les artefacts sont téléchargés et extraits dans le dossier de travail courant du déploiement.

Les commandes à une seule ligne et à plusieurs lignes sont prises en charge. Toutes les commandes spécifiées dans une étape sont exécutées dans la même session de l'interpréteur de commandes. Selon la valeur de steps/*/shell, il peut s'agir de commandes shell ou bash. L'interruption immédiate n'est pas activée. Pour que l'étape réussisse, la sortie de la dernière commande d'une étape est prise en compte. Si le code de sortie de la dernière commande est 0, l'étape est considérée comme réussie. La commande multiligne fonctionne comme un script bash. Si vous voulez activer l'interruption immédiate pour la commande multiligne, spécifiez celle-ci avec (pour le script bash) set -e \n <rest of the commands> pour vous assurer que le script s'arrête à la première commande qui échoue.

Par exemple, si vous spécifiez la commande wrongcommand \n /usr/bin/sudo -n -u root -E /home/opc/scripts/stop.sh \n echo \"Done\" comme set -e \n wrongcommand \n /usr/bin/sudo -n -u root -E /home/opc/scripts/stop.sh \n echo \"Done\", le script s'arrête sur wrongcommand.

steps: runAs Exécute l'étape avec l'utilisateur spécifié. Par défaut, toutes les étapes sont exécutées par l'utilisateur ocarun.
steps: timeoutInSeconds Indique la période de temporisation pour terminer une étape.
steps: shell Facultatif. Indique le type d'interpréteur de commandes de l'étape courante. Si elle n'est pas spécifiée, la valeur est héritée du paramètre shell global. Les valeurs autorisées sont /bin/sh et shell.
steps: onFailure Liste d'étapes à exécuter en cas d'échec pour quitter correctement l'étape de déploiement. Les commandes de la section onFailure ne sont exécutées que si l'étape correspondante échoue et, après exécution, la spécification de déploiement est arrêtée. La gestion de l'échec n'a aucune incidence sur le statut de l'étape de déploiement. Si l'une des étapes échoue, le statut de l'étape de déploiement demeure Échec.

Voici un exemple de fichier de configuration de déploiement :

version: 1.0
component: deployment
runAs: ocarun
env: 
  variables: 
    version: ${appVersion}
  vaultVariables:
    SECRET_ID: "OCID of the secret in the vault"    
files: 
  - source: /
    destination: /var/ocarun_staging/app1_staging_folder
steps: 
  - stepType: Command
    name: Validate Variables
    command: echo "Version = ${version}:  Secret = ${SECRET_ID}"
    timeoutInSeconds: 60
  - stepType: Command
    name: Stop currently-running application
    command: cd /var/ocarun_prod/main_app; ./stop.sh
    timeoutInSeconds: 600
  - stepType: Command
    name: Clean old version of source code in prod directory
    command: echo "Perform suitable cleanup"
    timeoutInSeconds: 600
  - stepType: Command
    name: Copy new version of source code from staging directory to prod directory
    command: cp -R /var/ocarun_staging/app1_staging_folder/main_app /var/ocarun_prod/
    timeoutInSeconds: 600
  - stepType: Command
    name: Install application
    command: cd /var/ocarun_prod/main_app; ./install.sh
    timeoutInSeconds: 600
  - stepType: Command
    name: Run application
    command: cd /var/ocarun_prod/main_app; ./start.sh
    timeoutInSeconds: 600

Exemple de fichier cloud-init pour configurer les deux répertoires (production et stockage temporaire) :

#cloud-config
users:
  - default
  - name: ocarun
    sudo: ALL=(ALL) NOPASSWD:ALL

# Create two directories, one for staging and one for production.
runcmd:
  - [mkdir, -p, /var/ocarun_staging]
  - [mkdir, -p, /var/ocarun_prod]
  - [chown, ocarun, /var/ocarun_staging]
  - [chown, ocarun, /var/ocarun_prod]

Exemple permettant de comprendre les entrées multiples pour la source et la destination :

version: 1.0
component: deployment
runAs: root
shell: bash
env:
  variables:
    version: ${appVersion}
  vaultVariables:
    docker_registry_password : <secret-ocid>  
files:
  # This section is to define how the files in the artifact is put on the compute instance.
  # Multiple entires are supported using a separate source destination section for every entry.
  - source: /
    destination: /genericArtifactDemo
  - source: /tmp/file1
    destination: /var/applicationPath/someDir1
  - source: /tmp/file2
    destination: /var/applicationPath/someDir2  
steps:
  # This section is to define the scripts that each step runs on the instance after file copy.
  - stepType: Command
    name: Install Apache Web Server
    command: /genericArtifactDemo/install_dependencies.sh
    runAs: root
    timeoutInSeconds: 600
  - stepType: Command
    name: Stop Web Server
    command: /genericArtifactDemo/stop.sh
    runAs: root
    timeoutInSeconds: 60
  - stepType: Command
    name: Install New Version of Software
    command: /genericArtifactDemo/install.sh
    runAs: root
    timeoutInSeconds: 60
  - stepType: Command
    name: Start Web Server
    command: /genericArtifactDemo/start.sh
    runAs: root
    timeoutInSeconds: 60
  - stepType: Command
    name: stop and install
    command: |
      /scripts/stop.sh
      echo "Done stop.sh.."
      /scripts/install_dependencies.sh
      echo "Done install_dependencies.sh.."
      /scripts/install.sh
      echo "Done install.sh.."
    timeoutInSeconds: 1200
    runAs: root
    shell: /bin/sh
    onFailure:
       - stepType: Command
         command: /scripts/recovery_steps.sh
         name:"OnFailure step"
         timeoutInSeconds: 1200

Exécution du fichier de configuration du déploiement

Le service DevOps utilise l'agent RunCommand pour exécuter les commandes spécifiées dans le fichier de configuration sur l'instance de calcul cible. Pour plus d'informations sur l'activation du plugiciel RunCommand, voir la section "Préalables" dans Déploiement vers un groupe d'instances. Si le fichier de configuration du déploiement contient des paramètres fictifs, ils sont remplacés par les valeurs définies dans la liste des paramètres du déploiement. Voir Configuration des paramètres.