Использование docker compose

Что такое Контейнер?

С официального сайта Docker

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

Это может показаться немного запутанным, так что, надеюсь, картинка из RightScale немного прояснит ситуацию.

Запущенный контейнер – это просто стандартный процесс операционной системы, а также зависимости файловой системы и сетевые подключения. На рисунке выше крайняя левая диаграмма показывает абстрактную модель процесса, где зеленый PGM показывает основной программный код, а MEM-память, используемую запущенным процессом. Два других блока немного продвинуты, но в основном это текущее состояние регистров процессора и таблица процессов, используемая ОС.

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

На последней диаграмме показан контейнер — обратите внимание, что теперь граница окружает файловую систему с новым полем под названием “net”. Все, что находится в оранжевом ящике, – это контейнер, единая распределяемая единица, представляющая собой запущенный процесс и то, что ему нужно для запуска

Отлично! Но зачем вообще беспокоиться об этом?

Основные причины, по которым мне нравится заставлять Docker работать в моем рабочем процессе, заключаются в следующем:

• Позволяет разбивать большие приложения на составные части, что помогает поддерживать низкую когнитивную нагрузку и обеспечивает более легкую отладку и большую прозрачность.
• Завершите сложные инструкции по применению таким образом, чтобы помочь документировать, как создавать и настраивать программное обеспечение.
• Если вы используете Docker как для разработки, так и для производства, то у вас есть идентичные стеки. Это уменьшает когнитивную нагрузку от знания того, как использовать несколько установок. Это также предотвращает оправдания “это работает для меня”, когда что-то ломается.
• Не нужно беспокоиться о сумасшедших шагах компиляции для установки программного обеспечения и обслуживания вашей машины.
• Помогает сохранить вашу работу по разработке независимой от вашей ОС (так что обновление Ubuntu не начинает касаться ваших библиотек разработки и т. Д.)

build

Помимо службы, основанной на указанном образе, она также может быть основана на Dockerfile, который выполняет задачу сборки при запуске с up.Этот тег сборки является build, который может указывать путь к папке, в которой находится Dockerfile. Compose будет использовать его для автоматического создания этого образа, а затем использовать этот образ для запуска сервисного контейнера.

Это также может быть относительный путь, если контекст определен, файл Docker может быть прочитан.

Задайте корневой каталог контекста, а затем укажите файл Docker на основе этого каталога.

Обратите внимание, что build — это каталог. Если вы хотите указать Dockerfile, вам нужно использовать тег dockerfile в дочерних тегах тега build, как в примере выше

Если вы укажете как изображение, так и теги сборки, Compose создаст изображение и назовет его после изображения.

Поскольку задача сборки может быть определена в docker-compose.yml, тег arg должен быть обязательным. Как и инструкция ARG в Dockerfile, он может указывать переменные среды в процессе сборки, но может быть отменен после успешной сборки. Файл yml также поддерживает эту запись:

Поддерживается также следующее письмо: Вообще говоря, следующее письмо больше подходит для чтения.

В отличие от ENV, ARG допускает нулевые значения. Например:

Таким образом, процесс сборки может присваивать им значения.

docker-compose.yml

docker-compose.yml — это как Dockerfile, но для распределенного приложения целиком. Например, если в упомянутом выше вэб-приложении web контейнер нужно собирать из Dockerfile, которые лежит в папке web-app, а сервис с данными —  чистый образ с mysql, то вот как для него может выглядеть compose-файл:

docker-compose.yml

YAML

version: ‘2’
services:
web:
build: ./web-app
depends_on:
— db
db:
image: mysql
environment:
— MYSQL_ROOT_PASSWORD=somepassword

1 2 3 4 5 6 7 8 9 10

version: ‘2’ services web build: ./web-app depends_on -db db image: mysql environment -MYSQL_ROOT_PASSWORD=somepassword

Здорово, правда? Тут даже задан root пароль через environment переменные, и явно указан порядок запуска контейнеров через
depends_on .

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

С
depends_on , правда, есть один момент. Например, мы указали, что web должен запуститься после db, и compose так и сделает. Но ведь на самом деле мы хотели, чтобы web запустился после того, как db будет готов принимать запросы. А это как повезет: очень часто mysql внутри него будет инициализироваться еще некоторое время после того, как сам контейнер уже запустился. Вроде, контейнер уже есть, но пока бесполезен.

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

Composer user

Осталось решить проблему с пользователем. и создаются от . Если не указано другое, то в самом контейнере используется тоже root. Это легко проверить:

