Если у вас НЕ высоконагруженный сервис — вы конечно можете отдать весь low-level на откуп «контейнерному облаку».
Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
В случае с бд — минимум танцев — это реплика на другой хост с последующим переключением. Докер тут не нужен от слова «совсем».
Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
Кроме вопроса о реальной необходимости ставить screen и bash c переменными — в случае с ansible вам нужно было просто разбить все эти установки на роли. И выглядело бы оно как
roles:
— { role: bash, var: 'foo' }
— screen
— wget
— vim
После десятка вполне определенных книг я полностью переосмыслил свой подход к менеджменту. После нескольких книг и семинаров. открыл свой бизнес. После двух конкретных видео-курсов, бизнес заколосился с новой силой.
Можете рассказать про эти книги, семинары и видео-курсы?
Перевод официальной документации мало кому интересен. Таких статей в интернете и так уже достаточно. Даже на хабре. Гораздо более интересен реальный опыт продакшна, реальные проблемы, возникшие в процессе работы и реальные способы их решения.
Основная проблема с переменными в ansible — что их можно много где описывать — и потом огрести проблемы с поддержкой. Поэтому необходимо с момента начала реальной эксплуатации вырабатывать некие правила работы с переменными.
Поделюсь своими наработками:
Максимум переменных выносим в роли, из них большинство должно находится в role/defaults/main.yml, то-есть быть переменными по-умолчанию.
Если у вас много переменных, завязанных на конкретный проект|сервис, а роль используется для многих проектов|сервисов, то пока лучшее решение, что я нашел — это напротив хоста или в группе хостов ставить переменную project=bla, а внутри роли импортировать в переменных массив такого вида:
А можете пояснить, для чего в 2015 году только выбирающий себе CM-систему человек, может заинтересоваться cfengine и обойти стороной chef, puppet, ansible и salt?
Не сарказм.
У вас же машина поднимается посредством ваших скриптов? Почему бы этими же скриптами не запускать с управляющей машины плейбук провижининга против нового хоста?
У нас порядка 400. А какие велосипеды писали, для чего, поделитесь? Нас ansible полностью устроил, основная проблема была в утрясании workflow, много итераций прошли в этом процессе.
Про идемпотентность:
Все зависит от вашего стиля написания плейбуков. Если вы использовали raw: wget foo.bla/file — то файл будет скачиваться каждый раз. Если же вы используете модуль get_url — то он будет проверять наличие и хэш файла перед скачиванием. Мы же в своей работе обычно пишем вначале стек проверок и заносим результаты в переменные. После чего в каждом шаге есть проверка вида «если nginx -v != заданной версии nginx — то берем собранный пакет и ставим. Если же nginx -v = заданной версии — то скипаем шаг. У нас, например, все роли обеспечивают идемпотентность.
Про кучу серверов единовременно:
У нас такой задачи не стоит обычно, но сами разработчики рапортуют об успешных инсталяциях на инфраструктурах в десятки тысяч машин. Можно запускать по очереди, по 10-20 хостов за раз. Можно отправить все задачи в кролика — и кем-то их разбирать. Архитектуры, которые решают подобные задачи уже изобретены.
Он простой, как три копейки. Например собрать собственный rpm-пакет из папки можно так(пример из оф. вики):
fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.
Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
SQL — есть
Нужно добавить HTML.
roles:
— { role: bash, var: 'foo' }
— screen
— wget
— vim
Можете рассказать про эти книги, семинары и видео-курсы?
Поделюсь своими наработками:
Максимум переменных выносим в роли, из них большинство должно находится в role/defaults/main.yml, то-есть быть переменными по-умолчанию.
Если у вас много переменных, завязанных на конкретный проект|сервис, а роль используется для многих проектов|сервисов, то пока лучшее решение, что я нашел — это напротив хоста или в группе хостов ставить переменную project=bla, а внутри роли импортировать в переменных массив такого вида:
в плейбуке строить шаги следующим образом:
этот шаг будет использовать переменные var1, var2 и var3 из массива, где в переменной project стоит необходимое значение (в нашем случае — bla).
Не сарказм.
Все зависит от вашего стиля написания плейбуков. Если вы использовали raw: wget foo.bla/file — то файл будет скачиваться каждый раз. Если же вы используете модуль get_url — то он будет проверять наличие и хэш файла перед скачиванием. Мы же в своей работе обычно пишем вначале стек проверок и заносим результаты в переменные. После чего в каждом шаге есть проверка вида «если nginx -v != заданной версии nginx — то берем собранный пакет и ставим. Если же nginx -v = заданной версии — то скипаем шаг. У нас, например, все роли обеспечивают идемпотентность.
Про кучу серверов единовременно:
У нас такой задачи не стоит обычно, но сами разработчики рапортуют об успешных инсталяциях на инфраструктурах в десятки тысяч машин. Можно запускать по очереди, по 10-20 хостов за раз. Можно отправить все задачи в кролика — и кем-то их разбирать. Архитектуры, которые решают подобные задачи уже изобретены.
fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.