Каждая стадия сборки может обмениваться файлами с предыдущими.
Эта возможность бывает особенно полезна при создании крупных приложений, состоящих из нескольких разных частей, использующих разные языки программирования и разные платформы.
### 2. Политики перезапуска и базовый мониторинг
Для контейнеров можно установить политики перезапуска, таким образом, чтобы Docker перезапускал контейнер в случае ошибки, или же в случае перезагрузки демона или даже операционной системы.
Docker также предоставляет инструмент HEALTHCHECK - возможность базового мониторинга состояния контейнера. Его можно указать как при сборке образа так и при запуске контейнера.
HEALTHCHECK **не** связан с политиками перезапуска напрямую. Для имплементации перезапуска при провале команды проверки, нужно реализовывать эту логику вручную.
### 3. Ограничение ресурсов
Docker позволяет ограничивать ресурсы компьютера, доступные контейнерам. Это бывает особенно полезно в случае некорректно написанных приложений, которые, к примеру, нерационально расходуют память системы. Таким образом можно как обезопасить хост-систему от переполнения памяти, так и более рационально распорядиться доступной памятью(или ресурсами CPU) в случае нескольких контейнеров.
### 4. Docker Compose
Как вы могли заметить, запуск команд Docker вручную - довольно утомительное занятие.
К счастью, Docker предоставляет плагин Docker Compose, который позволяет декларативно описывать конфигурацию Docker на локальной машине, включая контейнеры, сети, и все остальное. Продвинутые возможности Docker, такие как политики перезапуска, или ограничения ресурсов, в нем выглядят особенно просто и наглядно.
Docker Compose использует YAML в качестве языка конфигурации. По умолчанию, файл конфигурации называется `docker-compose.yml`
Docker Swarm это простой оркестратор для контейнеров, который доступен из коробки. Позволяет объединить докер демоны на разных машинах в кластер, что даёт возможность поставки распределённых приложений упакованных в контейнеры. Swarm, так же как и Compose, имеет декларативную модель описания кластерного приложения. Типичными задачами для такого типа приложений являются организация высокой доступности, балансировки нагрузки и канареечного обновления сервиса. Также вы можете добиться эластичности распределённого приложения, которое создаёт и удаляет контейнеры в зависимости от поступающей нагрузки.
Имейте ввиду, что разделение томов данных в кластере имеет свои особенности, о которых подробно можно почитать по ссылкам ниже, но вот некоторые из них.
Во-первых, стандартный драйвер томов данных в Docker имеет говорящее название `local`, и таким образом, при использовании его в кластере,
и при монтировании тома с помощью, к примеру, команды `docker service create --mount type=volume...`,
Это часто является нежелательным поведением, поэтому для кластеров часто используются специфические драйвера томов данных, такие как `NFS` или `GlusterFS`.
Во-вторых, тому данных можно задать область видимости(scope) - `single` или `multi`, что означает соответственно возможность доступа из одного или нескольких узлов.
В-третьих, тому данных можно задать ограничения на возможности чтения и записи, такие как
-`none` - доступ к тому возможен только из одного узла
-`readonly` - доступ к тому возможен только на чтение
-`ovewriter` - доступ к тому на запись возможен только с одного узла одновременно, доступ на чтение - отовсюду
