LINUX.ORG.RU

Вышел Ansible 2.0

 ,


3

5

Сегодня вышел Ansible 2.0. Этот релиз в первую очередь является масштабным рефакторингом, направленным на устранение technical debt, накопившегося за три года бурного роста до 1000 участников. Обещают обратную совместимость на уровне плейбуков, но API плагинов претерпел значительные изменения. Инструкция по портированию прилагается.

Новый релиз также привносит несколько ожидаемых улучшений: таск блоки, которые добавляют механизм исключений в плейбуки, человеческий код для парсинга YAML'а и, соответственно, нормальные сообщения об ошибках, динамические инклуды, а также плагины типа «execution strategy», которые позволяют пользователям менять, как происходит выполнение задач на целевых машинах. Кроме того, в поставку включены новые и/или существенно улучшенные модули для поддержки OpenStack, AWS, Docker, VMWare и Microsoft Windows.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Klymedy (всего исправлений: 1)

надеюсь, этот рефакторинг и изменения в API на убьют проект, как это часто бывает.

val-amart ★★★★★
() автор топика

Напиши, что это в новости

mittorn ★★★★★
()

Что такое этот Ansible? Даже на их сайте не понятно, зачем оно и что делает.

suiseiseki_desu
()

Экспресс-опрос: вы свои веб-проекты выкатываете каким-нибудь сторонним инструментом деплоймента вроде этого анзибля, или самописным скриптом (на базе библиотек) на основном языке проекта?

aidaho ★★★★★
()
Ответ на: комментарий от val-amart

рефакторинг и изменения в API на убьют проект

Вы только что озвучили краткую историю django-fab-deploy.

aidaho ★★★★★
()
Ответ на: комментарий от aidaho

Если бы приходилось ходя бы каждую неделю разворачиваться. А так один раз в пару лет, я как нибудь руками все разверну.

surefire ★★★
()
Ответ на: комментарий от surefire

«Как-нибудь» не интересно.
Плюс бытовое, вроде пнуть девелоперскую ветку на staging server и пусть оно там само тесты покрутит. Тоже руками каждый раз?

aidaho ★★★★★
()
Ответ на: комментарий от surefire

Цирковые выступления ручных локалхост-админов. Ми-ми-ми.

anonymous
()
Ответ на: комментарий от aidaho

Самописным инструментом на базе fabric (хотя там от него только самые базовые вещи остались), плюс puppet.

leave ★★★★★
()

Техникал дебт

направленным на устранение technical debt

направленным на устранение технического долга

Camel ★★★★★
()

Ну наконец-то. У меня в плейбуках где-то три костыля, решения для которых обещали в 2.0. Пришло время всё переписывать.

Spectator
()

очень годная штука.

amix ★★★
()
Ответ на: комментарий от aidaho

вы свои веб-проекты выкатываете каким-нибудь сторонним инструментом деплоймента

restore.php

prizident ★★★★★
()
Ответ на: Техникал дебт от Camel

Техникал дебт

направленным на устранение technical debt

направленным на устранение технического долга

Поддерживаю.

normann ★★★
()

Ура. Освоил недавно, зело нравится - новый хост настроить с нуля по образу и подобию можно на раз-два. Не нравится только наличие файла hosts который дублирует playbook и неудобство работы с разнородными хостами. Вот скажем, есть у меня три хоста, на каждом свой набор сервисов, наборы пересекаются, между ними есть зависимости, и это всё один проект:

  • hosta: s1 s2 s3
  • hostb: s2 s3 s4
  • hostc: s1 s4 s5

Как мне лучше составить playbook?

Если по отдельному play для s1, s2, s3, s4, s5, то зависимости между сервисами не работают (т.е. если s1 зависит от s2, s2 притащится два раза - в play для s2 и в play для s1 как его зависимость), и параллельности тоже не будет (т.е. каждому хосту коннектимся 3 раза в данном случае).

Можно сделать один play и разруливать наличие сервисов переменными, но это попахивает костылями, будет много мусора в логах (skipped) и какие-то ещё проблемы, не помню.

