Docker compose links для чего

What is the difference between links and depends_on in docker_compose.yml?

Both links and depends_on are used in a Docker Compose file ( docker-compose.yml ) to define relationships between containers. However, they differ in the way they establish these relationships.

Links

links is used to link a container to another container in the same Compose file. It creates a network connection between the linked containers, allowing them to communicate with each other. For example, if you have a web application container that depends on a database container, you can use links to ensure that the web application can access the database.

Here’s an example of using links in a Compose file:

clipboard#copy’> Copied!

version: '3' services: web: build: . links: - db db: image: postgres 

In this example, the web service links to the db service, allowing it to connect to the Postgres database.

depends_on

depends_on , on the other hand, is used to define the order in which services are started. It does not create a network connection between the services, but rather ensures that one service starts before another. For example, if you have a web application container that depends on a database container, you can use depends_on to ensure that the database is started before the web application.

Here’s an example of using depends_on in a Compose file:

clipboard#copy’> Copied!

version: '3' services: web: build: . depends_on: - db db: image: postgres 

In this example, the web service depends on the db service, ensuring that the database is started before the web application.

Summary

In summary, links is used to link containers and enable communication between them, while depends_on is used to define the order in which services are started.

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:

redis: expose: - "6379" webapp: links: - "redis" 

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.

Then if you wanted to publish the port on the Docker host, you could still use ports .

Here’s the updated v2 version of the above:

version: "2" services: redis: expose: - "6379" webapp: depends_on: - "redis 

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.

We also added in a depends_on property which will ensure redis gets started if it’s not already running if we directly start webapp .

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.

Difference between links and depends_on in docker_compose.yml

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)

19.9k 18 18 gold badges 102 102 silver badges 189 189 bronze badges
asked Mar 6, 2016 at 20:24
4,689 3 3 gold badges 13 13 silver badges 12 12 bronze badges

The —link flag is now a deprecated legacy feature of Docker and the documentation suggests «It may eventually be removed» Docker: Legacy container links. It is suggested not to use the Docker networks feature or the docker compose method. I figured this would be helpful to anyone here learning about this feature.

Sep 30, 2017 at 15:39

4 Answers 4

The post needs an update after the links option is deprecated.

Basically, links is no longer needed because its main purpose, making container reachable by another by adding environment variable, is included implicitly with network . When containers are placed in the same network, they are reachable by each other using their container name and other alias as host.

For docker run , —link is also deprecated and should be replaced by a custom network.

docker network create mynet docker run -d --net mynet --name container1 my_image docker run -it --net mynet --name container1 another_image 

depends_on expresses start order (and implicitly image pulling order), which was a good side effect of links .

answered Jan 18, 2019 at 9:51
11.3k 4 4 gold badges 44 44 silver badges 56 56 bronze badges

How to do the same thing in docker-compose? I think that with docker compose all services are in the same network already and there is no need to add anything. Still linking between the containers doesn’t work if one of the containers is trying to connect to container that is not in the Ready state.

Mar 27, 2019 at 8:44

I can’t see information about links being deprecated in docker-compose version 3 docs: docs.docker.com/compose/compose-file/#links . I don’t see the option too useful, since we have shared networks and depends_on, but it is not deprecated if I read the docs correctly (they only mention —link flag on docker container).

Jul 2, 2019 at 10:29

Note: containers (actually services) in the same network are accessible by service name, not container name. Official documentation: docs.docker.com/compose/networking/#links

Dec 23, 2019 at 13:47

@makkasi you can use the depends_on setting in a compose file to change how containers are span up. At worst, you can add a wait script to your image to only let it run the up command when a certain criteria is met. Such as, only starting the server once a script that checks if the database is up and running has finished executing.

Jan 12, 2022 at 6:52

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:

version: '2' services: db: image: postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - "8000:8000" depends_on: - db 

What is the difference between links and depends_on?

links:

When you create a container for a database, for example:

docker run -d --name=test-mysql --env="MYSQL_ROOT_PASSWORD=mypassword" -P mysql docker inspect d54cf8a0fb98 |grep HostPort 

And you may find

"HostPort": "32777" 

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.

web: links: - db 

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:

• docker-compose up will start services in dependency order. In the following example, db and redis will be started before web.
• docker-compose up SERVICE will automatically include SERVICE’s dependencies. In the following example, docker-compose up web will also create and start db and redis.

version: '2' services: web: build: . depends_on: - db - redis redis: image: redis db: image: postgres 

Note: depends_on will not wait for db and redis to be “ready” before starting web — only until they have been started. If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.

1 1 1 silver badge
answered Sep 23, 2016 at 10:19
6,902 4 4 gold badges 31 31 silver badges 50 50 bronze badges
I’ve updated my answer to clarify that the answer was intended for compose file v1.
Sep 23, 2016 at 13:36
Is this still valid for version 3?
Mar 20, 2017 at 0:03
Yes, you may have a look at https://docs.docker.com/compose/compose-file/compose-versioning/
Mar 20, 2017 at 2:36

«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» not if you specify the port binding in the docker-compose-file, it will not. And since this question is specifically about docker-compose, I feel that the example with docker run here is completely irrelevant, that’s not how the container will be run anyway. What am I missing?

May 10, 2017 at 5:34

Yes, you are right if you specify the port. My docker run example wanna point out why we need to use depends_on or links instead of hard-code a port number.just because if you not specify it, it change every time. I think this will let people understand more about depends_on or links.

May 10, 2017 at 8:01

[Update Sep 2016]: This answer was intended for docker compose file v1 (as shown by the sample compose file below). For v2, see the other answer by @Windsooon.

It is pretty clear in the documentation. depends_on decides the dependency and the order of container creation and links not only does these, but also

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

For example, assuming the following docker-compose.yml file:

web: image: example/my_web_app:latest links: - db - cache db: image: postgres:latest cache: image: redis:latest 

With links , code inside web will be able to access the database using db:5432 , assuming port 5432 is exposed in the db image. If depends_on were used, this wouldn’t be possible, but the startup order of the containers would be correct.

answered Mar 6, 2016 at 20:46
Xiongbing Jin Xiongbing Jin
11.8k 3 3 gold badges 48 48 silver badges 41 41 bronze badges

Can you give me an example? Because that part is what I’m still unclear about. Maybe there are other compose-file options that may make it more specific. Please provide further details. Thanks!

Mar 6, 2016 at 21:13

Thank you very much! I got it. One final question, please. So, in my particular case, i’m deploying my rails app, should i use links or depends_on or either of them is ok? My current docker-compose.yml uses depends_on and things seem to work fine. 🙂

Mar 7, 2016 at 8:36
If you don’t need to directly access the other container via name:port then depends_on is ok.
Mar 7, 2016 at 15:09
name:port works even without linking when you use expose:
Aug 21, 2016 at 13:32

«If depends_on were used, this wouldn’t be possible, but the startup order of the containers would be correct.». This is not correct. It would work if you just use depends_on. You can still access your db in the web using databases hostname.

Sep 22, 2016 at 4:08

I think that the answers for this question need updating based on the new Docker compose specification introduced first in v1.27.0, which now allows for a long-form of depends_on :

In this long form, you can specify that you want to wait for a service to be either started, healthy, or completed successfully.

Docker compose knows that a service is healthy if you produce a health_check on that service:

I’d recommend to read the examples in the documentation for more details, see links above!

For a quick example, this is what I used in a compose file for integration tests:

services: cloud-broker: image: my.docker.registry/activemq-artemis:latest healthcheck: test: ["CMD-SHELL", "wget http://localhost:8161/ --delete-after --tries=3 2> /dev/null"] interval: 10s timeout: 5s retries: 5 postgresql: image: postgres healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 environment: POSTGRES_PASSWORD: "" POSTGRES_USER: "postgres" POSTGRES_DB: "postgres" # This service calls a script to create an empty database and the service-user postgresql-setup: image: postgres depends_on: postgresql: condition: service_healthy restart: "no" volumes: - "./scripts:/scripts" environment: PGPASSWORD: "" entrypoint: "psql -U postgres -d postgres -h postgresql -f /scripts/create-db.sql" my-business-service: image: my.docker.registry/my-business-service:latest depends_on: cloud-broker: condition: service_healthy postgresql-setup: condition: service_completed_successfully 

Docker-compose: идеальное рабочее окружение

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

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

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

Предисловие

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

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

