Полная автоматизация среды разработки с помощью docker-compose

Step 1 — Installing Docker

First, install Docker if you haven’t already. The quickest way to install Docker is to download and install their installation script (you’ll be prompted for a sudo password).

The above command downloads and executes a small installation script written by the Docker team. If you don’t trust third party scripts or want more details about what the script is doing check out the instructions in the DigitalOcean Docker tutorial or Docker’s own installation documentation.

Working with Docker is a pain if your user is not configured correctly, so add your user to the group with the following command.

Log out and log in from your server to activate your new groups.

Note: To learn more about how to use Docker, read the How to Use Docker section of .

Summary

This post described how to get setup to build and run native Docker Windows containers on both Windows 10 and using the recently published Windows Server 2016 evaluation release. To see more example Windows Dockerfiles, check out the Golang, MongoDB and Python Docker Library images.
Please share any Windows Dockerfiles or Docker Compose examples your build with @docker on Twitter using the tag #windows. And don’t hesitate to reach on the Docker Forums if you have questions.

More Resources:

• Sign up to be notified of GA and the Docker Datacenter for Windows Beta
• Register for a webinar: Docker for Windows Server
• Learn more about the Docker and Microsoft partnership

Build and run your first #Docker @Windows #Server #container

Установка Docker

Docker распространяется в двух изданиях: Community Edition (CE) и Enterprise Edition (EE). Нам нужен Docker CE, т.к. он бесплатный и решает все нужные нам задачи.

А ещё Docker бывает Desktop и Server.

Server

Server-версии предназначены для установки на Linux и поддерживают 4 дистрибутива и только некоторые архитектуры. Поэтому заявление, что вы можете запустить docker-контейнер «где угодно» не совсем корректно.

Desktop

Установка на компьютер выглядит максимально привычно для пользователя Mac.

Ну или, если вы любите Homebrew.

После этого приложение становится доступно в верхней строке состояния (top status bar) и из консоли.

Нюанс заключается в том, что контрольные группы (cgroups) Linux отсутствуют на Mac и Windows (сюрприз, сюрприз), поэтому Docker Desktop использует Mac OS Hypervisor framework и Microsoft Hyper-V, соответственно.

То есть для поддержки виртуализации придётся отдать ещё примерно 4 GB оперативной памяти. Зато потом работающие контейнеры уже будут заниматься гораздо меньше места, чем если бы они были запущены на отдельных виртуальных машинах.

Вывод команды :

Что входит в Docker Desktop

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

Kitematic

Идеально для тех, кто не любит консоль и даже для GIT использует графический интерфейс.

Инструмент довольно сырой, но рабочий (v0.17.9, > 800 открытых issues).

php + nginx

https://hub.docker.com/_/nginx/https://hub.docker.com/_/php/

В данной связке php будет в формате fpm. Схематично это выглядит таким образом:

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

Что изменилось:

• — линкуем файл конфига nginx;
• — указываем зависимость nginx от php, т.е. по сути, это гарантия того что контейнер php запуститься раньше nginx.

Если мы не укажем depends_on, то можем словить подобную ошибку:

Создаем файл /nginx/nginx.conf в директории нашего проекта. Сам конфиг выглядит таким образом:

Все стандартное, главное, чтобы директива root совпадала с docker-compose.yml.
Глядя на конфиг, прошу обратить внимание на директиву fastcgi_pass, а именно на значение .
Обычно, когда настраивается локальный сервер указывается , НО т.к. php у нас находится в другом контейнере, то обращаться мы должны именно к нему (docker сам «подставит» нужный IP контейнера, по сути вся магия скрыта в простом дописывании файла hosts).
Чтобы это стало возможным, в наш docker-compose нужно добавить директиву links (хотя по факту не надо, )

После всех действий, директория нашего проекта выглядит таким образом:

• project
  • src
  • nginx
  • docker-compose.yml

Запускаем, проверяем, радуемся!

Деплой Traefik

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

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

Для развертывания (деплоя) Traefik создадим файл и отредактируем его в любом удобном вам редакторе. Для начала этот файл будет иметь следующий вид:

