Docker и docker compose в чем разница

Различия Между Docker Compose И Docker Stack

Данная статья является переводом англоязычной статьи Владислава Супалова.

В связи с последними релизами в мире Docker произошли некоторые изменения. В версии 1.12 в Docker Engine был интегрирован режим Swarm, в связи с чем появилось несколько новых инструментов. Среди прочего, теперь появилась возможность использовать Compose-файлы docker-compose.yml для создания стеков контейнеров Docker без необходимости устанавливать инструмент Docker Compose.

Теперь для этого есть команда docker stack, и она очень похожа на docker-compose . Сравните:

$ docker-compose -f docker-compose up $ docker stack deploy -c docker-compose.yml somestackname

Обе команды создают все сервисы, тома, сети и все остальное, что определено в файлах docker-compose.yml . Почему получилось так, что возникли два очень похожих инструмента, которые выполняют одну задачу? Отличается ли docker stack от docker-compose ? Зачем создали docker stack ? Что следует учитывать, кроме синтаксиса?

Отличия

Docker-compose – приложение, реализованное на языке Python . Изначально существовал проект под названием fig , который использовался, чтобы анализировать файлы fig.yml для создания стеков контейнеров Docker. Проект был довольно популярным, особенно среди тех, кто работает с Docker, поэтому команда Docker решила создать свою собственную версию, основанную на fig . Они назвали свою новую разработку Docker Compose. Она также создана на Python и работает на базе Docker Engine. Внутри Docker Compose используется Docker API для создания контейнеров в соответствии со спецификацией. Чтобы использовать docker-compose с Docker на вашей машине, вам придется установить его отдельно.

Функциональность docker stack реализована внутри Docker, поэтому для его использования не нужно устанавливать дополнительные пакеты. Развертывание стеков контейнеров является частью режима swarm. Docker Stack поддерживает те же файлы compose, но их обработка производится внутри ядра Docker. Прежде, чем использовать команду stack, необходимо создать “рой” из одной машины, но это не является проблемой.

Есть некоторые различия между Docker Compose и Docker Stack:

Сборка образов. Docker stack игнорирует инструкции build . Вы не сможете собрать новые образы, используя команду stack. Для нее необходимо наличие предварительно собранных образов. Поэтому в случае использования в разработке больше подходит docker-compose .

Спецификация. Также, есть части спецификации файла compose, которые игнорируются командой docker-compose или командой docker stack . Например, docker-compose игнорирует свойство deploy , а docker stack игнорирует depends_on . Есть и другие примеры.

Версии. Docker stack не поддерживает файлы docker-compose.yml , оформленные согласно спецификации версии 2. Версия должна быть последней, на момент написания данной статьи это была версия 3. А docker-compose может без проблем работать с версиями 2 и 3.

Заключение

Обе команды – и docker-compose , и сравнительно новая команда docker stack – могут использоваться с файлами docker-compose.yml , написанными в соответствии со спецификацией версии 3. Для проектов, работающих с версией 2, можно использовать docker-compose или обновить файл для соответствия новой версии.

Так как docker stack делает все то же, что и docker-compose , но является более прогрессивной утилитой, вероятно, что docker stack более предпочтителен для новых проектов. Вероятно, когда-нибудь docker-compose устареет и больше не будет поддерживаться.

Перевести рабочий процесс на docker stack несложно. Это легко можно сделать при обновлении файлов docker compose с версии 2 на версию 3.

Если вы только начали работать с Docker, или находитесь на этапе выбора технологии для нового проекта – без сомнений используйте docker stack .

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

Docker Compose — Docker: Основы

Docker Compose позволяет управлять набором контейнеров, каждый из которых представляет собой один сервис проекта. Управление включает в себя сборку, запуск с учетом зависимостей и конфигурацию. Конфигурация Docker Compose описывается в файле docker-compose.yml, лежащем в корне проекта.

Пример файла docker-compose.yml

