Docker compose links что это
Разница между ссылками и 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
Обновить
зависит от
Экспресс-зависимость между сервисами, которая имеет два эффекта:
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»
Docker Tip #37: What Do Links Do in Docker Compose?
Docker is a few years old now, and if you’re dealing with older Docker projects, you may run into links. Here’s what it is.
You may see this out in the wild if you take on legacy or older Dockerized apps.
Here’s what a legacy v1 Docker Compose file might look like:
In the above example, redis is exposing port 6379. This won’t publish it back to the Docker host, but it will make it available to any containers who happen to link redis (such as the webapp container in this example).
Back in the day Docker didn’t have networking, so the links property along with expose is how you let 2 containers communicate. This also ensured that redis would get started if you started webapp directly because links also doubled as a way to start dependent containers.
Here’s the updated v2 version of the above:
In the above example, we no longer need to use links because Docker Compose will automatically create a network for our Compose project and containers on that network will be able to talk freely with each other.
Technically we don’t even need to add expose because the official Redis Docker image has EXPOSE 6379 in its Dockerfile. I just added it here to be explicit in the example.
Like usual, if you wanted to publish the port on the Docker host you could use ports too.
Moving forward you should use networks and depends_on and avoid using links all together because it is considered legacy and may be deprecated. You can continue using expose and ports nowadays and both are considered standard to use.
Free Intro to Docker Email Course
Over 5 days you’ll get 1 email per day that includes video and text from the premium Dive Into Docker course. By the end of the 5 days you’ll have hands on experience using Docker to serve a website.
Networking in Compose
Estimated reading time: 6 minutes
This page applies to Compose file formats version 2 and higher. Networking features are not supported for Compose file version 1 (deprecated).
By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.
In v2.1+, overlay networks are always attachable
Each container can now look up the hostname web or db and get back the appropriate container’s IP address. For example, web ’s application code could connect to the URL postgres://db:5432 and start using the Postgres database.
Update containers
If you make a configuration change to a service and run docker-compose up to update it, the old container is removed and the new one joins the network under a different IP address but the same name. Running containers can look up that name and connect to the new address, but the old address stops working.
If any containers have connections open to the old container, they are closed. It is a container’s responsibility to detect this condition, look up the name again and reconnect.
Links
See the links reference for more information.
Multi-host networking
When deploying a Compose application on a Docker Engine with Swarm mode enabled, you can make use of the built-in overlay driver to enable multi-host communication.
Consult the Swarm mode section, to see how to set up a Swarm cluster, and the Getting started with multi-host networking to learn about multi-host overlay networks.
Specify custom networks
Instead of just using the default app network, you can specify your own networks with the top-level networks key. This lets you create more complex topologies and specify custom network drivers and options. You can also use it to connect services to externally-created networks which aren’t managed by Compose.
Each service can specify what networks to connect to with the service-level networks key, which is a list of names referencing entries under the top-level networks key.
Networks can be configured with static IP addresses by setting the ipv4_address and/or ipv6_address for each attached network.
Networks can also be given a custom name (since version 3.5):
For full details of the network configuration options available, see the following references:
Configure the default network
Instead of (or as well as) specifying your own networks, you can also change the settings of the app-wide default network by defining an entry under networks named default :
Use a pre-existing network
If you want your containers to join a pre-existing network, use the external option:
Difference between links and depends_on in docker_compose.yml
According to the Docker Compose’s compose-file documentation:
I don’t understand the purpose of linking to other containers so the difference between two options still seems quite difficult for me.
It would be much easier if there is an example, but I can’t find any.
I noticed, when I link container B with container A then container B will be «pingable» inside container A’s shell.
I ran ping B inside container A’s bash and got result like this (just for reference, image from the Internet)
4 Answers 4
This answer is for docker-compose version 2 and it also works on version 3
You can still access the data when you use depends_on.
If you look at docker docs Docker Compose and Django, you still can access the database like this:
What is the difference between links and depends_on?
links:
When you create a container for a database, for example:
This means you can connect the database from your localhost port 32777 (3306 in container) but this port will change every time you restart or remove the container. So you can use links to make sure you will always connect to the database and don’t have to know which port it is.
depends_on:
I found a nice blog from Giorgio Ferraris Docker-compose.yml: from V1 to V2
When docker-compose executes V2 files, it will automatically build a network between all of the containers defined in the file, and every container will be immediately able to refer to the others just using the names defined in the docker-compose.yml file.
So we don’t need links anymore; links were used to start a network communication between our db container and our web-server container, but this is already done by docker-compose
Update
depends_on
Express dependency between services, which has two effects: