Pull to refresh
31
0
Иван Тужилкин @1it

Systems Engineer, DevOps/SRE Advocate

Send message

Здравствуйте, в статье есть ссылки где можно почитать еще. А вообще очень много толковых англоязычных ресурсов, погуглите например "ivan velichko docker" - у него весьма толковый бложек.

Чем ответить на ваш  «сепулек», не представляю, боюсь опускаться до такого уровня.
С вашей точкой зрения всё ясно, однако она не является единственно верной. Как моя статья — субъективное отражение моего понимания вещей, не претендующая на истину в последней инстанции.
Писать всеобъемлющие технические статьи долго, тяжело и как правило не оправдывает средств. Написать статью, которая привлечет интерес читателя и не заставит его заснуть после пяти минут чтения, а возможно еще и заинтересует и вызовет вопросы — тоже та еще задачка. И потом, если бы люди писали статьи не оставляющие вопросов, (где бы токсики сбрасывали яд?) на Хабре не было бы смысла в комментах.
На мой взгляд, человек интересующийся чем-то, должен уметь всесторонне оценивать информацию, делать свои выводы, сравнивая разные точки зрения и не упрощать вещи (в которых 245k+ строк кода) до уровня "обертки" или "изоляции".

Дело не том что он плох внутри контейнера, он в принципе не то чтобы очень хорош. Но суть в том, что не нужно плодить процессы внутри контейнера. Один контейнер/один сервис/одна задача.

Спасибо, статья годная.
Жду когда появится на Debian.
В общем-то я уже сам делал пакетик, но не охота заморачиваться с его поддержкой.
В основном не знают (если это так) те, кто начинал осваивать ansible с более ранних версий. Например, я сравнительно недавно узнал про default(omit) хотя он появился в 1.8, а combine появился в 2.0.
В общем надо почаще заглядывать в документацию она обновляется с каждым релизом.
Эта схема будет работать автоматически, если в файле inventory (hosts) будут соответствующие группы (dev/stage/prod). В плейбуках при этом можно ничего специально не прописывать.
hosts
[dev]
host01
host02

[stage]
host01
host02

[prod]
host01
host02
Это не совсем правда. Дата задается, но меняется только если шаблон изменился.
У меня при --check не было такой проблемы (ansible 2.0.1.0). Хотя в некоторых версиях думаю такое могло быть.
«К сожалению», любой программный продукт нужно постоянно доделывать, допиливать и т.д.
Если вы не готовы, что либо поддерживать и дорабатывать, то вам нечего делать в ИТ.
Too many ifs! :)
Спрячте текст под спойлер плиз.
Я храню роли в отдельном репо. Смешивать с кодом (Python/PHP) я не стал бы, смысла нет (если только вы не упираетесь в какие-то ограничения).
Тут можно разные подходы использовать. Можно сделать плейбук который будет обновлять сам Ansible и обновлять репо с плейбуками/ролями — дергать его по крону или как pre-task в Jenkins или аналогах.
Stateless система под это дело совсем не подходит, поскольку нельзя делать откат ревизий, и, как следствие, нормальное A/B проходит мимо.

Обоснуйте.

Кроме того, у них в гайдлайне написано, дескать: не делайте параметризированных ролей, лучше копипаста.

Что-то не припомню такого. Тыкните в док.

Создал, запустил, упал, перезапустил, упал. И так в цикле, пока apdex не просядит и мониторинг не начнёт орать, да? :-}

О чем это? Неудачные опыты?

А стэктрейсы после запуска толстого плэйбука хотя бы на 50+ хостов смотреть? >____<

К примеру, когда в template неправильно указан аргумент src, а изменений много, и вносил их кто-то другой:

При наличии рук не растущих из плеч и отсутствии привычки тестировать свой код можно добиться и более впечатляющих результатов.
1) Нормально (хотя это не очень хорошо если вам приходится следить за зоопарком разных дистрибутивов).
2) Это тоже нормально, от этого не всегда можно уйти.
Очень понравился ваш подход к внедрению докера — очень разумно всё. Не просто: «О! Докер, круто! Погнали в продакшн!» — что не редкость как мне кажется. Рассмотрели, подготовились, собрали свои образы, ядро. Взяли ту часть сервисов, где было разумно его внедрить. Просто отлично.

Есть еще такая штука как LXD позволяет доставлять полноценные контейнеры с необрезанной ОС, плюс живая миграция и поддержка OpenStack.
Ну на самом деле за пределами документации сейчас уже не так и много всего.
Есть определенные тонкости, но их понимание приходит со временем, после третьей, четвертой ревизии ваших ролей.
Поэтому у каждого свои «best practices» их нельзя получить и усвоить разом из какой-нибудь статейки.
Я понял. :) Ответ выше. В jinja свои директивы, include/block там не будут работать.
Include/Block работают в контексте тасков плейбука/роли.
Вы говорили про странности с include и block.
Include нужен для того чтобы инклудить файлы с тасками в плебуках/ролях.
Block нужен что объединять группы тасков в блоки с некими общими условиями (when: something).
Тут вы пишите кусок jinja-шаблона. Теперь мне совсем не понятен контекст. :)
include вместе с block пока не использовал (block — относительно новая директива, в 2.0 появилась). А в чем странность?
Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.

Можно (и нужно) всё хранить в git даже пароли если использовать (ansible-vault). Ну кроме файлов приватных ключей наверное, хотя их тоже можно хранить в виде зашифрованных переменных.
Обычно во взрослых компаниях так или иначе использующих методологию DevOps настраивают несколько окружений. И как правило тестируют новый код на соответсвующем окружении (DEV например).
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.

Information

Rating
Does not participate
Location
Ирландия
Registered
Activity