FROM composer:latest AS composer
FROM php:7.2.3
COPY --from=composer /usr/bin/composer /usr/bin/composer
RUN apt update && apt install -y git
RUN whoami
WORKDIR /app

Соберите контейнер:

docker build -t php-composer:3.1 .
Output:
Step 5/6 : RUN whoami
---> Running in 8707eba18a3b
root
...
Successfully tagged php-composer:3.1

Если вы хотите, чтобы vendor оставался за тем пользователем, которого вы создали сами, то можно использовать два пути. Первый — с помощью инструкции USER добавить нужного пользователя во время сборки контейнера. Второй — запускать контейнер от пользователя, используя .

Dockerfile USER

Обновите Docker-файл:

FROM composer:latest AS composer
FROM php:7.2.3
COPY --from=composer /usr/bin/composer /usr/bin/composer
RUN apt update && apt install -y git
RUN adduser phpcomposeruser
USER phpcomposeruser
RUN whoami
RUN id
WORKDIR /app

Соберите новый контейнер:

docker build -t php-composer:3.2 .

Удалите каталог и файл :

sudo rm -rf vendor/ && sudo rm composer.lock

Соберите проект, используя версию 3.2:

docker run -ti --volume $(pwd)/:/app php-composer:3.2 composer install

Проверьте файлы:

ls -l
Output:
-rw-r--r-- 1 sample sample  142 Dec 13 15:21 composer.json
-rw-r--r-- 1 sample sample 8286 Dec 13 15:21 composer.lock
-rw-r--r-- 1 sample sample  222 Dec 13 15:18 Dockerfile
drwxr-xr-x 6 sample sample 4096 Dec 13 15:21 vendor

Здесь может быть неверно определено имя пользователя. Если это так, вернитесь к логам сборки

Обратите внимание на. Там указан UID пользователя

— это дефолтный пользователь на хосте. Тот пользователь, которого вы создали, будет иметь . Его права на каталог ограничены.

Запуск контейнера от пользователя

Второй способ — запускать контейнер от конкретного пользователя с помощью.

Уберите из Docker-файла . Верните первоначальный вид:

FROM composer:latest AS composer
FROM php:7.2.3
COPY --from=composer /usr/bin/composer /usr/bin/composer
RUN apt update && apt install -y git
WORKDIR /app

Соберите версию 3.3:

docker build -t php-composer:3.3 .

Удалите каталог vendor и файл :

sudo rm -rf vendor/ && sudo rm composer.lock

Соберите проект, добавив :

docker run --user phpcomposeruser -ti --volume $(pwd)/:/app php-composer:3.3 composer install

В терминале отобразится ошибка:

docker: Error response from daemon: linux spec user: unable to find user phpcomposeruser: no matching entries in passwd file.

Это связано с тем, что вы не создали пользователя с таким именем в образе . Чтобы устранить эту проблему, можно передать в контейнер UID и GID вместо имени пользователя.

Поменяйте владельца на :

sudo chown phpcomposeruser composer.json

Соберите проект:

docker run --user $(id -u phpcomposeruser):$(id -g phpcomposeruser) -ti --volume $(pwd)/:/app php-composer:3.3 composer install

Проверьте, что все работает:

ls -l
total 24
-rw-r--r-- 1 phpcomposeruser sample  142 Dec 13 14:54 composer.json
-rw-r--r-- 1 phpcomposeruser phpcomposeruser 8286 Dec 13 14:59 composer.lock
-rw-r--r-- 1 sample sample 155 Dec 13 14:44 Dockerfile
drwxr-xr-x 6 phpcomposeruser phpcomposeruser 4096 Dec 13 14:59 vendor

Готово, теперь образ собирается не от root, а от имени нового пользователя.

Run the application stack

Now that we have our file, we can start it up!

1. Make sure no other copies of the app/db are running first ( and ).

2. Start up the application stack using the command. We’ll add the flag to run everything in the
   background.

   When we run this, we should see output like this:

   You’ll notice that the volume was created as well as a network! By default, Docker Compose automatically creates a network specifically for the application stack (which is why we didn’t define one in the compose file).

3. Let’s look at the logs using the command. You’ll see the logs from each of the services interleaved
   into a single stream. This is incredibly useful when you want to watch for timing-related issues. The flag “follows” the
   log, so will give you live output as it’s generated.

   If you have run the command already, you’ll see output that looks like this:

   The service name is displayed at the beginning of the line (often colored) to help distinguish messages. If you want to
   view the logs for a specific service, you can add the service name to the end of the logs command (for example,
   ).

