Как разработать веб-приложение LAMP с помощью Docker, Puppet и Vagrant?
в темные века моя обычная настройка для разработки веб-приложений LAMP заключалась в локальном тестировании на моей машине. PHP (в моем случае), базы данных и веб-сервер были установлены изначально.
сервер был настроен со стандартными установками Apache и MySQL, и у меня было несколько виртуальных хостов для разных частей веб-приложения. Когда я был доволен результатами, которые у меня были на моей локальной машине, я бы вошел на сервер и git pull в промежуточной среде. Самонадеянный все работало так же хорошо на сервере, как и на моей машине, я бы сделал то же самое для производства.
новые начинания...
Итак, теперь я начинаю новое веб-приложение с нуля, и я хочу сделать это "надлежащим образом". Я читал о Докере, бродяге и кукле (и шеф-поваре, хотя лично я предпочитаю систему зависимостей марионетки, а не итерационный процесс шеф-повара). Несмотря на все исследования, которые я сделал, все еще кажется, что их несколько вопросы, на которые я не могу найти ответы:
должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера баз данных (например, MySQL) и каждого часть веб-приложения?
когда я говорю о частей веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и др. Эти "части" будут совместно использовать одну и ту же базу данных.
С тех пор Docker, похоже, предоставляет готовые контейнеры для таких вещей, как веб-серверы и серверы баз данных, похоже, что эти вещи, по крайней мере, должны быть в отдельных контейнерах. Должны ли различные части моего веб-приложения быть также в отдельных контейнерах?
контейнеры Docker, похоже, предназначены для замены, а не для обновления программного обеспечения внутри них. Насчет данных, они пишут, что я не хочу потерять?
сервер баз данных будет управлять файлами связано с содержимым моей базы данных (которую я хочу создать резервную копию). Веб-сервер будет создавать журналы, а мои веб-приложения будут управлять различными файлами и кэшами и т. д. Все эти файлы должны быть записаны вне контейнеров приложения (потому что я могу заменить их при обновлении?), так куда же они идут? Прямо в файловую систему хост-машин? Или в отдельный "Докер том"? Если они входят в Тома Docker, следует ли использовать отдельный том для базы данных, web сервера, приложения и т. д.? Могу ли я по-прежнему легко получить доступ к содержимому с помощью SFTP с моей локальной машины, как сейчас? Я не хочу терять здесь никаких удобств!
хорошо ли использовать Puppet для создания и управления контейнерами Docker, как для сервера разработки, так и для рабочего сервера?
Кажется, что Puppet поддерживает прямое управление контейнерами Docker, поэтому это кажется достаточно хорошим способом простой настройки сервера или производства окружающая среда (используя бродягу) с нуля.
надеюсь, я задал несколько актуальных вопросов; было бы здорово получить некоторые правильные "лучшие практики" для разработки и производства ламповых веб-приложений, просто там не так много, что я нашел!
2 ответа:
должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера баз данных (например, MySQL) и каждой части веб-приложения?
на этот вопрос нет правильного ответа. Если вы будете использовать docker в рабочей среде, попробуйте запустить контейнеры docker в своей среде разработки, поскольку они будут находиться в рабочей среде. Иначе просто используйте контейнеры docker самым простым способом.
на докер-концентратор предоставляет готовые контейнеры для php, баз данных и т. д., и их легко использовать. С другой стороны, вы должны ссылке их вместе, чтобы позволить им взаимодействовать. Для среды разработки, и если вы используете несколько контейнеров, я бы посоветовал использовать docker-compose.
другой путь-построить образ docker, который ближе всего к вашей рабочей машине (при условии, что у вас есть только одна машина), которая будет запускать базу данных, веб-сервер и php. Контейнер из такого образа пришлось бы запускать несколько процессов. Это может быть достигнуто различными способами. Взгляните на руководитель или phusion/baseimage.
когда я говорю о частях веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и т. д.
вы могли бы их разделить. Если эти приложения должны совместно использовать сеансы, убедитесь, что сеансы хранятся в базе данных или на томе docker, доступном для все.
контейнеры Docker, похоже, предназначены для замены, а не для обновления программного обеспечения внутри них. Насчет данных, они пишут, что я не хочу потерять?
Docker имеет вещь, называемую volume, чтобы разрешить запись данных в файловую систему из контейнера. Есть разные способы работы с томами: вы можете смонтировать каталог с узла docker к тому контейнера, или вы можете иметь сведения контейнеры томов или по имени Тома.
Docker Тома являются важной концепцией, и стоит потратить время, чтобы освоить их.
Если вы хотите легко получить доступ к данным, используемым вашими контейнерами, монтирование каталога на хосте docker-это путь.
что касается резервных копий, взгляните на руководство пользователя docker где все, что нужно знать в отношении с объемами подробно.
хорошо ли использовать Puppet для создания и управления контейнерами Docker, как для сервера разработки, так и для рабочего сервера?
лучше всего работать с вашей средой разработки так же, как вы будете работать с вашей производственной средой. Нет смысла правильно настраивать puppet для вашей среды разработки, если вся эта работа не будет использоваться для производственной среды. Имея Vagrantfile, который предоставляет виртуальную машину с докер очень легко с просто оболочки подготовки; кукла ИМХО / шеф-повар/... это перебор.
вы задаете правильные вопросы, но нет ответа, который подходит для всех ситуаций. На мой взгляд есть два способа делать вещи:
- сделайте так, чтобы ваша среда разработки точно копировала вашу производственную среду
- сделайте свою среду разработки отличной от производства, сохраняя ее настолько простой и прямой, насколько это возможно разработчики не почувствуют трения, вызванного использованием новых инструментов
хотя ответ @Thomasleveil уже очень хорош и охватывает все важные части, я хотел бы добавить некоторые дополнительные моменты.
Бродяга, кукла / шеф-повар и Докер-сочинять
когда вы готовите Виртуальная Машина С Vagrant вы обычно используете Puppet или Chef для установки необходимых пакетов для вашего сервера ... вместе с несколькими скриптами оболочки. PuPHPet является отличным источником для настройки на основе виртуальных машин Лампа стека и узнать, как марионетка и Бродяга работают вместе в немного более сложной обстановке. Альтернативой является Protobox кстати.
когда вы используете Docker containers С бродягой точно так же, как вы делаете это с виртуальными машинами. Тогда с
vagrant upвы по существу запускаете контейнеры docker с Docker провайдер. Vagrant будет строить контейнеры для вас из Dockerfile или использовать существующий образ, более или менее похожийdocker-compose(fig) и запускать их.основной причиной выбора Vagrant для настройки Docker является то, что вы или ваша команда частично работаете в среде Windows, поскольку Vagrant позволяет вам поддерживать согласованность настроек, независимо от того, какая ваша хост-система (см. ВМ).
если вы находитесь на OS X вы можете использовать
docker-composeС виртуальной машиной Virtual Box, если вы находитесь на Linux, вы можете использовать Docker изначально. Также всегда можно войти в boot2docker (или другой Докер Хост VM) черезssh, независимо от того, находитесь ли вы на Windows или OS X.Примечание: Вы не должны SSH в ваши контейнеры, но это другая тема.
по состоянию на февраль 2015 года
docker-composeчувствует себя немного быстрее для меня, а также обрабатывает запуск, остановку и перестройку контейнеров более эффективно.Vagrant имеет преимущество, чтобы указать другой хост VM, например. за проект, если вы предпочитаете такой установка.
Примечание: есть также Docker provisioner, который больше связан с процессом сборки марионетки.
должны ли быть отдельные контейнеры Docker для веб-сервера (например, Apache), сервера базы данных (например, MySQL) и каждой части веб-приложения?
при использовании контейнеров Docker вы в основном используете одиночные, изолированные процессы. Использование супервизора следует избегать и также не нужен для стога светильника.
поэтому мой ответ Определенно: да, должны быть отдельные контейнеры!
когда я говорю о частях веб-приложения, я имею в виду такие вещи, как mysite.com, controlpanel.mysite.com и т. д.
это зависит от ваших потребностей, я предлагаю вам прочитать о 12factor документация по применению, в которой описаны важные вещи, о которых нужно позаботиться очень подробно путь.
контейнеры Docker, похоже, предназначены для замены, а не для обновления программного обеспечения внутри них. Насчет данных, они пишут, что я не хочу потерять?
в дополнение к ответу @Thomasleveil я бы рекомендовал вам также отдельный сервер хранения для пользовательских загрузок, таких как Amazon S3, SFTP или WebDAV.
на мой взгляд, ваш контейнер веб-приложения должен рассматриваться как клиентское приложение доступа бэкэнды (службы) базы данных и хранилища не зависят от данных из томов при работе в рабочей среде.
хорошо ли использовать Puppet для создания и управления контейнерами Docker, как для сервера разработки, так и для рабочего сервера?
Я не знаю о возможностях оркестровки Puppet, но для создания контейнеров, если вы используете Vagrant, я не вижу необходимости в Puppet, из-за родного Докера провизионер бродяги.
бонус
для всех тех вещей, описанных выше, вы можете посмотреть на мой 12factor PHP шаблон приложения основано на рамках Yii 2.0 с dockerized стогом светильника. С помощью Docker вы также можете легко подключать обратные прокси или контейнеры для тестирования selenium в свой проект, потому что они существуют как готовые образы и могут быть загружены и настроены за несколько минут и началось через несколько секунд.