📚 Тут Jeff Geerling выложил свои книги по Ansible в свободный доступ, в связи с самизнаетекакими событиями в мире. Забрать можно по ссылкам:

• Ansible for kubernetes
• Ansible for devops

Просто поставьте цену в 0.00 и перейдите к "оплате" товаров. Подробно от самого Джеффа тут.

#фидбечат #книга #ansible

Ops by Pull Request: An Ansible GitOps Story
https://www.ansible.com/blog/ops-by-pull-request-an-ansible-gitops-story
#ansible #gitops

How to evaluate community Ansible roles for your playbooks | Jeff Geerling
https://www.jeffgeerling.com/blog/2019/how-evaluate-community-ansible-roles-your-playbooks
#ansible #galaxy #dependencies

https://habr.com/ru/post/509938 #ansible

https://servicesblog.redhat.com/2020/06/23/container-native-applications-with-ansible-operator/
#k8s #kubernetes #operator #ansible

Developing and Testing Ansible Roles with Molecule and Podman:
- Part 1
- Part 2
#ansible #podman #molecule

https://www.thetopsites.net/article/51723456.shtml
#ansible #portknocking

Testing Ansible Role with Molecule, Docker, Testinfra & Goss
#ansible #testing #testinfra #goss #molecule

- part1
- part2

Вооооот. А еще я наклепал лабу по linux hardening... По большей части это компиляция из известных ресурсов, моего там практически нет. В целом это выглядит как чистый хахреднинг, но на самом деле он лежит в разделе про ansible, потому что тут довольно неплохие задачи которые позволят прокачать свои умения в этом продукте. Так шо объединяем приятное с полезным - инфраструктура как код и сесурити, шобы злобный хацкер не майнил бетховенов на вашем железе!

https://github.com/bykvaadm/OS/tree/master/devops/ansible/lab4

#linux #hardening #security #ansible

Kubernetes Operators with Ansible Deep Dive
- Part 1
- Part 2
- Src
#kubernetes #k8s #operator #ansible

https://habr.com/ru/post/526526/
#ansible #loops

https://habr.com/ru/post/527454/
#ansible #molecule #test

о структуре ansible репозитория (часть 1)

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

В чем же проблема №1? а в том, что когда у вас несколько инвентарей, и вы пишете плейбуки которые по смыслу делают одно и то же но в разных инвентарях, вам их надо либо делать строго одинаковыми и в конечном итоге получать один файл (с возможными доработками в виде условий, которые в обычной жизни нахрен не нужны), либо делать несколько файлов для каждого инвентаря. Оба варианта очевидно в конечном итоге приводят к не очень хорошим результатам. В первом случае - это какая-то не нужная логика, которая усложняет поддержку и использование плейбука, а во втором случае у нас просто множится количество файлов. В моем опыте оказалась ситуация когда у коллег удавалось писать "абсолютный" плейбук для своих задач, но это им просто повезло - если ты пишешь плейбук для тестовой и для продовой инфры, сервера по сути одни и те же и способы ввыкладки сервиса тоже. а значит это по сути один и тот же инвентарь, который разделен логически на тест и прод. А вот мне повезло не так сильно и нужно было писать плейбуки под создание сервиса как на своих железках (которые мы можем приготовить как угодно) так и в облаке, а также на "территории" легасёвой инфраструктуры клиента. В таком случае сами понимате сделать 1 плейбук на всё невозможно. Стали рождаться плейбуки вида rolename_inventory_azaza, rolename_inventory_ololo, rolename_inventory_pururum итп. Ситуацию осложняло то, что не все придерживались практики (я никого не виню - не было никакой договорённости) указывать имя инвентаря в имени плейбука.
В конечном итоге ситуация пришла к тому, что в корневом каталоге у нас оказались порядка 50 плейбуков, вперемешку со служебными файлами - gitlab-ci, Dockerfile, ansible.cfg, ansible-lint итп итп. Лично мне стало уже просто неудобно этим оперировать репозиторием. Не критично, не тяжело или как-то сложно, а именно неудобно. плейбуки перестали помещаться в один столбец в pycharm, а понять из названия сразу к какому инвентарю относится плейбук стало тоже непонятно - нужно было заходить внутрь, смотреть группу по которой катался плейбук, грепать ее по инвентарям... короче гемор! При этом в текущем состоянии репозиторий не то чтобы был плох, нет, им вполне можно было пользоваться, но я понимал, что команда у нас растет, а репозиторию меньше года и что дальше будет только хуже. В итоге назрел план небольшой революции и перекроя репозитория. конечный результат - после истории №2.
#ansible

о структуре ansible репозитория (часть 2)