4. At this point, you should be able to open your app and see it running. And hey! We’re down to a single command!

Как работало раньше

Home Assistant можно установить несколькими разными способами.
Самый простой способ — это скачать официальный образ специальной
операционной системы в котором уже правильным способом существует HA.
Этот образ ставится на хост и Home Assistant работает.
Это способ никуда и не делся. Анонс про deprecated никак не
влияет на этот способ установки — этот способ все еще
официально поддерживается.

Плюс этого способа — он очень простой. Скачивается образ, заливается
на носитель — компьютер загружается — все, Home Assistant работает.

Но у этого способа есть недостаток: очень ограниченная возможность
делать что-то свое на операционной системе из этого образа.

Поэтому я использовал другой вариант установки:

• сам ставлю нужную мне операционную систему
• устанавливаю докер в это систему
• запускаю скрипт, который устанавливает набор докер контейнеров в которых живет HA

Вот ровно этот скрипт установки и объявили deprecated.

Почему я ставил HA не в виде официального образа, на собственноручно
установленную операционную систему? Во-первых, мне так удобнее.
Эту операционную систему я понимаю, ту которую тащит с собой HA — я не понимаю.
Удобно зайти, что-то там посмотреть-сделать.
Кроме Home Assistant у меня на этой операционной системе еще и крутятся мои
скрипты, с помощью которых у меня настроен удаленный доступ к HA (я делаю
проброску ssh туннелей, подробнее о том как это настроено тут).

Home Assistant заработает на том что за деньги предоставляют удаленный доступ к инсталляции HA.
Забавно что в моем случае то что задеприкейтили как раз используется для того
чтобы не платить им деньги, а сделать удаленный доступ другим способом.

Написать файл docker-compose

1. Создайте файл docker-compose.yml

1. Заполните содержимое в docker-compose.yml

1. Распределены ключевые каталоги каждого компонента проекта, теперь необходимо изменить адрес подключения в коде на адрес текущего окружения и скопировать код проекта в соответствующий каталог.
2. Используйте команду для запуска проекта, запустите команду (PS: терпеливо подождите, при первом запуске вам необходимо создать соответствующий образ, а затем запустить образ в контейнер)

Краткое содержание вопроса:

Фактически, в процессе компоновки компоновка может быть успешной, если следовать вышеуказанным шагам. Однако во время фактического процесса оркестрации служб возникла проблема. Activemq и servicemix перезагружались. Tomcat и mysql могут работать. Образ, созданный с помощью одного запуска docker-compose, является нормальным.

Свойства MSBuild для Docker Compose

В таблице ниже приводятся свойства MSBuild, доступные для проектов Docker Compose.

Имя свойства	Местоположение	Описание	Значение по умолчанию
AdditionalComposeFilePaths	DCPROJ	Указывает дополнительные файлы Compose в списке, разделенном точкой с запятой, которые будут отправлены в docker-compose.exe для всех команд. Относительные пути от файла проекта docker-compose (DCPROJ) разрешены.	—
DockerComposeBaseFilePath	DCPROJ	Указывает первую часть имен файлов docker-compose без расширения YML. Пример: 1. DockerComposeBaseFilePath = null/undefined: используйте базовый путь к файлу docker-compose, и файлы будут называться docker-compose.yml и docker-compose.override.yml.2. DockerComposeBaseFilePath = mydockercompose: файлы будут называться mydockercompose.yml и mydockercompose.override.yml. 3. DockerComposeBaseFilePath = ..\mydockercompose: файлы будут располагаться на уровень выше.	docker-compose
DockerComposeBuildArguments	DCPROJ	Указывает дополнительные параметры, передаваемые в команду . Например, .
DockerComposeDownArguments	DCPROJ	Указывает дополнительные параметры, передаваемые в команду . Например, .	—
DockerComposeProjectName	DCPROJ	Если указано, переопределяет имя проекта для проекта docker-compose.	dockercompose + автоматически сгенерированный хэш
DockerComposeProjectPath	CSPROJ или VBPROJ	Относительный путь к файлу проекта docker-compose (DCPROJ). Задайте это свойство при публикации проекта службы, чтобы можно было найти связанные параметры сборки образа, хранящиеся в файле docker-compose.yml.	—
DockerComposeProjectsToIgnore	DCPROJ	Определяет проекты, игнорируемые средствами docker-compose во время отладки. Это свойство можно использовать для любого проекта. Пути к файлам можно указать одним из двух способов: 1. Относительно DCPROJ. Например, . 2. Абсолютные пути.Примечание. Пути должны быть разделены с помощью символа .	—
DockerComposeUpArguments	DCPROJ	Указывает дополнительные параметры, передаваемые в команду . Например, .	—
DockerDevelopmentMode	DCPROJ	Определяет, создан ли пользовательский проект в контейнере. Допустимые значения Fast или Regular определяют, какие этапы создаются в Dockerfile. По умолчанию в качестве конфигурации отладки используется режим Fast, в противном случае — режим Regular.	Быстрый
DockerLaunchAction	DCPROJ	Указывает действие запуска, выполняемое при нажатии клавиши F5 или клавиш CTRL+F5. Допустимые значения: None, LaunchBrowser и LaunchWCFTestClient.	Отсутствуют
DockerLaunchBrowser	DCPROJ	Указывает, следует ли запускать браузер. Игнорируется, если задано свойство DockerLaunchAction.	False
DockerServiceName	DCPROJ	Если указать DockerLaunchAction или DockerLaunchBrowser, тогда DockerServiceName определяет запускаемую службу, на которую есть ссылка в файле docker-compose.	—
DockerServiceUrl	DCPROJ	URL-адрес, используемый при запуске браузера. Допустимые токены замены: «{ServiceIPAddress}», «{ServicePort}» и «{Scheme}». Пример: {Scheme}://{ServiceIPAddress}:{ServicePort}	—
DockerTargetOS	DCPROJ	Целевая ОС, используемая при сборке образа Docker.	—

