How to run docker compose

Overview of Docker Compose

Estimated reading time: 7 minutes

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration. To learn more about all the features of Compose, see the list of features.

Compose works in all environments: production, staging, development, testing, as well as CI workflows. You can learn more about each case in Common Use Cases.

Using Compose is basically a three-step process:

Define your app’s environment with a Dockerfile so it can be reproduced anywhere.

Define the services that make up your app in docker-compose.yml so they can be run together in an isolated environment.

Run docker compose up and the Docker compose command starts and runs your entire app. You can alternatively run docker-compose up using Compose standalone( docker-compose binary).

A docker-compose.yml looks like this:

For more information about the Compose file, see the Compose file reference.

Compose has commands for managing the whole lifecycle of your application:

Compose V2 and the new docker compose command

The new Compose V2, which supports the compose command as part of the Docker CLI, is now available.

Context of Docker Compose evolution

Introduction of the Compose specification makes a clean distinction between the Compose YAML file model and the docker-compose implementation. Making this change has enabled a number of enhancements, including adding the compose command directly into the Docker CLI, being able to “up” a Compose application on cloud platforms by simply switching the Docker context, and launching of Amazon ECS and Microsoft ACI. As the Compose specification evolves, new features land faster in the Docker CLI.

Compose V2 relies directly on the compose-go bindings which are maintained as part of the specification. This allows us to include community proposals, experimental implementations by the Docker CLI and/or Engine, and deliver features faster to users. Compose V2 also supports some of the newer additions to the specification, such as profiles and GPU devices.

Compose V2 has been re-written in Go, which improves integration with other Docker command-line features, and allows it to run natively on macOS on Apple silicon, Windows, and Linux, without dependencies such as Python.

For more information about compatibility with the compose v1 command-line, see the docker-compose compatibility list.

Features

The features of Compose that make it effective are:

Multiple isolated environments on a single host

Compose uses a project name to isolate environments from each other. You can make use of this project name in several different contexts:

Preserve volume data when containers are created

Compose preserves all volumes used by your services. When docker compose up runs, if it finds any containers from previous runs, it copies the volumes from the old container to the new container. This process ensures that any data you’ve created in volumes isn’t lost.

If you use docker-compose on a Windows machine, see Environment variables and adjust the necessary environment variables for your specific needs.

Only recreate containers that have changed

Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose re-uses the existing containers. Re-using containers means that you can make changes to your environment very quickly.

Variables and moving a composition between environments

Compose supports variables in the Compose file. You can use these variables to customize your composition for different environments, or different users. See Variable substitution for more details.

You can extend a Compose file using the extends field or by creating multiple Compose files. See extends for more details.

Common use cases

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

Development environments

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

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

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

Automated testing environments

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

Single host deployments

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

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

Release notes

To see a detailed list of changes for past and current releases of Docker Compose, refer to the CHANGELOG.

Getting help

Docker Compose is under active development. If you need help, would like to contribute, or simply want to talk about the project with like-minded individuals, we have a number of open channels for communication.

To report bugs or file feature requests: use the issue tracker on Github.

To talk about the project with people in real time: join the #docker-compose channel on the Docker Community Slack.

To contribute code or documentation changes: submit a pull request on Github.

Search Results

No Results

Filters

How to Use Docker Compose

What is Docker Compose?

If your Docker application includes more than one container (for example, a webserver and database running in separate containers), building, running, and connecting the containers from separate Dockerfiles is cumbersome and time-consuming. Docker Compose solves this problem by allowing you to use a YAML file to define multi-container apps. You can configure as many containers as you want, how they should be built and connected, and where data should be stored. When the YAML file is complete, you can run a single command to build, run, and configure all of the containers.

This guide will explain how the docker-compose.yml file is organized, and show how to use it to create several basic app configurations.

Before You Begin

Install Docker CE

You will need a Linode with Docker CE installed to follow along with the steps in this guide.

To install Docker CE (Community Edition), follow the instructions within one of the guides below:

For complete instructions on even more Linux distributions, reference the Install Docker Engine section of Docker’s official documentation.

Install Docker Compose

Download the latest version of Docker Compose. Check the releases page and replace 1.25.4 in the command below with the version tagged as Latest release:

Set file permissions:

Basic Usage

This section will review an example Docker Compose file taken from the Docker official documentation.

Open docker-compose.yml in a text editor and add the following content:

Save the file and run Docker Compose from the same directory:

You now have a WordPress container and MySQL container running on your host. Navigate to 192.0.8.1:8000/wordpress in a web browser to see your newly installed WordPress application. You can also use docker ps to further explore the resulting configuration:

Stop and remove the containers:

