Configuration des environnements Elastic Beanstalk Docker

Ce chapitre explique des informations de configuration supplémentaires pour toutes les branches de plate-forme Docker prises en charge, y compris la branche de plate-forme Docker ECS gérée. À moins qu'une branche de plate-forme ou un composant de branche de plate-forme spécifique ne soit identifié dans une section, cela s'applique à tous les environnements qui exécutent des plateformes Docker prises en charge ou ECS gérées.

Note

Si votre environnement Elastic Beanstalk utilise une version de la plateforme AMI Amazon Linux Docker (antérieure à Amazon Linux 2), veillez à lire les informations supplémentaires contenues dans. Configuration de Docker sur Amazon Linux AMI (antérieur à Amazon Linux 2)

Configuration des logiciels dans les environnements Docker

Vous pouvez utiliser la console Elastic Beanstalk pour configurer le logiciel s'exécutant sur les instances de votre environnement.

Pour configurer votre environnement Docker dans la console Elastic Beanstalk

1. Ouvrez la console Elastic Beanstalk, puis dans la liste des régions, sélectionnez votre Région AWS.

2. Dans le panneau de navigation, choisissez Environments (Environnements), puis choisissez le nom de votre environnement dans la liste.

   Note

   Si vous avez plusieurs environnements, utilisez la barre de recherche pour filtrer la liste des environnements.

3. Dans le panneau de navigation, choisissez Configuration.

4. Dans la catégorie de configuration Mises à jour, surveillance et journalisation, sélectionnez Modifier.

5. Effectuez les modifications de configuration nécessaires.

6. Pour enregistrer les modifications, cliquez sur Appliquer en bas de la page.

Pour de plus amples informations sur la configuration des paramètres logiciels dans n'importe quel environnement, veuillez consulter Propriétés de l'environnement et autres paramètres de logiciel. Les sections suivantes couvrent des informations spécifiques à Docker.

Options du conteneur

La section Options du conteneur contient des options spécifiques à la plateforme. Pour les environnements Docker, il vous permet de choisir si votre environnement inclut ou non le serveur NGINX proxy.

Environnements avec Docker Compose

Si vous gérez votre environnement Docker avec Docker Compose, Elastic Beanstalk suppose que vous exécutez un serveur proxy en tant que conteneur. Par conséquent, la valeur par défaut est None pour le paramètre du serveur proxy, et Elastic Beanstalk ne fournit aucune configuration. NGINX

Note

Même si vous NGINXle sélectionnez comme serveur proxy, ce paramètre est ignoré dans un environnement avec Docker Compose. Par défaut, le paramètre Proxy server (Serveur proxy) est toujours None (Aucun).

Étant donné que le proxy du serveur NGINX Web est désactivé pour Docker sur la plateforme Amazon Linux 2 avec Docker Compose, vous devez suivre les instructions de génération de journaux afin d'améliorer les rapports de santé. Pour de plus amples informations, veuillez consulter Génération de journaux pour des rapports de santé améliorés avec Docker Compose.

Propriétés de l'environnement et variables d'environnement

La section Propriétés de l'environnement vous permet de définir les paramètres de configuration de l'environnement sur les instances Amazon Elastic Compute Cloud (AmazonEC2) qui exécutent votre application. Les propriétés de l'environnement sont passées en tant que paires clé-valeur à l'application. Dans un environnement Docker, Elastic Beanstalk transmet les propriétés de l'environnement aux conteneurs en tant que variables d'environnement.

Votre code d'application s'exécutant dans un conteneur peut faire référence à une variable d'environnement par son nom et lire sa valeur. Le code source qui lit ces variables d'environnement varie selon le langage de programmation. Pour obtenir des instructions pour lire les valeurs des variables d'environnement dans les langages de programmation pris en charge par les plateformes gérées par Elastic Beanstalk, veuillez consulter la rubrique correspondante de chaque plateforme. Pour obtenir la liste des liens vers ces rubriques, veuillez consulter Propriétés de l'environnement et autres paramètres de logiciel.