Во внешний мир будут смотреть порты 80 и 443 для HTTP и HTTPS соответственно. Также пробросим в контейнер сокет демона Docker для работы механизма автоматической конфигурации. Конфигурацию Traefik будем описывать в файле находящемся в папке в текущей директории.

Создадим и будем постепенно наполнять этот файл.

Для начала опишем точки входа в наш прокси (те самые порты, которые смотрят во внешний мир):

Здесь и это просто названия (могут быть любыми, хоть и ) и были выбраны так для удобства.

Теперь добавим первого провайдера — Docker, это делается следующим образом:

Параметром указываем что Traefik не должен брать все контейнеры подряд, далее будет объяснено каким образом мы будем сообщать какие контейнеры нас интересуют. Также здесь видно зачем мы пробрасывали сокет в контейнер — именно через него Traefik будет получать сведения о запускаемых контейнерах на этом хосте (можно подключиться и к демону на другом хосте).

Следующим шагом развернем весь HTTP трафик в HTTPS (почему это было сделано именно таким образом будет описано дальше):

Traefik может проксировать не только HTTP трафик, но и просто TCP и UDP, поэтому указываем что этот блок конфигурации относится к .

Здесь мы встречаем два из трех основных элементов роутинга в Traefik 2 routers (роутеры) и middlewares(промежуточные обработчики), рассмотрим их подробнее.

Роутеры

Рассмотрим на примере описанного выше роутера:

• — имя роутера, может быть любым, но обязано быть уникальным в рамках блока всей конфигурации Traefik;
• — правило, описывает какой трафик попадает в этот роутер, в данном случае описывается , то есть поле запроса должно попадать под регулярное выражение (то есть любое), здесь мы видим специфику регулярных выражений в Traefik — оно должно быть заключено в фигурные скобки и иметь наименование ( в данном случае), то есть синтаксис имеем вид ;
• — массив описанных ранее точек входа, которые будут использоваться этим роутером, в нашем случае используем только ;
• — массив промежуточных обработчиков, куда попадает трафик перед передачей к сервису (сервисы будут рассмотрены позднее).

Промежуточные Обработчики

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

Таким образом мы получим первую рабочую конфигурацию. Выполняем

И прокси должен подняться, можно почитать логи () и убедиться, что всё работает.

Running on a remote host

A remote Docker host is a machine, inside or outside our local network which is running a Docker Engine and has ports exposed for querying the Engine API.

The sample application can be deployed on a remote host in several ways. Assume we have SSH access to a remote docker host with a key-based authentication to avoid a password prompt when deploying the application.

There are three ways to deploy it on the remote host:

1. Manual deployment by copying project files, install docker-compose and running it

A common usage of Compose is to copy the project source with the docker-compose.yml, install docker-compose on the target machine where we want to deploy the compose app and finally run it.

$ scp -r hello-docker user@remotehost:/path/to/src$ ssh user@remotehost$ pip install docker-compose$ cd /path/to/src/hello-docker$ docker-compose up -d

The disadvantages in this case is that for any change in the application sources or Compose file, we have to copy, connect to the remote host and re-run.

2. Using DOCKER_HOST environment variable to set up the target engine

Throughout this exercise we use the DOCKER_HOST environment variable scenario to target docker hosts, but the same can be achieved by passing the -H, –host argument to docker-compose.

$ cd hello-docker$ DOCKER_HOST=“ssh://user@remotehost” docker-compose up -d

This is a better approach than the manual deployment. But it gets quite annoying as it requires to set/export the remote host endpoint on every application change or host change.

3. Using docker contexts 

$ docker context lsNAME   DESCRIPTION   DOCKER ENDPOINT   KUBERNETES ENDPOINT   ORCHESTRATOR…remote               ssh://user@remotemachine$ cd hello-docker$ docker-compose ‐‐context remote up -d

Docker Contexts are an efficient way to automatically switch between different deployment targets. We will discuss contexts in the next section in order to understand how Docker Contexts can be used with compose to ease / speed up deployment.

Step 2 — Running a Container with Docker Compose

