Давайте поговорим об Ansible — инструменте, который превращает рутинную работу системного администратора в нечто, похожее на написание увлекательного романа (ну, или хотя бы короткого рассказа на YAML).

За свои 20 лет работы в сфере IT я перепробовал множество инструментов автоматизации — от простых bash-скриптов и Puppet до Chef, но Ansible — это что-то особенное.. Представьте себе швейцарский нож для DevOps-инженера, только вместо открывалки для бутылок там модули для управления серверами, а вместо штопора — автоматизация развертывания приложений (хотя, признаюсь, иногда штопор был бы не лишним после особенно сложных деплоев).

Ansible — это открытое программное решение, которое позволяет автоматизировать практически всё, до чего дотянутся ваши руки через SSH. При этом — и это действительно восхищает — вам не нужно устанавливать никаких агентов на управляемые серверы. Работает как телепатия: главный сервер просто подключается по SSH и выполняет команды. Магия? Нет, просто хорошая архитектура (кажется, я начинаю звучать как фанат Apple).

Ключевая особенность Ansible — идемпотентность. Это умное слово означает, что вы можете запускать один и тот же сценарий хоть тысячу раз, и результат будет одинаковым. Примерно как повторное нажатие кнопки лифта — лифт не начнет двигаться быстрее или медленнее, он просто продолжит делать то, что должен.

А еще Ansible использует YAML для написания конфигураций. Да-да, тот самый YAML, где пробелы имеют значение (программисты Python одобрительно кивают). Это означает, что ваши автоматизационные скрипты будут выглядеть почти как поэзия — с правильными отступами и структурой. Только вместо рифм — команды для развертывания серверов.

Основные компоненты Ansible

Давайте разберем анатомию Ansible, или, как я люблю говорить своим студентам, «внутренности швейцарского ножа для DevOps».

Если представить Ansible как оркестр (да, я фанат музыкальных метафор), то у нас есть дирижер (управляющий узел), музыканты (управляемые узлы) и партитура (инвентарь). И поверьте, этот оркестр способен исполнить даже самую сложную симфонию развертывания микросервисов.

Плейбуки — наши «партитуры»

Помните те времена, когда мы писали bash-скрипты длиной в километр? Так вот, плейбуки — это те же скрипты, только в элегантной YAML-обертке (примерно как конфета в красивой упаковке, только вместо сахара — код). Выглядит это примерно так:

- name: Поднимаем веб-сервер
  hosts: webservers
  become: yes  # Это как sudo, только в смокинге

Модули — кубики LEGO

Модули в Ansible — это как кубики LEGO для взрослых айтишников. Хотите установить nginx? Есть модуль. Нужно управлять Docker? Есть модуль. Хотите отправить себе письмо с мемом после успешного деплоя? И для этого есть модуль! (Хотя последнее я бы не рекомендовал делать в продакшене — можете затопить почтовый ящик мемами после автоматического обновления).

Инвентарь — записная книжка сисадмина

Инвентарь — это список всех ваших серверов, или, как я его называю, «телефонная книга для компьютеров». Только вместо номеров телефонов — IP-адреса и hostname’ы:

[webservers]
web01.company.com
web02.company.com  # Этот особенно капризный

Tasks (задачи) — кирпичики автоматизации

Задачи — это отдельные действия в плейбуке. Каждая задача делает что-то конкретное, например, устанавливает пакет или перезапускает сервис. Это как список покупок, только вместо «купить молоко» там «установить nginx и не сломать продакшен».

Всё это работает вместе как хорошо отлаженный механизм (ну, в большинстве случаев). Управляющий узел читает плейбук, смотрит в инвентарь, подключается к серверам по SSH и выполняет задачи. И да, всё это без установки агентов на целевые машины — просто магия SSH и Python (который, кстати, должен быть установлен на целевых машинах, но кто в наше время живет без Python?).

Идемпотентность — магия повторяемости

Помните фильм «День сурка»? Главный герой проживал один и тот же день снова и снова, и каждое утро всё начиналось заново. В мире Ansible есть нечто похожее, только гораздо более полезное — идемпотентность. И нет, это не заклинание из Гарри Поттера, хотя звучит впечатляюще.

