Conteneurs de service

Azure DevOps Services

Si votre pipeline nécessite la prise en charge d’un ou plusieurs services, vous devrez peut-être créer, vous connecter et nettoyer les services par travail. Par exemple, votre pipeline peut exécuter des tests d’intégration qui nécessitent l’accès à une base de données et un cache mémoire nouvellement créés pour chaque travail du pipeline.

Un conteneur fournit un moyen simple et portable d’exécuter un service dont dépend votre pipeline. Un conteneur de service vous permet de créer, de réseau et de gérer automatiquement le cycle de vie d’un service conteneurisé. Chaque conteneur de service est accessible uniquement au travail qui en a besoin. Les conteneurs de service fonctionnent avec n’importe quel type de travail, mais sont les plus couramment utilisés avec les travaux de conteneur.

Spécifications

• Les conteneurs de service doivent définir un CMD ou ENTRYPOINT. Le pipeline s’exécute docker run pour le conteneur fourni sans argument.

• Azure Pipelines peut exécuter des conteneurs Linux ou Windows. Vous pouvez utiliser le pool de conteneurs Ubuntu hébergé pour les conteneurs Linux ou le pool Windows hébergé pour les conteneurs Windows. Le pool macOS hébergé ne prend pas en charge l’exécution de conteneurs.

Travail de conteneur unique

L’exemple de définition de pipeline YAML suivant montre un seul travail de conteneur.

resources:
  containers:
  - container: my_container
    image: buildpack-deps:focal
  - container: nginx
    image: nginx

pool:
  vmImage: 'ubuntu-latest'

container: my_container
services:
  nginx: nginx

steps:
- script: |
    curl nginx
  displayName: Show that nginx is running

Le pipeline précédent récupère les conteneurs et buildpack-deps les nginx conteneurs à partir de Docker Hub, puis démarre les conteneurs. Les conteneurs sont mis en réseau ensemble afin qu’ils puissent se joindre les uns aux autres par leur nom services.

À partir de ce conteneur de travaux, le nginx nom d’hôte est résolu sur les services appropriés à l’aide de la mise en réseau Docker. Tous les conteneurs du réseau exposent automatiquement tous les ports les uns aux autres.

Travail unique noncontainer

Vous pouvez également utiliser des conteneurs de service sans conteneur de travaux, comme dans l’exemple suivant.

resources:
  containers:
  - container: nginx
    image: nginx
    ports:
    - 8080:80
    env:
      NGINX_PORT: 80
  - container: redis
    image: redis
    ports:
    - 6379

pool:
  vmImage: 'ubuntu-latest'

services:
  nginx: nginx
  redis: redis

steps:
- script: |
    curl localhost:8080
    echo $AGENT_SERVICES_REDIS_PORTS_6379

Le pipeline précédent démarre les derniers nginx conteneurs. Étant donné que le travail n’est pas en cours d’exécution dans un conteneur, il n’y a pas de résolution automatique de noms. Au lieu de cela, vous pouvez accéder aux services à l’aide localhostde . L’exemple fournit explicitement le 8080:80 port.

Une autre approche consiste à laisser un port aléatoire être affecté dynamiquement au moment de l’exécution. Vous pouvez ensuite accéder à ces ports dynamiques à l’aide de variables. Ces variables prennent la forme suivante : agent.services.<serviceName>.ports.<port>. Dans un script Bash, vous pouvez accéder aux variables à l’aide de l’environnement de processus.

Dans l’exemple précédent, redis un port disponible aléatoire est attribué sur l’hôte. La variable agent.services.redis.ports.6379 contient le numéro de port.

Plusieurs travaux

Les conteneurs de service sont également utiles pour exécuter les mêmes étapes sur plusieurs versions du même service. Dans l’exemple suivant, les mêmes étapes s’exécutent sur plusieurs versions de PostgreSQL.

resources:
  containers:
  - container: my_container
    image: ubuntu:22.04
  - container: pg15
    image: postgres:15
  - container: pg14
    image: postgres:14

pool:
  vmImage: 'ubuntu-latest'

strategy:
  matrix:
    postgres15:
      postgresService: pg15
    postgres14:
      postgresService: pg14

container: my_container

services:
  postgres: $[ variables['postgresService'] ]
steps:
- script: printenv

