Спустя три месяца с момента перехода проекта в руки компании Red Hat состоялся (http://www.ansible.com/blog/ansible-2.0-launch) релиз
инструментария Ansible 2.0, предоставляющего средства для управления конфигурацией, оркестровки, централизованной установки приложений и параллельного выполнения типовых задач на группе систем. Код Ansible написан на языке Python и распространяется под лицензией GPLv3.
Ключевые новшества (https://raw.githubusercontent.com/ansible/ansible/stable-2.0...):- Проведён большой рефакторинг кодовой базы, многие подсистемы переписаны с целью унификации и усовершенствования архитектуры проекта. Полностью переписан код парсеров и разбора формата YAML для упрощения добавления новых языковых возможностей и увеличения информации о сути выявляемых при разборе ошибках синтаксиса YAML. При этом, основной задачей при проведении рефакторинга было сохранение обратной совместимости и возможность продолжения использования уже имеющихся конфигураций;
- Добавлена поддержка блоков задач (Task Blocks), которые предоставляют пользователям средства группировки задач друг с другом, используя теги, условные выражения и различные атрибуты задач. Блоки также представляют новую концепцию привязки обработки исключений к плану конфигурации (playbooks (http://docs.ansible.com/ansible/playbooks.html)), которые реализованы по аналогии с применением try/except/finally в Python и влияют только на текущий playbooks.- Расширены средства диагностики ошибок в файлах YAML. Текст ошибки теперь более точно идентифицирует проблему и предлагает возможные способы исправления ошибки.
- Операция include теперь приводит к динамическому разбору подключаемых файлов вместо ранее применяемого метода подстановки их текста, вызывающего проблемы, если включение производится внутри цикла;
- Поддержка плагинов для определения стратегии выполнения, позволяющих изменить способ запуска задач на внешних хостах. Классический линейный способ заключается в поочерёдном разборе задач, с выполнением каждой задачи на всех хостах. В Ansible 2.0 дополнительно реализован плагин со стратегией "free", при которой задачи выполняются на хостах в соответствии с инидивидуальным списком, что позволяет переходить на хосте к новым задачам, не дожидаясь завершения выполнения задачи другими хостами.
- Представлено около 200 новых модулей, среди которых отдельно выделяются модули для управления OpenStack, для конфигурирования и управления окружениями VMware и Docker, для поддержки Amazon Web Services и Microsoft Windows.
Из особенностей Ansible можно отметить простой и читаемый язык управления конфигурацией, поддержку распараллеливания работ, отсутствие необходимости установки на удалённые системы специальных программ-агентов (все операции инициируются централизованно по SSH), возможность работы без прав root. Система Ansible не так усложнена как cfengine, puppet и Chef, но при этом предоставляет достаточно широкие возможности и высокую гибкость управления.URL: http://www.ansible.com/blog/ansible-2.0-launch
Новость: http://www.opennet.me/opennews/art.shtml?num=43661
О как хорошо, что не начал изучать раньше - пришлось бы переучиваться.
При этом, основной задачей при проведении рефакторинга было сохранение обратной совместимости и возможность продолжения использования уже имеющихся конфигураций;Шах и мат идиот!
И всё равно кое-где совместимость была нарушена. Пришлось пока откатиться на 1.9.4.
Это первый мажорный релиз, регрессии наверно.
Только что обновился, старые конфиги все работают.
А я рад, что уже пол года занимаюсь ансиблом. В данном случае, я думаю, что чем раньше, тем лучше, нечего тянуть.
Надеюсь, что переход под крыло Red Hat поможет им разгрести накопившиеся пул-реквесты.
> Система Ansible не так усложнена как cfengine, puppet и Chef, но при этом предоставляет достаточно широкие возможности и высокую гибкость управления.Не так усложнена, как CFEngine, и настолько же неприменима ни для решения проблемы бутстрапа, ни для управления большим количеством серверов. С другой стороны, лучше хипстеры с Ansible, чем "матёрые" "юникс" "админы", что-то там руками админящие. Поздравляю всех пользователей и советую всё же разобраться в "сложном" CFEngine.
Хочется предметно. Какие киллер фичи?
Плюсую вопрос.После чтения комментов к новостям, складывается впечателение, что местные "гуру" работают как минимум у гугла или амазона в датацентрах решая вопросы миллионов серверов, выдавая специфичные задачи за повседневность.
Куда нам "старым юникс админам" локалхоста до таких.
Старым юникс-админам и pussy.exe хватит.
Кстати, я со своими сотнями железок и тысячами виртуалок себя "гуру" не считаю, ибо с паппетами и прочими ансиблами это уже просто, удобно и тривиально.
И ещё, знал бы ты, кто работает в датацентрах.... Часто приходилось с ними общаться. Это вообще тупиковая ветвь.
Электрики там работают...
Вы слишком хорошо о них думаете, но к сожалению, всё гораздо хуже.
Да, нет там никаких киллерфич. Аноним просто пытается казаться умным. Я использовал cfengine, puppet (chief) и сейчас ansible. Ansible показался настоящим раем после всего прочего. Просто отдыхаешь на конфигах и тратишь минимум времени.
> Да, нет там никаких киллерфич. Аноним просто пытается казаться умным. Я использовал
> cfengine, puppet (chief) и сейчас ansible. Ansible показался настоящим раем после
> всего прочего. Просто отдыхаешь на конфигах и тратишь минимум времени.а это самое главное, коллеги, сейчас, к сожалению. отдыхать на конфигах. пока очередная приблудина на питоне, написанная таким же второкурсником, отъедает 100% ядра, просто чтобы сливать с хоста логи и метрики.
зато конфиги очевидные.
>> Да, нет там никаких киллерфич. Аноним просто пытается казаться умным. Я использовал
>> cfengine, puppet (chief) и сейчас ansible. Ansible показался настоящим раем после
>> всего прочего. Просто отдыхаешь на конфигах и тратишь минимум времени.
> а это самое главное, коллеги, сейчас, к сожалению. отдыхать на конфигах. пока
> очередная приблудина на питоне, написанная таким же второкурсником, отъедает 100% ядра,
> просто чтобы сливать с хоста логи и метрики.
> зато конфиги очевидные.предпочитаете отдыхать на ruby? когда я говорю, что отдыхаю - это означает, что их писать легко. меньше вероятность ошибки. а про второкурсника - это кто?
Ну да если ты не ruby программист для chef сложно писать рецепты. Плюс сам chef более развесистый.
> отъедает 100% ядра, просто чтобы сливать с хоста логи и метрики.В смысле непомерно долго отъедает или хотелось бы, чтоб процесс происходил неспешней, зато ядра были свежей?
В двух словах не расскажешь. Надо очень издалека начинать, с Promise Theory и всего, что из неё следует.
Т.е. прочитали введение и больше сказать нечего? Открою секрет, в ansible ровно такие же promises, только намного удобнее.
В Ansible основной стратегией, ещё со времён неадеквакта ДеХаана, является push. На этом можно было бы закончить обсуждение, но он из проекта ушёл совсем, а RH, что бы я про них ни думал, вынуждены обслуживать своих корпоративных клиентов с большим количеством оборудования, где push неприменим принципиально. Есть надежды, что pull в итоге получит необходимое количество внимания. Вторая боль Ansible --- зависимость от Питона. С Питоном (что бы там ни рассказывали "матёрые" "сишники" :) всё в порядке, но увы, проблема бутстрапа с Ansible решается сложнее, чем с CFE. Третья проблема --- зависимость от OpenSSH и следующая из этого невозможность гарантировать добровольную кооперацию. Если где-то есть шелл, то в этот шелл рано или поздно зайдёт "матёрый" "юникс" "админ", и всё там "починит".Отсутствие возможности гарантировать соответствие нормативам сходимости конфигураций и гарантии детерминированного поведения в проблемы записывать не будем, это просто отсутствие нужного кода в нужных местах. Будет ли он написан мы узнаем со временем.
Увы, тут 99% не понимают что такое push/pull/bootstrap в контексте ansible/puppet. Сам был ярым фанатом ansible, пока не перешёл на новую работу где везде используется стратегия pull с puppet и не увидел очевидные минусы ansible..
> и не увидел очевидные минусы ansible..Опять же было бы здорово кратенько их тут описать -- про любой полезный инструмент лучше знать именно пределы и недостатки, достоинства-то более очевидны обычно.
Так проблема не в Ansible как таковом, а именно в стратегии, которую он предлагает (я в курсе про pull, но он не является основным и не "рекламируется" как таковой). Если действительно необходимо расписать преимущества и недостатки push vs. pull --- я могу, у меня и примеры из реальной жизни имеются хорошие. Но мне так кажется, что это и без меня тут все хорошо представляют.
Да всё впорядке в ansible и c pull:
https://github.com/ansible/ansible-examples/blob/master/lang...и с бутстрапом:
- include: bootstrap.yml----bootstrap.yml----
...
task:
- name: ansible bootstrap
raw: apt-get clean && apt-get update && apt-get install -y python sudo
a лулзы про "основную стратегию" оставьте маркетологам.
Бутстрап — это не файлик bootstrap.yml, который уже кто-то положил на установленную систему. Это когда надо достать из коробки пустой сервер и ввести его в строй.Пулл в Ансибле это затычка «чтобы тоже было». Крон упал и весь пулл кончился вместе с ним. При этом на каждой машине лежит копия всего из DVCS. Как PoC нормально, но в прод это нельзя. Там ещё код писать и писать.
И про маркетологов: pull считается «инвертированной» технологией. Вот цитата из документации, выделение моё: «Should you want to *invert the architecture of Ansible*, so that nodes check in to a central location, instead of pushing configuration out to them, you can». И не надо мне тут заливать про фигуры речи. Это официальная документация, а не «Капитанская дочка». К тому же, pull — это не просто инвертирование push. Есть нюансы, и они критически важны, особенно в тех случаях, когда есть внешние требования (соответствие условиям сертификации итп).
Достать пустой сервер из коробки и сделать ему опля это либо dhcp+pxe с дистрибутивом который подтянет откуда-нибудь тарнутый набор (будь то приблуды от chef(omnibus), puppet или salt, или ansble) который развернёт bootstrap, либо ilo/idrac и provisioning, который одинаково приходится допиливать (для тех же перечисленных систем управления конфигурациями).
И так же как и cron может упасть и chef-client, и puppet-agent, и salt, так что ни разу не аргумент.
И не надо лечить про копию всего из dvcs, ansible-pull по умолчанию только последний срез забирает, а забирать всё - надо ключик --full допихать в cron (или к systemd.timer).
И всё лаконично в доке сказано про pull - you can.
А про сертификацию это - аргументация кончилась? Хз не приходилось ещё систему управления конфигурациями сертифицировать, там где требуется сертификация обычно paсkages в дистрибутиве/репозитории и развертывание по pxe/usb/cd/dvd.
Сразу видно, что про Энсибл ты узнал из этой новости 5 минут назад.
> Сразу видно, что про Энсибл ты узнал из этой новости 5 минут
> назад.Сразу видно, что ты в небо пальцем. Я ещё помню те страшные времена, когда Ansible была "настоящей системой управления, а не какой-то там библиотекой" (почти точная цитата ДеХаана) и не работала в virtualenv вообще из-за захардкоженных путей в коде.
В принцыпе free... Но лично у меня плэйбуки для каждого хоста отдельные(потому как мне так удобнее), и соотв не актуально.
> Не так усложнена, как CFEngine, и настолько же неприменима ни для решения проблемы бутстрапакак раз ощутимо более, чем cfengine, puppet или chef. не?
> ни для управления большим количеством серверов
это с каким количеством серверов у вас cfengine не справляется?
самое главное забыли> * Releases are now named after Led Zeppelin songs, 1.9 will be the last Van Halen named release.
так глядишь мало-помалу они и от питона откажутся.
Перепишут на го?
на леди гого
Gogo Blackwater?
нужно, годно. Наконец-то с поддержкой python 3!
И ещё поддержку Solaris 10 + 11 добавили.
https://www.opencsw.org/packages/ansible/