Идемпотентность в Ansible — это как кнопка «Сохранить» в текстовом редакторе. Сколько бы раз вы её ни нажали, результат будет одинаковым. Или, если хотите более житейский пример, это как попытки включить уже включенную лампочку — сколько бы раз вы ни щёлкали выключателем, светить ярче она не станет.

Давайте разберем это на практическом примере:

- name: Установка и настройка nginx
  hosts: webservers
  tasks:
    - name: Установка nginx
      apt:
        name: nginx
        state: present  # Вот она, идемпотентность в действии!
        
    - name: Создание конфигурационного файла
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'  # И здесь тоже!

В чём здесь магия? Запустите этот плейбук хоть сто раз:

• Если nginx не установлен — он установится
• Если уже установлен — ничего не произойдет
• Если конфиг отличается от шаблона — обновится
• Если конфиг идентичен — останется без изменений

Это как заботливая мама, которая проверяет, надел ли ты шапку: если надел — отлично, если нет — наденет. Но две шапки одновременно она на вас не наденет (ну, по крайней мере, в большинстве случаев).

А теперь представьте себе альтернативу — скрипт без идемпотентности:

#!/bin/bash
apt-get install nginx  # Каждый раз пытается установить
cp nginx.conf /etc/nginx/nginx.conf  # Слепо копирует, не проверяя изменения

Запустите такой скрипт несколько раз, и вы никогда не будете уверены в результате. Это как играть в русскую рулетку с вашей инфраструктурой (не рекомендую, если хотите сохранить работу).

В реальной жизни идемпотентность особенно важна, когда:

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

P.S. Знаете, что самое приятное в идемпотентности? Когда в пятницу вечером вы случайно запустите плейбук дважды, можно спокойно идти домой, а не оставаться на работе, пытаясь понять, что же сломалось. Поверьте, я говорю по опыту!

Установка и настройка

Помните, как в детстве мы собирали конструктор, гордо игнорируя инструкцию? С Ansible так не прокатит (поверьте моему печальному опыту). Давайте я расскажу, как поставить этот чудо-инструмент правильно, чтобы потом не пришлось переделывать всё с нуля в 3 часа ночи.

Для счастливых обладателей Linux

На Ubuntu/Debian это просто как приготовить растворимый кофе:

sudo apt update
sudo apt install ansible

(Только, в отличие от растворимого кофе, Ansible действительно работает)

На RedHat/CentOS процесс установки зависит от версии системы:

Для RHEL/CentOS 8 и новее:

sudo dnf install ansible

(Да, в новых версиях всё просто!)

Для RHEL/CentOS 7 и старее придется подключить EPEL репозиторий:

sudo yum install epel-release
sudo yum install ansible

(Старые привычки умирают медленно)

Для пользователей macOS

Используйте Homebrew (потому что это macOS, а значит всё должно быть хипстерски):

brew install ansible

После установки можете гордо сказать, что у вас теперь есть что-то общее с Google и Amazon (они тоже используют Ansible, только в чуть большем масштабе).

Для храбрых душ на Windows

Тут два пути:

1. Использовать WSL (Windows Subsystem for Linux) — и делать вид, что вы всё-таки на Linux
2. Использовать Python pip (и молиться, чтобы всё заработало):

pip install ansible

Проверка установки

После установки проверьте версию:

ansible --version

Если вы видите что-то похожее на номер версии — поздравляю, вы в клубе! Если видите ошибку — добро пожаловать в мир отладки зависимостей (я там провел немало «весёлых» часов).

Базовая конфигурация

Создайте конфигурационный файл (или используйте дефолтный в /etc/ansible/ansible.cfg):

[defaults]
inventory = ./inventory
remote_user = your_ssh_user
private_key_file = ~/.ssh/id_rsa

Это как настройка нового смартфона — вроде и можно использовать по умолчанию, но лучше настроить под себя. И да, обязательно настройте SSH-ключи — потому что вводить пароли вручную это как печатать на печатной машинке в эпоху компьютеров.

P.S. Если что-то пошло не так — не паникуйте. У меня была ситуация, когда я случайно автоматизировал перезагрузку всех серверов в продакшене (спойлер: я больше там не работаю). Просто помните главное правило DevOps: «Сначала тестируем на staging!»

Начало работы с Ansible

