Здравствуйте, в статье есть ссылки где можно почитать еще. А вообще очень много толковых англоязычных ресурсов, погуглите например "ivan velichko docker" - у него весьма толковый бложек.
Чем ответить на ваш «сепулек», не представляю, боюсь опускаться до такого уровня. С вашей точкой зрения всё ясно, однако она не является единственно верной. Как моя статья — субъективное отражение моего понимания вещей, не претендующая на истину в последней инстанции. Писать всеобъемлющие технические статьи долго, тяжело и как правило не оправдывает средств. Написать статью, которая привлечет интерес читателя и не заставит его заснуть после пяти минут чтения, а возможно еще и заинтересует и вызовет вопросы — тоже та еще задачка. И потом, если бы люди писали статьи не оставляющие вопросов, (где бы токсики сбрасывали яд?) на Хабре не было бы смысла в комментах. На мой взгляд, человек интересующийся чем-то, должен уметь всесторонне оценивать информацию, делать свои выводы, сравнивая разные точки зрения и не упрощать вещи (в которых 245k+ строк кода) до уровня "обертки" или "изоляции".
Дело не том что он плох внутри контейнера, он в принципе не то чтобы очень хорош. Но суть в том, что не нужно плодить процессы внутри контейнера. Один контейнер/один сервис/одна задача.
В основном не знают (если это так) те, кто начинал осваивать ansible с более ранних версий. Например, я сравнительно недавно узнал про default(omit) хотя он появился в 1.8, а combine появился в 2.0.
В общем надо почаще заглядывать в документацию она обновляется с каждым релизом.
Эта схема будет работать автоматически, если в файле inventory (hosts) будут соответствующие группы (dev/stage/prod). В плейбуках при этом можно ничего специально не прописывать.
Это не совсем правда. Дата задается, но меняется только если шаблон изменился.
У меня при --check не было такой проблемы (ansible 2.0.1.0). Хотя в некоторых версиях думаю такое могло быть.
«К сожалению», любой программный продукт нужно постоянно доделывать, допиливать и т.д.
Если вы не готовы, что либо поддерживать и дорабатывать, то вам нечего делать в ИТ.
Я храню роли в отдельном репо. Смешивать с кодом (Python/PHP) я не стал бы, смысла нет (если только вы не упираетесь в какие-то ограничения).
Тут можно разные подходы использовать. Можно сделать плейбук который будет обновлять сам Ansible и обновлять репо с плейбуками/ролями — дергать его по крону или как pre-task в Jenkins или аналогах.
1) Нормально (хотя это не очень хорошо если вам приходится следить за зоопарком разных дистрибутивов).
2) Это тоже нормально, от этого не всегда можно уйти.
Очень понравился ваш подход к внедрению докера — очень разумно всё. Не просто: «О! Докер, круто! Погнали в продакшн!» — что не редкость как мне кажется. Рассмотрели, подготовились, собрали свои образы, ядро. Взяли ту часть сервисов, где было разумно его внедрить. Просто отлично.
Есть еще такая штука как LXD позволяет доставлять полноценные контейнеры с необрезанной ОС, плюс живая миграция и поддержка OpenStack.
Ну на самом деле за пределами документации сейчас уже не так и много всего.
Есть определенные тонкости, но их понимание приходит со временем, после третьей, четвертой ревизии ваших ролей.
Поэтому у каждого свои «best practices» их нельзя получить и усвоить разом из какой-нибудь статейки.
Вы говорили про странности с include и block.
Include нужен для того чтобы инклудить файлы с тасками в плебуках/ролях.
Block нужен что объединять группы тасков в блоки с некими общими условиями (when: something).
Тут вы пишите кусок jinja-шаблона. Теперь мне совсем не понятен контекст. :)
Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.
Можно (и нужно) всё хранить в git даже пароли если использовать (ansible-vault). Ну кроме файлов приватных ключей наверное, хотя их тоже можно хранить в виде зашифрованных переменных.
Обычно во взрослых компаниях так или иначе использующих методологию DevOps настраивают несколько окружений. И как правило тестируют новый код на соответсвующем окружении (DEV например).
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.
Здравствуйте, в статье есть ссылки где можно почитать еще. А вообще очень много толковых англоязычных ресурсов, погуглите например "ivan velichko docker" - у него весьма толковый бложек.
Чем ответить на ваш «сепулек», не представляю, боюсь опускаться до такого уровня.
С вашей точкой зрения всё ясно, однако она не является единственно верной. Как моя статья — субъективное отражение моего понимания вещей, не претендующая на истину в последней инстанции.
Писать всеобъемлющие технические статьи долго, тяжело и как правило не оправдывает средств. Написать статью, которая привлечет интерес читателя и не заставит его заснуть после пяти минут чтения, а возможно еще и заинтересует и вызовет вопросы — тоже та еще задачка. И потом, если бы люди писали статьи не оставляющие вопросов, (где бы токсики сбрасывали яд?) на Хабре не было бы смысла в комментах.
На мой взгляд, человек интересующийся чем-то, должен уметь всесторонне оценивать информацию, делать свои выводы, сравнивая разные точки зрения и не упрощать вещи (в которых 245k+ строк кода) до уровня "обертки" или "изоляции".
Дело не том что он плох внутри контейнера, он в принципе не то чтобы очень хорош. Но суть в том, что не нужно плодить процессы внутри контейнера. Один контейнер/один сервис/одна задача.
Жду когда появится на Debian.
В общем-то я уже сам делал пакетик, но не охота заморачиваться с его поддержкой.
В общем надо почаще заглядывать в документацию она обновляется с каждым релизом.
host01
host02
[stage]
host01
host02
[prod]
host01
host02
У меня при --check не было такой проблемы (ansible 2.0.1.0). Хотя в некоторых версиях думаю такое могло быть.
Если вы не готовы, что либо поддерживать и дорабатывать, то вам нечего делать в ИТ.
Спрячте текст под спойлер плиз.
Тут можно разные подходы использовать. Можно сделать плейбук который будет обновлять сам Ansible и обновлять репо с плейбуками/ролями — дергать его по крону или как pre-task в Jenkins или аналогах.
Обоснуйте.
Что-то не припомню такого. Тыкните в док.
О чем это? Неудачные опыты?
При наличии рук не растущих из плеч и отсутствии привычки тестировать свой код можно добиться и более впечатляющих результатов.
2) Это тоже нормально, от этого не всегда можно уйти.
Есть еще такая штука как LXD позволяет доставлять полноценные контейнеры с необрезанной ОС, плюс живая миграция и поддержка OpenStack.
Есть определенные тонкости, но их понимание приходит со временем, после третьей, четвертой ревизии ваших ролей.
Поэтому у каждого свои «best practices» их нельзя получить и усвоить разом из какой-нибудь статейки.
Include нужен для того чтобы инклудить файлы с тасками в плебуках/ролях.
Block нужен что объединять группы тасков в блоки с некими общими условиями (when: something).
Тут вы пишите кусок jinja-шаблона. Теперь мне совсем не понятен контекст. :)
Можно (и нужно) всё хранить в git даже пароли если использовать (ansible-vault). Ну кроме файлов приватных ключей наверное, хотя их тоже можно хранить в виде зашифрованных переменных.
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.