Репозиторий для localhost

Для начала мы развернем репозиторий, который сможет обслуживать только локальный сервер (о том, как развернуть сетевое хранилище образов Docker будет ).

Чтобы запустить сервис, который сможет принимать запросы docker push и docker pull, вводим команду:

docker run -d -p 5000:5000 —restart=always —name registry registry:2

* в данном примере мы поднимает контейнер Docker с именем registry из образа registry:2. Он будет слушать сетевые запросы на порту 5000. Параметр —restart=always позволит автоматически запускаться контейнеру после перезагрузки сервера.

Проверяем, что на порту 5000 у нас запустился контейнер docker:

ss -tunlp | grep :5000

Мы должны увидеть что-то на подобие:

tcp     LISTEN   0    4096     *:5000     *:*      users:((«docker-proxy»,pid=484238,fd=4))

Попробуем проверить работу нашего репозитория. На том же сервере сначала загрузим из облака докер-хаба образ, например, для python:

docker pull python:latest

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

docker tag python:latest localhost:5000/python

* в данном примере мы указываем тег localhost:5000/python, в названии которого мы видим localhost:5000 — локальный сервер, порт 5000.

Загружаем образ питона на наш сервер:

docker push localhost:5000/python

Теперь удалим тот образ, который был загружен из облака:

docker image remove python:latest

… и образ, который мы загрузили в наш локальный репозиторий:

docker image remove localhost:5000/python

Теперь снова загрузим образ python, но на этот раз из нашего собственного репозитория:

docker pull localhost:5000/python

Мы должны увидеть процесс загрузки:

Using default tag: latest
latest: Pulling from python
8bf9c589d5f9: Pull complete 
4c70e46d8b5f: Pull complete 
ea848ad42f0d: Pull complete 
48fe137f8d26: Pull complete 
4b13f6ed9b0c: Extracting  56.82MB/192.3MB
ba85279f50e0: Download complete 
59a18d8c3680: Download complete 
c610993f70c6: Download complete 
a9afc028cd66: Download complete 

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

Digest: sha256:1e3b89f69bb6ada672153256bd88d74ae60571f6755703369a108c76595ea00f
Status: Downloaded newer image for localhost:5000/python:latest
localhost:5000/python:latest

Наш репозиторий Docker готов и работает для локального сервера.

Подробнее о структуре docker-compose.yaml

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

Элементы верхнего уровня, которые можно использовать в :

1. — версия формата конфигурационного файла, скоро этот элемент должны исключить;
2. — список контейнеров, которые нужно запустить в изолированной среде, это обязательный элемент;
3. — подсети Docker Network, которые объединяют группы контейнеров в локальную сеть, доступную из внешнего мира;
4. — список томов, которыми будут пользоваться контейнеры, указанные в файле конфигурации;
5. — параметры, позволяющие запускать контейнеры в разных режимах без необходимости собирать их заново;
6. — чувствительные с точки зрения безопасности параметры, по сути, то же, что и , но специального назначения.

Очень подробно спецификация элементов расписана в отдельном репозитории на GitHub. Здесь же давайте познакомимся поближе с тремя часто используемыми элементами — services, networks и volumes.

