Docker - как перестроить и обновить контейнер без простоя с помощью docker-compose?

Предварительные требования

Для выполнения этого руководства вам потребуется сервер Ubuntu 18.04 и следующее:

Пользователь с привилегиями sudo без прав root (в статье Начальная настройка сервера с Ubuntu 18.04 объясняется, как это настроено).
Docker, установленный согласно инструкциям в шаге 1 и шаге 2 руководства Установка и использование Docker в Ubuntu 18.04

После установки всех необходимых компонентов мы сможем двигаться дальше.

Примечание. Хотя в предварительных условиях содержатся указания по установке Docker в Ubuntu 18.04 команды в этой статье должны работать в других операционных системах, где установлен Docker.

Основы ENTRYPOINT && CMD

Перед началом нужно кратко вспомнить, что это такое и чем отличается. Эти две директивы в Dockerfile наверняка всем известны – обе запускают процессы в контейнере. Как правило, в entrypoint используется какой-либо скрипт или команда для запуска процесса внутри контейнера, а в cmd – параметры, которые передаются в entrypoint.

Если указывать параметры в квадратных скобках, т.е. в формате exec, то внутри контейнера будет выполняться лишь процесс, который указан для запуска, и никаких оболочек запущено не будет. Это значит, что замена (substitution) переменных и их обработка невозможны – это также предпочтительный вариант для простого запуска какого-либо процесса. О более сложных моментах будет рассказано далее.

Если же указать команду для запуска без фигурных скобок, то внутри контейнера можно будет увидеть, что процесс запущен через форму shell и процесс внутри будет вида sh -c “ping ya.ru”.

Грубый пример Dockerfile для демонстрации работы exec формы:

После сборки образа с именем “ping” и дальнейшего запуска контейнера из него будет выполняться команда “/bin/ping it-lux.ru”. Домен можно переопределить, указав его при запуске контейнера, например:

Тем самым выполняется переопределение значения из параметра CMD в Dockerfile, что очень удобно – из одного образа можно запускать команды с различными аргументами. Такой способ я использовал для выполнения крон-задач в отдельном докер-контейнере, указывая на хосте в crontab через аргументы путь к скриптам при запуске docker run, которые принимал для выполнения php.

Что такое Composefile?

Composefile используется в двух типах развертываний: в некластерном развертывании с помощью docker-compose и кластерном развертывании с docker swarm.

Чтобы различать эти два типа, мы собираемся обратиться к файлу набора, отвечающему за развертывание кластера, как к файлам стека. Мы расскажем о файлах стека чуть позже.

Компоновка файлов – это часть инструмента, называемого docker-compose. Это клиентское приложение для сервера демона докеров, что-то вроде docker клиента CLI, но вместо того, чтобы каждый раз запускать все команды docker-compose, вы можете повторно использовать один и тот же файл YAML снова и снова и развертывать один и тот же контейнер с тем же конфигурация, как и в первый раз.

Он более читаемый, более удобный в обслуживании, более интуитивно понятный. Один файл компоновки может содержать несколько конфигураций развертывания контейнера.

Поддержка файла Compose будет частью клиента докеров по умолчанию, который написан на Go в качестве аргумента командной строки «docker compose». Обратите внимание на отсутствующий дефис. Это все еще экспериментально, поэтому в производстве по-прежнему рекомендуется использовать версию Python, т.е. docker-compose.. Давайте возьмем предыдущий образ и развернем его, используя файл набора

Давайте возьмем предыдущий образ и развернем его, используя файл набора.

version: "3.3"

services:
    fortune:
        image: "fortune:alpine"

Сохраните файл как docker-compose.yml. Теперь запустите в том же каталоге следующую команду

docker-compose up

Вы не должны сохранить файл как docker-compose.yml, вы можете сохранить его, как вам нравится, но если это не так, docker-compose.yml или docker-compose.yaml, убедитесь, что вы используете опцию -f .