Environnements avec Docker Compose

Si vous gérez votre environnement Docker avec Docker Compose, vous devez effectuer une configuration supplémentaire pour récupérer les variables d'environnement dans les conteneurs. Pour que les exécutables lancés dans votre conteneur puissent accéder à ces variables d'environnement, vous devez les référencer dans le fichier docker-compose.yml. Pour plus d'informations, veuillez consulter Référencement de variables d'environnement dans les conteneurs.

Référencement de variables d'environnement dans les conteneurs

Si vous utilisez l'outil Docker Compose sur la plateforme Docker Amazon Linux 2, Elastic Beanstalk génère un fichier d'environnement Docker Compose appelé .env dans le répertoire racine de votre projet d'application. Ce fichier stocke les variables d'environnement que vous avez configurées pour Elastic Beanstalk.

Note

Si vous incluez un fichier .env dans le bundle de fichiers de votre application, Elastic Beanstalk ne générera pas de fichier .env.

Pour qu'un conteneur référence les variables d'environnement que vous définissez dans Elastic Beanstalk, vous devez suivre l'une de ces approches de configuration, ou les deux.

• Ajoutez le fichier .env généré par Elastic Beanstalk à l'option de configuration env_file dans le fichier docker-compose.yml.

• Définissez directement les variables d'environnement dans le fichier docker-compose.yml.

Les fichiers suivants fournissent un exemple. L'exemple de fichier docker-compose.yml illustre les deux approches.

• Si vous définissez les propriétés d'environnement DEBUG_LEVEL=1 et LOG_LEVEL=error, Elastic Beanstalk génère le fichier .env suivant pour vous :

  DEBUG_LEVEL=1
  LOG_LEVEL=error

• Dans ce fichier docker-compose.yml, l'option de configuration env_file pointe vers le fichier .env, et elle définit également la variable d'environnement DEBUG=1 directement dans le fichier docker-compose.yml.

  services:
    web:
      build: .
      environment:
        - DEBUG=1
      env_file:
        - .env

Remarques

• Si vous définissez la même variable d'environnement dans les deux fichiers, la variable définie dans le fichier docker-compose.yml a une priorité plus élevée que la variable définie dans le fichier .env.

• Veillez à ne pas laisser d'espace entre le signe égal (=) et la valeur attribuée à votre variable, afin d'empêcher l'ajout d'espaces à la chaîne.

Pour en savoir plus sur les variables d'environnement dans Docker Compose, veuillez consulter Environment variables in Compose

Utilisation de la fonction d'interpolation pour les variables d'environnement avec Docker Compose

À compter de la version de plateforme du 28 juillet 2023, la branche de plateforme Docker Amazon Linux 2 propose la fonctionnalité d'interpolation de Docker Compose. Grâce à cette fonctionnalité, les valeurs d'un fichier Compose peuvent être définies par des variables et interpolées au moment de l'exécution. Pour plus d'informations sur cette fonctionnalité, veuillez consulter la rubrique Interpolation (français non garanti) sur le site Web de documentation Docker.

Important

Si vous voulez utiliser cette fonctionnalité avec vos applications, sachez que vous devez mettre en œuvre une démarche qui utilise des hooks de plateforme.

Cela est nécessaire en raison d'une atténuation que nous avons mise en œuvre dans le moteur de la plateforme. Cette atténuation garantit la rétrocompatibilité pour les clients qui ne sont pas au courant de la nouvelle fonctionnalité d'interpolation et dont les applications existantes utilisent des variables d'environnement avec le caractère $. Le moteur de plateforme mis à jour échappe à l'interpolation par défaut en remplaçant le caractère $ par des caractères $$.

Vous trouverez ci-dessous un exemple de script de hook de plateforme que vous pouvez configurer pour permettre l'utilisation de la fonctionnalité d'interpolation.

#!/bin/bash