Итак, вы установили Ansible и готовы к первым шагам в мире автоматизации. Примерно как ребёнок, который только что научился ходить — вроде и страшно, но очень хочется побежать и что-нибудь сломать (желательно не в продакшене).

Первый плейбук (или «Привет, сервер!»)

Давайте начнем с чего-то простого — например, убедимся, что на всех наших серверах установлен Vim (потому что, ну серьёзно, как можно жить без Vim?):

---  # Эти три дефиса как "Жили-были" в сказке
- name: Мой первый плейбук
  hosts: all
  become: yes  # Потому что sudo - наше всё
 
  tasks:
    - name: Установить Vim
  	apt:
    	name: vim
    	state: present
    	update_cache: yes  # На всякий случай обновим кэш

Сохраните это в файл first_playbook.yml и запустите:

ansible-playbook first_playbook.yml

Если всё прошло хорошо, вы увидите красивый вывод с зелёными галочками (или красными крестиками, если что-то пошло не так — welcome to DevOps!).

Проверка связи с серверами

Прежде чем писать сложные плейбуки, давайте убедимся, что мы вообще можем достучаться до наших серверов:

ansible all -m ping

Это как постучать по микрофону и спросить «Раз-раз, меня слышно?», только в мире серверов. Если получаете «pong» в ответ — отлично! Если нет — проверьте SSH-ключи (и да, я тоже иногда забываю их добавить).

Первые команды

А теперь немного магии — выполним команду на всех серверах одновременно

ansible all -a "uptime"

Поздравляю! Вы только что сделали то, что раньше потребовало бы открытия десятка SSH-сессий и ручного ввода команд (а потом ещё полчаса попыток вспомнить, на каком сервере что было сделано).

Помните: с большой силой приходит большая ответственность. Теперь вы можете одной командой перезагрузить все сервера в компании. Но не нужно. Правда не нужно. (Говорю по опыту…)

Управление конфигурацией и плейбуки

А теперь давайте поговорим о плейбуках — этих восхитительных YAML-файлах, которые превращают часы ручной работы в минуты автоматизированного волшебства (или кошмара, если забыть про отступы — YAML очень чувствителен к пробелам, прямо как поэт-модернист).

Анатомия плейбука

Плейбук в Ansible — это как рецепт в поваренной книге, только вместо «щепотки соли» у нас «пара строк конфигурации nginx». Выглядит это примерно так:

---
- name: Настройка веб-сервера мечты
  hosts: webservers
  become: yes  # Потому что root - это звучит гордо
  vars:
    server_name: example.com
    max_clients: 200  # Оптимистично, да?
 
  tasks:
    - name: Установка nginx
  	apt:
    	name: nginx
    	state: present
    
    - name: Настройка конфига
  	template:
    	src: nginx.conf.j2
    	dest: /etc/nginx/nginx.conf
  	notify: Перезапустить nginx  # Потому что просто так перезапускать - это не по-DevOps'ски
 
  handlers:
    - name: Перезапустить nginx
  	service:
    	name: nginx
    	state: restarted

Роли — для тех, кто любит порядок

Если плейбук — это рецепт, то роль — это целая кулинарная книга. Только вместо разделов «Супы» и «Десерты» у нас «Tasks» и «Templates». Структура роли выглядит примерно так:

roles/
  webserver/
    tasks/
  	main.yml  # Основное блюдо
    handlers/
  	main.yml  # Гарнир
    templates/
  	nginx.conf.j2  # Специи
    vars/
  	main.yml  # Список покупок

Переменные — душа плейбука

Переменные в Ansible — это как специи в кулинарии: используйте их правильно, и ваш код заиграет новыми красками. Используйте неправильно — и придется все переделывать:

vars:
  app_port: 8080
  db_password: "{{ vault_db_password }}"  # Потому что хардкодить пароли - это плохо, очень плохо

Обработчики (handlers) — для особых случаев

Обработчики — это специальные задачи, которые выполняются только при определенных условиях. Как будильник, который звонит только если вы действительно изменили конфигурацию:

handlers:
  - name: Перезапустить приложение
    systemd:
  	name: myapp
  	state: restarted
    listen: "app config changed"  # Как метка "срочно" в почте

И помните: плейбук без комментариев — это как код без документации. Через полгода вы сами не поймете, что хотели этим сказать (говорю по личному опыту, до сих пор пытаюсь разобраться в своем плейбуке годичной давности).