docker-compose -f docker-compose.yml up

Подождите и посмотрите, что произойдет.

Что такое файл стека?

Файлы стека идентичны файлам компоновки с аналогичным синтаксисом и большинством внутренних параметров, за некоторыми исключениями. Файлы стека используются для развертывания стеков сервисов в роевом кластере.

Вы можете повторно использовать предыдущий файл композиции непосредственно как файл стека.

Сначала инициализируйте кластер.

docker swarm init

Затем запустите команду, подобную следующей

docker stack deploy -c docker-compose.yml fortune

При таком развертывании необходимо проверить вывод, просмотрев журналы службы с помощью docker service logs ….

Этап 2. «Мы тоже так хотим»

Когда вы все это развернете, то, конечно же, захотите похвастаться перед коллегами: «Смотрите, как у меня все работает!»

Конечно же, они скорее всего захотят свои проекты потестировать. Ну или у вас там не один проект, вы еще какие-то другие проекты захотите запускать. Получается, вам вашу схему надо отмасштабировать.
Поскольку у вас, скорее всего, по-прежнему останется один сервер, а проектов будет много, у вас начнут появляться очереди на сборку. То есть вы запускаете задание, оно сколько-то выполняется, а за ним следующее-следующее-следующее, и т.д.
Чтобы разгрузить эти очереди, вы будете заводить несколько агентов на сборку – то есть машины, на которых вы будете выполнять задания. Мы пробовали разные схемы – поднимали виртуальные машины, брали просто несколько компьютеров, в частности, запускали прямо на компьютерах разработчиков. Последний более-менее рабочий вариант у нас был – мы завели мультилогон на одном из серверов и просто в нескольких сессиях запускали тесты. В общем, это не очень хорошая история, не советую на ней долго останавливаться.
Вам придется идти на какой-то компромисс по окружению, а поскольку вы уже будете запускаться не один, то вам надо договориться – какое же программное обеспечение у вас будет стоять, на каких платформах вы будете тестироваться.
Ну и начинать потихонечку добавлять метрики и мониторинг, чтобы вся эта ваша система не упала.

Создание docker контейнеров в Unix/Linux

Приводил примеры в своей статье:

По данной статье — создание докер контейнеров ( а в ней я приводил сборку LEMP-а), я соберу кластер из всех этих служб внутри каждого из контейнеров ( т.к по одному из запускать уже не актуально).

Создаем docker-compose.yml файл:

# vim docker-compose.yml

И прописываем в него:

version: "2"
services:
  nginx:
    image: nginx:latest
    #environment: 
    #  NGINX_SERVER_NAME: docker_machine.local   
    container_name: lemp_nginx
    restart: always
    links:
      - php
    volumes:
      - ./DATA/html:/var/www/html/:ro
      #- ./DATA/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./DATA/nginx/conf.d:/etc/nginx/conf.d:ro
    ports:
      - 80:80
      - 443:443
    networks:
      - bridge
  php:
    image: php:latest
    container_name: lemp_php
    restart: always
    volumes:
      #- ./DATA/php-fpm/site.conf:/usr/local/etc/php-fpm.d:ro 
      - ./DATA/html:/var/www/html
    depends_on:
      - db
    links:
      - db
    networks:
      - bridge
    environment:
      - DB_NAME=lemp_magento
      - TABLE_PREFIX=lemp_
      - DB_HOST=lemp
      - DB_PASSWORD=magento
      - PHP_HOST_NAME=localhost:9000
  db:
    image: mariadb:latest
    container_name: lemp_mariadb
    restart: always
    volumes:
      #- ./DATA/mariadb/my.cnf:/etc/mysql/my.cnf:ro  
      #- ./DATA/mariadb/conf.d:/etc/mysql/conf.d:ro
      - db-data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root666PW
    networks:
      - bridge
volumes:
  db-data:
    driver: local

