Работаю на связке линукс, пхп, мускул, апач. Недавно попробовал докер. Суть разделения по контейнерам понятна, для пхп свой, для мускула свой, для доступа к ФС свой и т.д. Для чего это делается тоже понятно. Но нет полной картины, так сказать, начиная от машины разработчика и до выкладки на сервер.
Вот несколько вопросов:
- есть у меня образы всех выше перечисленных сервисов и я решил расшарить их с другим разработчиком. Ок, сделали, работаем. Потом решаем соскочить с пхп 5.6 на 7. Между собой без проблем, а как отправить это дело на рабочий сервер, не ручками?
- с ФС вообще тупик. Что делать, как обновлять к примеру базу данных миграциями, чтобы продакт получал готовую базу и сырцы движка сайта? Есть подозрения, что это к докеру не имеет отношения.
Может кто поделиться ссылочкой на статью (-и), где весь пазл с докером собирается воедино? Не обязательно под пхп, апач и т.д. Главное уловить суть.
Нет, для доступа к ФC используйте именованные волумы (named volumes). Контейнеры (data-only) для этог оне нужны.
Между собой без проблем, а как отправить это дело на рабочий сервер, не ручками?
docker registry, либо используем платный либо ставим у себя и там храним образы. То есть если кто-то решил обновиться до php7.0 мы должны заменить базовый контейнер, проверить что все работает, запушить... а у всх все подтянется.
Что делать, как обновлять к примеру базу данных миграциями, чтобы продакт получал готовую базу и сырцы движка сайта? Есть подозрения, что это к докеру не имеет отношения.
Именно, никакого отношения к докеру. Я обычно миграции накатываю прямо при старте контейнера. Так надежнее.
Может кто поделиться ссылочкой на статью
На статью - нет, их много. Могу поделиться тем как я использую docker на своих проектах. Там описан процесс сборки и деплоя в крадце. В идеале сборкой и деплоем должен заведовать CI-сервер а не руками локально:
А чем не нравится вариант с выполнением команд сборки в отдельном контейнере? Ведь тогда не придется тушить контейнер( а то и весь compose) при накатывании чего-то. И если в случае с миграциями это - ок, то например grunt-таска для сборки фронта вполне может выполниться на живом.
Николай: сборка, работа с зависимостями и т.д. это не часть дистрибьюции билдов. В болде уже все должно быть собрано, скачено и поставлено. Можно сказать статически слинковано.
Что до "накатки миграций" из отдельного контейнера - просто это сложнее. Процесс деплоймента усложняется с такого:
Николай: я предпочитаю минимизировать различия между окружениями. На самом деле я очень долго думал на эту тему, даже пробовал работать так как вы предлагаете но в итоге плюнул.
Дело Докера - сэмулировать окружение операционной системы, чтобы моя программа могла запускаться где угодно. И все. Плюс удобное API.
Мы вот сейчас используем Yandex Cocaine. Хорошая вещь. Но безпроблемно компилируется только на Ubutnu 14.04. Поэтому мы его просто запускаем в Docker.
А сам Яндекс Кокаин уже умеет запускать нужные нам приложения ))) Вот такая змея, кусающая себя за хвост, получается. )))
То есть Докер решает одну из задач Деплоя - воспроизводимость операционного окружения запускаемой программы (не забывайте, что маппирование портов и дисков все же остается снаружи). При этом оно кушает немножко лишнего дискового места (хотя при использании всех образов с единым предком - не так уж и много).
Запускается довольно быстро.
То, о чем вы пишете - удобная и воспроизводимая настройка - это к инструментам типа Puppet, Ansible, Chief, Salt.
Будут ли они при этом использовать Докер или нет - другой вопрос. Скорее, да, будут использовать - для упрощения.
Но в вашем случае можно и без Докер - держать на сервере 3 версии PHP в разных каталогах. И выбор той или иной версии настраивать через fastcgi (или что там у вас используется). Докер для этого не нужен.
docker-compose - это всего лишь утилита для оркестрации, которая позволяет запустить то, что записано в конфигурационном файле.
Наш Яндекс-Кокаин даже более комплексное средство оркестрации с дополнительными возможностями - пользоляет использовать Докер, а также содержит в одном флаконе и средства мониторинга, логгирования, распределения нагрузки по кластеру и пр. и пр. Но вещь весьма специфичная.
Поэтому я бы обратил ваше внимание для оркестрации Докер-контейнеров на продукты HashiCorp, Kubernetes, Mesos.
1. docker-compose решает все проблемы(ну или почти все) ссылка
2. для миграций, сборок, обновления зависимостей через composer/npm/.... можно сделать контейнер(ы) который будет выполнять необходимую команду(например composer install) при запуске docker-compose и выключаться. При необходимости повторного выполнения какой-то операции - можно просто запустить этот контейнер заново. Ну перезапустить весь compose.
Средний