: '
example data format in .env file
key1=value1
key2=value2
'
envfile="/var/app/staging/.env"
tempfile=$(mktemp)

while IFS= read -r line; do
  # split each env var string at '='
  split_str=(${line//=/ })
  if [ ${#split_str[@]} -eq 2 ]; then
    # replace '$$' with '$'
    replaced_str=${split_str[1]//\$\$/\$}
    # update the value of env var using ${replaced_str}
    line="${split_str[0]}=${replaced_str}"
  fi
  # append the updated env var to the tempfile
  echo "${line}" ≫"${tempfile}"
done < "${envfile}"
# replace the original .env file with the tempfile
mv "${tempfile}" "${envfile}"

Placez les hooks de plateforme dans ces deux répertoires :

• .platform/confighooks/predeploy/

• .platform/hooks/predeploy/

Pour plus d'informations, consultez Hooks de plateforme dans la rubrique Extension des plateformes Linux de ce guide.

Génération de journaux pour des rapports de santé améliorés avec Docker Compose

L'agent d'état fournit des métriques sur l'état du système d'exploitation et des applications pour les environnements Elastic Beanstalk. Il s'appuie sur des formats de journaux de serveur web qui transmettent les informations dans un format spécifique.

Elastic Beanstalk suppose que vous exécutez un proxy de serveur web en tant que conteneur. Par conséquent, le proxy du serveur NGINX Web est désactivé pour les environnements Docker exécutant Docker Compose. Vous devez configurer votre serveur pour qu'il écrive les journaux à l'emplacement et au format utilisés par l'agent d'état Elastic Beanstalk. Cela vous permet d'utiliser pleinement les rapports d'intégrité améliorés, même si le proxy du serveur web est désactivé.

Pour obtenir des instructions sur la façon de procéder, veuillez consulter Configuration de journal de serveur web

Journalisation personnalisée des conteneurs Docker avec Docker Compose

Afin de résoudre efficacement les problèmes et de surveiller vos services conteneurisés, vous pouvez demander des journaux d'instance à Elastic Beanstalk via la console de gestion de l'environnement ou via EB. CLI Les journaux d'instance sont composés de journaux de groupe et de journaux de fin, combinés et empaquetés pour vous permettre d'afficher les journaux et les événements récents de manière efficace et directe.

Elastic Beanstalk crée des répertoires de journaux sur l'instance de conteneur, un pour chaque service défini dans le fichier docker-compose.yml, à l'emplacement /var/log/eb-docker/containers/<service name>. Si vous utilisez la fonctionnalité Docker Compose sur la plateforme Docker Amazon Linux 2, vous pouvez monter ces répertoires à l'emplacement souhaité dans la structure du fichier de conteneur où les journaux sont écrits. Lorsque vous montez des répertoires de journaux pour écrire des données de journaux, Elastic Beanstalk peut collecter les données de journaux à partir de ces répertoires.

Si vos applications se trouvent sur une plateforme Docker qui n'utilise pas Docker Compose, vous pouvez suivre la procédure standard décrite dans Journalisation personnalisée des conteneurs Docker avec Docker Compose.

Pour configurer les fichiers journaux de votre service afin qu'ils soient des fichiers de fin et des journaux de groupe récupérables

1. Modifiez le fichier docker-compose.yml.

2. Sous la clé volumes de votre service, ajoutez un montage lié de la manière suivante :

   "${EB_LOG_BASE_DIR}/<service name>:<log directory inside container>

   Dans l'exemple de fichier docker-compose.yml ci-dessous :

   • nginx-proxyest <service name>

   • /var/log/nginxest <log directory inside container>

   services:
     nginx-proxy:
       image: "nginx"
       volumes:
         - "${EB_LOG_BASE_DIR}/nginx-proxy:/var/log/nginx"

• Le répertoire var/log/nginx contient les journaux du service nginx-proxy dans le conteneur, et il sera mappé au répertoire /var/log/eb-docker/containers/nginx-proxy sur l'hôte.

• Tous les journaux de ce répertoire peuvent désormais être récupérés sous forme de journaux de processus et de groupe via la fonctionnalité de demande de journaux d'instance d'Elastic Beanstalk.

Remarques

• $ {EB_ _ LOG BASE _DIR} est une variable d'environnement définie par Elastic Beanstalk avec la valeur. /var/log/eb-docker/containers

• Elastic Beanstalk crée automatiquement le répertoire /var/log/eb-docker/containers/<service name> pour chaque service dans le fichier docker-compose.yml.

Images Docker

Les branches Docker et ECS administrées de la plateforme Docker pour Elastic Beanstalk prennent en charge l'utilisation d'images Docker stockées dans un référentiel d'images en ligne public ou privé.

Spécifiez des images par nom dans Dockerrun.aws.json. Notez ces conventions :

• Les images dans les référentiels officiels sur Docker Hub utilisent un nom unique (par exemple, ubuntu ou mongo).

• Les images dans les autres référentiels sur Docker Hub sont qualifiées par un nom d'organisation (par exemple, amazon/amazon-ecs-agent).

• Les images dans les autres référentiels en ligne sont qualifiées par un nom de domaine (par exemple, quay.io/assemblyline/ubuntu ou account-id.dkr.ecr.us-east-2.amazonaws.com/ubuntu:trusty).

Pour les environnements utilisant la plateforme Docker uniquement, vous pouvez également créer votre propre image lors de la création d'environnement avec un fichier Dockerfile. Consultez Création d'images personnalisées avec un Dockerfile pour plus de détails. La plateforme ECS gérée Docker ne prend pas en charge cette fonctionnalité.

Configuration des mises à jour gérées pour les environnements Docker

Avec les mises à jour gérées de la plateforme, vous pouvez configurer votre environnement afin qu'il se mette à jour automatiquement avec la dernière version d'une plateforme selon un calendrier défini.

Dans le cas des environnements Docker, vous pouvez déterminer si une mise à jour de la plateforme automatique doit être appliquée en cas de changement de version de Docker (lorsque la nouvelle version de plateforme inclut une nouvelle version de Docker). Elastic Beanstalk prend en charge les mises à jour de plateformes gérées dans toutes les versions Docker lors de la mise à jour à partir d'un environnement exécutant une version de plateforme Docker antérieure à la version 2.9.0. Lorsqu'une nouvelle version de plateforme inclut une nouvelle version de Docker, Elastic Beanstalk incrémente le numéro de version de la mise à jour mineure. Par conséquent, pour autoriser les mises à jour de plateforme gérées sur différentes versions de Docker, activez les mises à jour gérées de la plateforme pour les mises à jour de version mineure et les correctifs. Pour empêcher les mises à jour de plateforme gérées sur différentes versions de Docker, activez les mises à jour gérées de la plateforme afin d'appliquer uniquement les mises à jour contenant des correctifs.

Par exemple, le fichier de configuration suivant permet les mises à jour gérées de la plateforme à 9 h 00 UTC chaque mardi, tant pour les mises à jour mineures que pour les mises à jour de correctifs, permettant ainsi des mises à jour gérées entre les versions de Docker :

Exemple extensions .eb/ .config managed-platform-update

option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: minor

Pour les environnements exécutant des versions de plateforme Docker 2.9.0 ou antérieures, Elastic Beanstalk n'effectue jamais de mises à jour des plateformes gérées si la nouvelle version de plateforme inclut une nouvelle version de Docker.

Espaces de noms de la configuration Python

Vous pouvez utiliser un fichier de configuration pour définir des options de configuration et exécuter d'autres tâches de configuration d'instance pendant les déploiements. Les options de configuration peuvent être spécifiques à la plate-forme ou s'appliquer à toutes les plateformes du service Elastic Beanstalk dans son ensemble. Les options de configuration sont organisées en espaces de noms.

Note

Ces informations s'appliquent uniquement à l'environnement Docker qui n'exécute pas Docker Compose. Cette option a un comportement différent avec les environnements Docker qui exécutent Docker Compose. Pour de plus amples informations sur les services proxy avec Docker Compose, veuillez consulter Options du conteneur.

La plateforme Docker prend en charge les options des espaces de noms suivants en plus des options prises en charge pour tous les environnements Elastic Beanstalk :

• aws:elasticbeanstalk:environment:proxy – Choisissez le serveur proxy pour votre environnement. Docker prend en charge l'exécution de Nginx ou aucun serveur proxy.

L'exemple de fichier de configuration suivant configure un environnement Docker de façon à ce qu'il n'exécute aucun serveur proxy.

Exemple .ebextensions/docker-settings.config

option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none

Configuration de Docker sur Amazon Linux AMI (antérieur à Amazon Linux 2)

Si votre environnement Elastic Beanstalk Docker utilise une version de plateforme Amazon AMI Linux (antérieure à Amazon Linux 2), consultez les informations supplémentaires contenues dans cette section.

Utilisation d'un fichier d'authentification pour un référentiel privé

Ces informations sont pertinentes pour vous si vous utilisez des images provenant d'un référentiel privé. En commençant par Docker version 1,7, la commande docker login a modifié le nom du fichier d'authentification et le format du fichier. Les versions de la plateforme Amazon Linux AMI Docker (antérieures à Amazon Linux 2) nécessitent l'ancien ~/.dockercfg format de fichier de configuration.

Avec Docker version 1.7 et les versions ultérieures, la commande docker login crée le fichier d'authentification dans ~/.docker/config.json au format suivant.

{
    "auths":{
      "server":{
        "auth":"key"
      }
    }
  }

Avec Docker version 1.6.2 et les versions antérieures, la commande docker login crée le fichier d'authentification dans ~/.dockercfg au format suivant.

{
    "server" :
    {
      "auth" : "auth_token",
      "email" : "email"
    }
  }

Pour convertir un config.json fichier, supprimez la auths clé extérieure, ajoutez une email clé et aplatissez le JSON document pour qu'il corresponde à l'ancien format.

Sur les versions de la plateforme Docker Amazon Linux 2, Elastic Beanstalk utilise le nom et le format de fichier d'authentification les plus récents. Si vous utilisez une version de la plateforme Docker Amazon Linux 2, vous pouvez utiliser le fichier d'authentification créé par la commande docker login sans aucune conversion.

Configuration de volumes de stockage supplémentaires

Pour améliorer les performances sur Amazon LinuxAMI, Elastic Beanstalk configure EBS deux volumes de stockage Amazon pour les instances Amazon de votre environnement Docker. EC2 Outre le volume racine fourni pour tous les environnements Elastic Beanstalk, un deuxième volume de 12 Go nommé xvdcz est mis en service pour le stockage d'images sur les environnements Docker.

Si vous avez besoin de plus d'espace de stockage ou d'une augmentation IOPS pour les images Docker, vous pouvez personnaliser le volume de stockage des images en utilisant l'option de BlockDeviceMapping configuration dans l'espace de noms aws:autoscaling:launchconfiguration.

Par exemple, le fichier de configuration suivant augmente la taille du volume de stockage à 100 Go, 500 étant provisionnés IOPS :

Exemple .ebextensions/blockdevice-xvdcz.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500

Si vous utilisez l'option BlockDeviceMappings pour configurer des volumes supplémentaires pour votre application, vous devez inclure un mappage pour xvdcz pour vous assurer de sa création. L'exemple suivant configure deux volumes, le volume de stockage d'image xvdcz avec les paramètres par défaut et un volume d'application de 24 Go supplémentaires nommé sdh :

Exemple .ebextensions/blockdevice-sdh.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24

Note

Lorsque vous modifiez les paramètres dans cet espace de noms, Elastic Beanstalk remplace toutes les instances de votre environnement par des instances exécutant la nouvelle configuration. Consultez Configuration changes pour plus de détails.