Compose File Syntax

A docker-compose.yml file is organized into four sections:

Most of this guide will focus on setting up containers using the services section. Here are some of the common directives used to set up and configure containers:

Many other configuration directives are available. See the Compose File reference for details.

Build an Application from Scratch

Create a docker-compose.yml file one section at a time to illustrate the steps of building a multi-container application.

Define a Simple Service:

Create a new docker-compose.yml in a text editor and add the following content:

Each entry in the services section will create a separate container when docker-compose is run. At this point, the section contains a single container based on the official Alpine distribution:

Bring up your container:

Check the status of your container:

The output should resemble the following:

Bring down the container:

Add Additional Services

From here you can begin to build an ecosystem of containers. You can define how they work together and communicate.

Reopen docker-compos.yml and add the database service below:

There are now two services defined:

Check the running containers:

This command shows the status of the containers, the port mapping, the names, and the last command running on them. It’s important to note that the postgres container reads “docker-entrypoint…” under commands. The Postgres Docker Entrypoint script is the last thing that launches when the container starts.

Bring down both containers:

Add an nginx Service

Add an nginx container so that your application will be able to serve websites:

This docker-compose file contains some new directives: environment and links. The first directive sets runtime level options within the container. links creates a dependency network between the containers. The nginx container depends on the other two to execute. In addition, the corresponding containers will be reachable at a hostname indicated by the alias. In this case, pinging db from the web container will reach the database service. While you do not need the links directive for the containers to talk with each other, links can serve as a failsafe when starting the docker-compose application.

Start Docker Compose and check the container status:

The output should be similar to:

Test nginx by navigating to your Linode’s public IP address, port 8080 in a browser (for example 192.0.2.0:8080 ). You should see the default nginx landing page displayed.

Persistent Data Storage

For these reasons it is important to set up a persistent volume on the host that the database containers will use to store their data.

Add a volumes section to docker-compose.yml and edit the database service to refer to the volume:

external: true tells Docker Compose to use a pre-existing external data volume. If no volume named data is present, starting the application will cause an error. Create the volume:

Start the application as before:

Next Steps

Docker Compose is a powerful tool for orchestrating sets of containers that can work together. Things like an app or a development environment can utilize Docker-compose. The result is a modular and configurable environment that can be deployed anywhere.

This page was originally published on Tuesday, January 2, 2018.

Руководство по Docker Compose для начинающих

Автор статьи, перевод которой мы сегодня публикуем, говорит, что она предназначена для тех разработчиков, которые хотят изучить Docker Compose и идут к тому, чтобы создать своё первое клиент-серверное приложение с использованием Docker. Предполагается, что читатель этого материала знаком с основами Docker. Если это не так — можете взглянуть на эту серию материалов, на эту публикацию, где основы Docker рассмотрены вместе с основами Kubernetes, и на эту статью для начинающих.

Что такое Docker Compose?

Docker Compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов.

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

Как узнать, нужно ли вам, при развёртывании некоего проекта, воспользоваться Docker Compose? На самом деле — очень просто. Если для обеспечения функционирования этого проекта используется несколько сервисов, то Docker Compose может вам пригодиться. Например, в ситуации, когда создают веб-сайт, которому, для выполнения аутентификации пользователей, нужно подключиться к базе данных. Подобный проект может состоять из двух сервисов — того, что обеспечивает работу сайта, и того, который отвечает за поддержку базы данных.

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

Разница между Docker и Docker Compose

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

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

Docker (отдельный контейнер) и Docker Compose (несколько контейнеров)

Типичный сценарий использования Docker Compose

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

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

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

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

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

Разработка клиент-серверного приложения с использованием Docker Compose

Теперь, когда вы знаете о том, для чего мы собираемся использовать Docker Compose, пришло время создать ваше первое клиент-серверное приложение с использованием этого инструмента. А именно, речь идёт о разработке небольшого веб-сайта (сервера) на Python, который умеет выдавать файл с фрагментом текста. Этот файл у сервера запрашивает программа (клиент), тоже написанная на Python. После получения файла с сервера программа выводит текст, хранящийся в нём, на экран.

Обратите внимание на то, что мы рассчитываем на то, что вы владеете основами Docker, и на то, что у вас уже установлена платформа Docker.

Приступим к работе над проектом.

▍1. Создание проекта

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

▍2. Создание сервера

Тут мы, в процессе создания сервера, затронем некоторые базовые вещи, касающиеся Docker.

2a. Создание файлов

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

2b. Редактирование Python-файла.

Добавим в файл server.py следующий код:

2c. Редактирование HTML-файла

В файл index.html добавим следующий текст:

Этот текст будет передаваться клиенту.