P.S. А знаете, что самое прекрасное в плейбуках? Они идемпотентны — можете запускать их хоть 100 раз, результат будет тот же. Как кнопка перехода на следующий этаж в лифте — сколько ни жми, выше заданного этажа не поедет (если, конечно, лифт не сломан — но это уже совсем другая история).

Примеры плейбуков

Давайте рассмотрим несколько реальных примеров плейбуков, которые я использовал в своей практике (некоторые из них даже работают!). Считайте это сборником рецептов от шеф-повара инфраструктурной кухни.

Установка LAMP-стека (или «Как развернуть веб-сервер и не сойти с ума»)

---
- name: Разворачиваем LAMP - классику веб-разработки
  hosts: webservers
  become: yes
  vars:
    mysql_root_password: "{{ vault_mysql_root_password }}"  # Никаких '12345' в продакшене!
    
  tasks:
    - name: Установка Apache и друзей
  	apt:
    	name:
      	- apache2
      	- mysql-server
      	- php
      	- php-mysql
      	- libapache2-mod-php
    	state: present
    	update_cache: yes  # Потому что apt update - наше всё
    
    - name: Старт и активация сервисов
  	service:
    	name: "{{ item }}"
    	state: started
    	enabled: yes  # Чтобы после ребута всё автоматом поднялось
  	loop:
    	- apache2
    	- mysql

Настройка мониторинга (или «Как спать спокойно по ночам»)

- name: Установка системы мониторинга
  hosts: monitoring
  become: yes
 
  tasks:
    - name: Установка Prometheus
  	docker_container:
    	name: prometheus
    	image: prom/prometheus
    	ports:
      	- "9090:9090"
    	volumes:
      	- /etc/prometheus:/etc/prometheus
    	restart_policy: always  # Потому что "упс" случается со всеми

    - name: Установка Grafana
  	docker_container:
    	name: grafana
    	image: grafana/grafana
    	ports:
      	- "3000:3000"
    	restart_policy: always  # И с Grafana тоже

Бэкап базы данных (или «Как не потерять данные и работу одновременно»)

- name: Бэкап MySQL
  hosts: databases
  become: yes
  vars:
    backup_path: "/backup/mysql"
    timestamp: "{{ ansible_date_time.date }}"
 
  tasks:
    - name: Создание директории для бэкапа
  	file:
    	path: "{{ backup_path }}"
    	state: directory
    	mode: '0755'
    
    - name: Выполнение дампа
  	mysql_db:
    	state: dump
    	name: all
    	target: "{{ backup_path }}/backup-{{ timestamp }}.sql"
  	register: backup_result  # На случай, если что-то пойдёт не так
    
    - name: Удаление старых бэкапов
  	shell: "find {{ backup_path }} -type f -mtime +7 -delete"  # Потому что хранить всё вечно - это утопия

Помните: эти примеры — как конструктор LEGO. Можете брать отдельные части и собирать из них что-то своё. Главное — не забывайте про отступы в YAML (поверьте, я знаю, о чём говорю — однажды потратил два часа на отладку плейбука, а всё дело было в одном лишнем пробеле).

И да, всегда тестируйте свои плейбуки на тестовом окружении. Потому что «работает на моей машине» — это не оправдание, когда вы случайно уроните продакшен (а вы уроните, мы все через это проходили).

Расширенные возможности и интеграция

Теперь, когда мы освоили основы, давайте поговорим о продвинутых фишках Ansible — тех самых, которые превращают простой инструмент автоматизации в настоящий швейцарский нож DevOps-инженера (только не пытайтесь открывать им бутылки, серьезно).

Интеграция с облаками (или «Как потратить годовой бюджет за 5 минут»)

Ansible прекрасно дружит с облачными провайдерами. Вот пример работы с AWS (спойлер: следите за billing alerts):

- name: Разворачиваем инфраструктуру в AWS
  hosts: localhost
  tasks:
    - name: Создание EC2 инстанса
  	amazon.aws.ec2:
    	key_name: my_key
    	instance_type: t2.micro  # Потому что t2.xlarge - это для богатых
    	image: ami-123456
    	region: us-east-1
    	count: 1
    	vpc_subnet_id: subnet-123456
    	wait: yes
  	register: ec2  # Чтобы потом знать, кого винить