networks:
  bridge:
    driver: bridge
    ipam:
     config:
       - subnet: 172.10.1.0/16
         gateway: 172.10.1.255
         aux_addresses:
           nginx: 172.10.1.10
           php: 172.10.1.20      
           db: 172.10.1.30

Для запуска всего этого добра, служит команда:

┌(vagrant@vagrant-ansible)─(✓)─(10:23 pm Sun Feb 05)
└─(~/magento2)─(6 files, 12Kb)─> sudo docker-compose up -d
Starting lemp_mariadb
Starting lemp_php
Starting lemp_nginx

┌(vagrant@vagrant-ansible)─(✓)─(10:23 pm Sun Feb 05)
└─(~/magento2)─(6 files, 12Kb)─>

Чтобы убить созданное, используем:

$ sudo docker-compose kill

Killing lemp_nginx ... done
Killing lemp_php ... done
Killing lemp_mariadb ... done

Открываем браузер и тестируем созданный стек. А статья «Работа с docker + docker-compose в Unix/Linux» завершена.

Работа с образами

Docker — больше, чем просто программа. Это целая экосистема со множеством проектов и сервисов. Главный сервис, с которым вам придется иметь дело — Registry. Хранилище образов.

Когда мы выполняем команду run , то Docker проверяет наличие указанного образа на локальной машине и скачивает его по необходимости. Список образов, уже скачанных на компьютер, можно посмотреть командой :

Разберемся с тем, как формируется имя образа, и что оно в себя включает.

Вторая колонка в выводе выше называется TAG. Когда мы выполняли команду , то на самом деле выполнялась команда . То есть мы не просто скачиваем образ nginx, а скачиваем его конкретную версию. Latest — тег по умолчанию. Несложно догадаться, что он означает последнюю версию образа.

Важно понимать, что это всего лишь соглашение, а не правило. Конкретный образ вообще может не иметь тега latest, либо иметь, но он не будет содержать последние изменения, просто потому, что никто их не публикует

Впрочем, популярные образы следуют соглашению. Как понятно из контекста, теги в Докере изменяемы, другими словами, вам никто не гарантирует, что скачав образ с одним и тем же тегом на разных компьютерах в разное время вы получите одно и то же. Такой подход может показаться странным и ненадежным, ведь нет гарантий, но на практике есть определенные соглашения, которым следуют все популярные образы. Тег latest действительно всегда содержит последнюю версию и постоянно обновляется, но кроме этого тега активно используется семантическое версионирование. Рассмотрим https://hub.docker.com/_/nginx

Теги, в которых присутствует полная семантическая версия (x.x.x) всегда неизменяемы, даже если в них встречается что-то еще, например, 1.12.2-alphine. Такую версию смело нужно брать для продакшен-окружения. Теги, подобные такому 1.12, обновляются при изменении path версии. То есть внутри образа может оказаться и версия 1.12.2, и в будущем 1.12.8. Точно такая же схема и с версиями, в которых указана только мажорная версия, например, 1. Только в данном случае обновление идет не только по патчу, но и по минорной версии.

Как вы помните, команда скачивает образ, если его нет локально, но эта проверка не связана с обновлением содержимого. Другими словами, если nginx:latest обновился, то его не будет скачивать, он использует тот latest, который прямо сейчас уже загружен. Для гарантированного обновления образа существует другая команда: . Вот она всегда проверяет, обновился ли образ для определенного тега.

Кроме тегов имя образа может содержать префикс: например, . Этот префикс является именем аккаунта на сайте, через который создаются образы, попадающие в Registry. Большинство образов как раз такие, с префиксом. И есть небольшой набор, буквально сотня образов, которые не имеют префикса. Их особенность в том, что эти образы поддерживает сам Docker. Поэтому если вы видите, что в имени образа нет префикса, значит это официальный образ. Список таких образов можно увидеть здесь: https://github.com/docker-library/official-images/tree/master/library

Удаляются образы командой .