Те, кто считают иначе — это ваше полное право, но только не нужно навязывать свою точку зрения.
Спасибо!

Docker

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

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

Docker-compose

Пакетный менеджер (по аналогии с composer и npm, только у docker — контейнеры), позволяющий описывать необходимую структуру в одном файле (конфиге).
Подробнее также можно узнать из ссылок в конце статьи.

Docker-hub

Репозиторий контейнеров (по аналогии с packagist и npm).
Важное замечание: внимательно читайте описание к образу, 70-80% тупых вопросов там описано, не тратьте время на гугление.

Установка

Переписывать документацию docker я не стану, поэтому просто кину ссылки:

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

Если вы устанавливали docker под Windows, то работать нужно через специальную консоль Docker Quickstart Terminal. После установки, на рабочем столе должен появиться соответствующий ярлык.

Структура проекта

Для начала определимся со структурой проектов:

• project 1
• project 2
• project N
  • src
  • container 1
  • container 2
  • container N
  • docker-compose.yml

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

  CMD / Terminal

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

  • docker ps – просмотр всех контейнеров (подробнее),
  • docker-compose up —build – сборка проекта. Параметр build используется для того, чтобы заставить compose пересоздавать контейнеры. (подробнее).

  Описание прочих команд, можно найти на официальном сайте.
  Перейдем непосредственно к делу.

  apache

  Начнем, пожалуй, с самого популярного сервера — Apache.
  Создадим директорию проекта:

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

  docker-compose.yml

  version: '3' services: apache: image: httpd:2.4 ports: - 80:80 volumes: - ./src:/usr/local/apache2/htdocs

  Что здесь происходит:

  • image: httpd:2.4 — указываем какой образ нам нужно и его версию (список доступных версий и модификаций можно посмотреть в соответствующем docker-hub).
  • ports: 80:80 — пробрасываем порты между docker и нашей машиной, т.е. все запросы которые будут идти на 80 порт нашей машины, будут транслироваться на 80 порт docker.
  • volumes: ./src:/usr/local/apache2/htdocs — линкуем директорию на нашей машине, с рабочей директорий apache, т.е. все файлы находящиеся в директории src, будут доступны для apache, как будто они лежат в директории htdocs (обратное тоже работает, все что создано в docker «копируется» на локальную машину).

  Создадим файл src/index.html в рабочей директории с содержимым:

  Hi, I'am Apache

  Запускаем наш проект:

  docker-compose up --build

  Переходим в браузер по адресу ПК и наблюдаем приветствие нашего сервера.
  Чтобы уничтожить контейнеры нашего проекта, достаточно в консоле выполнить Ctrl+C.

  Если докер работает через VirtualBox, то нужно заходить по IP виртуалки. При любом раскладе, если вы работаете через Docker Quickstart Terminal, то адрес выведется при запуске консоли.

  Работа в фоновом режиме

  Если вам необходимо запустить docker и далее работать в консоле, то можно запустить проект в фоном режиме:

  docker-compose up --build -d

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

  docker ps

  В моем случае получился такой вывод:

  CONTAINER ID IMAGE . 988e27da7bdf httpd:2.4 . 

  Теперь останавливаем и удаляем наш контейнер:

  docker stop 988e27da7bdf docker rm 988e27da7bdf

  Либо можно поступить грубо и сразу удалить:

  docker rm -f 988e27da7bdf

  nginx

  Конфиг nginx строиться по той же самой схеме, что и apache: образ, порты, рабочая директория. Выглядит файл таким образом:

  docker-compose.yml

  version: '3' services: nginx: image: nginx:1.13 ports: - 80:80 volumes: - ./src:/usr/share/nginx/html

  Создаем файл src/index.html в рабочей директории с содержимым:

  Hi, I'am Nginx

  Заходим в браузер, и видим приветствие очередного сервера.

  php + apache

  Если говорить про связку PHP и Apache, то для нее уже есть готовый образ, поэтому про линковку контейнеров будем говорить далее. А сейчас просто конфиг:

  docker-compose.yml

  version: '3' services: web: image: php:7.2-apache ports: - 80:80 volumes: - ./src:/var/www/html

  Создаем файл src/index.php в рабочей директории с содержимым:

  Проверяем его работу в браузере.

  php + nginx

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

  

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

  docker-compose.yml

  version: '3' services: nginx: image: nginx:1.13 ports: - 80:80 volumes: - ./src:/usr/share/nginx/html - ./nginx/nginx.conf:/etc/nginx/nginx.conf depends_on: - php php: image: php:7.2-fpm volumes: - ./src:/usr/share/nginx/html

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

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

  nginx_1 | 2018/01/05 08:56:42 [emerg] 1#1: host not found in upstream "php" in /etc/nginx/nginx.conf:23 nginx_1 | nginx: [emerg] host not found in upstream "php" in /etc/nginx/nginx.conf:23

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

  nginx.conf

  worker_processes 1; events < worker_connections 1024; >http < include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server < root /usr/share/nginx/html; listen 80; server_name localhost; location / < index index.html index.htm; >location ~ \.php$ < fastcgi_pass php:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; >> >

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

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

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

  php + apache + nginx

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

  

  • php используется как php-fpm, потому что быстрее и моднее;
  • apache используется, потому что популярен и htaccess.

  Для того чтобы все настроить нам нужно будет также слинковать конфиг apache, и таким образом docker-compose будет выглядеть так:

  docker-compose.yml

  version: '3' services: apache: image: httpd:2.4 volumes: - ./src:/var/www/html - ./httpd/httpd.conf:/usr/local/apache2/conf/httpd.conf depends_on: - php nginx: image: nginx:1.13 ports: - 80:80 volumes: - ./src:/var/www/html - ./nginx/nginx.conf:/etc/nginx/nginx.conf depends_on: - apache php: image: php:7.2-fpm volumes: - ./src:/var/www/html

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

  docker run -d httpd:2.4 docker ps docker cp [ID контейнера]:/usr/local/apache2/conf/httpd.conf ./httpd.conf

  После выполнения данных команд, в текущей директории появится файл httpd.conf, который мы и будем использовать в качестве основы.
  По сути, это простое копирование из запущенного контейнера.
  Создаем файл /httpd/httpd.conf в рабочей директории, который после правок выглядит так:

  httpd.conf

  ServerRoot "/usr/local/apache2" Listen 80 LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_core_module modules/mod_authn_core.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_core_module modules/mod_authz_core.so LoadModule access_compat_module modules/mod_access_compat.so LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule reqtimeout_module modules/mod_reqtimeout.so LoadModule filter_module modules/mod_filter.so LoadModule mime_module modules/mod_mime.so LoadModule log_config_module modules/mod_log_config.so LoadModule env_module modules/mod_env.so LoadModule headers_module modules/mod_headers.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule version_module modules/mod_version.so LoadModule unixd_module modules/mod_unixd.so LoadModule status_module modules/mod_status.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule dir_module modules/mod_dir.so LoadModule alias_module modules/mod_alias.so # additional LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so ServerAdmin you@example.com AllowOverride none Require all denied DocumentRoot "/var/www/html" Options Indexes FollowSymLinks Includes ExecCGI AllowOverride All Require all granted User daemon Group daemon DirectoryIndex index.php index.pl index.cgi index.asp index.shtml index.html index.htm \ default.php default.pl default.cgi default.asp default.shtml default.html default.htm \ home.php home.pl home.cgi home.asp home.shtml home.html home.htm Require all denied LogFormat "%h %l %u %t \"%r\" %>s %b \"%i\" \"%i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%h %l %u %t \"%r\" %>s %b \"%i\" \"%i\" %I %O" combinedio  ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/" AllowOverride All Options None Require all granted RequestHeader unset Proxy early TypesConfig conf/mime.types AddType application/x-compress .Z AddType application/x-gzip .gz .tgz AddType text/html .shtml AddHandler cgi-script .cgi .pl .asp AddOutputFilter INCLUDES .shtml # # Настройка FPM #  SetHandler "proxy:fcgi://php:9000"  

  Создаем файл /nginx/nginx.conf в рабочей директории со следующим содержимым:

  nginx.conf

  worker_processes 1; events < worker_connections 1024; >http < include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server < listen 80; server_name localhost; location ~ \.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ < root /var/www/html; >location ~ /\.ht < deny all; >location / < proxy_pass http://apache; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_connect_timeout 120; proxy_send_timeout 120; proxy_read_timeout 180; >> >

  В строке proxy_pass http://apache мы опять указываем не IP адрес, а название контейнера (вспоминаем про магию с hosts).

  Для тестинга, нам нужно будет проверить, работает ли PHP и работает ли Apache.
  Сформируем такую структуру проекта:

  Содержимое .htaccess:

  Deny from all

  Содержимое index.php:

  Содержимое index.html:

  Apache not working :-(

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

  • /index.php — откроется информация о php
  • /protected/index.html — откроется 403 ошибка apache
  • /protected/.htaccess — откроется 403 ошибка nginx (визуально они отличаются)

  mariadb + phpmyadmin

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

  docker-compose.yml

  version: '3' services: mariadb: image: mariadb:10.3 restart: always volumes: - ./mariadb:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: qwerty phpmyadmin: image: phpmyadmin/phpmyadmin links: - mariadb:db ports: - 8765:80 environment: MYSQL_ROOT_PASSWORD: qwerty depends_on: - mariadb

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

  Для phpmyadmin мы вручную указали директиву links:

  links: - mariadb:db

  Сделать это необходимо для того, чтобы phpmyadmin знал с какой базой соединятся.
  Если бы контейнер mariadb назывался db, то указывать эту директорию было бы не нужно.

  Для mariadb мы слинковали директорию с данными:

  volumes: - ./mariadb:/var/lib/mysql

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

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

  php + apache + nginx + mariadb + phpmyadmin

  Ну, а теперь совмещаем наши конфиги, и получаем неплохое веб-окружение:

  docker-compose.yml

  version: '3' services: apache: image: httpd:2.4 volumes: - ./src:/var/www/html - ./httpd/httpd.conf:/usr/local/apache2/conf/httpd.conf depends_on: - php nginx: image: nginx:1.13 ports: - 80:80 volumes: - ./src:/var/www/html - ./nginx/nginx.conf:/etc/nginx/nginx.conf depends_on: - apache php: build: ./php volumes: - ./src:/var/www/html - ./php/php.ini:/usr/local/etc/php/php.ini depends_on: - mariadb mariadb: image: mariadb:10.3 volumes: - ./mariadb:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: qwerty phpmyadmin: image: phpmyadmin/phpmyadmin links: - mariadb:db ports: - 8765:80 environment: MYSQL_ROOT_PASSWORD: qwerty depends_on: - mariadb

  Для php мы добавили директиву build (подробнее), в которой указали директорию php, где хранится Dockerfile со следующим содержанием:

  FROM php:7.2-apache RUN apt-get update RUN docker-php-ext-install pdo pdo_mysql mysqli

  В данном файле мы обновляем репозитории и устанавливаем php модули (подробнее про docker-php-ext-install).
  Также мы слинковали конфиг php, чтобы можно было его настроить нужным нам образом.
  Содержимое php.ini можно взять, например, здесь.

  Запускаем, проверяем, радуемся!
  Если все сделано правильно, то index.php отработает без ошибок, а в директории project/mysql появятся служебные файлы базы.

  Docker production

  По данному вопросу к сожалению я ничего сказать не могу, зато может сказать официальная документация.
  Если у вас есть опыт использования docker на боевых проектах, то просьба поделиться своим опытом в комментариях: стоит ли, какие трудности и подводные камни у вас возникли и др. полезную информацию для молодых и неопытных.

  Заключение

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

  Полезные ссылки (a.k.a список используемой литературы)

  P.S.

  Если честно, я не понимаю откуда столько негатива.
  Судя по комментариям, основные претензии к формулировкам и терминологии, и это с учетом того, что в предисловии я написал что умышленно упрощаю многие моменты.
  Цель статьи — показать, как просто работать с docker-compose, как вместо того, чтобы разворачивать 100500 окружений и ПО для каждого своего проекта, можно использовать docker-compose и быть довольным.
  Тут нет речи про prodUction (одного абзаца хватит), про deploy, про миграцию между dev и prod средой.
  Нет, статья не об этом.

  P.P.S.

  Большое спасибо krocos Caravus Vershnik Fesor за дельные комментарии.

  Похожие публикации:

  1. Wealthtech что это
  2. Как написать скрипт для браузера chrome
  3. Как получить url ссылку
  4. Как поменять цвет текста ссылки в css