# Версия схемы, которую мы используем. # Зависит от установленной версии docker # https://docs.docker.com/compose/compose-file/ version: "3" # Определяем список сервисов — services # Эти сервисы будут частью нашего приложения services: app: # Имя сервиса build: # Контекст для сборки образа, # в данном случае, текущая директория context: . # Имя Docker-файла из которого будет собран образ dockerfile: Dockerfile # Команда, которая будет выполнена после старта сервиса command: make start ports: # Проброс портов - "3000:8000" # Перечисляем тома (volumes) # Они будут подключены к файловой системе сервиса # Например, все что находится в . мы увидим в директории /app volumes: # Текущая директория пробрасывается в директорию /app внутри контейнера # Путь внутри контейнера (после двоеточия) обязательно должен быть абсолютным - ".:/app" - "/tmp:/tmp" # Сервис будет запущен, только после старта db depends_on: - db db: # Имя образа. Здесь мы используем базу данных Postgres image: postgres:latest environment: # А так задаются переменные окружения POSTGRES_PASSWORD: password volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:

Команды для работы с Docker Compose

# Собирает сервисы, описанные в конфигурационных файлах docker compose build # Запускает собранные сервисы docker compose up # Запуск контейнеров на фоне с флагом -d docker compose up -d # Если какой-то из сервисов завершит работу, # то остальные будут остановлены автоматически docker compose up --abort-on-container-exit # Запустит сервис application и выполнит внутри команду make install docker compose run application make install # А так мы можем запустить сервис и подключиться к нему с помощью bash docker compose run application bash # С флагом --rm запускаемые контейнеры будут автоматически удаляться docker compose run --rm application bash # Останавливает и удаляет все сервисы, # которые были запущены с помощью up docker compose down # Останавливает, но не удаляет сервисы, запущенные с помощью up # Их можно запустить снова с помощью docker-compose start docker compose stop

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

130 курсов, 2000+ часов теории
1000 практических заданий в браузере
360 000 студентов

[Basics] Основы Docker: Dockerfile и docker-compose.yml

basics

Привет, %username% ! Поскольку Docker мы уже установили, теперь надо что-то в нем запустить. И как только мы захотели что-то запустить, то первое с чем мы сталкиваемся это Dockerfile и docker-compose.yml . О них и будет речь далее.

Образы Docker#

Для начала заглянув в документацию вспомним, что же такое контейнер Docker и поймем, что Docker-контейнер — это Docker image (образ) который оживили. Собственно говоря Docker image — это то, из чего запускается любой Docker-container.

Каждому Docker image соответствует свой набор инструкций и файл с такими инструкция называется Dockerfile – без расширений и каких-либо точек. Из Dockerfile в дальнейшем собираются Docker images (образы). Сброка нового образа выполняется запуском команды:

docker build -f ./Dockerfile

Учитывая, что наш Dockerfile расположен в той же директории где и мы запускаем команду сборки, то команду можно упростить до такого вида:

docker buid

Каждый контейнер состоит из слоев, а каждый слой контейнера (за исключением последнего) предназначен исключительно для чтения. Собственно основная задача Dockerfile состоит в том, чтобы описать последовательность данных слоев – в каком порядке они идут.

Учитывая, что в Unix все есть файл мы можем сказать, что отдельный слой это всего лишь файл, который описывает изменение состояния по сравнению с предыдущим слоем.

Базовый образ является лишь исходным слоем (слоями) создаваемого образа (иногда называют родительским образом).

Файл Dockerfile#

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

FROM ubuntu:20.04 COPY . /var/www/html

Новые слои в итоговом образе создаются только инструкциями FROM , RUN , COPY , ADD . Остальные инструкции что-то описывают, настраивают или общаются с Docker’ом говоря, например – открыть такой-то порт.

Инструкции Dockerfile#

FROM — задаёт базовый (родительский) образ.
LABEL — описывает метаданные. Например — сведения о том, кто создал и поддерживает образ.
ENV — устанавливает постоянные переменные среды.
RUN — выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов.
COPY — копирует в контейнер файлы и папки которые лежат локально.
ADD — копирует файлы и папки в контейнер, может распаковывать локальные .tar-файлы, а так же получать на вход URL и скачивать файл внутрь image.
CMD — описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD .
WORKDIR — задаёт рабочую директорию для следующей инструкции.
ARG — задаёт переменные для передачи Docker во время сборки образа.
ENTRYPOINT — предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются.
EXPOSE — указывает на необходимость открыть порт. Также можно открыть socket, но это тема для отдельной заметки.
VOLUME — создаёт точку монтирования для работы с постоянным хранилищем.

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

Живой пример Dockerfile#

Вот живой, но довольно простой пример Dockerfile:

# В качестве родителя используем Python v3.8 основанный на Ubuntu FROM python:3.8  # Просим Python не писать .pyc файлы ENV PYTHONDONTWRITEBYTECODE 1  # Просим Python не буферизовать stdin/stdout ENV PYTHONUNBUFFERED 1  # Задаем рабочую директорию WORKDIR /opt/app  # Копируем файл с зависимостями COPY ./req.txt /opt/app/requirements.txt  # Устанавливаем зависимости RUN pip install -r /opt/app/requirements.txt  # Копируем исходный код приложения COPY ./src /opt/app  # Говорим что надо открыть снаружи порт 8000 EXPOSE 8000  # Команда которая должна быть выполнена при запуске контейнера CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

Думаю ничего сложного тут нет, учитывая все комментарии и вышеизложенное.

Сборка/публикация в registry#

Вот мы обзавелись простым Dockerfile, а что дальше? Дальше нам необходимо выполнить сборку:

docker build -t jtprog/django_movie:0.1 .

По порядку: мы говорим докеру сбилдить образ, дать ему имя django_movie и тэг ( -t – сокращение от —tag ) 0.1 , ну а Dockerfile взять из текущей директории (точка в конце). jtprog – говорит о том, что данный образ будет принадлежать мне и будет привязан к моему аккаунту на hub.docker.com

Теперь у нас есть собраный образ и он хранится локально. Посмотреть его можно вот так:

docker images REPOSITORY TAG IMAGE ID CREATED SIZE jtprog/django_movie 0.1 e4d1fb505769 24 minutes ago 1.04GB python 3.8 4e2d08f34f6d 3 days ago 934MB

Данная команда покажет все images которые у нас есть и локально доступны – скачаны. Собственно после сборки образа его можно отправить в реестр ( docker registry ), дабы им могли воспользоваться другие или вы сами с другого компьютера/сервера. Самым простым вариантом в таком случае является собственно Docker Hub и к тому же он бесплатный. Регистрация там простая, так что справитесь.

После регистрации нам необходимо выполнить в консоли вот эту команду:

docker login

У вас будет спрошен адрес удаленного реестра, логин и пароль для доступа к нему. Указываете свои логин и пароль – готово!

Теперь отправим свой образ в реестр – на Docker Hub. Делается это так же довольно просто:

docker image push jtprog/django_movie:0.1

Теперь наш Docker image доступен всем и каждому вот тут – django_movie.

Запуск#

Научились простенько собирать образы и публиковать их на Docker Hub, а теперь попробуем воспользоваться нашим образом. Попробуем запустить из него контейнер. Для этого выполним вот такую команду:

docker run -p 8000:8000 --detach --name movie jtprog/django_movie:0.1

Тут по порядку: docker run – просим запустить, -p 8000:8000 – пробросить порт 8000 с нашего сервера (компуктера) на порт 8000 нашего контейнера, —detach – отключиться (не интерактивная работа с контейнером), —name movie – называем наш контейнер movie , jtprog/django_movie:0.1 – имя пользователя в реестре/имя образа/тэг. Вроде внятно и понятно.

Теперь в списке запущенных контейнеров наш свеженький появится с именем movie . А посмотреть список запущенных контейнеров можно следующей командой:

docker ps

И вроде бы всё хорошо, мы видим наш контейнер, но что-то мы забыли – не кажется? Правильно – у нас же ж простое приложение на Django , которое использует в качестве БД PostgreSQL. А мы ничего для ее – БД – запуска не сделали, соответственно наше приложение не может подключиться для инициализации к базе данных.

Используем docker-compose#

Согласно одной из легенд, docker-compose появился после того, как к разработчикам Docker пришли и сказали: “Docker – отличная вещь! Но сделайте удобно!”. Будем считать что он уже поставлен у вас. Так что сразу перейдем к делу – содаем локально рядом с Dockerfile еще и docker-compose.yml .