The public Docker registry, Docker Hub, includes a Hello World image for demonstration and testing. It illustrates the minimal configuration required to run a container using Docker Compose: a YAML file that calls a single image:

First, we’ll create a directory for the YAML file and move into it:

Then, we’ll create the YAML file:

Put the following contents into the file, save the file, and exit the text editor:

docker-compose.yml

The first line in the YAML file is used as part of the container name. The second line specifies which image to use to create the container. When we run the command it will look for a local image by the name we specified, . With this in place, we’ll save and exit the file.

We can look manually at images on our system with the command:

When there are no local images at all, only the column headings display:

Now, while still in the directory, we’ll execute the following command:

The first time we run the command, if there’s no local image named , Docker Compose will pull it from the Docker Hub public repository:

After pulling the image, creates a container, attaches, and runs the hello program, which in turn confirms that the installation appears to be working:

Then it prints an explanation of what it did:

Docker containers only run as long as the command is active, so once finished running, the container stopped. Consequently, when we look at active processes, the column headers will appear, but the container won’t be listed because it’s not running.

We can see the container information, which we’ll need in the next step, by using the flag which shows all containers, not just the active ones:

This displays the information we’ll need to remove the container when we’re done with it.

Step 4 — Accessing the Docker Container Filesystem

In order to work on the command prompt inside a container and access its filesystem, you can use the command.

The “Hello World” example exits after it runs, so to test out , start a container that will keep running. For the purposes of this tutorial, use the Nginx image from Docker Hub.

Create a new directory named and move into it:

Next, make a file in your new directory and open it in a text editor:

Next, add the following lines to the file:

~/nginx/docker-compose.yml

Save the file and exit. Start the Nginx container as a background process with the following command:

Docker Compose will download the Nginx image and the container will start in the background.

Now you will need the for the container. List all of the containers that are running with the following command:

You will see something similar to the following:

If you wanted to make a change to the filesystem inside this container, you’d take its ID (in this example ) and use to start a shell inside the container:

The option opens up a terminal, and the option makes it interactive. opens a bash shell to the running container.

You will then see a bash prompt for the container similar to:

From here, you can work from the command prompt inside your container. Keep in mind, however, that unless you are in a directory that is saved as part of a data volume, your changes will disappear as soon as the container is restarted. Also, remember that most Docker images are created with very minimal Linux installs, so some of the command line utilities and tools you are used to may not be present.

Let’s Encrypt

Поскольку мы хотим использовать HTTPS нам нужно где-то взять SSL сертификаты для сервисов, есть возможность использовать свои сертификаты, но мы настроем автоматическое получение бесплатных сертификатов от Let’s Encrypt.

Добавим в конфигурацию () новый блок:

Здесь:

• — это просто имя резолвера;
• — тип резолвера (других типов в общем-то и нет);
• — файл, в котором хранятся сведения о полученных сертификатах;
• — тип acme-челенжа, дополнительно указываем параметр — точку входа;
• — позволяет использовать не основной сервер Let’s Encrypt в тестовых целях, так как основной имеет строгие лимиты API (можно закомментировать, когда наладите получение сертификатов).

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

Step 2 — Running a Container with Docker Compose

The public Docker registry, Docker Hub, includes a simple “Hello World” image for demonstration and testing. It illustrates the minimal configuration required to run a container using Docker Compose: a YAML file that calls a single image.

First, create a directory for our YAML file:

Then change into the directory:

Now create the YAML file using your favorite text editor. This tutorial will use Vi:

Enter insert mode, by pressing , then put the following contents into the file:

docker-compose.yml

The first line will be part of the container name. The second line specifies which image to use to create the container. When you run the command it will look for a local image by the name specified, .

With this in place, hit to leave insert mode. Enter then to save and exit the file.

To look manually at images on your system, use the command:

When there are no local images at all, only the column headings display:

Now, while still in the directory, execute the following command to create the container:

The first time we run the command, if there’s no local image named , Docker Compose will pull it from the Docker Hub public repository:

