Comments 20
У вас spoiler не сработал
Сам первое что пробовал — Ansible, вот уже пол года активно пользуюсь и радуюсь. Но тут захотел попробовать Puppet, но что то модель pull мне совершенно не нравится
Сам первое что пробовал — Ansible, вот уже пол года активно пользуюсь и радуюсь. Но тут захотел попробовать Puppet, но что то модель pull мне совершенно не нравится
Кстати, судя по гитхабу и багтрекеру ансибл-модуля «докер», который бы Вам пригодился, Этот ансибл модуль докера я бы пока в продакшен не выпускал.
а так — я бы на Вашем месте реально подумал про Docker — полноценная виртуалка требует больше внимания на администрирование.
а так — я бы на Вашем месте реально подумал про Docker — полноценная виртуалка требует больше внимания на администрирование.
Удел докера, это быстрое создание лёгкого окружения разработчика, а отнюдь не контейнерная виртуализация для продакшена.
Хоть и декларируется, что «Docker is an open platform for developers and sysadmins of distributed applications.», сисадминам удобнее использовать полноценные виртуальные машины с большей изоляцией, и полноценной операционкой.
Поддерживать в продакшене докер контейнеры не проще, наоборот — это редкостный геморрой, на самом-то деле. Можно запихать в каждый образ ssh, пакетный менеджер, клиент системы мониторинга и.т.п., но при этом он уже и не будет отличаться от других контейнеров при этом имея проблемы с изоляцией той же. А без этих инструментов для продакшена он просто не годится, т.к. без обновлений, мониторинга и.т.п. вы далеко в продакшене не уплывёте.
Обратите внимание на страничку www.docker.com/resources/usecases — для чего крупные компании используют докер — в основном это " testing and deployment"
Хоть и декларируется, что «Docker is an open platform for developers and sysadmins of distributed applications.», сисадминам удобнее использовать полноценные виртуальные машины с большей изоляцией, и полноценной операционкой.
Поддерживать в продакшене докер контейнеры не проще, наоборот — это редкостный геморрой, на самом-то деле. Можно запихать в каждый образ ssh, пакетный менеджер, клиент системы мониторинга и.т.п., но при этом он уже и не будет отличаться от других контейнеров при этом имея проблемы с изоляцией той же. А без этих инструментов для продакшена он просто не годится, т.к. без обновлений, мониторинга и.т.п. вы далеко в продакшене не уплывёте.
Обратите внимание на страничку www.docker.com/resources/usecases — для чего крупные компании используют докер — в основном это " testing and deployment"
Простите, но Вы кажется не очень понимаете идеологию Docker'а.
Попробую объяснить на примере тот самый Demployment, который вы упомянули в конце комментария, в противоречие своим же словам «продакшене докер контейнеры», Вот, допустим, я пишу свой какойнить бложек на Perl + Mojolicious. у меня туева хуча зависимостей из Cpan, компилирующихся в ~blog/.perl… Чтобы не засырать этими сборками систему, я пишу нечто вроде:
после чего говорю какому-нить скрипту или mesos'у — эй, чувак, наплоди мне на вон том списке хостов стопицот контейнеров из этого образа.
после чего мне достаточно натравить на этот зоопарк nginx.
какой ssh, какое пакетный менеджер, Вы о чем?
идеология контейнеров как раз в том, что Вы в них не лезете и у Вас повторимость, хоть на CoreOS, хоть на Ubuntu, да хоть на Debian 7, хоть еще гдё.
С учётом того, что логи отправляются на какойнить Sentry для аналитики, живущий в контейненре из рядом лежащего образа.
Ну или про сборку/тесты — можно пойти например путём — собираем образ из нужных нам gcc/cpp/make с apt-get|yum install (нужный_список_библиотек) с точкой входа — скрипт компиляции. Про запуске контейнера делаем mount /src и /out на каталоги хост системы. После окончания работы контейнера получаем в /out собранный софт/библиотеки/пакеты. Ну, или в случае тестов получаем лог passed/failed тестов.
Попробую объяснить на примере тот самый Demployment, который вы упомянули в конце комментария, в противоречие своим же словам «продакшене докер контейнеры», Вот, допустим, я пишу свой какойнить бложек на Perl + Mojolicious. у меня туева хуча зависимостей из Cpan, компилирующихся в ~blog/.perl… Чтобы не засырать этими сборками систему, я пишу нечто вроде:
RUN apt-get update && apt-get install -y make gcc postgresql-server-dev-all cpanminus &&\
apt-get clean && apt-get autoremove -y && apt-get autoclean &&\
cpanm -n Mojolicious DBI DBD::Pg Mojolicious::Plugin::Database Mojolicious::Plugin::I18N Date::Parse&&\
mkdir /opt/panel
COPY pmblog /opt/panel/
EXPOSE 8080
VOLUME ["/opt/panel"]
ENTRYPOINT ["/usr/local/bin/hypnotoad","-f","/opt/panel/script/pm_blog"]
после чего говорю какому-нить скрипту или mesos'у — эй, чувак, наплоди мне на вон том списке хостов стопицот контейнеров из этого образа.
после чего мне достаточно натравить на этот зоопарк nginx.
какой ssh, какое пакетный менеджер, Вы о чем?
идеология контейнеров как раз в том, что Вы в них не лезете и у Вас повторимость, хоть на CoreOS, хоть на Ubuntu, да хоть на Debian 7, хоть еще гдё.
С учётом того, что логи отправляются на какойнить Sentry для аналитики, живущий в контейненре из рядом лежащего образа.
Ну или про сборку/тесты — можно пойти например путём — собираем образ из нужных нам gcc/cpp/make с apt-get|yum install (нужный_список_библиотек) с точкой входа — скрипт компиляции. Про запуске контейнера делаем mount /src и /out на каталоги хост системы. После окончания работы контейнера получаем в /out собранный софт/библиотеки/пакеты. Ну, или в случае тестов получаем лог passed/failed тестов.
Про deployment опечатка, прошу прощения.Подразумевалось, конечно, development.
«Чтобы не засырать этими сборками систему»
Как раз и нужно без cpan обойтись, поставив нужное пакетным менеджером системы контейнера. Иной способ хорош только при разработке, когда вы не знаете, что вам может понадобиться в итоге, и ставите пачку всего, и продолжаете этот процесс в течении цикла разработки.
«после чего говорю какому-нить скрипту или mesos'у — эй, чувак, наплоди мне на вон том списке хостов стопицот контейнеров из этого образа.»
И что должен сделать админ, при нахождении критической уязвимости в любой софтине/библиотеке вашего образа? Пересобрать его?
Или по вашему цикл разработки вечен, и разработчик будет выкатывать каждый раз новые образы? В большинстве случаев, это и близко не так.
Логи и мониторинг это несколько разные вещи. Или вы считаете, что вообще не важно, что делается в конкретном контейнере?
Искать проблемы потом по логам, возможно, будет проблематично…
«и у Вас повторимость, хоть на CoreOS, хоть на Ubuntu, да хоть на Debian 7»
А так-ли это нужно в реальности — в рамках одного проекта такой зоопарк держать всё равно не будет никто. А если распространять приложение как образ контейнера для внешнего использования, то возникнет масса других проблем, частично описанных выше. Частично с доверием к вашему образу.
«Чтобы не засырать этими сборками систему»
Как раз и нужно без cpan обойтись, поставив нужное пакетным менеджером системы контейнера. Иной способ хорош только при разработке, когда вы не знаете, что вам может понадобиться в итоге, и ставите пачку всего, и продолжаете этот процесс в течении цикла разработки.
«после чего говорю какому-нить скрипту или mesos'у — эй, чувак, наплоди мне на вон том списке хостов стопицот контейнеров из этого образа.»
И что должен сделать админ, при нахождении критической уязвимости в любой софтине/библиотеке вашего образа? Пересобрать его?
Или по вашему цикл разработки вечен, и разработчик будет выкатывать каждый раз новые образы? В большинстве случаев, это и близко не так.
Логи и мониторинг это несколько разные вещи. Или вы считаете, что вообще не важно, что делается в конкретном контейнере?
Искать проблемы потом по логам, возможно, будет проблематично…
«и у Вас повторимость, хоть на CoreOS, хоть на Ubuntu, да хоть на Debian 7»
А так-ли это нужно в реальности — в рамках одного проекта такой зоопарк держать всё равно не будет никто. А если распространять приложение как образ контейнера для внешнего использования, то возникнет масса других проблем, частично описанных выше. Частично с доверием к вашему образу.
Админ — в случае уязвимости — да, пересобрать образ.
ssh и rdp — нужны для виртуалок на lxc/openvz/hyper-v. Виртуалок. полных.
А у контейнера другая задача — запускать ОДНО конкретное приложение, висеть на хосте и молотить что надо после аппаратного балансера или nginx'а какого.
Логи и ошибки должны собираться каким-нить Sentry, Elastix'ом и тикетной системой из почты.
Вот у меня на крайнем проекте было полсотни лезвий, apache kafka обрабатывал 5-6 миллионов запросов в секунду от всех.
Скорость добавления записей в логи — сколько-то сотен метров в секунду на все молотилки.
Вы думаете у Вас получится гигабайты логов в сутки, а самое главное — зачем, Если все события должны быть к чему-то привязаны, и могут происходить на разных лезвиях в рамках одной сесии.
Насчет что делается внутри контейнера — нет, не важно. Если там внутри приложение, то оно делает исключительно то, что написали программисты. Или не делает, Но это обычно должно отсекаться разными вариантами тестов.
Насчёт cpan — Ну нет нужных мне модулей в пакетном менеджере репозитория, нету. Не, вру. часть — есть, часть, кхм, устарела. Но часть требует сборки — Вы мне предлагаете сделать еще один образ для сборки cpan модуля в deb, и во втором образе подсовывать его из личного репозитория.
А повторимость нужна не только Вам. Вот у меня был проект из нескольких офисов — в Далласе CoreOS исторически, в Лондоне — debian, в Киеве — centos.
ssh и rdp — нужны для виртуалок на lxc/openvz/hyper-v. Виртуалок. полных.
А у контейнера другая задача — запускать ОДНО конкретное приложение, висеть на хосте и молотить что надо после аппаратного балансера или nginx'а какого.
Логи и ошибки должны собираться каким-нить Sentry, Elastix'ом и тикетной системой из почты.
Вот у меня на крайнем проекте было полсотни лезвий, apache kafka обрабатывал 5-6 миллионов запросов в секунду от всех.
Скорость добавления записей в логи — сколько-то сотен метров в секунду на все молотилки.
Вы думаете у Вас получится гигабайты логов в сутки, а самое главное — зачем, Если все события должны быть к чему-то привязаны, и могут происходить на разных лезвиях в рамках одной сесии.
Насчет что делается внутри контейнера — нет, не важно. Если там внутри приложение, то оно делает исключительно то, что написали программисты. Или не делает, Но это обычно должно отсекаться разными вариантами тестов.
Насчёт cpan — Ну нет нужных мне модулей в пакетном менеджере репозитория, нету. Не, вру. часть — есть, часть, кхм, устарела. Но часть требует сборки — Вы мне предлагаете сделать еще один образ для сборки cpan модуля в deb, и во втором образе подсовывать его из личного репозитория.
А повторимость нужна не только Вам. Вот у меня был проект из нескольких офисов — в Далласе CoreOS исторически, в Лондоне — debian, в Киеве — centos.
«Админ — в случае уязвимости — да, пересобрать образ.»
Ну вот это первое большое неудобство с точки зрения администрирования.
«ssh и rdp — нужны для виртуалок на lxc/openvz/hyper-v. Виртуалок. полных.»
hyper-v тут лишнее, остальное, это та же контейнерная виртуализация, обычно, действительно, с более полным окружением, но запустить в таком контейнере можно и 1 процесс init, вообще без какого-либо окружения.
rdp обычно излишне, а вот ssh полезен хотя бы для того, чтобы автоматизировать что-либо тем же ansible на уровне контейнера.
«запускать ОДНО конкретное приложение, висеть на хосте и молотить что надо после аппаратного балансера»
Что точно также, но с большей изоляцией, часто, как раз и реализуется на тех же lxc/openvz.
Или не делает, Но это обычно должно отсекаться разными вариантами тестов.
В идеальном мире это так.
Насчёт cpan — Ну нет нужных мне модулей в пакетном менеджере репозитория, нету. Не, вру. часть — есть, часть, кхм, устарела. Но часть требует сборки — Вы мне предлагаете сделать еще один образ для сборки cpan модуля в deb, и во втором образе подсовывать его из личного репозитория.
Ну во-первых, оно где-то наверняка есть и поддерживается уже кем-то, в виде пакета, но если действительно нет, то да, поддерживать собственный репозиторий. Или не гоняться за последними версиями модулей при разработке, что тоже часто разумно, например, с точки зрения стабильности и поддерживаемости, о которой программисты часто забывают.
Ну вот это первое большое неудобство с точки зрения администрирования.
«ssh и rdp — нужны для виртуалок на lxc/openvz/hyper-v. Виртуалок. полных.»
hyper-v тут лишнее, остальное, это та же контейнерная виртуализация, обычно, действительно, с более полным окружением, но запустить в таком контейнере можно и 1 процесс init, вообще без какого-либо окружения.
rdp обычно излишне, а вот ssh полезен хотя бы для того, чтобы автоматизировать что-либо тем же ansible на уровне контейнера.
«запускать ОДНО конкретное приложение, висеть на хосте и молотить что надо после аппаратного балансера»
Что точно также, но с большей изоляцией, часто, как раз и реализуется на тех же lxc/openvz.
Или не делает, Но это обычно должно отсекаться разными вариантами тестов.
В идеальном мире это так.
Насчёт cpan — Ну нет нужных мне модулей в пакетном менеджере репозитория, нету. Не, вру. часть — есть, часть, кхм, устарела. Но часть требует сборки — Вы мне предлагаете сделать еще один образ для сборки cpan модуля в deb, и во втором образе подсовывать его из личного репозитория.
Ну во-первых, оно где-то наверняка есть и поддерживается уже кем-то, в виде пакета, но если действительно нет, то да, поддерживать собственный репозиторий. Или не гоняться за последними версиями модулей при разработке, что тоже часто разумно, например, с точки зрения стабильности и поддерживаемости, о которой программисты часто забывают.
Всё-таки вы неправильно различаете полноценные окружения вроде lxc/openvz и docker.
Идеология докера как раз в том. что в него не вмешиваются. Настроил образ, собрал, наплодил контейнеров и понеслась. всё. точка.
Как раз для того, чтобы я мог написав свой перлобложек просто выложить Dockerfile и любой мог этот докерфайл собрать и получить готовый к работе бложик.
В случае обновлений — просто его пересобрать.
Идеология докера как раз в том. что в него не вмешиваются. Настроил образ, собрал, наплодил контейнеров и понеслась. всё. точка.
Как раз для того, чтобы я мог написав свой перлобложек просто выложить Dockerfile и любой мог этот докерфайл собрать и получить готовый к работе бложик.
В случае обновлений — просто его пересобрать.
Я честно смотрел на Докер и думал, как его прикрутить себе в проект. Не нашел возможности.
Для общего уровня развития — как происходит выкладка нового кода с контейнерами? Вот есть у меня фронт, за ним 6 апстримов… Что будет в момент перевыкладывания?..
Для общего уровня развития — как происходит выкладка нового кода с контейнерами? Вот есть у меня фронт, за ним 6 апстримов… Что будет в момент перевыкладывания?..
Пока билдится новая версия образа бложика старое работает. После успешного билда поднимаю новые контейнеры, прописываю в конфиг нгинкса апстримы, передергиваю нгинкс, тушу старые контейнеры, грохаю старый образ. CI в общем-то.
У меня это все пошло немного дальше, я докер в условиях кластерного шаредхостинга хочу использовать, интересный опыт в процессе ковыряния получаю.
У меня это все пошло немного дальше, я докер в условиях кластерного шаредхостинга хочу использовать, интересный опыт в процессе ковыряния получаю.
Во многом согласен. Для себя выбрал lxc.
Про vars_promt даже не слышал, попробую. Очень интересная возможность
про Jinja2 тоже почитайте… конфиги под ситуацию править
Я уже давно использую ansible в продакшене, конфиги всякие доводилось мастерить :)
А вот про интерактив с запуском плейбука услышал впервые :)
А вот про интерактив с запуском плейбука услышал впервые :)
А как Вы себе представляете программирование без переменных?
Sign up to leave a comment.
Centos-admin.ru: познаем Ansible