Docker compose links для чего

Docker Compose: от разработки до продакшена

Перевод транскрипции подкаста подготовлен в преддверии старта курса «Администратор Linux»

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

С появлением docker compose v3 эти YAML-файлы могут использоваться непосредственно в рабочей среде, при работе с кластером Docker Swarm.

Но значит ли это, что вы можете использовать один и тот же docker-compose файл в процессе разработки и в продакшен среде? Или использовать этот же файл для стейджинга? Ну, в целом — да, но для такого функционала нам необходимо следующее:

Различия между файлами для разработки и продакшена

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

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

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

Переопределение конфигурации

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

Docker compose поддерживает объединение различных compose-файлов для
получения окончательной конфигурации. Как это работает можно увидеть на примере:

Как было сказано, docker compose поддерживает объединение нескольких compose-
файлов, это позволяет переопределять различные параметры во втором файле. Например:

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

К счастью, docker compose автоматически ищет специальный файл с именем
docker-compose.override.yml для переопределения значений docker-compose.yml. Если
переименовать второй файл, то получится тот же результат, только с помощью изначальной команды:

Хорошо, так запомнить проще.

Интерполяция переменных

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

И если вы выполняете docker-compose build (или push) без переменной окружения
$MY_SERVICE_VERSION, будет использовано значение latest, но если вы установите
значение переменной окружения до сборки, оно будет использовано при сборке или пуше
в регистр private.registry.mine.

Мои принципы

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

Давайте посмотрим на простой пример.

Я могу использовать docker-compose (docker-compose up), чтобы запустить стек в
режиме разработки с исходным кодом, смонтированным в /project/src.

Я могу использовать эти же файлы на продакшене! И я мог бы использовать точно
такой же файл docker-compose.yml для стейджинга. Чтобы развернуть это на
продакшен, мне просто нужно собрать и отправить образ с предопределенным тегом
на этапе CI:

На продакшене это можно запустить с помощью следующих команд:

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

В итоге мы использовали два разных docker-compose файла, которые без
дублирования конфигураций могут использоваться для любой вашей среды!

Узнать подробнее о курсе «Администратор Linux»

Источник

Разница между ссылками и depen_on в docker_compose.yml

Согласно документации файла Docker Compose :

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

Было бы намного проще, если бы был пример, но я не могу его найти.

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

Я побежал ping B в контейнер А bash и получил такой результат (просто для справки, изображение из Интернета)

Сообщение нуждается в обновлении после того, как links опция устарела.

Этот ответ предназначен для docker-compose версии 2, а также для версии 3

Вы по-прежнему можете получить доступ к данным, когда вы используете зависимость_.

В чем разница между ссылками и зависимости_?

ссылки по теме:

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

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

зависит от:

Я нашел хороший блог от Джорджио Феррари Docker-compose.yml: от V1 до V2

Когда docker-compose выполняет файлы V2, он автоматически создает сеть между всеми контейнерами, определенными в файле, и каждый контейнер сразу же может ссылаться на другие, просто используя имена, определенные в файле docker-compose.yml.

Поэтому нам больше не нужны ссылки; ссылки использовались для запуска сетевого взаимодействия между нашим контейнером db и нашим контейнером веб-сервера, но это уже сделано docker-compose

Обновить

зависит от

Экспресс-зависимость между сервисами, которая имеет два эффекта:

Источник

Compose file version 3 reference

Estimated reading time: 78 minutes

Reference and guidelines

These topics describe version 3 of the Compose file format. This is the newest version.

Compose and Docker compatibility matrix

There are several versions of the Compose file format – 1, 2, 2.x, and 3.x. The table below is a quick look. For full details on what each version includes and how to upgrade, see About versions and upgrading.

This table shows which Compose file versions support specific Docker releases.

In addition to Compose file format versions shown in the table, the Compose itself is on a release schedule, as shown in Compose releases, but file format versions do not necessarily increment with each release. For example, Compose file format 3.0 was first introduced in Compose release 1.10.0, and versioned gradually in subsequent releases.

The latest Compose file format is defined by the Compose Specification and is implemented by Docker Compose 1.27.0+.

Compose file structure and examples

Here is a sample Compose file from the voting app sample used in the Docker for Beginners lab topic on Deploying an app to a Swarm:

Service configuration reference

This section contains a list of all configuration options supported by a service definition in version 3.

build

Configuration options that are applied at build time.

build can be specified either as a string containing a path to the build context:

