Docker — архитектурные вопросы о деплое и не тольно?

Question

[Flaker]

Доброго времени суток, вопросы к людям, которые умеют Docker

1) Как организовать доступ к нескольких сайтам по домену с хоста?
Я сделал так: прокинул порт nginx и в hosts прописал 127.0.0.1 api.domain.local

Но если несколько контейнеров в nginx будут?

2) Как организовать деплой нескольких php-проектов используя докер?
Сейчас думаю так:
Отдельный репозиторий для docker-environment'a, отдельный репо для каждого php-проекта, дальше их git clone, и потом просто папку с проектами маунтим в php и nginx контейнеры. Порты nginx прокинуты.

3) Где держать крон для запуска задач?
Внутри контейнера, в котором находится сам скрипт для выполнения задачи?
Сделать отдельный контейнер для крона (Но как тогда запускать задачи из других контейнеров, даже если они (контейнеры) в одной сети)?
Или держать крон на host системе?

Как я понимаю, правильный путь: держать cron и его таски на хост системы, а сами jobs запускать как docker exec ...?

4) Как обновлять софт в докер-контейнере? Например сейчас у меня через apt-get install в Dockerfile ставится версия libxml2-dev (2.9.1), а последняя 2.9.3.
Как организуется обновление до последних версий софта?
Весь софт руками перерывать?
И если например apt-get update && apt-get upgrade в докер-файле писать, не будет ли так, что в dev, stage, prod environment версии софта будут различные?

5) Можно ли билдить image где-то на своем сервере, и оттуда забирать уже на другие машины?
Что-бы только билд-сервер отвечал за билд, а все остальные пользовались тем, что он выдает. (Образы ведь должны быть одинаковые на всех этапах разработки)

6) Правильно ли держать композер в контейнере с PHP?
Если нет, то как его выносить в отдельный контейнер? Наследоваться от контейнера с пхп и билдить для каждого проекта отдельно?
А если держать его внутри контейнера, то, получается, что в его скриптах нельзя прописывать npm install, так как ноду надо держать отдельно, как в таком случае организовать развертку правильно? Разнести все сборщики в отдельные контейнеры и на хосте собирать?

6.5) Где вообще держать вещи типа: composer, npm, gulp, webpack, bower?

7) Нужен ли композер на проде или туда уже все должно приходить вместе с Docker-Image?

8) Сборщик логов/дампер баз располагать в контейнере с проектом? Или отдельный контейнер для каждого? Или на хосте держать?

9) Как вы организовываете развертывание проекта состоящего из нескольких приложений (Под приложением имею ввиду например: api на php, воркер на node, демон - на С++, блог на WP, базы данных)

Т.е. как научиться разворачивать большой проект на голый сервер в приемлимое время. + иметь возможность быстро поставить это на компьютере нового разработчика в команде (Как минимум в виртуалку)

Comments

[Flaker]

Кажется ответ на вопрос 8 я нашел тут: https://blog.docker.com/2014/06/why-you-dont-need-...

[Flaker]

По-поводу 6 и 6.5 почитал: https://medium.com/@tomsowerby/proper-provisioning...

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

Answer 1

[Сергей Протько]

1) nginx-proxy
2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
4) обновлять базовый образ. А там уж как организуетесь.
5) Можно, смотрим пункт 2.
6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.

Comments

[Flaker]

Спасибо) Еще несколько вопросов:

1) Еще не успел полностью понять, что такое nginx-proxy, но вот прям вчера ночью на такую проблему налетел:

Есть 2 php приложения. Я их засунул в один контейнер с php. Одно приложение является API-сервисом, к которому должно обращаться второе. Так вот как второму обращаться к первому?
На моем хосте, я в файле /etc/hosts прописал домены, но из контейнера то этот файл не видел => приложения не могут друг к другу обращаться?

Конкретная ошибка выглядит так: cURL error 6: Could not resolve host: api.site.local

nginx-proxy как-то может такое разруливать?

2)
> либо платный docker-hub либо разверните свой

Где почитать о том, как развернуть свой?

4)
> обновлять базовый образ.
Что подразумевается под "базовый" и как его обновлять правильно?
> А там уж как организуетесь.
А какие есть варианты организации?

6) Не понял ответа.
> Вы можете же хранить зависимости прямо в репозитории..
> .. Но вы этого не делаете.

Ну это же правильный подход (Подгружать зависимости менеджерами зависимостей)?

> И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.

Вы имеете ввиду, что для node и composer есть свои official docker image? Да, но, мой проект, например, работает на PHP7 + работает с монгой с отдельными драйверами для нее на пхп.
Я пробовал делать установку вендоров используя оффициальный образ composer с docker-hub'а, так вот есть 2 проблемы:
- В офф. образе php5.6 => composer не может сделать autoload
- В офф. образе нет драйверов под монгу => composer говорит, что такой-то вендорный пакет не будет работать, потому что ему нужны такие-то системные зависимости.

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

[Сергей Протько]

Flaker:

1) не нужно их пихать в один контейнер. Они должны быть каждый в своем контейнере. Обращаться они должны по сети. Для удобства рекомендую воспользоваться docker-compose.

2) ридми docker/distribution на гитхабе.

4) ну вот вы в Dockerfile пишите FROM php-fpm например. Вот это и есть базовый образ. Вы можете сделать свой образ и от него уже наследовать остальные, и таким образом вы сможете обновить софт во всех своих образах один раз и потом просто пересобрать остальные.