2d. Редактирование файла Dockerfile

Теперь займёмся работой над клиентом.

▍3. Создание клиента

Создавая клиентскую часть нашего проекта, мы попутно вспомним некоторые основы Docker.

3a. Создание файлов

Перейдите в папку вашего проекта client и создайте в ней следующие файлы:

3b. Редактирование Python-файла

Добавим в файл client.py следующий код:

Благодаря этому коду клиентское приложение может загрузить данные с сервера и вывести их на экран.

3c. Редактирование файла Dockerfile

▍4. Docker Compose

Вот код, который нужно поместить в файл docker-compose.yml :

▍5. Сборка проекта

▍6. Запуск проекта

Теперь, когда проект собран, пришло время его запустить. Этот шаг нашей работы соответствует шагу, на котором, при работе с отдельными контейнерами, выполняется команда docker run :

Полезные команды

Рассмотрим некоторые команды, которые могут вам пригодиться при работе с Docker Compose.

Эта команда позволяет останавливать и удалять контейнеры и другие ресурсы, созданные командой docker-compose up :

Эта команда выводит журналы сервисов:

С помощью такой команды можно вывести список контейнеров:

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

Такая команда позволяет вывести список образов:

Итоги

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

Уважаемые читатели! Пользуетесь ли вы Docker Compose в своих проектах?

Настройка LEMP-сервера с помощью docker для простых проектов. Часть третья: docker-compose, Dockerfile

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Dockerfile, docker-compose и как поднять полноценный веб-сервер с помощью docker. Отмечу, что если вы являетесь опытным администратором, можете смело пропускать данный материал.

Предыдущие статьи обязательны к прочтению:

DockerFile

Пример: Собрать образ php8.1-fpm с дополнительными пакетами libgeoip-dev, libmemcached-dev и установленными модулями geoip, mcrypt, memcached.

Основные команды.

Основные команды с помощью, которых и пишется Dockerfile:

Больше команд и информации о них в официальном мануале.

Слои Dockerfile.

Как собираются слои?

Docker берет образ из репозитория, после чего начинает записывать на него слои, которые описаны в Dockerfile.

В итоге у нас получается пирог из нескольких слоев. Все это собирается в образ, после чего запускается на сервере.

Пример: Запускаем установку curl и sendmail.

Получается такой тортик:

Важно знать, что при каждом запуске команд. Docker записывает новый слой. Чем больше слоев тем больше будет весить собранный образ, и тем дольше будет собираться контейнер. Поэтому всегда необходимо оптимизировать слои Dockerfile. Иначе вместо миниатюрного милого тортика он превратиться в огромный торт весов в 3G и сборкой в полчаса.

И вы со словами “Я несу тортик”. Понесете его на продакшен.

Как оптимизировать слои, мы поговорим после того, как напишем первый Dockerfile.

Начинаем писать Dockerfile.

Как писать хороший Dockerfile? Нам необходима тактика.

Тактика заключается в том, что мы заранее сделаем список из нужных нам пакетов, библиотек. После чего на основе данного списка протестируем запуск пакетов и напишем команды для Dockerfile.

Cписок модулей, сервисов, пакетов, библиотек.

Тестирование установки в контейнер

Написание Команд для Dockerfile.

Перенос результата в Dockerfile.

Dockerfile php8.1-fpm.

Пункт 1. Cписок модулей, сервисов, пакетов, библиотек.

Нам нужно знать, какие нам пакеты, сервисы, модули нужны в контейнеры. Мы составляем список всего, что нам нужно. В данных статьях мы разворачиваем php-fpm под wordpress, поэтому берем список модулей для php, которые необходимы для wordpress. С офф.сайт.

Нам необходимы модули:

exif, imagick, openssl, zip, bcmath, filter, gd, intl, curl, dom, fileinfo, hash, mbstring, xml, iconv, simplexml, sodium, xmlreader, zlib, pcre.

Для начала нам необходимо проверить какие модули уже установлены в образе php8.1-fpm.

Запускаем сбор тестового образа простой командой из 1 статьи.

Далее заходим в контейнер командой из первой статьи:

Смотрим, какие модули установлены из коробки:

В контейнере нет модулей:

exif, imagick, openssl, zip, bcmath, filter, gd, intl, mcrypt

Уже есть в контейнере:

curl, dom, fileinfo, hash, mbstring, xml, iconv, simplexml, sodium, xmlreader, zlib, pcre.

Список состоит из данных модулей exif, imagick, openssl, zip, bcmath, filter, gd, intl, mcrypt. Их необходимо поставить в контейнер.

Пункт 2 и 3. Тестирование установки в контейнер и написание Команд для Dockerfile.

