не надо ))

не надо ))

Почему?

а зачем? )))

Кругозор

ну попробуй )

вдруг понравится

они по идеологии похожи

Тут просто кто-то хвалил его

он меньше всего умеет

но зато умеет быстро

А кто как реюзает роли на своих проектах? Я щас через ansible-galaxy делаю, но неудобно что на каждую роль надо создавать отдельный репозиторий. Может есть какой-то более прямой путь?

А еще есть фабрик. Он прикольный

есть в папка defaults/main.yml, где я могу писать переменные или даже массив с key->value есть папка vars, где я могу пистаь тоже самое, в чем смысл и разница? между папками defaults, vars.

defaults можно использовать для описания всех переменных роли и значений по умолчанию и кладется в гит. Когда тестируете новые значения или применяете на серверах, где нужно указать другие конкретные значения, то переопределяете их в vars и не портите историю в гит.

defaults можно использовать для описания всех переменных роли и значений по умолчанию и кладется в гит. Когда тестируете новые значения или применяете на серверах, где нужно указать другие конкретные значения, то переопределяете их в vars и не портите историю в гит.

Т. О.. Vars удобно использовать для определения частного случая применения роли или отладки.

defaults можно использовать для описания всех переменных роли и значений по умолчанию и кладется в гит. Когда тестируете новые значения или применяете на серверах, где нужно указать другие конкретные значения, то переопределяете их в vars и не портите историю в гит.

Идеологически, это надо пихать в конфиг других хостов и тоже класть в гит

Если требуется повторяемость конфигурации на одних и тех же хостах и именно возможность повторения, то да, согласен.

у меня есть shoutcast, ансиблем не менеджу, пофиг.

Там поддержка 3 питона не появилась,

?

в 2.2 начальная появилась: ansible localhost -m ping -e 'ansible_python_interpreter=/usr/local/bin/python3' localhost | SUCCESS => { "changed": false, "ping": "pong" }

То есть мне нужно обновиться с 2.0 до 2.2 и мне не придется устанавливать питон 2 в 16.04?

- hosts: all gather_facts: False tasks: - name: Ставим ебучий второй питон! raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)

То есть мне нужно обновиться с 2.0 до 2.2 и мне не придется устанавливать питон 2 в 16.04?

Сначала нужно проверить работают-ли нужные модули под python3

Сначала нужно проверить работают-ли нужные модули под python3

Ага, спасибо. Как раз полез доку читать

Там поддержка 3 питона не появилась,

Говорят в 2.2 экспериментально

Они этим два модуля сломали, пока пилили

Медленно они как-то

- hosts: all gather_facts: False tasks: - name: Ставим ебучий второй питон! raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)

чото как-то ниочинь. лучше бы в pre_tasks и не забыть - setup: а потом tasks: начинать

чото как-то ниочинь. лучше бы в pre_tasks и не забыть - setup: а потом tasks: начинать

Ток тогда в плейбуке не будут работать всякие переменные хоста

Так шо лучше отдельный плейбук сделать на hosts:all с установкой пейтона

Про defaults, vars, все остальные места, где можно задать variables и линтер. Нет разницы, какие конкретно места вы используете для задавания переменных. Есть разница, если все пользователи НЕ используют одни и те же места. В некотором идеале есть defaults у роли - и ещё только одно место, где вы переменные переопределяете. Если этих мест больше - вы сами себе злобный буратино

Про defaults, vars, все остальные места, где можно задать variables и линтер. Нет разницы, какие конкретно места вы используете для задавания переменных. Есть разница, если все пользователи НЕ используют одни и те же места. В некотором идеале есть defaults у роли - и ещё только одно место, где вы переменные переопределяете. Если этих мест больше - вы сами себе злобный буратино

Или у вас проект 40к строк yml...

Использование... многоточий... делает любую хуйню... глубокомысленной...

И загадочной... непременно загадочной...

Никакой загадки. Просто много кода - следствие большого количества бизнес требований, площадок, хостов и легаси, накопившегося за время написания. А также необходимости иметь некоторую изоляцию. Поэтому, в реальной жизни используется всё: и варс, и дефолты, и переменные групп, и хостов

Просто всему своё место

А вот переменные и правда не стоит путать, а задавать каждую в каком-то одном месте. Как-то так.

This is still the best way to organize hosts and groups in Ansible for me https://speakerdeck.com/lig/efficient-ansible-host-groups-organization