Or, as an object with the path specified under context and optionally Dockerfile and args:

Note when using docker stack deploy

The build option is ignored when deploying a stack in swarm mode The docker stack command does not build images before deploying.

context

Either a path to a directory containing a Dockerfile, or a url to a git repository.

When the value supplied is a relative path, it is interpreted as relative to the location of the Compose file. This directory is also the build context that is sent to the Docker daemon.

Compose builds and tags it with a generated name, and uses that image thereafter.

dockerfile

Compose uses an alternate file to build with. A build path must also be specified.

Add build arguments, which are environment variables accessible only during the build process.

First, specify the arguments in your Dockerfile:

Then specify the arguments under the build key. You can pass a mapping or a list:

You can omit the value when specifying a build argument, in which case its value at build time is the value in the environment where Compose is running.

Tip when using boolean values

cache_from

A list of images that the engine uses for cache resolution.

labels

Add metadata to the resulting image using Docker labels. You can use either an array or a dictionary.

It’s recommended that you use reverse-DNS notation to prevent your labels from conflicting with those used by other software.

network

Set the network containers connect to for the RUN instructions during build.

Use none to disable networking during build:

shm_size

Set the size of the /dev/shm partition for this build’s containers. Specify as an integer value representing the number of bytes or as a string expressing a byte value.

target

cap_add, cap_drop

Add or drop container capabilities. See man 7 capabilities for a full list.

Note when using docker stack deploy

The cap_add and cap_drop options are ignored when deploying a stack in swarm mode

cgroup_parent

Specify an optional parent cgroup for the container.

Note when using docker stack deploy

command

Override the default command.

The command can also be a list, in a manner similar to dockerfile:

configs

Grant access to configs on a per-service basis using the per-service configs configuration. Two different syntax variants are supported.

Note: The config must already exist or be defined in the top-level configs configuration of this stack file, or stack deployment fails.

For more information on configs, see configs.

Short syntax

The short syntax variant only specifies the config name. This grants the container access to the config and mounts it at / within the container. The source name and destination mountpoint are both set to the config name.

config definitions are only supported in version 3.3 and higher of the compose file format.

Long syntax

The long syntax provides more granularity in how the config is created within the service’s task containers.

You can grant a service access to multiple configs and you can mix long and short syntax. Defining a config does not imply granting a service access to it.

container_name

Specify a custom container name, rather than a generated default name.

Because Docker container names must be unique, you cannot scale a service beyond 1 container if you have specified a custom name. Attempting to do so results in an error.

Note when using docker stack deploy

The container_name option is ignored when deploying a stack in swarm mode

credential_spec

The credential_spec option was added in v3.3. Using group Managed Service Account (gMSA) configurations with compose files is supported in file format version 3.8 or up.

The following example load the credential spec from a value named my-credential-spec in the registry:

Example gMSA configuration

depends_on

Express dependency between services. Service dependencies cause the following behaviors:

There are several things to be aware of when using depends_on :

deploy

Several sub-options are available:

endpoint_mode

Specify a service discovery method for external clients connecting to a swarm.

The options for endpoint_mode also work as flags on the swarm mode CLI command docker service create. For a quick list of all swarm related docker commands, see Swarm mode CLI commands.

To learn more about service discovery and networking in swarm mode, see Configure service discovery in the swarm mode topics.

labels

Specify labels for the service. These labels are only set on the service, and not on any containers for the service.

To set labels on containers instead, use the labels key outside of deploy :

placement

Specify placement of constraints and preferences. See the docker service create documentation for a full description of the syntax and available types of constraints, preferences, and specifying the maximum replicas per node

max_replicas_per_node

If the service is replicated (which is the default), limit the number of replicas that can run on a node at any time.

When there are more tasks requested than running nodes, an error no suitable node (max replicas per node limit exceed) is raised.

replicas

If the service is replicated (which is the default), specify the number of containers that should be running at any given time.

resources

Configures resource constraints.

Changed in compose-file version 3

Each of these is a single value, analogous to its docker service create counterpart.

In this general example, the redis service is constrained to use no more than 50M of memory and 0.50 (50% of a single core) of available processing time (CPU), and has 20M of memory and 0.25 CPU time reserved (as always available to it).

The topics below describe available options to set resource constraints on services or containers in a swarm.

Looking for options to set resources on non swarm mode containers?

The options described here are specific to the deploy key and swarm mode. If you want to set resource constraints on non swarm deployments, use Compose file format version 2 CPU, memory, and other resource options. If you have further questions, refer to the discussion on the GitHub issue docker/compose/4513.