Диаграмма отображает процесс развёртывания EC2-инстанса через Ansible

Работа с контейнерами (или "Docker, я твой отец")
Ansible + Docker = любовь с первого плейбука:

- name: Управление контейнерами
  hosts: docker_hosts
  tasks:
    - name: Запуск контейнера
  	docker_container:
    	name: my_app
    	image: my_app:latest
    	ports:
      	- "80:80"
    	env:
      	PRODUCTION: "true"  # Потому что в продакшене всё по-взрослому
    	restart_policy: always  # На случай, если что-то пойдет не так (а оно пойдет)

Vault (или «Где спрятать пароли от продакшена»)

Ansible Vault — это как сейф для ваших секретов, только вместо комбинации цифр используется один мастер-пароль (который, надеюсь, не «password123»):

# Создание зашифрованного файла
ansible-vault create secrets.yml

# Редактирование (для тех случаев, когда вы забыли добавить еще один секрет)
ansible-vault edit secrets.yml

# Использование в плейбуке
- name: Секретная операция
  hosts: all
  vars_files:
    - secrets.yml  # Все секреты в одном месте, как скелеты в шкафу

Динамический инвентарь (или «А где мои сервера?»)

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

#!/usr/bin/env python
# dynamic_inventory.py
import json

def get_inventory():
    return {
    	"webservers": {
        	"hosts": ["web1.example.com", "web2.example.com"],
        	"vars": {
            	"http_port": 80  # Потому что 8080 - это так 2010
        	}
    	}
    }

if __name__ == '__main__':
    print(json.dumps(get_inventory()))

Используйте его так:

ansible-playbook -i dynamic_inventory.py your_playbook.yml

Параллельное выполнение (или «Почему так долго?»)

Потому что иногда нужно всё и сразу:

# ansible.cfg
[defaults]
forks = 30  # Потому что 10 по умолчанию - это слишком медленно

P.S. Помните: с большой мощью приходит большая ответственность. И большие счета за облака, если вы забыли остановить тестовые инстансы (да, я говорю по опыту — однажды развернул тестовую среду и забыл про нее на месяц… финансовый отдел до сих пор косо на меня смотрит).

Автоматизация сетевых устройств

Поговорим о том, как Ansible может помочь в управлении сетевым оборудованием — той самой областью IT, где один неверный конфиг может превратить рабочий день в увлекательный квест «найди, кто отключил полкомпании от интернета» (спойлер: обычно это я).

Cisco и Ansible (или «Как автоматизировать CLI из 90-х»)

---
- name: Настройка Cisco устройств
  hosts: cisco_switches
  gather_facts: no  # Потому что факты из IOS собирать -- это отдельное приключение
 
  tasks:
    - name: Настройка VLAN
  	cisco.ios.ios_vlan:
    	vlan_id: 100
    	name: "Users_VLAN"
    	state: present
  	register: output  # Чтобы потом было что показать в отчете
    
    - name: Сохранение конфига
  	cisco.ios.ios_command:
    	commands:
      	- write memory  # Потому что "copy running-config startup-config" слишком длинно писать

Работа с Juniper (или «Дорого-богато»)

- name: Настройка Juniper
  hosts: juniper_routers
  tasks:
    - name: Настройка интерфейса
  	junipernetworks.junos.junos_interface:
    	name: ge-0/0/0
    	description: "Линк в интернет (наверное)"
    	enabled: yes
  	register: interface_result

Mikrotik (или «Бюджетное решение, которое внезапно работает»)

- name: Настройка Mikrotik
  hosts: mikrotik_routers
  tasks:
    - name: Создание бэкапа
  	community.routeros.command:
    	commands:
      	- /system backup save name=before_ansible  # Потому что "лучше перебдеть"
    
    - name: Настройка файрвола
  	community.routeros.command:
    	commands:
      	- /ip firewall filter add chain=forward action=drop protocol=tcp \
        	dst-port=23 comment="Drop telnet (кто вообще использует telnet в 2024?)"

Мультивендорная конфигурация (или «Когда в сети зоопарк»)

