Комментарии 5
Звук как-то «интересно» записан. На отдельные микрофоны для видео звук писался? Гул стоит страшный конечно, когда спикер говорит в микрофон в руке еще.
:(
:(
confd?
1. А как у вас организовано ли CI контейнеров? Как собираются контейнеры для тестирования?
2. У вас в контейнерах с php-кодом в качестве entrypoint'а/cmd выступает php-fpm?
3. Как у вас организован service discovery? Или повсеместно используются etcd/confd?
4. Как ваша система деплоя понимает, где и в каких количествах нужно разворачивать контейнеры определенного типа?
2. У вас в контейнерах с php-кодом в качестве entrypoint'а/cmd выступает php-fpm?
3. Как у вас организован service discovery? Или повсеместно используются etcd/confd?
4. Как ваша система деплоя понимает, где и в каких количествах нужно разворачивать контейнеры определенного типа?
На второй вопрос ответ уже получил из видео.
Добрый день,
попробую ответить на ваши вопросы:
1. У нас для сборки «тестовых»(а потом уже и не тестовых, после тестирования) образов на той машине, где происходит сборка осуществляется поддержка структуры каталогов для сборки через Puppet. Я понимаю, что это может быть не самое красивое решение, но нам для переходного этапа, когда часть сервисов в контейнере, а часть по прежнему на «голом железе» этот вариант кажется самым предпочтительным. Т.е. у нас получается так:
Build_Directory/
— service_name/
— Dockerfile
— file1
— file2
…
т.е. автоматически наполняем Dockerfile и всю необходимую структуру.
Далее, когда в build системе происходит сборка бинаря/приложения, то оно на основании «шаблона» собирает образ. Тут есть 2 варианта: собралось/не собралось. Если собралось, то тегируем образ, пушим в registry, сообщаем команде тестирования о том, что есть новый образ и нужно начать его тестировать(образ оказывается на нужной для тестирования машины, в задаче на тестирования присутствуют все нужные параметры для запуска контейнера из образа).
2. тут вы уже сами ответ нашли.
3. У нас нет как такого глобального service discovery. У нас есть «карта сервисов», на основании которой мы регулируем то, на каком хосте и кто/что у нас должно работать.
etcd/confd используется уже на отдельновзятом хосте, если мы точно знаем о том, что сервис может быть перезапущен с переключением нагрузки на второй/третий/… инстанс. Да, не все сервисы, к сожалению, умеют так делать. Многим нужен корректный shutdown перед тем, как запустить вторую копию и прочее. Именно поэтому реализация «плавного» перезапуска у нас сделана «поштучно».
4. У нас есть «карта» сервисов, которая поддерживается инженером, на основании которой уже и происходит принятие решений о том кого где и сколько. Т.е. вариант «вот тебе вычислительные мощности — запусти мне где-нить 10-ку инстансов и мне все равно где...» нам не подходит.
попробую ответить на ваши вопросы:
1. У нас для сборки «тестовых»(а потом уже и не тестовых, после тестирования) образов на той машине, где происходит сборка осуществляется поддержка структуры каталогов для сборки через Puppet. Я понимаю, что это может быть не самое красивое решение, но нам для переходного этапа, когда часть сервисов в контейнере, а часть по прежнему на «голом железе» этот вариант кажется самым предпочтительным. Т.е. у нас получается так:
Build_Directory/
— service_name/
— Dockerfile
— file1
— file2
…
т.е. автоматически наполняем Dockerfile и всю необходимую структуру.
Далее, когда в build системе происходит сборка бинаря/приложения, то оно на основании «шаблона» собирает образ. Тут есть 2 варианта: собралось/не собралось. Если собралось, то тегируем образ, пушим в registry, сообщаем команде тестирования о том, что есть новый образ и нужно начать его тестировать(образ оказывается на нужной для тестирования машины, в задаче на тестирования присутствуют все нужные параметры для запуска контейнера из образа).
2. тут вы уже сами ответ нашли.
3. У нас нет как такого глобального service discovery. У нас есть «карта сервисов», на основании которой мы регулируем то, на каком хосте и кто/что у нас должно работать.
etcd/confd используется уже на отдельновзятом хосте, если мы точно знаем о том, что сервис может быть перезапущен с переключением нагрузки на второй/третий/… инстанс. Да, не все сервисы, к сожалению, умеют так делать. Многим нужен корректный shutdown перед тем, как запустить вторую копию и прочее. Именно поэтому реализация «плавного» перезапуска у нас сделана «поштучно».
4. У нас есть «карта» сервисов, которая поддерживается инженером, на основании которой уже и происходит принятие решений о том кого где и сколько. Т.е. вариант «вот тебе вычислительные мощности — запусти мне где-нить 10-ку инстансов и мне все равно где...» нам не подходит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Видео докладов с DevOps Meetup про Docker