И приводим его к такому виду:

# Версия Docker API version: '3.7' # Сервисы которые мы будем запускать services: # Первый сервис - db db: # Образ на основе которого он будет запускаться image: postgres:12-alpine # volumes - магическая вещь, которая создает некоторое устройство в # рамках Docker и монтирует его в директорию /var/lib/postgresql/data volumes: - postgres_data:/var/lib/postgresql/data/ # Переменные окружения environment: POSTGRES_USER: movie POSTGRES_PASSWORD: 123456 POSTGRES_DB: movie # Говорим открыть снаружи порт 5432 expose: - 5432  # Второй сервис - app app: # Говорим что его надо будет собрать - в качестве контекста # передаем текущую директорию - в ней лежит Dockerfile build: . # Монтируем локальную директорию ./src в директорию # внутри контейнера /opt/app volumes: - ./src:/opt/app # Говорим пробросить порт 8000 хоста в порт 8000 контейнера ports: - 8000:8000 # Зависит от сервиса db - запускать после него depends_on: - db # Просто говорим создать volume с именем postgres_data volumes: postgres_data:

После этого в консоли выполним вот эту команду:

docker-compose up --build -d

Тут мы говорим: up – поднять, —build – собрать, -d – пусть робит в фоне. После чего мы можем посмотреть список запущенных сервисов:

docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------- django_movie_drf_app_1 python /opt/app/manage.py . Up 0.0.0.0:8000->8000/tcp django_movie_drf_db_1 docker-entrypoint.sh postgres Up 5432/tcp

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

К слову у вас может быть несколько файлов docker-compose.yml и их можно включать все например вот такой конструкцией:

docker-compose -f docker-compose.yml -f docker-compose.admin.yml run -it backup_db

Кейс: в файле docker-compose.admin.yml может быть больше доступа. Или для среды разработки можно поднимать моки вместо реальных сервисов.

Так же замечу, что все сервисы описанные в рамках одного docker-compose.yml файла (в нашем примере это сервисы db и app ), будут сразу “из коробки” видеть друг друга по указанным именам.

Ну а теперь откройте в браузере http://127.0.0.1:8000/swagger/ и убедитесь, что приложение поднялось и заработало – откроется Swagger-документация по API нашего приложения. По крайней мере так может казаться на первый взгляд.

Работа напильником#

Действительно, на первый взгляд может показаться, что все работает, но нет. Мы же в консоли через manage.py создаем миграции, накатываем их, собираем статику, создаем суперпользователя. Так что давай-ка подумаем: как нам выполнить всё то же самое в контейнере? И готов поспорить, что первое что пришло тебе в голову:

RUN python manage.py makemigrations RUN python manage.py migrate

Как только тебе это пришло в голову – иди попей чаю, покушай, отдохни, поспи! Короче гони из головы эту дичь! Я какбэ не запрещаю тебе страдать хернёй, но тем не менее делать так не советую.

Как быть дальше и с какой стороны/силы приложить напильник, будет описано в следующей статье.

На этом всё! Profit!

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

docker
dockerfile
docker-compose

Укрощение Docker Compose в тестировании

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

Docker и Docker Compose — в чем разница?

Основное отличие Docker Compose от Docker состоит в том, что первый используется для управления несколькими контейнерами с сервисами, которые составляют приложение, а Docker выполняет управление лишь над отдельным сервис-контейнером. Например: DB + Frontend + Backend.

Основные команды docker-compose

docker-compose build: сборка сервисов, описанных в конфигурационных файлах
docker-compose up: запуск собранных сервисов из конфигурационного файла
docker-compose up -d: запуск контейнеров на фоне с флагом -d
docker-compose up —abort-on-container-exit: завершение работы всех сервисов в случае завершения одного из сервисов
docker-compose run application make install: запуск сервисов application с выполнением внутри контейнера команды make install
docker-compose down: остановка и удаление всех сервисов, которые были запущены с помощью up
docker-compose stop: остановка всех сервисов, которые были запущены с помощью up (их можно будет перезапустить docker-compose start)
docker-compose restart: перезапуск всех остановленных и запущенных сервисов

Практическая часть