- name: Универсальная настройка NTP
  hosts: all_network
  tasks:
    - name: Cisco NTP
  	cisco.ios.ios_ntp:
    	server: 10.0.0.1
    	source_int: Loopback0
  	when: ansible_network_os == 'ios'
    
    - name: Juniper NTP
  	junipernetworks.junos.junos_ntp:
    	server: 10.0.0.1
  	when: ansible_network_os == 'junos'
 	 
    # И так далее для каждого вендора в вашей сети
    # (молитесь, чтобы их было не слишком много)

Бонус-совет: всегда делайте бэкап конфигурации перед любыми изменениями. Потому что «упс, я случайно…» — это не то объяснение, которое хочет услышать ваш руководитель в 3 часа ночи.

И помните: сетевое оборудование не прощает ошибок. В отличие от серверов, где всегда можно переустановить ОС, неправильная команда на коммутаторе может отправить вас в увлекательное путешествие в серверную (и хорошо, если она находится в том же здании).

P.S. Если вы когда-нибудь будете автоматизировать настройку BGP через Ansible — пожалуйста, протестируйте свой плейбук раз 10 на тестовом оборудовании. Потому что сломать BGP — это как случайно отключить интернет целой компании (да, я знаю, о чём говорю, и нет, я не хочу об этом рассказывать).

Изучение и сообщество Ansible

Давайте поговорим о том, как не утонуть в океане Ansible-знаний и найти свой путь к просветлению (или хотя бы к работающим плейбукам).

Официальная документация (или «Святой Грааль»)

Начнем с того, что официальная документация Ansible — это как инструкция к конструктору LEGO: вроде и скучно читать, но без неё собрать что-то работающее практически невозможно. Найти её можно на docs.ansible.com — закладывайте эту страницу прямо сейчас, она станет вашим лучшим другом (и злейшим врагом в 3 часа ночи, когда вы будете искать, почему не работает какой-нибудь obscure параметр).

Ansible Galaxy (или «App Store для автоматизаторов»)

Ansible Galaxy — это как GitHub для ролей Ansible. Здесь вы найдете готовые решения практически для всего: от установки nginx до развертывания целого Kubernetes-кластера (правда, работать будет только половина, но это уже детали).

Мой совет: не изобретайте велосипед, сначала проверьте Galaxy. Возможно, кто-то уже решил вашу проблему (и набил шишки, которые вам набивать не придется).

Сообщество (или «Группа поддержки»)

Ansible имеет огромное сообщество. Stack Overflow, Reddit (r/ansible), GitHub Issues — везде вы найдете людей, готовых помочь (или хотя бы посмеяться над вашими ошибками). Главное правило — не стесняйтесь задавать вопросы, но сначала попробуйте поискать ответ самостоятельно (серьезно, ваш вопрос про «почему не работает переменная» уже задавали как минимум сто раз).

Практика (или «Набивание шишек»)

Лучший способ изучить Ansible — это создать тестовую среду и начать экспериментировать. Vagrant + VirtualBox — отличное комбо для этого. И помните: сломать тестовую среду — это нормально. Главное — не сломать продакшен (по крайней мере, не в свой первый день).

Хотя самостоятельная практика бесценна, иногда нужен более структурированный подход к обучению. Если вы чувствуете, что заблудились в океане технологий или хотите ускорить свой профессиональный рост, стоит присмотреться к специализированным курсам. На KursHub собрана отличная подборка курсов для системных администраторов, где вы найдете программы разного уровня сложности — от базовых основ до продвинутой автоматизации с Ansible. Это как навигатор в мире IT — поможет выбрать правильное направление и не застрять на обочине технологического прогресса (поверьте, намного приятнее учиться на чужих ошибках, чем набивать собственные шишки в продакшене).

Советы от бывалого

1. Начинайте с малого. Не пытайтесь автоматизировать всё сразу (поверьте, я пробовал — результат был… интересным).
2. Используйте —check и —diff флаги. Они спасли не одну карьеру.
3. Версионируйте свои плейбуки. Git — ваш друг (особенно когда нужно понять, кто и когда добавил тот странный таск).
4. Комментируйте код. Ваше будущее «я» скажет спасибо (или хотя бы не будет так сильно ругаться).

P.S. И помните: даже эксперты иногда гуглят простейшие вещи. Недавно поймал себя на том, что искал синтаксис копирования файла в Ansible — после 5 лет работы с ним. Так что не переживайте, если что-то не получается сразу — это нормально!