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

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

Что это такое? Для кого софтина и какая область применения?)

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

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

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

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

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

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

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

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

Jenkins

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

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

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

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

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

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

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

restore.php

Jenkins

женкинс сам деплоить что-то может нынче?

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

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

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

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

Ура. Освоил недавно, зело нравится - новый хост настроить с нуля по образу и подобию можно на раз-два. Не нравится только наличие файла 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/что там ещё? Мне то что требует наличия агентов как-то даже трогать не хочется.

джаву вполне адекватно деплоит.

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

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

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

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

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

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

«nj yt jxtym gj[j;t yf heccre. byajhvfwb. j, JC Kbyerc/

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

кулстори, бро

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

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

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

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

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

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

jenkins

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

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

configuration management

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

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

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

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

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

Ansible. Проект на LEMP/LAMP стеке + Asterisk.

Это... прекрасно!

Про semaphore не знал, спасибо. Стоит посмотреть

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

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

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

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

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

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

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

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

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

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

Доки у ансибла вполне пристойные. Если что - форкай https://github.com/ansible/ansible-modules-core, в начале нужного модуля правь DOCUMENTATION и EXAMPLES, и присылай pull request. Они их достаточно оперативно принимают.

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

Ты там явно давно был, сейчас всё есть: http://docs.ansible.com/ansible/playbooks_best_practices.html

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

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

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

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

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

Каждый сервис - отдельная роль, желательно с параметрами для гибкости. Для каждой группы хостов набор сервисов определяется подключенными ролями в плейбуке для этой группы хостов. Все плейбуки сводятся в одну в общей 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 в выхлопе и кажется были ещё какие-то проблемы, возможно также с зависимостями.

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