сборки UI-тестов в Docker image,
запуска Selenoid и Selenoid UI в Docker Compose,
запуска тестов в контейнере.

В этой части покажем на примере тестирования интерфейса сайта testit.software, как запускать контейнеры Selenoid, Selenoid-UI и UI tests c помощью Docker Compose из терминала.

Приступим к выполнению:

1. Установите docker desktop

2. Создайте проект ‘ui-test’ с пакетным менеджером maven в intellij idea

3. Вставьте следующие зависимости в pom файл

xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=»http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd»> 4.0.0 org.example ui-test jar 1.0-SNAPSHOT UTF-8 3.8.1 11 2.22.2 11 11 UTF-8 UTF-8 1.7.0 5.5.2 6.1.1 org.junit.jupiter junit-jupiter $ test com.codeborne selenide $ clean test org.apache.maven.plugins maven-compiler-plugin $ UTF-8 $ $ maven-surefire-plugin methods true 5 org.apache.maven.plugins $

4. Создайте следующую структуру папок и файлов

├───config(folder)
│ ├───browsers.json
├───src(folder)
│ └───test(folder)
│ ├───java(folder)
│ │ └───uiTest(folder)
│ │ ├───Locators(class)
│ │ ├───TestDocker(class)
│ └───resources(folder)
├───Dockerfile(file)
├───docker-compose.yml(file)
├───docker-compose-tests.yml(file)

5. Опишем локаторы для сайта https://temp.testit.software/ для выполнения следующих сценариев:

Выполнить переход с главной страницы в раздел “О продукте” > ”Автоматизированное тестирование”;
Выполнить переход с главной страницы в раздел “Версии” > ”Enterprise VS Cloud”;
Выполнить переход с главной страницы в раздел “Цены” > “Enterprise”

Для этого опишем локаторы в классе Locators:

public class Locators < public void clickNavLink(String nameNavLink) < $x("//span[contains(normalize-space(.),'" + nameNavLink + "')]").click(); >public void clickSubNavLink(String nameSubNavLink) < $x("//a[contains(normalize-space(.),'" + nameSubNavLink + "')]").click(); >public void checkTextSubNavLink(String nameSubNavLink) < $x("//h1[@class='title intro__title']").shouldHave(Condition.ownText(nameSubNavLink)); >>

Далее напишем простые UI-автотесты для сайта https://temp.testit.software/ с переходом по разделам:

public class TestDocker < private Locators locators = new Locators(); private static void configurationRemote() < //Указание базовой url тестируемого сайта Configuration.baseUrl = "https://temp.testit.software/"; //Указание удаленной url для selenoid if(System.getenv("StartRemote").equals("yes"))< Configuration.remote = "http://kubernetes.docker.internal:4444/wd/hub"; >//Определение типа браузера = chrome Configuration.browser = "chrome"; //Отключение системы безопасности браузера System.setProperty("chromeoptions.args", "--no-sandbox"); //Параметры для игнорирования ошибок сертификта System.setProperty("chromeoptions.args", "--ignore-certificate-errors"); //Определение расширения браузера Configuration.browserSize = "1920x1080"; //Создаём объект класса DesiredCapabilities, используется как настройка вашей конфигурации с помощью пары ключ-значение DesiredCapabilities capabilities = new DesiredCapabilities(); //Включить поддержку отображения экрана браузера во время выполнения теста capabilities.setCapability("enableVNC",true); //Переопределяем Browser capabilities Configuration.browserCapabilities = capabilities; > @BeforeAll public static void setUp() < configurationRemote(); >@AfterAll public static void tearDown() < Selenide.closeWebDriver(); >@BeforeEach public void prepareForTest() < open("/"); >@Test @DisplayName("Переход в раздел 'О продукте' в подраздел 'Автоматизация тестирования'") public void aboutOfProductTest() < $("h1[class='title intro__title']").shouldHave(Condition.ownText("Единый интерфейс")); locators.clickNavLink("О продукте"); locators.clickSubNavLink("Автоматизация тестирования"); locators.checkTextSubNavLink("Автоматизация"); >@Test @DisplayName("Переход в раздел 'Версии' в подраздел 'Enterprise VS Cloud'") public void aboutOfVersionProductTest() < $("h1[class='title intro__title']").shouldHave(Condition.ownText("Единый интерфейс")); locators.clickNavLink("Версии"); locators.clickSubNavLink("Enterprise VS Cloud"); locators.checkTextSubNavLink("Cloud или Enterprise -- что выбрать?"); >@Test @DisplayName("Переход в раздел 'Цены' в подраздел 'Enterprise'") public void aboutOfPriceForProductTest() < $("h1[class='title intro__title']").shouldHave(Condition.ownText("Единый интерфейс")); locators.clickNavLink("Цена"); locators.clickSubNavLink("Enterprise"); $x("//h3[@class='form-calc__startup-title']").shouldHave(Condition.ownText("Скидка за кейс")); >>