Если в Докере присутствует хоть один контейнер из удаляемого образа, то Докер не даст его удалить по понятным причинам. Если вы всё же хотите удалить и образ, и все контейнеры, связанные с ним, используйте флаг .

Код приложения

В открывшемся проекте рядом с главным классом, содержащим метод main, создаём ещё один класс — контроллер с методом hello ().

Класс помечен аннотацией @RestController, означающей, что он предназначен для обработки web-запросов. А метод помечен аннотацией @GetMapping c адресом «/» — перейдя по нему (выполнив get-запрос к http://localhost:8080/), мы получим сообщение «Hello Docker!»

Теперь открываем терминал и вводим команду:

Она упакует приложение в jar-файл и запустит его. Чтобы убедиться в корректности работы приложения — перейдём на http://localhost:8080/ в браузере и увидим заветное сообщение.

Теперь создаём файл с именем Dockerfile в корне проекта, который содержит инструкции для сборки образа со следующим текстом:

Вот что происходит, когда мы вводим этот код:

Команда	Описание
FROM adoptopenjdk/openjdk11:alpine-jre	Oбраз создаётся на основе alpine linux с установленной openjdk11
ARG JAR_FILE=target/spring-docker-simple-0.0.1-SNAPSHOT.jar	Переменной JAR_FILE присваивается путь к jar- архиву
WORKDIR /opt/app	Назначаем рабочую директорию, в которой будут выполняться дальнейшие команды (перемещаемся в папку app)
COPY ${JAR_FILE} app.jar	Наш jar-файл, указанный в JAR_FILE, копируется в папку app, и копии задаётся имя app.jar
ENTRYPOINT	jar-файл запускается, собирается команда java -jar app.jar из заданной рабочей директории

После этого в терминале вводим команду, с помощью которой собираем образ и запускаем контейнер.

Точка в конце важна, она указывает на расположение Dockerfile (символ «точка» означает текущую директорию. Проверьте, что образ создан командой docker images. Вывод должен быть таким:

Запускаем контейнер командой:

Опция -d означает старт процесса в фоновом режиме. Опция -p тоже важна — дело в том, что контейнер собирается в полностью изолированном окружении. Тот факт, что приложение внутри контейнера запущено на порту 8080, не означает, что оно доступно вне контейнера на этом порту.

Требуется явно указать, что порту 8080 в контейнере (здесь второе значение — это порт, на котором работает наше приложение в контейнере) соответствует порт 8080 на локальной машине, который будет использоваться при обращении к контейнеру. Поэтому пишем через двоеточие -p 8080:8080.

Теперь введём в терминале команду:

Шаг 2 — Запуск контейнера с помощью Docker Compose

В общедоступном реестре Docker, Docker Hub, содержится образ Hello World, используемый для демонстрации и тестирования. Он демонстрирует минимальные параметры конфигурации, необходимые для запуска контейнера с помощью Docker Compose: файл YAML, вызывающий отдельный образ:

Сначала мы создадим директорию для файла YAML и перейдем в нее:

Затем мы создадим в этой директории файл YAML:

Поместите в файл следующие данные, сохраните его и закройте текстовый редактор:

docker-compose.yml

Первая строка файла YAML используется в качестве части имени контейнера. Вторая строка указывает, какой образ используется для создания контейнера. При запуске команды она будет искать локальный образ по указанному имени, т.е. . После этого можно сохранить и закрыть файл.

Мы можем вручную просмотреть образы в нашей системе с помощью команды :

Когда локальные образы отсутствуют, будут отображены только заголовки столбцов:

Далее, находясь в директории , мы выполним следующую команду:

При первом запуске команды, если локальный образ с именем отсутствует, Docker Compose будет загружать его из открытого репозитория Docker Hub:

После загрузки образа создает контейнер, помещает в него и запускает программу hello, что, в свою очередь, подтверждает, что установка, выполнена успешно:

Затем программа отображает объяснение того, что она сделала:

Контейнеры Docker продолжают работать, пока команда остается активной, поэтому после завершения работы контейнер останавливается. Следовательно, когда мы просматриваем активные процессы, заголовки столбцов будут появляться, но контейнер не будет появляться в списке, поскольку он не запущен.

Мы можем просмотреть информацию контейнера, которая нам потребуется на следующем шаге, используя флаг , с помощью которого можно отобразить все контейнеры, а не только активные:

Так мы можем получить информацию, которая нам потребуется для удаления контейнера, когда мы закончим работать с ним.

Области применения

Среды разработки

Запуск и взаимодействие с приложением в изолированной среде — важная часть разработки. Compose помогает создать необходимое окружение и взаимодействовать с ним через интерфейс командной строки.

Вы описываете все зависимости службы в файле — базы данных, веб-службы API, очереди, кеши. Создать и запустить один или несколько контейнеров можно одной командой — .

Такой подход помогает значительно ускорить процесс разработки. Не нужны многостраничные инструкции, вся конфигурация укладывается в один небольшой файл.

Автоматизированные среды тестирования

Для непрерывного проведения автоматизированных тестов нужна изолированная среда. Docker Compose обеспечивает удобный процесс создания и удаления систем для тестирования. Все действия можно уложить в три простые команды:

docker-compose up -d
./run_tests
docker-compose down

В этом примере вы запускаете приложение, выполняете необходимые тесты и останавливаете выполнение контейнера.

Развертывание хоста

Традиционно Compose больше используется для разработки и тестирования. Но с каждым новым релизом в нем появляется больше инструментов для деплоя.

Возможности Docker Desktop

Существует множество преимуществ:

Поддерживает широкий спектр инструментов разработки.
Обеспечьте быстрый и оптимизированный способ создания и публикации контейнерного образа на любой облачной платформе.
Простота установки и настройки полной среды Docker
Повышение производительности благодаря встроенной виртуализации Hyper-V для Windows и HyperKit для MAC.
Возможность работать в Linux через WSL 2 на компьютерах с Windows.
Легкий доступ к работающим контейнерам в локальной сети.
Возможность поделиться любым приложением на облачной платформе, на разных языках и в разных средах.
Для обеспечения безопасности и актуальности выполняются автоматические обновления.
Включены последние версии Kubernetes.
Возможность переключения между Linux и Windows сервером на Windows.

Однако

Также рекомендуем прочитать:

Docker для начинающих — технология контейнеров
В чем разница между Docker и Kubernetes?
Введение в Docker Hub и все, что вы должны знать о нем
Как установить Docker на Ubuntu, Windows, Debian и CentOS?
Kubernetes — Введение для начинающих
Docker посмотреть запущенные контейнеры, запустить или остановить контейнеры

Что такое Dockerfile

Dockerfile — это текстовый файл, содержащий все команды, которые пользователь может запустить в командной строке для создания образа. Он включает в себя все инструкции, необходимые Docker для создания образа.

Образы Docker состоят из серии слоев файловой системы, представляющих инструкции в файле Dockerfile образа, составляющем исполняемое программное приложение.

Файл Docker имеет следующую форму:

не чувствительна к регистру, но по соглашению для ее имен используется ЗАПИСЬ.

Ниже приведен список с кратким описанием некоторых из наиболее часто используемых инструкций Dockerfile:

ARG — эта инструкция позволяет вам определять переменные, которые могут быть переданы во время сборки. Вы также можете установить значение по умолчанию.
FROM — базовое изображение для построения нового изображения. Эта инструкция должна быть первой инструкцией без комментариев в Dockerfile. Единственное исключение из этого правила — когда вы хотите использовать переменную в аргументе . В этом случае может предшествовать одна или несколько инструкций .
LABEL — используется для добавления метаданных к изображению, таких как описание, версия, автор и т. Д. Вы можете указать несколько , и каждая инструкция представляет собой пару «ключ-значение».
RUN — команды, указанные в этой инструкции, будут выполняться в процессе сборки. Каждая инструкция создает новый слой поверх текущего изображения.
ДОБАВИТЬ — используется для копирования файлов и каталогов из указанного источника в указанное место назначения в образе докера. Источником могут быть локальные файлы, каталоги или URL. Если источником является локальный tar-архив, он автоматически распаковывается в образ Docker.
КОПИРОВАТЬ — аналогично но источником может быть только локальный файл или каталог.
ENV — Эта инструкция позволяет вам определить переменную среды.
CMD — используется для указания команды, которая будет выполняться при запуске контейнера. Вы можете использовать только одну инструкцию в своем Dockerfile.
ENTRYPOINT — аналогично , эта инструкция определяет, какая команда будет выполняться при запуске контейнера.
WORKDIR — эта директива устанавливает текущий рабочий каталог для инструкций , , , и .
ПОЛЬЗОВАТЕЛЬ — Установите имя пользователя или для использования при выполнении любых следующих инструкций , , , и .
VOLUME — позволяет подключить каталог хост-машины к контейнеру.
EXPOSE — используется для указания порта, на котором контейнер прослушивает во время выполнения.

Чтобы исключить добавление файлов и каталогов в образ, создайте файл в контекстном каталоге. Синтаксис аналогичен файла Git.

Общие сведения о контейнерах Docker

Docker — это средство для создания, развертывания и запуска приложений с использованием контейнеров. Контейнеры позволяют разработчикам упаковывать приложения с использованием всех необходимых компонентов (библиотек, платформ, зависимостей и т. п.) и поставлять все это как один пакет. Использование контейнера дает возможность приложению работать одинаково, независимо от настроенных параметров или ранее установленных библиотек на компьютере, где оно запускается, так как он может отличаться от компьютера, который использовался для написания и тестирования кода приложения. Это позволяет разработчикам сосредоточиться на написании кода, не беспокоясь о том, в какой системе он будет выполняться.

Контейнеры Docker похожи на виртуальные машины, но не создают всю виртуальную операционную систему. Вместо этого контейнер Docker позволяет приложению использовать то же ядро Linux, что и система, в которой оно работает. Таким образом пакету приложения требуются только те части, которых еще нет на главном компьютере. В результате размер пакета уменьшается, а производительность увеличивается.

Постоянная доступность, которую обеспечивает использование контейнеров Docker с такими инструментами, как Kubernetes, — еще одна причина популярности контейнеров. Это позволяет создавать несколько версий контейнера приложения в разное время. Вместо того чтобы останавливать всю систему для обновления или обслуживания, каждый контейнер (и определенные микрослужбы) можно заменить на лету. Вы можете подготовить новый контейнер со всеми обновлениями, настроить его для рабочей среды и просто указать новый контейнер после его готовности. Можно также архивировать различные версии вашего приложения, используя контейнеры, и при необходимости поддерживать их работу в качестве резервного ресурса.

Дополнительные сведения см. в разделе Введение в контейнеры DOCKER на Microsoft Learn.

Установка docker-compose в Unix/Linux

Ну, чтобы использовать compose в docker — нужно его установить. Осуществить это можно несколькими способами.

1. Выкачать файл:

Выкачиваем последнюю версию данной утилиты и сохраняем ее в нужное место:

$ curl -L "https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Выставляем права:

# chmod +x /usr/local/bin/docker-compose

2. Использовать pip:

# pip install docker-compose

И проверяем чтобы все работало:

$ docker-compose --version

docker-compose version 1.7.0, build 0d7bf73

Если есть необходимость удалить:

# rm /usr/local/bin/docker-compose

Или если использовали pip:

# pip uninstall docker-compose

Define the app service

To remember, this was the command we were using to define our app container.

If you are using PowerShell then use this command:

First, let’s define the service entry and the image for the container. We can pick any name for the service.
The name will automatically become a network alias, which will be useful when defining our MySQL service.
Typically, you will see the close to the definition, although there is no requirement on ordering.
So, let’s go ahead and move that into our file.
Let’s migrate the part of the command by defining the for the service. We will use the
here, but there is also a more verbose
available as well.
Next, we’ll migrate both the working directory () and the volume mapping () by using
the and definitions. Volumes also has a and syntax.

One advantage of Docker Compose volume definitions is we can use relative paths from the current directory.
Finally, we need to migrate the environment variable definitions using the key.

Define the MySQL service

Now, it’s time to define the MySQL service. The command that we used for that container was the following:

If you are using PowerShell then use this command:

We will first define the new service and name it so it automatically gets the network alias. We’ll
go ahead and specify the image to use as well.
Next, we’ll define the volume mapping. When we ran the container with , the named volume was created
automatically. However, that doesn’t happen when running with Compose. We need to define the volume in the top-level
section and then specify the mountpoint in the service config. By simply providing only the volume name,
the default options are used. There are though.
Finally, we only need to specify the environment variables.

At this point, our complete should look like this:

Запуск тестирования на GitLab и Jenkins

При запуске этой сборки у нас опять возникает картинка – Jenkins против GitLab CI.

Сначала посмотрим GitLab, потому что он чуть проще.

На машине, где установлен Docker, вам нужно зарегистрировать GitLab runner – он запускает тесты в GitLab CI.

Дальше – в файле gitlab-ci.yml вы указываете:

образ, в котором хотите запускать тесты;
на каких компьютерах вы хотите их запускать;
GitLab сам скачивает последнюю версию образа, запускает контейнер, и потом все эти команды будут выполняться уже внутри контейнера.

То есть вам не надо сильно изучать Docker – вы просто пишете типовые команды.

Теперь как это устроено в Jenkins – он позволяет настроить более тонко, но и настраивать это дольше.

Первое, что вам надо – это запустить на вашем Docker-хосте Docker-daemon https://docs.docker.com/engine/reference/commandline/dockerd.
На Jenkins вам надо поставить Docker-plugin – это позволяет запустить Docker Cloud Provider.
Самая большая проблема – это то, что в ваших Docker-образах должна быть установлена Java и, собственно, агент Jenkins. По адресу https://github.com/jenkinsci/docker-inbound-agent есть официальный пример от Jenkins, как это добавить.
А дальше вы каждому такому образу присваиваете Label, который будет соответствовать Jenkins-агентам.

Как это выглядит на практике?

У вас на Jenkins по каким-то триггерам или при помещении кода, или по таймеру в очередь встает задание.
Jenkins смотрит, что это задание надо запускать на Cloud-провайдере каком-то, запрашивает возможность запустить эти данные – проверяет, хватает там сейчас памяти или нет.
Готовит специальный образ только под эту задачу, в него подключается и дальше запускает задачки внутри контейнера.

Как настраивается Cloud Provider?

Если вы запускаете тестирование просто на Docker, то вам надо указать IP-адрес вашего Docker-хоста и авторизацию, если есть.

И дальше нужно описать, какие Docker-агенты вы будете запускать – на базе какого образа, назначить ему Label и, если нужно, дополнительные параметры.

Теперь в задаче Jenkins вы:

указываете Label контейнера;
если хотите больших настроек, можно указывать вручную образ и параметры запуска;
а дальше пишите типовой код на Jenkins, указывая путь к Jenkinsfile.

На слайде показано, как выглядит Jenkinsfile у нас.

Мы говорим, что хотим собираться на версии платформы 8.3.15, а дальше у нас обыкновенный код – мы подготавливаем папки, забираем наш репозиторий, ну и запускаем тесты. В частности, тут юниты.

Если хотим больше настроек, мы можем прямо указать, с какого Docker Registry скачивать, какую версию.

И тут через точку можно указывать кучу параметров – сколько памяти он будет занимать, как долго контейнер будет жить и т.д. и т.п.