6) я к тому что зависимости уже должны быть поставлены на момент docker build. У меня для этого просто скрипт для сборки, который перед docker build дергает composer, npm и т.д. У меня даже сборка фронтэнда через gulp/webpack ДО сборки контейнера происходит потому как.... в контейнер уже должно попадать все готовое. Ну а что бы было еще удобнее, можно все эти композеры, npm-ы и т.д. юзать из докера, готовые образы есть и их много.

что до вашей проблемы - вопервых есть там composer под php7 (посмотрите список тэгов). А вопрос с драйверами решается банально --ignore-platform-reqs.

Ну или опять же да, можно сделать как вы предлагаете, но вот честно еще ни разу не сталкивался с проблемами такими, хоть и окружение у меня отнюдь не стандартное.

Answer 2

[jamaZ]

Зачем в наше время пилить Docker вручную, когда есть Nomad, Kubernetes, Mesos, Swarm, Cocaine или, на худой конец Consul

Comments

[vayho]

Ansible, Fleet.

[Inteli Sense]

Чисто теоретически - по времени выгодней знать мотор автомобиля или вообще какие то познания в автомеханике - что бы в нужный момент не остаться на дороге в ожидании сервиса - а смочь решить проблему самому. Предполагаю что тут как бы такая же тема)

[jamaZ]

Давид Габриелян:
если у вас механически управляемый двигатель на карбютаторе - то да, вы даже и почистить и отрегулировать карбюратор сможете на дороге.
для современных, управляемых электроникой двигателей - сие невозможно в принципе.
ну если только вы не профи автосервиса, всегда таскающий в багажнике диагностическое оборудование.
P.S.:
в чем то я с вами согласен, потому и держу один автомобиль с полностью механическим управлением (дизель с классическим ТНВД без электроники) для покатушек по бездорожью.
но основной мой автомобиль - все же с современным двигателем, в котором ковыряться будут только сервисмены.

[Inteli Sense]

jamaZ: И тем не менее нельзя просто взять и поехать. Особенно если у тебя нет прав. Нет опыта. И нет машины. Нельзя просто так взять без докера и сесть на Consoul, Nomad и все что вы там перечислили.

[jamaZ]

Давид Габриелян:
вы бы еще написали - без знания ассемблера нельзя программировать теги в вебе ))))))

дело-то в том, что управлением докером на низком уровне будут заниматься уже высокоуровревые системы, а не ты лично.

[Inteli Sense]

jamaZ: Что то вас понесло. Если мы с вами общаемся в контексте вопроса - то наверно вы увидели что человек только учится что то делать и вообще понимать философию докер.
И ему все эти ваши супер крутые мега заумные "сопле жующие" сервисы не нужны. Либо не стало задачи в которой бы они могли понадобиться.

А по поводу вашего вышесказанного не относящемуся к вопросу - скажу что быстро решать проблему - можно и без этих ваших сервисов, уж поверьте на слово. Уж каким то боком эти разработчики Nomad или Consoul жуящие сопли - решали вопросы и без своих сервисов задолго до их появления. Вероятно они решали их просто с докером верно? или я чего то не понимаю.

[Inteli Sense]

jamaZ: Заканчивайте яро продвигать свою точку зрения. Она меня лично не переубедит.)

[Inteli Sense]

jamaZ: Оказывается в высокодоходном сегменте микросервисов тоже есть быдло. Теперь буду знать)

[Inteli Sense]

jamaZ: Слушайте вы так уверенно разговариваете... А можно парочку ваших проектов? Хоть заценю что вы там такое Сверхъестественное пишете. Очень интересно.
Мол права вам тыкать мне никто не давал. Ведете себя по хамски. Ужасно по хамски. Вы мне вообще никто. А смеете поучать. Отношение уровень быдло. Я представляю что за контора. На хабре о вас ни слова. В интернете о вас только геймерские ролики.

[Flaker]

Заканчивайте ругаться)
Я действительно не умею все эти системы и более того, я про большинство из них даже не слышал. Спасибо, что подсказали о том, что они есть, буду изучать. Но и более низкоуровневые вещи я тоже хочу знать, поэтому вопрос, все-таки, актуален.

[Сергей Протько]

jamaZ то что вы перечислили - это экосистема вокруг, оно не отменяет "ручную работу". С этим тоже надо разбираться и это тоже надо готовить. Тот же сварм автору еще вообще не нужен, так как пока все будет на одной машине. Консул хорошо подходит для разруливания конфигурации и как dns для zero-downtime деплоймента, но руками придется поработать.

[jamaZ]

Сергей Протько: экосистема берет на себя 40% из заданных вопросов. а еще есть best practices к продуктам, где все хорошо описано как решается именно с ними.

[Inteli Sense]

jamaZ: Что же прогресс на лицо. Хотя бы На "Вы обращаться стали" А по поводу вашей конторы - смотрю что вы зарабатываете максимум 4-5$(и то завышено) и мне теперь уж точно пофиг чем вы там занимаетесь)

[Inteli Sense]

jamaZ: Вы поправили комментарий в районе 7 раз. И честно говоря вы такую ахинею несли. Ни в одной корпорации мира не могут работать такие бредо-генераторы как вы. Я просто делю все что вы сказали как минимум на 50. Потому как версии поправленной информации в комментарии расходятся чуть ли не полностью. Вы мечетесь от решения к решению. Если вы так же работаете я представляю эту архитектуру или этот код которого касалась ваша рука. Я не думаю что вы гений разработки, девопс, или системного администрирования. И Отсюда я еще 2 дня назад общаясь с вами сделал вывод что максимум на что вы способны это слова, не более. И как я упомянул - мне вы не интересны. Так что можете засунуть свои рассуждения сами знаете куда.