Могут ли изображения Docker быть «встроенными» («скомпилировано»), чтобы не требовать Docker?

У меня очень небольшой опыт работы с Docker для экспериментов и разработки, и у меня нет опыта работы с Docker, когда речь идет о постановке и развертывании — так что простите все, что звучит наивно.

Главный вопрос

Предположим, у меня есть изображение Docker (или даже docker-compose.yml файл, состоящий из нескольких изображений и служб), который при запуске настраивает среду для моего приложения и запускает мое приложение — позволяя устанавливать соединения через публично открытый порт и отвечать на запросы.

Чтобы запустить этот образ в рабочей среде (и, следовательно, чтобы запустить мое приложение в рабочей среде), на рабочем сервере должен быть установлен Docker. Это похоже на нарушение Приложение с двенадцатью факторами дизайн. Особенно, если учесть Привязка порта Тенета:

Приложение из двенадцати факторов полностью автономно

Точно так же, как приложение не должно полагаться на установку Apache или nginx, разве приложение также не должно полагаться на установку Docker?

Это заставило меня задуматься, есть ли способ «упаковать», «собрать» или иным образом «скомпилировать» среду выполнения Docker и образ в исполняемый двоичный файл. Что-то, что может быть развернуто на любой сервер и запустить как единый процесс без необходимости сначала устанавливать Docker.

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

Что подняло это

У меня есть проект веб-приложения, который я ранее разрабатывал, используя Облако 9. Когда я запускаю этот проект в производство, я вручную захожу на производственный сервер через SSH и выполняю git pull, composer update, npm install, а также gulp, Я немного хлопотно, но для очень в небольших масштабах я работаю над этим было достаточно, и это ад намного лучше, чем загрузка всех моих зависимостей через FTP.

Однако я иногда сталкиваюсь с проблемами с внешними зависимостями. Что-то работает отлично в разработке, тогда, когда я запускаю это в производство, я понимаю, что на рабочем сервере установлена ​​устаревшая версия MySQL. Или версия pngquant, установленная на производственном сервере, содержит ошибку. Или конфиг nginx на сервере не совсем совпадает с конфигом nginx в разработке, и это вызывает некоторые крайние случаи при маршрутизации некорректных запросов.

Сегодня все эти проблемы возникли сразу, когда я попытался загрузить свой проект в CodeAnywhere вместо Cloud9. Я должен был обеспечить:

• Версия PHP была обновлена
• NodeJS был обновлен
• НПМ был обновлен
• cURL был установлен
• Все необходимые расширения PHP были установлены
• Было установлено несколько библиотек GNU
• так далее

я потратил часов пытаясь запустить этот код — и это код я писал

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

Замечания: Я не просто разрабатываю соло, а затем непосредственно внедряюсь в производство У меня фактически есть этот проект, настроенный в BitBucket, я использую систему тикетов, чтобы отслеживать изменения, ветка создается для каждого тикета, и ветки извлекаются в промежуточной среде, прежде чем быть объединенным в master. Поэтому я создал довольно надежную систему для управления изменениями, чтобы избежать ошибок в работе и обеспечить гибкую разработку. Однако, когда дело доходит до проверки ветки в постановке или же Производство это та же ручная хрень: git pull, composer update, npm install, gulp,

Что мне нравится в Docker

Возможность определить мою рабочую среду в файле конфигурации с управлением исходным кодом устранит большую часть моих проблем. Никогда больше мне не нужно было бы убедиться, что PHP обновлен, убедиться, что NodeJS обновлен, убедиться, что cURL был установлен и т. Д. Если образ Docker имеет все зависимости, то он все равно будет иметь эти зависимости при развертывании в стадии подготовки или производства , Согласованность окружающей среды на всех этапах развития сделает мою жизнь много Полегче.

Кроме того, я еще не играл с что-нибудь это продвинутый уровень, но я понимаю, что с помощью Docker легко настроить автоматическое развертывание. Если бы я мог щелкнуть ветку в BitBucket, затем щелкнуть «отправить в промежуточный» и через минуту развернуть ее и подготовить к тестированию — это сэкономило бы мне часы времени каждую неделю. Если бы я мог аналогичным образом автоматически развернуть код в рабочей среде, когда он был объединен с мастером, это не только сэкономило бы мне время, но и позволило бы избежать риска затухания готовых функций в BitBucket и никогда не оказаться перед клиентом.

Наконец, и это может в конечном итоге стать спорным вопросом, я должен понять, что Docker делает зеленый / синий развертывание много Полегче. В настоящее время, когда я запускаю новое изменение в производство, рабочий сервер ненадолго отключается. Обычно только на 15-20 секунд, но однажды это был целый час. В течение этого окна 15-20 секунд я бегу composer update, npm install, а также gulp, Первые две команды обычно не нужно ничего делать (поскольку мои зависимости меняются не часто) и gulp обычно завершается в течение 15 секунд. Однако, когда зависимости делать изменить или когда есть большие проблемы (например, необходимость обновления MySQL), сайт может отключиться на целый час. Если бы я мог медленно и спокойно развертывать на вторичном производственном сервере, а затем переключить коммутатор за миллисекунды, когда я убедился, что он работает правильно, это означало бы меньшее время простоя и больше довольных клиентов.

Конечно, последний может быть спорным, потому что я в настоящее время не использую шаг «сборки» (другая часть приложения с двенадцатью факторами), и все эти шаги должны быть частью фазы «сборки» — не фаза «развертывания».

Что мне не нравится в Docker

Это еще один инструмент для изучения. Для того, чтобы понять и разработать для моего приложения, вам уже нужно понять:

• PHP
• Композитор
• Symfony
• Laravel
• NodeJS
• NPM
• Глоток
• начальная загрузка
• VueJS
• (вероятно, много других вещей, о которых я не могу думать прямо сейчас)

Добавление «Docker» в этот список просто означает, что этому проекту будет намного сложнее обучать кого-либо, если я когда-нибудь передам его другому разработчику. я хочу меньше зависимости, не более

Кроме того, Docker не поставляется по умолчанию с любой операционной системой, о которой я знаю. Так что это не похоже на cURL, где, хотя технически это сторонняя зависимость, обычно можно ожидать, что у людей она есть. Вместо этого это целый зверь, который должен быть установлен отдельно.

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