New Reply
Name
×
Email
Subject
Message
Files Max 5 files10MB total
Tegaki
Password
[New Reply]


ansible — система управления конфигурациями, написанная на языке программирования Python, с использованием декларативного языка разметки для описания конфигураций.

документация:
* https://docs.ansible.com/ansible/latest/index.html
* https://redhat-cop.github.io/automation-good-practices
* https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html

полезное:
* https://github.com/sandervanvugt/rhce8-book
* https://github.com/geerlingguy/ansible-for-devops

курсы/видосы:
* Ansible: From Basics to Guru by Sander van Vugt
* Red Hat RHCE 8 (EX294)

книги:
* Sander van Vugt - Red Hat RHCE 8 (EX294)
* https://www.jeffgeerling.com/ansible-2022
Есть такая контора southbridge. И они недавно запустили бесплатные курсы по ansible. Пошел смотреть и сначала было интересно, потом смешно, а потом уже не смешно.

Например, они говорят:

так делать плохо:
- name: Rpmcheck exclusions file templated
  template:
    src: "{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}.j2"
    dest: "/{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}"
    owner: root
    group: root
    mode: "0644"

так хорошо:
- name: Rpmcheck exclusions file templated
  template:
    src: "srv/southbridge/etc/fix-rpm.local.conf.j2"
    dest: "/srv/southbridge/etc/fix-rpm.local.conf"
    owner: root
    group: root
    mode: "0644"

Оцените масштаб аргументации: **Лишние "усы" ({{ }}) ухудшают читаемость кода и вынуждают в процессе чтения "прыгать" по
разным файлам.**

ссылка на это произведение: https://galaxy.southbridge.io/docs/ansible/guidelines/-/blob/master/no_extra_vars.adoc

То что код нужно сокращать и неповторяться - пофигу. Давайте наговнякаем чтобы более-менее читалось. И пофигу на долгое и сложное внесение изменений в такое.


Еще рассказывали, что не пользуются molecule, так как в подавляющем большинстве случаев она нужна для запуска линтера. А в докер контейнере они используют venv для установки ансибля. Дальше слушать не смог.
Открыл для себя циклические зависимости в ансибле! Можно смело уходить на выходные.

В общем, если сделать так:

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

мы получим: 

Error was a <class 'ansible.errors.AnsibleError'>, original message: recursive loop detected in template string: {{ victoria_single_node.unit.name }}.service. maximum
recursion depth exceeded while calling a Python object

В итоге, пришлось разбивать на два словаря. Не так красиво как изначально, но хотя бы работает.
Вообще все чаще думаю о переходе с ansible на nix/guix. Пора в футуре шагнуть обеими ногами.
как оказалось такой вариант править  непросто

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

похоже реально в ямле  нужно по минимуму использовать переменные
ClipboardImage.png
[Hide] (503.9KB, 563x648)
Здравствуйте, мои дорогие дети. Ваши сердца полны стремления к знаниям, и вы не желаете терять ни минуты своего времени. Однако, в этом стремлении к скорости, вы регулярно допускаете ошибки, которые в итоге лишь увеличивают затрачиваемое время. Сегодня я хочу поделиться с вами тем, как действовать правильно, чтобы избежать мучительных , как зубная боль, моментов в будущем.

Приготовьте чай, нарежьте бутиков и давайте погрузимся в чарующий мир , прости господи, айти.

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

И вот вылупились salt, puppet и ansible. С тех пор жизнь системных администраторов кардинально изменилась и уже никогда не вернется к прежнему.

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


Отсутствие тестирования.

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

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

Один из простых и рутинных способов тестирования - тестирование на чистой виртуалке. Пишем роль и запускаем её отлавливая ошибки, неточности и упущения.

И тут мы сталкиваемся с той самой рутиной. Запустить один раз простую роль не составляет проблем. Хотя многие отваливаются, как осенний лист, уже на этом этапе. Запускать же исправленную роль с несколькими вариантами конфигурации есть пусть для сильных духом. И нужно глазами смотреть на результат. Плюс надо постоянно чистить виртуалку от результатов запуска роли. Есть так же вариант с пересозданием виртуалки. Тут по хорошему нужен преднастроенный образ соответствующий базовым настройкам остальных хостов. Если же чистую виртуалку приводить в нужное состояние каждый раз - можно за этим занятием дожить до тепловой смерти вселенной.

Локальное тестирование.

Как вариант тестирования натравливать роль на заранее подготовленный докер образ. В этом варианте пересоздание тестовой среды проходит крайне быстро. Но не всегда просто и доступно. Например, не все могут подготовить докер имедж для тестирования systemd unit запускающего докер контейнер.

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

Тестирование с помощью молекулы.

Если вы дочитали до этого момента - поздравляю! Здесь начинается самое интересное.

В природе существует такая библиотека - molecule. С помощью неё можно запускать подготовленные докер имеджи, запускать роль в этом докер имедже, и, самый сок - проверять соответствует ли полученное ожидаемому!

Создаем несколько конфигов molecule (create.yml, destroy.yml и т.д). Добавляем в verify.yml проверку на разные необходимые нам вещи. Добавляем линтер и жизнь заиграет совсем другими красками!

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

И получается следующее. В первый раз придется немного поразбираться с написанием тестов на молекуле. Но оно того стоит:

* будем отлавливать ошибки при запуске тестов, а не при установке в рабочий контур

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

* при встреченной ошибке в рабочей среде, просто добавляем нужный тест и не лезем в вики за чеклистом проверок

* довольно хорошо встраивается в ci/cd

* доказываем принадлежность к виду человека разумного
Заключение.

Использование тестов , в том числе на молекуле, сделает жизнь в айти менее каторжной.

---

Для утоления жажды знания по тестированию ролей обращайтесь к книге "Ansible Up and Running, 3rd Edition" и официальной документации molecule https://ansible.readthedocs.io/projects/molecule/.
[New Reply]
Connecting...
Show Post Actions

Actions:

Captcha:

- feedback - news - rules - faq -
jschan 1.6.2