After pulling the image, creates a container, attaches, and runs the hello program, which in turn confirms that the installation appears to be working:

It will then print an explanation of what it did:

Docker containers only run as long as the command is active, so once finished running, the container stops. Consequently, when you look at active processes, the column headers will appear, but the container won’t be listed because it’s not running:

Use the flag to show all containers, not just the active ones:

Now that you have tested out running a container, you can move on to exploring some of the basic Docker Compose commands.

Быстрый старт с docker-compose

Docker-compose — это простой инструмент, который позволяет запустить несколько докер-контейнеров одной командой. Перед тем как окунуться в детали, я должен рассказать о структуре проекта. Мы используем monorepo, и кодовая база каждого сервиса (веб-приложение, API, фоновые обработчики) хранится в своей корневой директории. У каждого сервиса есть описывающий его зависимости Docker-файл. Пример такой структуры можно увидеть в нашем демонстрационном проекте.

Давайте начнем с автоматизации простого приложения, которое зависит от MongoDB и небольшого сервиса на Node.JS. Конфигурация для docker-compose находится в файле , который обычно помещается в корневую директорию проекта.

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

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

1. — таким образом указывается путь к исходному коду сервиса в рамках monorepo.
2. — для окружений разработки мы используем отдельный Dockerfile.dev. В production исходный код копируется прямо в контейнер, а для разработки подключается в виде тома. Поэтому нет необходимости заново создавать контейнер при каждом изменении кода.
3. — таким образом каталог с кодом добавляется в docker в виде тома.
4. Docker-compose автоматически связывает контейнеры друг с другом, поэтому, например, веб-сервис может получить доступ к mongodb по имени:

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

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

• Один сервер Ubuntu 18.04, настроенный в соответствии с руководством по начальной настройке сервера Ubuntu 18.04, включая пользователя sudo без прав root и брандмауэр.
• Docker, установленный на сервере в соответствии с указаниями обучающего модуля «Установка и использование Docker в Ubuntu 18.04».
• Docker Compose, установленный в соответствии с указаниями обучающего модуля «Установка Docker Compose в Ubuntu 18.04».
• Домен и три записи A, , и , каждая из которых указывает на IP-адрес вашего сервера. Вы можете научиться включать переадресацию доменов на дроплеты DigitalOcean, ознакомившись с документацией DigitalOcean по доменам и DNS. Для целей этого обучающего модуля указывайте свой домен вместо в файлах конфигурации и примерах.

Шаг 4 — Настройка конфигурации Nginx и файлов дампа базы данных

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

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

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

Откройте в этой директории новый файл с именем :

Скопируйте следующую конфигурацию Nginx в этот файл:

docker-compose/nginx/travellist.conf

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

Сохраните и закройте файл после завершения редактирования.

Чтобы настроить базу данных MySQL, мы откроем для общего доступа дамп базы данных, который будет импортирован при инициализации контейнера. Эта возможность обеспечивается образом MySQL 5.7, который мы будем использовать в этом контейнере.

Создайте новую папку для файлов инициализации MySQL в папке :

Откройте новый файл :

Следующий дамп MySQL основан на базе данных, которую мы настроили в обучающем руководстве по Laravel на LEMP. Она создаст новую таблицу с именем . Затем таблица будет заполнена местами на основе образца.

Добавьте в файл следующий код:

docker-compose/mysql/db_init.sql

Таблица содержит три поля: , и . Поле — это флаг, используемый для отметки мест со статусом to go. Вы можете свободно изменять или добавлять места в образец. Сохраните и закройте файл после завершения.

Мы завершили настройку файла Dockerfile приложения и файлов конфигурации служб. Далее мы выполним настройку Docker Compose для использования этих файлов при создании наших служб.

Шаг 2 — Запуск контейнера Traefik

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

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

Создайте пустой файл, где будет храниться информация Let’s Encrypt. Мы передадим ее в контейнер, чтобы Traefik мог ее использовать:

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

После передачи файла в Docker владелец автоматически сменяется на пользователя root внутри контейнера.

Затем создайте контейнер Traefik с помощью следующей команды:

Это команда немного длинная, так что попробуем ее разбить.

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

Затем мы сопоставим порты и нашего хоста Docker с аналогичными портами контейнера Traefik, чтобы Traefik принимал весь трафик HTTP и HTTPS, поступающий на сервер.

Затем мы создадим два ярлыка Docker, которые будут предписывать Traefik направлять трафик хоста на порт в контейнере Traefik, открывая доступ к информационной панели мониторинга.

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

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

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

После запуска контейнера вы получили информационную панель, которую можете использовать для просмотра состояния ваших контейнеров. Также вы можете использовать эту информационную панель для визуализации клиентских и серверных ресурсов, зарегистрированных Traefik. Откройте панель мониторинга, введя в браузер адрес . Вам будет предложено ввести имя пользователя и пароль. Используйте имя пользователя admin и пароль, заданный на шаге 1.

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

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

Мы запустили прокси Traefik, настроили его для работы с Docker и подготовились к отслеживанию других контейнеров Docker. Теперь запустим контейнеры, для которых Traefik будет выступать в качестве прокси.

Виртуализация

Возможность виртуализации появилась достаточно давно.

Когда я занимался разработкой в 2012 году, моя команда делала проекты на Ruby on Rails. У меня возникала необходимость запускать у себя на ноутбуке такие вещи, как Ruby, MySQL, PostgreSQL. Это всё довольно плохо работало под Windows, поэтому приходилось использовать виртуализацию.

Тогда существовали такие решения, как VirtualBox, VMware Workstation, Vagrant. Всё рабочее окружение выносилось на виртуалку, а в хост-системе оставались только IDE, Git, браузер.

Вот эта схема, взятая из документации Docker, как раз показывает, как работают виртуальные машины (VM).

У нас есть Infrastructure (наш компьютер) и Hypervisor (VMWare, VirtualBox или ещё что-то). И на всём этом мы запускаем виртуальную машину, которая включает гостевую операционную систему (Guest OS), нужные библиотеки (Bins/Libs) и наше приложение (App).

Естественно, что сами виртуальные машины получались очень большие и неповоротливые. Накладные расходы на обслуживание виртуалки были высоки. Мой ноутбук с трудом всё это вывозил.

Docker, Inc предложили нам не тянуть в виртуальный контейнер гостевую операционную систему, а пользоваться хост-системой и получать изоляцию процессов при помощи механизма контрольных групп (cgroups) в Linux.

Это значительно уменьшило размеры образов. Например, образ alpine:3.11.0 (дистрибутив Linux, ориентированный на безопасность, легковесность и нетребовательность к ресурсам) весит всего 2.5 MB, а docker-образ с node:alpine — всего 27 MB.

Трудности

Я большой поклонник Docker-контейнеров и также часто использую Docker Compose, инструмент для управления группами нескольких связанных контейнеров. А у Commento есть готовый к употреблению Docker-образ в GitLab container registry.

Поэтому решение применить контейнеры созрело само собой — но сначала предстояло решить несколько моментов.

Трудность №1: PostgreSQL

Commento требует сервера PostgreSQL довольно свежей версии, никакие другие SQL-серверы, к сожалению, не поддерживаются.

Ну ладно, мы всё равно всё запускаем в контейнерах, так что тут довольно просто.

Трудность №2: нет поддержки HTTPS

Commento сам по себе является веб-сервером, но он поддерживает лишь незащищённый протокол HTTP.

Тут надо отметить, что такая практика в наши дни довольно распространена: сервер в данном случае прячут за обратным прокси, который также выполняет SSL offloading. Штука в том, что поддержка SSL/HTTPS в данном случае совершенно обязательна, в конце концов на дворе 2019 год и на попытки авторизовать пользователя с помощью незащищенного Интернет-протокола будут смотреть очень косо.

Я решил использовать сервер Nginx, во-первых, у меня был немалый опыт работы с ним, а во-вторых, он очень быстр, экономичен и стабилен. И публикует официальные сборки Docker-образов.

