Было бы неплохо и CFEngine включить в сравнение.

Хорошее замечание, правда я последний раз его использовал лет 8 назад. Не думал что он ещё кому-то интересен и пользуется хоть какой-то популярностью.
Используйте ‘accelerate’, он в 2-6 раз быстрее SSH разворачивает конфигурации (для el6).

Он deprecated.


Используйте ‘with_items’

Совет в духе «когда на улице зима, одевайтесь тепло».


Ansible — фаворит. SaltStack очень хороший, очень гибкий, но требует знания Python,

Без питона Ansible тоже малопригоден, т.к. любые нестандартные вещи требуют написания своих модулей, фильтров, lookup'ов и т.п.


кто использует Puppet — я не знаю. В принципе, он очень похож на Chef, но со своими нюансами.

Puppet более всего похож на CFEngine.

Он deprecated.

Да, но к сожалению для el6(Centos/RHEL) он всё ещё актуален

Без питона Ansible тоже малопригоден

Очень даже пригоден, ведь уже очень много всего написано готового и шанс найти что-то подходящее достаточно велик. Особенно в сравнении с SaltStack.

Puppet более всего похож на CFEngine.

Они оба(Puppet и Chef) «выросли» из CFEngine и очень на него похожи.
>>Без питона Ansible тоже малопригоден

>Очень даже пригоден, ведь уже очень много всего написано готового и шанс найти что-то подходящее достаточно велик

Пригоден, да. Но при написании достаточно комплексных штух (чтобы не писать кучи повторений) все же необходимо базовое знание Питона, а еще больше Jinji-ы. Как в общем и в Папите Ruby и ERB и т.п.
Модули для ansible можно писать на любом языке в отличии от salt и pappet.
Puppet на самом деле попахивает стариной, но очень широко используется. Особенно в компаниях, которые на рынке давненько (что-то типа enterprise). Как раз в этих компаниях в основном папит-код немного повергает в шок ).

Я бы даже сказал, что по популярности он где-то после Ansible.
Аккуратно используйте ‘local_action’ и ‘delegated’. Первый позволяет получить нечто похожее на SaltStack Runner, второй умеет делегировать задачи конкретным машинам.

— name: create postgresql database
postgresql_db:
name: "{{ database_name }}"
login_host: "{{ database_host }}"
login_user: "{{ database_master_user }}"
login_password: "{{ database_master_password }}"
encoding: «UTF-8»
lc_collate: «en_US.UTF-8»
lc_ctype: «en_US.UTF-8»
template: «template0»
state: present
delegate_to: "{{ groups.pg_servers|random}}"

Это кусок по созданию баз данных. Без последней строчки операция выполнилась бы несколько раз и свалилась на второй попытке создать ту же самую базу данных.

есть же run_once: true
есть же run_once: true

Такой комментарии был и в зале во время доклада, я же хотел показать пример именно с `delegate`
А с Ansible проблема — если нет Tower, — нет возможности запустить конфигурацию в Pull-режиме с наших нод, что необходимо делать в демилитаризованной зоне.
У нас нет товера, но пулл работает с гитом нормально, ЧЯДНТ? Я даже больше скажу, вообще не понимаю нахрена он нужен для ansible-pull, товер же не выступает репозиторием для ансибла никак.

Framework for CLI (на Python). Ansible подобный инструментарий не поддерживает.
Это ansible-console нет или чего? Ансибл это как корутины, которые просто с параметрами правильными вызвать надо. Какой к нему фреймворк лепить то? На крайний случай взгляните на awx для REST API, не фреймворк конечно, но не такая уж и большая сложность.
У нас нет товера, но пулл работает с гитом нормально, ЧЯДНТ? Я даже больше скажу, вообще не понимаю нахрена он нужен для ansible-pull, товер же не выступает репозиторием для ансибла никак.

Если я верно вас понял то вы имеете в виду pull из git с последующим локальным запуском плейбука, в нашей задаче мы не могли использовать этот подход, а сам ansible не имеет возможности стянуть все необходимое как это делают те же Chef-Client или Salt-Minion с соотвественно Chef-Server'a и Salt-Master'a

Какой к нему фреймворк лепить то?

Задача была не к нему фреймворк сделать, а на его основе сделать свой для простого и удобного написания CLI интерфейса который смогут использовать как продуктовые команды(те кто делают непосредственно само ПО которое мы разворачиваем) так и инженеры в поле(те кто этот продукт соотвественно настраивает в датацентре заказчика)
А с Ansible проблема — если нет Tower, — нет возможности запустить конфигурацию в Pull-режиме с наших нод, что необходимо делать в демилитаризованной зоне.

Простите если у меня нубский вопрос — сам я только присматриваюсь к этим систем и думаю какую выбрать для изучения на своём небольшом проекте. Вопрос такой:
А нельзя ли прокинуть Ansible в эту DMZ зону, чтобы DMZ хосты стали доступны для него? Да, это получается такая дырка в DMZ, но Tower — дырка ничуть не меньше.

Это так называемый bastion host. Вот мой например велосипед: https://selivan.github.io/2018/01/29/ansible-ssh-bastion-host.html


Или можно в ansible_ssh_common_args добавлять ProxyCommand

То есть никакой проблемы «пуллить» нету?

ansible-pull достаточно примитивен, по сути это git pull + ansible-playbook. Он запускается на управляемой машине, ему нужен доступ к vcs-репозиторию, откуда он заберёт плейбуки и применит локально.


В нормальном режиме ansible запускается на управляющей машине, идёт по ssh(или по winrm для windows) на управляемую и там работает. И вот если прямого доступа по ssh на управляемую машину нету, то можно использовать соединение через бастион-хост, с которым соединение есть и который может ходить на управляемую.

Мало написать плейбуки\кукбуки и что угодно еще, гораздо сложнее сделать так, чтобы все изменения выполнялись через систему контроля версий и только через SCM. Учитывая самый низкий порог вхождения, Ansible — фаворит, ибо настолько всё прозрачно и просто, что въехать в тему может за пару дней почти любой специалист.

Как видно основная проблема el6 была тут:


to support ControlPersist. (This means basically all operating systems except Enterprise Linux 6 or earlier).

https://docs.ansible.com/ansible/2.4/intro_configuration.html#openssh-specific-settings


Используйте ‘accelerate’, он в 2-6 раз быстрее SSH разворачивает конфигурации (для el6). Для всех остальных есть ‘pipelining’. Для обратной совместимости он выключен, но включить обратно ‘pipelining’ очень легко, рекомендую это делать.

Как давно вы пробовали использовать pipelining в el6?


Прокомментируйте https://access.redhat.com/errata/RHBA-2014:1854 в этом контексте.

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