Out Of Memory Exceptions (OOME)

If your services or containers attempt to use more memory than the system has available, you may experience an Out Of Memory Exception (OOME) and a container, or the Docker daemon, might be killed by the kernel OOM killer. To prevent this from happening, ensure that your application runs on hosts with adequate memory and see Understand the risks of running out of memory.

restart_policy

rollback_config

Configures how the service should be rollbacked in case of a failing update.

update_config

Configures how the service should be updated. Useful for configuring rolling updates.

The order option is only supported by v3.4 and higher of the compose file format.

Not supported for docker stack deploy

The following sub-options (supported for docker-compose up and docker-compose run ) are not supported for docker stack deploy or the deploy key.

See the section on how to configure volumes for services, swarms, and docker-stack.yml files. Volumes are supported but to work with swarms and services, they must be configured as named volumes or associated with services that are constrained to nodes with access to the requisite volumes.

devices

Note when using docker stack deploy

Custom DNS servers. Can be a single value or a list.

dns_search

Custom DNS search domains. Can be a single value or a list.

entrypoint

Override the default entrypoint.

The entrypoint can also be a list, in a manner similar to dockerfile:

env_file

Add environment variables from a file. Can be a single value or a list.

Environment variables declared in the environment section override these values – this holds true even if those values are empty or undefined.

Compose expects each line in an env file to be in VAR=VAL format. Lines beginning with # are treated as comments and are ignored. Blank lines are also ignored.

If your service specifies a build option, variables defined in environment files are not automatically visible during the build. Use the args sub-option of build to define build-time environment variables.

The value of VAL is used as is and not modified at all. For example if the value is surrounded by quotes (as is often the case of shell variables), the quotes are included in the value passed to Compose.

And the following files:

environment

Add environment variables. You can use either an array or a dictionary. Any boolean values (true, false, yes, no) need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser.

Environment variables with only a key are resolved to their values on the machine Compose is running on, which can be helpful for secret or host-specific values.

If your service specifies a build option, variables defined in environment are not automatically visible during the build. Use the args sub-option of build to define build-time environment variables.

expose

external_links

Link to containers started outside this docker-compose.yml or even outside of Compose, especially for containers that provide shared or common services. external_links follow semantics similar to the legacy option links when specifying both the container name and the link alias ( CONTAINER:ALIAS ).

The externally-created containers must be connected to at least one of the same networks as the service that is linking to them. Links are a legacy option. We recommend using networks instead.

Note when using docker stack deploy

The external_links option is ignored when deploying a stack in swarm mode

extra_hosts

An entry with the ip address and hostname is created in /etc/hosts inside containers for this service, e.g:

healthcheck

Configure a check that’s run to determine whether or not containers for this service are “healthy”. See the docs for the HEALTHCHECK Dockerfile instruction for details on how healthchecks work.

The start_period option was added in file format 3.4.

image

Specify the image to start the container from. Can either be a repository/tag or a partial image ID.

If the image does not exist, Compose attempts to pull it, unless you have also specified build, in which case it builds it using the specified options and tags it with the specified tag.

Run an init inside the container that forwards signals and reaps processes. Set this option to true to enable this feature for the service.

The default init binary that is used is Tini, and is installed in /usr/libexec/docker-init on the daemon host. You can configure the daemon to use a custom init binary through the init-path configuration option.

isolation

labels

Add metadata to containers using Docker labels. You can use either an array or a dictionary.

It’s recommended that you use reverse-DNS notation to prevent your labels from conflicting with those used by other software.

links

Link to containers in another service. Either specify both the service name and a link alias ( «SERVICE:ALIAS» ), or just the service name.

Containers for the linked service are reachable at a hostname identical to the alias, or the service name if no alias was specified.

Links also express dependency between services in the same way as depends_on, so they determine the order of service startup.

If you define both links and networks, services with links between them must share at least one network in common to communicate.

Note when using docker stack deploy

logging

Logging configuration for the service.

The default value is json-file.

Logging options are key-value pairs. An example of syslog options:

The default driver json-file, has options to limit the amount of logs stored. To do this, use a key-value pair for maximum storage size and maximum number of files:

The example shown above would store log files until they reach a max-size of 200kB, and then rotate them. The amount of individual log files stored is specified by the max-file value. As logs grow beyond the max limits, older log files are removed to allow storage of new logs.