А хочется, задать, грубо говоря, матрицу хост-сервисы, и чтобы она выполнилась максимально параллельно, с подключением к каждому хосту только один раз. И чтобы она была задана в одном месте, а не размазана по hosts и playbook.

И сразу, стоит ли вообще после ansible смотреть chef/puppet/cfengine/salt/что там ещё? Мне то что требует наличия агентов как-то даже трогать не хочется.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

И сразу, стоит ли вообще после ansible смотреть chef/puppet/cfengine/salt/что там ещё?

им[х]o — нет. разве что chef ввиду большего комьюнити, и то это уже мало актуально сейчас.

val-amart ★★★★★
() автор топика
Ответ на: комментарий от slovazap

http://docs.ansible.com/ansible/playbooks_best_practices.html

Каждый сервис - отдельная роль, желательно с параметрами для гибкости. Для каждой группы хостов набор сервисов определяется подключенными ролями в плейбуке для этой группы хостов. Все плейбуки сводятся в одну в общей site.yml.

Для ролей можно определять зависимости: http://docs.ansible.com/ansible/playbooks_roles.html#role-dependencies Но проще задавать для каждой группы хостов нужный набор сервисов.

selivan ★★★
()
Ответ на: комментарий от slovazap

Если пока ещё не завязан плотно на ansible - есть смысл посмотреть на salt. Я знаю ребят, которые, попробовав то и другое, выбрали именно salt. Вроде как там нормальный открытый аналог ansible-tower имеется.

selivan ★★★
()
Последнее исправление: selivan (всего исправлений: 1)
Ответ на: комментарий от selivan

для ansible тоже есть бесплатный semaphore, да и я подозреваю что tower откроют. его ведь не оракл купил все таки

dyasny ★★★★★
()
Ответ на: комментарий от Spectator

не все, только костыли - там обратная совместимость. Вангую что костыли в shell,command написаны

anonymous
()
Ответ на: комментарий от val-amart

Хочу в тебя динамически инклудироваться, шалунишка.

anonymous
()
Ответ на: комментарий от anonymous

В 1.9 с чем-то virtualenv не мог указывать версию питона, переписал через shell. Второй костыль архитектурный, что-то с передачей аргументов в таски, сейчас уже не вспомню. Остальные тоже надо искать.

Spectator
()
Ответ на: комментарий от surefire

так один раз в пару лет, я как нибудь руками все разверну.

В том и дело, что ansible дал вменяемые способ описать что надо сделать (и тупо не вспоминать, что ты делал два года спустя), да ещё и конфиги хранить централизованно в VCS.

AlexVR ★★★★★
()
Ответ на: комментарий от aidaho

Jenkins + самописные shell-скрипты. Собственно, эти же скрипты пошли в прод для поднятия нового инстанса приложения. Самописные скрипты для обновления тоже есть, они на тесте/проде вручную запускаются. До тестирования обновления Jenkins'ом руки пока не дошли, но тоже в планах допилить и включить в репу.

winlook38 ★★
()
Ответ на: комментарий от dyasny

да и я подозреваю что tower откроют. его ведь не оракл купил все таки

Мечты-мечты. Скорее Шапке понравится пилить проприетарный софт и обмазываться патентами.

anonymous
()

Смотрел когда он был RC, каких-то сверхнужных фич, которые бы сподвигли к обновлению, не увидел.

Обещают обратную совместимость на уровне плейбуков

Не стал бы на это надеяться, нужно тестить - они даже в минорных релизах теряли коммиты и патчи, а тут все-таки есть «инфраструктурные» изменения, скорее всего какой-нибудь сложной для дебага и не заметной на первый взгляд ерунды будет много.

И, да, вместо вот этого маркетингового описания можно было и ченджлог показать

alozovskoy ★★★★★
()
Ответ на: комментарий от slovazap

Я для этого делал плейбук ансибли, который ходил на хосты и запускал там команду puppet agent -t

AnDoR ★★★★★
()

Ну кто так новость пишет? что это?

таск блоки плейбуки инклуды

sehellion ★★★★★
()
Ответ на: комментарий от selivan

Я, наоборот, перешел с Salt на Ansible для своих проектов. Потому как Ansible прост как автомат Калашникова, а для Salt-а надо отдельного человека нанимать, чтобы мейнтейнить все это .sls-jinja2-овно.