> Поэтому, в реальной жизни используется всё: и варс, и дефолты, и переменные групп, и хостов я вот этого наелся в своё время - поэтому сейчас использую только defaults и group_vars

и хост варс

иногда надо)

вот из-за таких послаблений потом можно огрести

есть defaults - есть group_vars

ну а что делать если мне надо только на 2 хоста из 10 разлить 2ух юзеров?

например

отдельная группа заводится, например :)

чет не думал об этом

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

А чтобы ip хоста прописать тоже группа?

ip хоста и ansible - это о разном

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

ip хоста и ansible - это о разном

А? Реальная жизнь... Напоминаю

Я тоже в реальной жизни живу, напоминаю

В любом коде можно наплодить говна, оправдывая это реальной жизнью

Это может быть хостнейм, который резолвится только после прохода через ssh bastion, например

Id уникального хоста в aws

по-прежнему не понимаю, как тут может помешать разумное ограничение в хранении переменных в одном определенном месте

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

по-прежнему не понимаю, как тут может помешать разумное ограничение в хранении переменных в одном определенном месте

Я про то, что одно место оно для каждой переменной разное

Г - логика

Просто каждая переменная определяется один раз

я её не вижу всё еще

Я вопрос задал. Куда пихать hostname конкретного хоста

Группа с одним хостом?

Тогда это будет усложнять только и делать неочевидным наличие этой группы

ERROR: S client not available

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

А как у вас это решено?

У нас есть группы с одним хостом. Мастера в разных кафках и зк, например.

Как я пишу. У переменных есть смысл. Каждая задается или вычисляется в своем месте. Естественно, для каждой переменной оно своё

Что мешает вычислять что-то в одном месте?

Ну и смотри слайды выше

в тех же груп_варс _или_ в хост_варс?

Что мешает вычислять что-то в одном месте?

Потому что нет такого места.

в тех же груп_варс _или_ в хост_варс?

В групп варс я ещё не знаю что в зависимостях ролей и как это изменит контекст

Ох

Ещё и зависимости ролей

Обязательно

Я всё понял.

Вот что бывает, когда программист берётся делать работу админа

Или мне копипастить установку nginx для каждого типа хоста?

Вот что бывает, когда программист берётся делать работу админа

Да, потому что DRY

котаны, а это я что-то не так делаю, или действительно в подавляющем большинстве случаев нет никакого смысла выдрачивать плейбуки под переносимость между дистрибутивами, делать их максимально "общими" и всё такое?

у меня вот есть две инфры, одна на центоси, вторая на убунте

Да, потому что DRY

но не KISS в вашем случае, к сожалению

Сложность 100 хостов и 20 окружений ведь.

когда мне надо что-то раскатать на убунту из того, что я уже раскатывал на центось мне НАМНОГО проще написать новый плейбук

котаны, а это я что-то не так делаю, или действительно в подавляющем большинстве случаев нет никакого смысла выдрачивать плейбуки под переносимость между дистрибутивами, делать их максимально "общими" и всё такое?

Если ты не хочешь их на гитхабе пошарить. Я не вижу смысла. У нас вот одна ось везде. Я могу внутри проекта на это рассчитывать.

когда мне надо что-то раскатать на убунту из того, что я уже раскатывал на центось мне НАМНОГО проще написать новый плейбук

А вот тут не уверен

Сложность 100 хостов и 20 окружений ведь.

Не понял мысль

если я мысль понял, то не надо усложнять

чем проще, тем лучше

пусть не драй, зато просто

Сложность 5 окружений примерно и около 15 групп. Хостов больше, но там группами в основном, да

котаны, а это я что-то не так делаю, или действительно в подавляющем большинстве случаев нет никакого смысла выдрачивать плейбуки под переносимость между дистрибутивами, делать их максимально "общими" и всё такое?

плейбуки сами по себе должны делать то, что от них требуется - и не больше :) если требуется уметь работать с двумя дистрами - ду ит, чо уж. Хотя у нас вся логика в ролях обычно, плейбуки только включают роли и пре\пост таски

Не понял мысль

Прости, это был переход на личности

плейбуки сами по себе должны делать то, что от них требуется - и не больше :) если требуется уметь работать с двумя дистрами - ду ит, чо уж. Хотя у нас вся логика в ролях обычно, плейбуки только включают роли и пре\пост таски

А вот пре пост таски мне интересно зачем нужны:)

Вот что бывает, когда программист берётся делать работу админа

Потому что админов нельзя пускать в DevOps - Ansible получается тогда