У меня очень небольшой опыт работы с Docker для экспериментов и разработки, и у меня нет опыта работы с Docker, когда дело доходит до постановки и развертывания - так что простите все, что звучит наивно.
Основной вопрос
Предположим, у меня есть образ Docker (или даже файл docker-compose.yml, состоящий из нескольких изображений и сервисов), который при запуске устанавливает среду для моего приложения и запускает мое приложение - с учетом соединений через публично открытый порт и отвечая на запросы.
Чтобы запустить этот образ в рабочей среде (и, следовательно, чтобы запустить мое приложение в рабочей среде), на рабочем сервере должен быть установлен Docker. Это похоже на нарушение дизайна приложения Twelve-Factor . Особенно, если учесть привязку порта принцип:
Приложение из 12 факторов полностью автономно
Так же, как приложение не должно полагаться на устанавливаемый Apache или nginx, разве приложение также не должно полагаться на устанавливаемый Docker?
Это заставило меня задуматься, существует ли способ «упаковать», «собрать» или иным образом «скомпилировать» среду выполнения Docker и образ в исполняемый двоичный файл. Что-то, что можно развернуть на любом сервере и запустить как единый процесс без предварительной установки Docker.
Теперь, возможно, я просто думаю об этом совершенно неправильно. По этой причине я подробно остановился на проблемах и проблемах ниже
Что подняло это
У меня есть проект веб-приложения, который я ранее разрабатывал с использованием Cloud9 . Когда я запускаю этот проект в производство, я вручную захожу на рабочий сервер через SSH и выполняю git pull, composer update, npm install и gulp. Я немного переживаю, но для очень мелкого масштаба, над которым я работаю, этого было достаточно, и это ад намного лучше, чем загрузка всех моих зависимостей через FTP.
Однако я иногда сталкиваюсь с проблемами с внешними зависимостями. Что-то работает отлично в разработке, тогда, когда я запускаю это в производство, я понимаю, что на рабочем сервере установлена устаревшая версия MySQL. Или версия pngquant, установленная на производственном сервере, содержит ошибку. Или конфиг nginx на сервере не совсем совпадает с конфигом nginx в разработке, и это вызывает некоторые крайние случаи при маршрутизации некорректных запросов.
Сегодня все эти проблемы возникли сразу, когда я попытался загрузить свой проект в CodeAnywhere вместо Cloud9. Я должен был обеспечить:
- Версия PHP была обновлена
- NodeJS был обновлен
- NPM обновлен
- cURL был установлен
- Все необходимые расширения PHP были установлены
- Установлено несколько библиотек GNU
- и т.д.
Я потратил часов , пытаясь запустить этот код - и это код I написал
Наличие всех этих проблем напомнило мне о приложении с двенадцатью факторами . Поэтому я прыгнул на сайт и подумал, чтобы выяснить, что я делаю неправильно.
Примечание: Я не просто разрабатываю соло, а затем непосредственно внедряюсь в производство. У меня фактически есть этот проект, настроенный в BitBucket, я использую систему тикетов для отслеживания изменений, ветвь создается для каждого тикета, и ветки извлекаются в промежуточной среде перед тем, как быть объединенными в master. Поэтому я создал довольно надежную систему для управления изменениями, чтобы избежать ошибок в работе и обеспечить гибкую разработку. Однако, когда дело доходит до проверки ветки при постановке или производства, это то же самое ручное дерьмо: git pull, composer update, npm install, gulp.
Что мне нравится в Docker
Возможность определения моей рабочей среды в файле конфигурации с управлением исходным кодом устранит большую часть моих проблем. Никогда больше мне не нужно было бы убедиться, что PHP обновлен, убедиться, что NodeJS обновлен, убедиться, что cURL был установлен и т. Д. Если образ Docker имеет все зависимости, то он все равно будет иметь эти зависимости при развертывании в стадии подготовки или производства , Согласованность среды на всех этапах развития сделает мою жизнь на 1092 * много проще.
Кроме того, я еще не играл с что-нибудь таким продвинутым, но я должен понять, что с помощью Docker легко настроить автоматическое развертывание. Если бы я мог щелкнуть ветку в BitBucket, затем щелкнуть «отправить в промежуточный» и через минуту развернуть ее и подготовить к тестированию - это сэкономило бы мне часы времени каждую неделю. Если бы я мог аналогичным образом автоматически развернуть код в рабочей среде, когда он был объединен с мастером, это не только сэкономило бы мне время, но и позволило бы избежать риска того, что готовые функции будут томиться в BitBucket и никогда не окажутся перед клиентом.
Наконец, и в конечном итоге это может стать спорным вопросом, я должен понять, что Docker облегчает развертывание зеленого / синего намного . В настоящее время, когда я запускаю новое изменение в производство, рабочий сервер ненадолго отключается. Обычно только на 15-20 секунд, но однажды это был целый час. В течение этого 15-20 секундного окна я запускаю composer update, npm install и gulp. Первые две команды обычно не нужно ничего делать (поскольку мои зависимости меняются не часто), а gulp обычно завершается в течение 15 секунд. Однако при изменении зависимостей do или при возникновении более серьезных проблем (например, необходимости обновления MySQL) сайт может отключиться на целый час. Если бы я мог медленно и спокойно развертывать на вторичном производственном сервере, а затем переключить коммутатор за миллисекунды, когда я убедился, что он работает правильно, это означало бы меньшее время простоя и больше довольных клиентов.
Конечно, последний может быть спорным, потому что я в настоящее время не использую шаг "сборки" (другая часть приложения с двенадцатью факторами), и все эти шаги должны быть частью фазы "сборки" - не фаза "развертывания".
Что мне не нравится в Docker
Это еще один инструмент для изучения . Для того, чтобы понять и разработать для моего приложения, вам уже нужно понять:
- PHP
- Композитор
- Symfony
- Laravel
- NodeJS
- NPM
- Глоток
- VueJS
- (вероятно, многие другие вещи, о которых я сейчас не могу думать)
Добавление «Docker» в этот список просто означает, что этому проекту будет намного сложнее обучать кого-либо, если я когда-либо передам его другому разработчику. Я хочу меньше зависимостей, не больше.
Кроме того, Docker не поставляется по умолчанию с любой операционной системой, о которой я знаю. Так что это не похоже на cURL, где, хотя это технически сторонняя зависимость, обычно можно ожидать, что она у людей есть. Вместо этого это отдельный зверь, который должен быть установлен отдельно.
Первая проблема, которую я не могу обойти. Если я решу использовать Docker, это означает добавление еще одного инструмента в мою панель инструментов для этого приложения. Однако последней проблемы можно избежать, если образы Docker можно каким-либо образом компилировать в автономные двоичные файлы.