Как рулить docker-compose в проде?

Question

[Zmtrk62]

Всем привет. А можно много вопросов? Случилось так, что я с LXC перелезаю на докер и мне технически почти всё понятно, но не понятна философия в нескольких местах. Интересует именно то, как бы вы сделали. Предположим, что имеем веб сервер средней важности. На нём развернуты сервисы (в docker-compose):

nginx
php-fpm (собирается из образа с установкой всяких extentions через Dckerfile)
MySQL

1) А теперь я хочу апнуть версию PHP. Для этого я могу собрать еще один контейнер в том же yaml файле, сделать link на него у других сервисов и потом переключить в конфигах Nginx backend. Норм?
А ведь я могу взять и собрать контейнер именно в докерфайле и потом сказать docker-compose, что берем локальный image?
2) Кстати, как поддерживаете чистоту локальных собранных image?
3) Нормально вообще на проде пересобирать сервисы? Напомню, что сайт средней важности. 1-10 мин не критичны.
4) Общий вопрос: предположим вы заядлый Ubuntu пользователь. Но внезапно надо собрать тот же веб сервер как у меня, но на образе Centos. Там разные названия библиотек, extensions для php, названия пакетов и т.д. И вы их не знаете. Это не сложно сделать на "живой системе", но конопатить dockerfile по сто раз с чтением ошибки - бред и долго. Как происходит написание инструкций в Dockerfile при таком раскладе?
5) Что делать если я хочу временно опустить один контейнер? Compose не обидится?

Всем спасибо.

Answer 1

[Александр Иванов]

docker-compose не очень, сейчас в моде kubernetes. Но если очень хочется, то можно:
1. Редактируем yaml и Dockerfile если надо. docker-compose build, docker-compose down, docker-compose up -d. Если изменения yaml большие, например меняется состав сервисов, то стоит down сначала, потом редактирование.
2,3. По возможности локально image не собираются. Есть отдельный процесс разработки, image выкладываются в частный registry, откуда и берутся композом.
4. Образы строятся на том, на чём удобно разработчику. Ни разу не было задачи заменить типа описанной. Но бывает наоборот - новая ОС, на ней запускаются старые проверенные докеры.
5. docker-compse stop servicename

Comments

[Zmtrk62]

Спасибо за ответ. Про кубернетесы в курсе, избыточен на данный момент.
По п.1 - редактирую yaml, Dockerfile и просто делаю docker-compose up -d -- build. Всё собирается и поднимается. Без down. В чем косяк такой схемы?
По п. 4 - немного Вы не поняли. Имеется ввиду не система, на которой собирается контейнер, а именно ОС контейнера - DEB или RPM ориентированная.

[Александр Иванов]

п.1 - обновляемся аккуратненько, делаем build почти без риска влияния на систему, а опасные операции down и up делаем явно. Но это больше вопрос принципа, чем обход конкретной проблемы
п.4 - да я понял, просто описанная задача похожа на искусственную, реально не нужно было. А вообще в процесс разработки, если что-то непонятно и надо руками поковырять, то можно сделать run bash на то, что есть и в консоли руками всё проделать и сохранить важное для Dockerfile

[Roman K]

а зачем делать down? я всегда делаю только up -d, это пересоздаёт сервисы с новыми образами и не трогает те, что без изменений

[Александр Иванов]

Roman Kitaev, можно и не делать. Но я предпочитаю явно делать опасные действия.

Answer 2

[Валентин]

Как рулить docker-compose в проде?

Никак, это решение не для прода, а для запуска на локальных компьютерах. Для прода Kubernetes.

сделать link на него у других сервисов и потом переключить в конфигах Nginx backend

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

Но внезапно надо собрать тот же веб сервер как у меня, но на образе Centos. Там разные названия библиотек, extensions для php, названия пакетов и т.д.

Так, стоп, вы тут всё в кучу смешали. Вы пишите, что у вас сервер, который запускает контейнеры. А в контейнерах уже внутри у вас там вебсервер. Так вот если у вас контейнеры - вам там какая разница, какие они внутри? Ну в смысле что вы берёте те, что вам нравятся и которые вы понимаете, и пользуетесь этим. Зачем пересобирать контейнер из убунты в центось, когда можно пойти и взять сразу с центосью? А самое главное - зачем это делаеть тому человеку, который не знает названий бибилотек и вот этого всего? Если он не знает - он возьмёт то, что знает, контейнеры в том числе для этого и придуманы - вот знает у вас разработчик убунту, использует её, и контейнеры на базе убунты собирает. А дальше он уходит на продовый сервер, который сис.админы подняли на centos например, потому что считают, что для этих задач она им лучше подходит. Таким образом разные люди используют каждый то, что знают уже, и всё вместе работает и решает поставленные задачи.

Comments

[Zmtrk62]

" А самое главное - зачем это делаеть тому человеку, который не знает названий бибилотек и вот этого всего?"
А вы знаете названия ВСЕХ библиотек/пакетов в своей любимой ОС?

[Валентин]

Zmtrk62, эм, "всех" в смысле всех установленных на моем рабочем компьютере? Ну большинство да, я знаю зачем установлены. И именно поэтому с одной стороны я знаю, что вашу задачу "внезапно надо собрать такой же, но на Centos" я могу сделать, т.к. библиотеки-то одни и те же, отличаются особенности сборки и поэтому отличаются зависимости, но суть в итоге одна, но именно поэтому же я и не понимаю, нафиг оно надо? Ну т.е. такая задача - Сизифов труд. Если кому-то понадобится сделать на базе Centos - он будет понимать, зачем он это делает, и соответственно он и сможет это сделать. И он не будет брать ваше и повторять точь-в-точь, он просто сделает такое же сам, как знает.