Ports

Lorsque vous appelez une ressource de conteneur ou un conteneur inline, vous pouvez spécifier un tableau de ports données à exposer sur le conteneur, comme dans l’exemple suivant.

resources:
  containers:
  - container: my_service
    image: my_service:latest
    ports:
    - 8080:80
    - 5432

services:
  redis:
    image: redis
    ports:
    - 6379/tcp

La spécification ports n’est pas nécessaire si votre travail s’exécute dans un conteneur, car les conteneurs sur le même réseau Docker exposent automatiquement tous les ports les uns aux autres par défaut.

Si votre travail s’exécute sur l’hôte, ports vous devez accéder au service. Un port prend la forme <hostPort>:<containerPort> ou simplement <containerPort> avec une option facultative /<protocol> à la fin. Par exemple, 6379/tcp expose tcp sur le port 6379, lié à un port aléatoire sur l’ordinateur hôte.

Pour les ports liés à un port aléatoire sur l’ordinateur hôte, le pipeline crée une variable du formulaire agent.services.<serviceName>.ports.<port> afin que le travail puisse accéder au port. Par exemple, agent.services.redis.ports.6379 résout le port attribué de manière aléatoire sur l’ordinateur hôte.

Volumes

Les volumes sont utiles pour partager des données entre des services ou pour conserver des données entre plusieurs exécutions d’un travail. Vous spécifiez des montages de volume sous la forme d’un tableau de volumes formulaire, où <source> il peut s’agir d’un volume nommé ou d’un chemin absolu sur l’ordinateur hôte et <destinationPath> est un chemin absolu <source>:<destinationPath>dans le conteneur. Les volumes peuvent être nommés volumes Docker, volumes Docker anonymes ou montages de liaison sur l’hôte.

services:
  my_service:
    image: myservice:latest
    volumes:
    - mydockervolume:/data/dir
    - /data/dir
    - /src/dir:/dst/dir

Options de démarrage

Les conteneurs de service partagent les mêmes ressources de conteneur que les travaux de conteneur. Cela signifie que vous pouvez utiliser les mêmes options de démarrage.

Contrôle d’intégrité

Si un conteneur de service spécifie un HEALTHCHECK, l’agent peut éventuellement attendre que le conteneur soit sain avant d’exécuter le travail.

Exemple de plusieurs conteneurs avec services

L’exemple suivant contient un conteneur web Python Django connecté aux conteneurs de base de données PostgreSQL et MySQL.

• La base de données PostgreSQL est la base de données primaire et son conteneur est nommé db.
• Le conteneur utilise le db volume /data/db:/var/lib/postgresql/dataet il existe trois variables de base de données transmises au conteneur via env.
• Le conteneur utilise le mysql port 3306:3306et il existe également des variables de base de données passées via env.
• Le conteneur web est ouvert avec le port 8000.

Dans les étapes, pip installe les dépendances, puis les tests Django s’exécutent.

Pour configurer un exemple de travail, vous avez besoin d’un site Django configuré avec deux bases de données. L’exemple suppose que votre fichier manage.py se trouve dans le répertoire racine et que votre projet Django se trouve également dans ce répertoire. Si ce n’est pas le cas, vous devrez peut-être mettre à jour le chemin d’accès /__w/1/s/ dans /__w/1/s/manage.py test.

resources:
  containers:
    - container: db
      image: postgres
      volumes:
          - '/data/db:/var/lib/postgresql/data'
      env:
        POSTGRES_DB: postgres
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: postgres
    - container: mysql
      image: 'mysql:5.7'
      ports:
         - '3306:3306'
      env:
        MYSQL_DATABASE: users
        MYSQL_USER: mysql
        MYSQL_PASSWORD: mysql
        MYSQL_ROOT_PASSWORD: mysql
    - container: web
      image: python
      volumes:
      - '/code'
      ports:
        - '8000:8000'

pool:
  vmImage: 'ubuntu-latest'

container: web
services:
  db: db
  mysql: mysql

steps:
    - script: |
        pip install django
        pip install psycopg2
        pip install mysqlclient
      displayName: set up django
    - script: |
          python /__w/1/s/manage.py test

Contenu connexe

• Spécifier des travaux dans votre pipeline
• Utiliser des travaux de conteneur dans des pipelines YAML