anonymous
()

Чем оно лучше saltstack?

Слышал, что благодаря playbooks вхождение фактически моментальное.

anonymous
()
Ответ на: комментарий от anonymous

Ну, например, не всем хочется гонять отдельного демона на сервере только для развертывания целевого ПО.

anonymous
()
Ответ на: комментарий от surefire

А так один раз в пару лет, я как нибудь руками все разверну.

Особенно, если забыл какие-нибудь ньюансы. А с написанным плейбуком всегда можно хотя бы глазами пробежаться.

autonomous ★★★★★
()
Ответ на: комментарий от Yustas

Есть где-то доки по новому API, окоромя ОДНОГО примера на оффсайте?

Можно вообще расширить вопрос. Есть ли нормальная документация в принципе, поскольку это всегда была беда проекта: «А я вот читал docs.ansible.com... Да это фигня, никто так уже не делает!»

zloelamo ★★★★
()
Ответ на: комментарий от selivan

Так проблема в том, что я то не знаю как должно быть. Когда я последний раз там был не было информации как правильно организовывать структуру плейбуков - тупо куда что положить, чтоб было правильно и кошерно. Тут и всплыл вопрос, что я все через попу делаю, а как правильно: ну погугли вот тут, вот там.

zloelamo ★★★★
()
Ответ на: комментарий от zloelamo

Есть ли нормальная документация в принципе

Опенсорс же, у тебя есть исходники, что еще нужно?!

Когда я последний раз там был не было информации как правильно организовывать структуру плейбуков - тупо куда что положить, чтоб было правильно и кошерно.

Тут и всплыл вопрос, что я все через попу делаю

Делай так, как удобно. Вот те же роли, что они постоянно советуют использовать, имхо удобны только в случае постоянного развертывания типовых хостов с нуля, в реальной жизни я так и не придумал, какой профит от них должен быть.

alozovskoy ★★★★★
()
Ответ на: комментарий от selivan

Каждый сервис - отдельная роль, желательно с параметрами для гибкости. Для каждой группы хостов набор сервисов определяется подключенными ролями в плейбуке для этой группы хостов. Все плейбуки сводятся в одну в общей site.yml.

Да, так и сделано, я просто немного подзабыл уже терминологию. Проблема в том, что каждый хост при такой схеме определяется своим плейбуком, потому что групп у меня нет - все хосты разные, но набор сервисов пересекается. Т.е. сейчас так:

- hosts: hosta
  roles
    - s1
    - s2
    - s3

- hosts: hostb
  roles
    - s2
    - s3
    - s4

- hosts: hostc
  roles
    - s1
    - s4
    - s5

Не устраивает то что это не наглядно и исполняется последовательно (сначала hosta, потом hostb, потом hostc), а хотелось бы параллельно и так чтобы результаты по s1 для hosta и hostc показались рядом.

Можно сделать так:

- hosts: hosta hostc # или сделать группу типа servers-that-run-s1
  roles:
    - s1

- hosts: hosta hostb
  roles:
    - s2

- hosts: hosta hostb
  roles:
    - s3

- hosts: hostb hostc
  roles:
    - s4

- hosts: hostc
  roles:
    - s5

Это нагляднее и исполняется примерно как я хочу, но в такой ситуации неудобно работать с зависимостями (если s1 зависит от s2, то s2 будет применено два раза - в первой playbook как зависимость s1 и во второй самостоятельно), а также для каждой playbook соединение и опрос всех хостов выполняется заново, это медленно.

А можно сделать так (синтаксис наизусть не помню, пишу примерно):

- hosts: hosta hostb hostc
  roles:
    - s1 { when $hostname in $servers-that-run-s1 }
    - s2 { when $hostname in $servers-that-run-s2 }
    - s3 { when $hostname in $servers-that-run-s3 }
    - s4 { when $hostname in $servers-that-run-s4 }
    - s5 { when $hostname in $servers-that-run-s5 }

Но это костыльно, куча skipped в выхлопе и кажется были ещё какие-то проблемы, возможно также с зависимостями.

В общем у каждого способа свои минусы, а хочется не иметь их вообще.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.