Services

В мультиконтейнерном приложении сервисы взаимодействуют друг с другом. Как правило, они делятся так, чтобы один обеспечивал одну функцию. Например, API — для обмена данными, веб-сервер — чтобы отдавать статичный сайт, база данных — чтобы хранить данные.

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

Посмотрим на конкретном примере. Здесь описана конфигурация двух сервисов — для фронтенда и бэкенда:

services:
  frontend:
    image: awesome/app
    build: ./app
    deploy:
      mode: replicated
      replicas: 7
  backend:
    image: awesome/db
    build:
      context: backend
      dockerfile: ../backend.Dockerfile
    deploy:
    resources:
      limits:
        cpus: '0.60'
        memory: 60M
      reservations:
        cpus: '0.15'
        memory: 10M

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

Его ресурсы будут расходоваться до тех пор, пока не закончатся.

Для сервиса мы указываем другие настройки. Образ собирается перед использованием приложения. В настройке содержится относительный путь к папке сервиса. Есть также требования к используемым ресурсам:

• Не более 60% процессора в штатном режиме, до 75% на пиковых нагрузках.
• Не более 60 МБ оперативной памяти и не более 70 МБ на пиковых нагрузках.

Networks

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

services:
  frontend:
    image: awesome/app

    networks:
      - front-tier
      - back-tier

  backend:
    image: awesome/db

    networks:
      - back-tier

networks:
  front-tier:
    external: true
    name: host
  back-tier:

Volumes

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

services:

  backend:
    image: awesome/db

    volumes:
      - db-data:/etc/data

volumes:
  db-data:

Common use cases

Compose can be used in many different ways. Some common use cases are outlined
below.

Development environments

When you’re developing software, the ability to run an application in an
isolated environment and interact with it is crucial. The Compose command
line tool can be used to create the environment and interact with it.

The Compose file provides a way to document and configure
all of the application’s service dependencies (databases, queues, caches,
web service APIs, etc). Using the Compose command line tool you can create
and start one or more containers for each dependency with a single command
().

Together, these features provide a convenient way for developers to get
started on a project. Compose can reduce a multi-page “developer getting
started guide” to a single machine readable Compose file and a few commands.

Automated testing environments

An important part of any Continuous Deployment or Continuous Integration process
is the automated test suite. Automated end-to-end testing requires an
environment in which to run tests. Compose provides a convenient way to create
and destroy isolated testing environments for your test suite. By defining the full environment in a Compose file, you can create and destroy these environments in just a few commands:

Single host deployments

Compose has traditionally been focused on development and testing workflows,
but with each release we’re making progress on more production-oriented features.

For details on using production-oriented features, see
compose in production in this documentation.

Начало работы: Установка

В оставшейся части этого урока я буду использовать Docker engine, machine и compose. Я также буду использовать Virtualbox для локальной машины Docker и Digital Ocean в последней части. Чтобы сделать этот учебник короче, я свяжусь с примечаниями по установке всех этих инструментов:

• Docker Примечания по установке

  • Для тех, кто работает на Windows, перейдите сюда
  • Для тех, кто работает на Mac OS X, перейдите сюда
• Virtualbox Примечания по установке

Для Docker машины на Linux:

$ curl -L https://github.com/docker/machine/releases/download/v0.8.2/docker-machine-`uname -s`-`uname -m` > /usr/local/bin/docker-machine && chmod +x /usr/local/bin/docker-machine   

Для Docker Compose в Linux:

$ 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 

Adding and overriding configuration

Compose copies configurations from the original service over to the local one.
If a configuration option is defined in both the original service and the local
service, the local value replaces or extends the original value.

For single-value options like , or , the new value
replaces the old value.

original service:

local service:

result:

For the multi-value options , , , ,
, and , Compose concatenates both sets of values:

original service:

local service:

result:

In the case of , , , and , Compose
“merges” entries together with locally-defined values taking precedence. For
and , the environment variable or label name determines
which value is used:

original service:

local service:

result

Entries for and are merged using the mount path in the
container:

original service:

local service:

result:

Итого

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

Несколько часов на переезд и и меня опять все работает.
Даже, похоже, что это жрет немного меньше ресурсов (хотя это все неважно, раньше
проц был загружен на 4%, сейчас на 2%, все то же самое)

Я только-только это сделал, и пока не пожил с этим. Вполне возможно
что какие-то вещи я переделаю, но пока мне кажется очень верным решение
вообще отказаться от супервизора.

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

Иван Бессарабов[email protected]

10 мая 2020