связывание исходного кода в контейнерах докеров

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

В dev, я могу построить контейнер супер быстро, так как исходный код и активы для контейнера находятся вне контекста контейнера - тогда я просто сопоставляю каталог wwwroot в контейнере, используя флаг -v команды docker run. Он отлично работает!

Однако теперь у меня есть приложение Elastic Beanstalk (настроено для докеров), и я ищу для развертывания моего контейнера. Я думаю, что подход «-v» для производства не является правильным, и мне, возможно, нужно иметь отдельный файл Docker для производства, который физически COPY использует мой исходный код в контейнере? Тогда, возможно, это контейнер, который я подталкиваю к докер-хабу и как-то пересылаю на Эластичный бобовый шток.

Или здесь есть лучший подход? Я не смог найти четкого указания относительно того, как подойти к этому.

источник

2016-02-25 Brian FitzGerald

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

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

источник

2016-02-25 15:03:58

Копирование активов для производства имеет смысл, спасибо. Но в dev, чтобы скопировать активы в контейнер, будет означать, что вам нужно будет перестроить при каждом изменении кода, не так ли? Кажется, настоящая боль. –

Большинство разработок включает в себя повторную стадию «сборки» (код изменения, сборка, тестирование, повтор). Это ваш контейнер (и копирование активов). –

Отличный момент, спасибо за обмен. У нас есть процесс сборки, но мы запускаем сборку только тогда, когда мы готовы к фиксации, а не обязательно после каждого изменения кода, чтобы увидеть, как приложение запускает новый код (до того, как вы готовы к фиксации). Независимо от того, я ценю ваше понимание, и теперь я вижу, как можно запустить процесс сборки изображений докеров в ваш общий процесс сборки приложений. –

Лучшая практика указывает, что файл Docker должен быть как можно более эфемерным. Следовательно, флаг -v на самом деле является правильным способом совместного использования кода. Код не должен быть в образе.

источник

2016-02-25 15:08:27 Auzias

Код не должен быть на изображении, даже в производственной среде? Тогда где это должно быть? –

На том же хосте (или доступном хранилище) и обменивается томом. Если вы когда-либо вставляли свой код, при каждой фиксации вам понадобилось бы новое изображение ( вы даже версии bro?). Докер нацелен на облегчение шага между разработчиком и развертыванием, что означает состояние системы, пакеты, сама система, а не код, который развивается намного быстрее, чем вся необходимая экосистема. Следовательно, код делится через -v и не внедряется. – Auzias

Lol сильная шутка произведение. Да, то, что вы описываете, - это подход, который кажется мне очень естественным, поскольку, естественно, наш код приложения будет изменять FAR чаще, чем экосистема. Тем не менее, я думал, что то, что вы описываете, на самом деле считается плохой практикой в том, что контейнер Docker становится менее портативным, так как внезапно он зависит от среды, в которой он запущен, и больше не является полностью «автономным» объектом. –

связывание исходного кода в контейнерах докеров

ответ

Смежные вопросы