rxd_txd
306 subscribers
479 photos
25 videos
22 files
2.71K links
[
{
"channel":"rxd_txd",
"info":"my bookmarks",
"feedback":"@flsixtyfour",
"topics":[
"devops",
"linux",
"sci",
"music",
"go",
"/dev/null"
]
}
]
Download Telegram
📚 Тут Jeff Geerling выложил свои книги по Ansible в свободный доступ, в связи с самизнаетекакими событиями в мире. Забрать можно по ссылкам:

Ansible for kubernetes
Ansible for devops

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

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

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

#linux #hardening #security #ansible
Forwarded from Админим с Буквой (bykva)
о структуре 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
Forwarded from Админим с Буквой (bykva)
о структуре 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
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