Here is an example docker-compose.yml file that limits logging storage:

Logging options available depend on which logging driver you use

The above example for controlling log files and sizes uses options specific to the json-file driver. These particular options are not available on other logging drivers. For a full list of supported logging drivers and their options, refer to the logging drivers documentation.

network_mode

Источник

Инструмент Docker Compose для начинающего разработчика

Сейчас читают:

Содержание:

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

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

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

Самый очевидный пример – веб-сайт, где для авторизации пользователей необходимо подключение к базе данных. Для такого проекта нужно два сервиса – один отвечает за функционирование сайта, а другой за базу данных. Соответственно, разработчику понадобится средство, позволяющее управлять одновременно двумя контейнерами. И тут на помощь приходит Docker Compose, который позволяет включать два и более сервиса всего одной командой.

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

Практика применения

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

Допустим, по мере развития проекта становится понятно, что мощностей текущего сервера уже недостаточно. Принимается решение перенести сайты на новый сервер. Без Docker Compose придется переносить и настраивать все сервисы заново. Тогда сама работа займет много времени. Кто же возникает вероятность что-нибудь забыть в процессе.

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

Создание клиент-серверного приложения

Для примера приведен небольшой сайт (сервер) на Python, умеющий отображать файл с текстом. Запрос на него делает программа-клиент, тоже на Python. Когда файл с сервера будет получен, программа выведет текст из файла на экран.

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

Примечание. Этот проект создавался и тестировался на дистрибутивах Ubuntu и CentOS 7. Для выполнения всех приведенных ниже команд используется стандартный терминал Linux.

Разработка проекта

Создание основного каталога

Сборка тестируемого клиент-серверного приложения начинается с создания каталога проекта (в примере — «project»).

Компоненты каталога

Содержимое основного каталога проекта будет отображаться в следующем виде:

Работа с папкой server

Подготовка файлов сервера

Следует открыть каталог «server», чтобы создать в нем следующие файлы:

После создания трех упомянутых выше файлов, содержимое каталога «server» должно выглядеть так:

Работа с файлом server.py

Теперь нужно открыть файл «server.py» предпочитаемым текстовым редактором, чтобы добавить в него следующий код:

Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.

Работа с файлом index.html

Далее потребуется отредактировать index.html, добавив в него такое содержимое:

Работа с Dockerfile

Теперь следует произвести настройку файла Dockerfile. С помощью него будет организована среда выполнения для Python-сервера. В примере основой создаваемого контейнера будет официальный образ для запуска Python-приложений.

Ниже приведено содержимое файла:

Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.

Создание клиент-приложения

Можно приступать к разработке клиента. При создании клиент-приложения проекта будут одновременно использоваться основные возможности Docker.

Файлы клиента

Сначала следует открыть каталог «client» и создать в нем файлы:

После этих операций в каталоге client должны храниться следующие файлы:

Работа с файлом Python

Снова следует открыть текстовый редактор, чтобы добавить в client.py такой код:

Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.

Работа с файлом Dockerfile

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

Ниже представлен его код:

Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.

Работа с Docker Compose

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

В этом примере не стоит задача ознакомиться со всеми возможными командами, доступными для использования в docker-compose.yml. Основная цель – увидеть, как Docker Compose можно применить на практике.

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

Важно! При добавлении информации в файл docker-compose.yml нужно обязательно сохранять форматирование, данное в примере. Это прежде всего касается отступов перед блоками. Если это расстояние нарушить, будет выведена ошибка.

Создание готового образа

Когда docker-compose.yml получит требуемые для работы команды, останется выполнить сборку проекта. Она делается почти аналогично docker build.

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

Если все сделано правильно, в терминале будет отображен следующий результат:

Тестирование проекта

Сборка проекта завершена и можно переходить к тестированию проекта. Для этого следует выполнить команду:

Она по сути соответствует команде docker run, используемой в Docker при работе с одним контейнером.

В окне терминала можно увидеть строку «Docker-Compose is magic!». Так клиентская программа сигнализирует, что выполнила запрос на вывод содержимого файла «index.html» серверной программе, после чего вторая передала информацию клиенту. Это значит, что проект успешно запущен и работает.

Аналогичный результат можно получить в окне браузера, после ввода соответствующего веб-адреса (не забыв указать порт 1234):

Дополнительная информация

Ниже приведены несколько часто используемых полезных команд Docker Compose.

Начни экономить на хостинге сейчас — 14 дней бесплатно!

Источник