6. Подготовим Dockerfile с UI-тестами:

FROM maven:3.6.3-jdk-11 WORKDIR /app COPY pom.xml . COPY src ./src

7. Подготовим docker-compose.yaml с запуском Selenoid и Selenoid-UI:

version: '3.5' networks: selenoid: services: selenoid: container_name: selenoid image: "aerokube/selenoid:latest-release" ports: - "4444:4444" volumes: - ./config/:/etc/selenoid/:ro - ./video:/opt/selenoid/video - ./logs:/opt/selenoid/logs - /var/run/docker.sock:/var/run/docker.sock command: ["-conf", "/etc/selenoid/browsers.json", "-container-network", "ui-test_selenoid", "-limit", "10", "-retry-count", "2"] networks: selenoid: selenoid-ui: container_name: selenoid-ui image: "aerokube/selenoid-ui:latest-release" links: - selenoid ports: - "8080:8080" command: ["--selenoid-uri", "http://selenoid:4444"] networks: selenoid:

Образ с тестами будет запускаться в отдельном контейнере от Selenoid т.к. Selenoid относится к серверной части, которую можно останавливать/запускать/оставить в запущенном состоянии, в зависимости от особенностей вашего проекта, а UI-тесты будут изменяться, поэтому их лучше запускать контейнере.

Подготовим docker-compose-tests.yml для запуска тестов:

version: '3.5' networks: selenoid: services: ui-tests: build: context: ./ dockerfile: ./Dockerfile environment: StartRemote: "yes" command: mvn clean test container_name: ui-tests ports: - 0.0.0.0:5555:5555

8. Подготовим конфигурацию для запуска браузера Chrome:

< "chrome": < "default": "102", "versions": < "102.0_ru": < "port": "4444", "image": "selenoid/vnc:102.0", "env" : ["LANG=ru_RU.UTF-8", "LANGUAGE=ru_RU.UTF-8", "LC_ALL=ru_RU.UTF-8"], "additionalNetworks": ["ui-test_selenoid"] >, "102.0_en": < "port": "4444", "image": "selenoid/vnc:102.0", "env" : ["LANG=en_US.UTF-8", "LANGUAGE=en_US.UTF-8", "LC_ALL=en_US.UTF-8"], "additionalNetworks": ["ui-test_selenoid"] >> > >

9. Скачаем Image браузером Сhrome docker pull selenoid/vnc:102.0

10. Запустим Docker Compose с Selenoid+Selenoid-UI.

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

docker-compose -f docker-compose.yml up -d

При выполнении docker-compose будут скачаны образа в локальный(aerokube/selenoid:latest-release / aerokube/selenoid-ui:latest-release)/

Проверим результат запуска:

Проверьте selenoid. Для этого перейдите по ссылке http://localhost:4444/status

Должно быть написано следующее:

,"102.0_ru":<>>>>

Проверьте selenoid-ui. Для этого перейдите по ссылке http://localhost:8080/
Проверьте в правом верхнем углу статус CONNECTED для SSE и SELENOID
Создайте тестовую сессию в браузере в вкладке CAPABALITIES

Примечание: в момент создания сессии и до ее остановки запускается docker контейнер selenoid/vnc:102.0. После удаления сессии-контейнер удаляется.

Если результат как на гифке выше — сессия создается, vnc доступ есть, ссылка testit.software открывается — вы на верном пути!

11. Запустим Docker Compose с UI тестами.