В контейнерах php для подключение модулей используются команды:

Первый модуль из списка это exif. Пробуем ставить модули:

В контейнере запускаем:

Записываем команду в Dockerfile.

Лайфхак: можете просто записывать команды в текстовый редактор. После чего все перенесете в Dockerfile. КЭП time.

Далее по списку это imagick.

Не находит imagick. Модуля нет.

Пробуем с помощью pecl:

Также получаем ошибку:

Начинаем искать данную ошибку в дебрях интернета, после чего находим ответ, что не хватает библиотек libmagickwand-dev и libmagickcore-dev.

Ставим библиотеки в контейнер:

Видим, что модуль установлен.

Осталось только включить его:

В наш Dockerfile идут команды:

Далее методом проб и ошибок получаем такие RUN:

Внимание! Рекомендуем попробовать самостоятельно поставить все оставшиеся модули, после чего сверить с тем, что у нас получилось.

Dockerfile RUN спойлер.

Отлично у нас есть все RUN со всеми нужными нам модулями, библиотеками и зависимостями.

Наши слои готовы. Осталось добавить вишенку на торте. Это FROM, WORKDIR и CMD.

Пункт 4. Перенос результата в Dockerfile.

Удаляем тестовый контейнер:

Переходим в директорию Dockerfile php-fpm:

Вставляем в Dockerfile php-fpm полученный результат.

Далее пробуем запустить сборку контейнера по получившемуся Dockerfile:

Если вы в директории, где находится Dockerfile, получается следующее:

Если тестовая сборка завершилась без ошибок, значит ошибок при написание команд не обнаружено и вы написали все правильно!

Теперь мы оптимизируем Dockerfile, чтобы не было много слоев. Сейчас их 18!

Разделим установки библиотек, модулей. Это упростить нам жизнь в будущем.

Берем команды установки библиотек:

Объединим их в один слой с помощью обратного слеша \ (перенос на новую строку).

Объедим команды apt-get update и apt-get install. Так как это команды, необходимо использовать and (&&).

Мы объединили библиотеки в один слой. В дальнейшем, если будут необходимы дополнительные библиотеки или пакеты мы можем вписывать их в этот слой.

Остались модули. У нас имеются команды:

Также объединяем их в один слой с помощью обратного слэша и (т.к это команды) and (&&).

Вместо 18 слоев получилось всего 5. Это отличный результат!

Dockerfile для php8.1-fpm готов.

Dockerfile mysql и nginx.

Так как во второй статье мы для каждого контейнера добавили Dockerfile, в mysql и nginx нам нужно добавить какой образ использовать. У нас нет необходимости ставить дополнительные библиотеки, модули в данные контейнеры на текущий момент. Поэтому добавляем в Dockerfile только FROM:

Запуск docker-compose.

Базовые ключи для запуска docker-compose, которые необходимо знать:

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

Переходим в директорию с docker-compose.

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

Все контейнеры запущены и работают.

Что, если если у вас, вдруг, STATUS не UP?

Значит, контейнер не запущен. Скорее всего где то в конфигурационных файлах допущена ошибка.

Смотрим логи контейнера:

Исправляем ошибку и заново запускаем docker-compose.yml.

Указываем id пользователя и id группы из /etc/passwd. В нашем случае 1001 и 1001.

Обязательно проверьте, что все работает c помощью docker ps!

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

Для создания БД необходимо зайти в контейнер mysql и там добавить пользователя.

Развернем код WordPress.

Переходим в /var/www/DOMAIN_NAME/.

Переносим все из директории wordpress/ в data/. Можно все сделать с помощью F6 в mc.

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

Переходим на сайт в браузере:

Осталось указать ip адрес mysql, имя БД, пользователя и пароль.

И можно работать!

Мы написали контейнеры для LEMP-проектов. Важно, что куда бы мы ни перенесли данные контейнеры, они везде будут работать одинаково. Данные yml можно загрузить в систему хранения репозиторием (например, в gitlab), после чего выгружать на новые сервера с помошью git.

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

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

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

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

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

Предисловие

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

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

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

Docker

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

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

Docker-compose

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

Docker-hub

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

Установка

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

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

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

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

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

CMD / Terminal

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

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

apache

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

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

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

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

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

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

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

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

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

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

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

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

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

nginx

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

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

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

php + apache

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

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

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

php + nginx

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

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

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

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

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

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

php + apache + nginx

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

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

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

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

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

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

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

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

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

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

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

mariadb + phpmyadmin

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

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

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

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

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

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

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

php + apache + nginx + mariadb + phpmyadmin

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

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

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

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

Docker production

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

Заключение

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

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

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