Проблема №2: кросс инвентарные переменные. А вот это нужно для того чтобы можно было из любого инвентаря воспользоваться нужной общей переменной. Например вы создаете виртуалку и хотите чтобы после ее разворота можно было сразу обратиться по доменному имени. Вы добавляете роль управления днс именами в плейбук... а как авторизоваться? как хороший пацан вы написали универсальную роль и не захардкодили в ней параметр с токеном. Или другой пример - база данных пользователей, если вы катаете их ансиблом (хейтеры, отстаньте), то чтобы катать их на разные инвентари и не дублировать, нужно либо иметь один плейбук который будет только что и делать что настраивать пользователей и вы будете запускать его с лимитами по нужным хостам..... ну, да, звучит ужасно. Либо - хранить где-то снаружи ямл с ключами и хешами юзеров. Общие ссл сертификаты. адрес консула. Ну и итд итп, это много где используется. С самого начала такой файл был организован как group_vars/all.yml в корне ансибла. По сути этой бы проблемы не было, если бы не способ решения первого пункта. Для справки как это вообще работало: запускаемый плейбук читает свою директорию. и у него нет никаких проблем залезть в соседнюю с ним папку group_vars и забрать all.yaml а потом сходить в inventory/i_name/ и там прочитать group_vars, host_vars... и так мы получали все нужные переменные при запуске....

А теперь к решению. Для того чтобы сделать красиво я рассмотрел вариант убрать все плейбуки по инвентарям в папку playbooks/i_name. Сказано - сделано. и в этот момент мгновенно перестали работать роли и кросс-инвентарные переменные. Решение вопроса было осуществлено с помощью симлинка. т.е. мы взяли и слинковали в каждом инвентаре кросс-инвентарный файл с переменными. а в ansible.cfg нужно добавить вот эти строки:

[defaults]
roles_path = roles:~/.ansible/roles:/etc/ansible/roles

добавление ~/.ansible/roles нужно для того чтобы подцеплялись galaxy роли.
А конечная структура вышла вот такой:

.
├── inventories
│   ├── global.yml
│   ├── inventory1
│   │   ├── group_vars
│   │   │   ├── all
│   │   │   │   ├── global.yml -> ../../../global.yml
│   │   │   │   └── local.yml
│   │   │   ├── group1.yml
│   │   │   ├── ...
│   │   │   └── groupN.yml
│   │   ├── host_vars
│   │   │   ├── host1.yml
│   │   │   ├── ...
│   │   │   └── hostN.yml
│   │   └── hosts
│   └── inventory2
│       ├── group_vars
│       │   ├── all
│       │   │   ├── global.yml -> ../../../global.yml
│       │   │   └── local.yml
│       │   ├── group1.yml
│       │   ├── ...
│       │   └── groupN.yml
│       ├── host_vars
│       │   ├── host1.yml
│       │   ├── ...
│       │   └── hostN.yml
│       └── hosts
├── playbooks
│   ├── inventory1
│   │   ├── play1.yml
│   │   ├── ...
│   │   └── playN.yml
│   └── inventory2
│       ├── play1.yml
│       ├── ...
│       └── playN.yml
├── roles
│   ├── role1
│   ├── ...
│   └── roleN
├── ansible.cfg
├── tabpy.yml
├── test.yaml
├── wireguard.yml
└── zookeeper.yml

Запуск плейбука осуществляется из директории с ансиблом такой командой:

ansible-playbook -i inventories/inventory1/hosts playbooks/inventory1/play1.yml -bD [--tags, ...]

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

Остается до сих пор проблема того, что в нашем кросс-инвентарном файле может быть довольно много переменных. На текущий момент в качестве решения я думаю о том чтобы сделать symlink кросс-платформенных переменных не на файл global.yml, а на директорию, all -> all. в директори можно хранить множество разделенных по смыслу файлов и все они будут подсасываться во время работы. а файл специфичных для инвентаря переменных вынести по классике в group_vars/all.yml. Но это - тема для будущей революции =)

#ansible

https://www.redhat.com/sysadmin/configure-gmail-using-ansible
#ansible #gmail

https://habr.com/ru/post/553908/
#ansible #module

https://itnext.io/a-practical-kubernetes-operator-using-ansible-an-example-d3a9d3674d5b
#ansible #k8s #kubernetes #operator

Mitogen for Ansible is a completely redesigned UNIX connection layer and module runtime for Ansible. Requiring minimal configuration changes, it updates Ansible’s slow and wasteful shell-centric implementation with pure-Python equivalents, invoked via highly efficient remote procedure calls to persistent interpreters tunnelled over SSH. No changes are required to target hosts.

The extension is considered stable and real-world use is encouraged.

https://vimeo.com/283272293

https://mitogen.networkgenomics.com/ansible_detailed.html
#ansible #mitogen