Вторым ингредиентом в рецепте HTTPS является SSL-сертификат для домена. Я бесконечно признателен EFF и Mozilla за то, что они создали центр сертификации Let’s Encrypt, ежемесячно выдающий миллионы бесплатных сертификатов.

Let’s Encrypt также предоставляет свободную утилиту командной строки под названием certbot, сильно упрощающую процесс получения и обновления сертификата. Ну и — разумеется — Docker-образ для него!

Трудность №3: проблема курицы-яйца Certbot

А вот эта заморочка более хитрая.

Мы хотим сослаться на SSL-сертификат в конфигурации нашего обратного прокси на Nginx, что означает, что без сертификата он просто откажется стартовать. В том же самое время, чтобы получить SSL-сертификат для домена, требуется рабочий HTTP-сервер, который докажет Let’s Encrypt ваше владение этим доменом.

Мне удалось решить и эту проблему, причём, как мне кажется, довольно изящно:

1. Сначала генерируется фиктивный, невалидный сертификат, единственное предназначение которого состоит в том, чтобы дать Nginx запуститься.
2. Nginx и certbot совместно получают новый, теперь уже валидный сертификат.
3. Как только сертификат получен, certbot переходит в «ждущий режим», просыпаясь раз в 12 часов для проверки необходимости его обновления — согласно рекомендациям Let’s Encrypt.
4. Когда момент наступил и сертификат обновился, certbot подаёт сигнал Nginx перезапуститься.

Трудность №4: что-то должно сохраняться

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

Также, чтобы Let’s Encrypt вас не забанил из-за слишком частых запросов, неплохо бы хранить полученные сертификаты в течение всего срока их годности.

Оба момента решены в предлагаемой конфигурации с помощью томов (volumes) Docker, автоматически создаваемых systemd при первом запуске Commento. Тома помечены как «внешние» (), поэтому Docker пропускает их при удалении контейнеров с помощью .

Interested?

If you’re interested then head over to the GitHub repository at https://github.com/docker/app. You’ll find basic documentation and several examples, as well as instructions for downloading the latest release (for Windows, macOS or Linux) and the application source code. Please open issues in the repository with any questions, ideas, issues reports or feature requests.

If you’re a Docker EE customer and interested in managing Compose-based applications, or addressing workflow issues between developers and operators, please get in touch via your sales representative. works with Docker EE today and we’re actively looking at other interesting integration opportunities.

#Docker Compose is now easier to use with new application packages

Learn more:

• Check out our other big preview: Federated Application Management
• Register to access the beta when it’s available and download the current version of Docker Desktop for macOS or Windows 10 today, including the option to use Kubernetes.

Несколько файлов docker-compose

После запуска команды она по умолчанию ищет файл в текущей директории.

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

Так зачем же нужны несколько файлов конфигурации? В первую очередь для разбиения составного проекта на несколько подпроектов. Радует, что сервисы из разных compose-файлов все равно могут быть связаны. Например, вы можете поместить в один файл docker-compose контейнеры, связанные с инфраструктурой (базы данных, очереди и т. д.), а в другой — контейнеры, связанные с приложениями.

File провайдер

С контейнерами работает, а как быть если есть какой-то сервис работающий на выделенном хосте (пускай IP 192.168.1.222 и порт 8080) и мы его хотим пропустить через этот же прокси, заодно закрыв его с помощью HTTPS. Для этого есть решение.

Добавим в ещё один :

Пускай описания таких хостов у нас будут лежать в (а что, вдруг ещё появятся).

Добавим в конфигурацию file провайдера для этих файлов:

Директория следует из нашего , а значит что Traefik будет автоматически обновлять конфигурацию при обнаружении изменений в этих файлах (помните про обновление конфигурации “на лету”, вот работает даже для файлов, а не только для оркестраторов).

Перезапускаем Traefik и теперь можно создать файл с описанием нашего отдельного хоста ():

Роутер описывался раньше, тут добавилось только — связь с нашим сервисом, и конфигурация для TLS.

Описание для сервиса имеет вид:

Дополнительно мы указываем параметр чтобы тот хост думал, что он на самом деле смотрит в сеть и прокси нет.