Как разработать веб-приложение LAMP с помощью Docker, Puppet и Vagrant?

В темные века моя обычная настройка для создания веб-приложений LAMP заключалась в локальном тестировании на моей машине. PHP (в моем случае), база данных и веб-сервер были установлены изначально.

Сервер был настроен со стандартными установками Apache и MySQL, и у меня было несколько виртуальных хостов для разных частей веб-приложения. Когда я был доволен результатами, полученными на моем локальном компьютере, я зашел на сервер и git pull в промежуточную среду. Предполагая, что все работает на сервере, как это было на моей машине, я бы сделал то же самое для производства.

Новые начинания...

Итак, теперь я начинаю новое веб-приложение с нуля, и я хочу сделать это "правильно". Я читал о докерах, бродяжниках и куклах (и шеф-повара, хотя я лично предпочитаю систему кукольных игр, а не итеративный процесс Chef). Несмотря на все проведенные мной исследования, все еще есть несколько вопросов, на которые я не могу найти ответы:

Должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера базы данных (например, MySQL) и каждой части веб-приложения?

Когда я говорю о частях веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и т.д. Эти "части" будут использовать одну и ту же базу данных.

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

Контейнеры для докеров, похоже, предназначены для замены, а не для обновления программного обеспечения внутри них. Как насчет данных, которые они пишут, что я не хочу потерять?

Сервер базы данных будет управлять файлами, связанными с содержимым моей базы данных (что я хочу создать резервную копию). Веб-сервер будет создавать журналы, и мои веб-приложения будут управлять различными файлами и кэшами и т.д. Все эти файлы должны быть написаны за пределами контейнеров приложений (потому что я могу их заменить при обновлении?), Поэтому, куда они идут? Прямо в файловую систему хост-машин? Или в отдельный "объем докеров"? Если они входят в объемы докеров, я должен использовать отдельный том для базы данных, веб-сервера, приложения и т.д.? Могу ли я получить доступ к содержимому с помощью SFTP с моей локальной машины, как сейчас? Я не хочу потерять удобство здесь!

Полезно ли использовать Puppet для создания и управления контейнерами Docker как для сервера разработки, так и для производственного сервера?

Кажется, что Puppet поддерживает управление контейнерами Docker напрямую, поэтому это похоже на разумно хороший способ легко настроить сервер или производственную среду (используя Vagrant) с нуля.

Надеюсь, я задал несколько важных вопросов; было бы здорово получить некоторые надлежащие "лучшие практики" для разработки и производства LAMP-подобных веб-приложений, но, похоже, это не так много, что я нашел!

Ответ 1

Должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера базы данных (например, MySQL) и каждой части веб-приложения?

Нет правильного ответа на этот вопрос. Если вы будете использовать докер в производстве, попробуйте запустить ваши контейнеры докеров в своей среде разработки, так как они будут в производстве. Else просто используйте контейнеры докеров самым простым способом.

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

Другой путь - создать образ докеры, наиболее близкий к вашей производственной машине (при условии, что у вас есть только одна машина), которая будет запускать базу данных, веб-сервер и php. Контейнер из такого образа должен запускать несколько процессов. Это может быть достигнуто по-разному. Взгляните на supervisor или phusion/baseimage.

Когда я говорю о частях веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и т.д.

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

Контейнеры-докеры, по-видимому, предназначены для замены, а не для обновления программного обеспечения внутри них. Как насчет данных, которые они пишут, что я не хочу потерять?

Докер имеет вещь под названием volume, позволяющую записывать данные из файловой системы из контейнера. Существуют разные способы работы с томами: вы можете монтировать каталог с хоста docker в объем контейнера, или вы можете иметь контейнеры объема данных или именованные тома.

Объемы докеров являются важной концепцией, и стоит потратить время на их освоение.

Если вы хотите легко получить доступ к данным, используемым в ваших контейнерах, то можно создать каталог на хосте docker.

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

Хорошо ли использовать Puppet для создания и управления контейнерами Docker как для сервера разработки, так и для производственного сервера?

Лучшей практикой является работа в среде вашего разработчика так же, как и в вашей производственной среде. Нет смысла правильно настраивать марионетку для вашей среды разработчиков, если все эти работы не будут использоваться для производственной среды. Имея Vagrantfile, который предоставляет виртуальную машину с докером, очень просто с помощью оболочки; ИМХО марионетка/шеф-повар/... переполнены.

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

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

Ответ 2

В то время как ответ @Thomasleveil уже очень хорош и охватывает все важные части, я хотел бы добавить дополнительные моменты.

Бродяга, Кукольный/Шеф-повар и докер-сочинитель

Когда вы создаете виртуальную машину с помощью Vagrant, вы обычно используете Puppet или Chef для установки необходимых пакетов для вашего сервера... наряду с несколькими сценариями оболочки. PuPHPet является отличным источником для настройки стека LAMP на виртуальной машине и изучения того, как Puppet и Vagrant работают вместе в более сложной настройке. Альтернативой является Protobox.

Когда вы используете контейнеры Docker с Vagrant так же, как и с виртуальными машинами. Затем с vagrant up вы, по сути, запускаете контейнеры докеров с поставщиком Docker. Vagrant построит для вас контейнеры из файла Docker или использует существующее изображение, более или менее похожее на docker-compose (fig) и запустит их.

Основная причина выбора Vagrant для вашей установки Docker - если вы или ваша команда частично работаете в среде Windows, так как Vagrant позволяет вам поддерживать вашу настройку согласованной, независимо от того, какая ваша хост-система (см. Host VM).

Если вы используете OS X, вы можете использовать docker-compose с виртуальной виртуальной машиной, если вы работаете в Linux, вы можете использовать Docker изначально. Также всегда можно войти в boot2docker (или другую виртуальную машину Docker Host) через ssh, независимо от того, находитесь ли вы в Windows или OS X.

Примечание. Вы не должны использовать SSH в своих контейнерах, но это другая тема.

По состоянию на февраль 2015 года

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

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

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

Должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера базы данных (например, MySQL) и каждой части веб-приложения?

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

Итак, мой ответ определенно: Да, должны быть отдельные контейнеры!

Когда я говорю о частях веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и т.д.

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

Контейнеры-докеры, по-видимому, предназначены для замены, а не для обновления программного обеспечения внутри них. Как насчет данных, которые они пишут, что я не хочу потерять?

В дополнение к ответу @Thomasleveil я бы порекомендовал вам также отдельный бэкэнд для хранения пользователей, таких как Amazon S3, SFTP или WebDAV.

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

Хорошо ли использовать Puppet для создания и управления контейнерами Docker как для сервера разработки, так и для производственного сервера?

Я не знаю о возможностях оркестровки Puppet, но для создания контейнеров, если вы используете Vagrant, я не вижу необходимости в Puppet, из-за собственного помощника Docker для Vagrant.

Bonus

Для всех описанных выше вещей вы можете посмотреть мой 12factor PHP-шаблон приложения на основе Yii 2.0 Framework с доклерным стеком LAMP. С Docker вы также можете легко подключать обратные прокси или контейнеры для тестирования селена в свой проект, поскольку они существуют как изображения предварительной сборки и могут быть загружены и настроены за несколько минут и начаты через несколько секунд.