Скажи, кто твой AI, и я скажу, кто ты.

Всем привет.

Популярная фраза теперь звучит так "Скажи, кто твой AI, и я скажу, кто ты." Ажиотаж вокруг AI еще тот. И он оправдан. Вы можете любить или ненавидеть  AI, но с каждым днем его все больше в вашей жизни.

Сегодня процитирю вам АІ-советы от Александра Фролова, начальника отдела информационных технологий МГУ им. адм. Г.И. Невельского.

Нейросети - это мощный инструмент для системных администраторов, который помогает экономить время и решать сложные задачи. Однако важно использовать их с умом: проверять ответы, задавать четкие вопросы и не полагаться на них полностью в критически важных ситуациях. Для сисадминов особенно полезны ChatGPT, GitHub Copilot и Claude, так как они помогают автоматизировать рутинные задачи и находить решения быстрее. 

Для сисадминов (DevOps) особенно полезны ChatGPT, GitHub Copilot и Claude, так как они помогают автоматизировать рутинные задачи и находить решения быстрее.

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

Наиболее популярные инструменты:

⦁ ChatGPT (OpenAI): для генерации скриптов, анализа ошибок, поиска решений, документации.

⦁ GitHub Copilot: для помощи в написании кода и автоматизации задач.

⦁ Perplexity.ai: для поиска информации и быстрого получения ответов на технические вопросы.

⦁ Bard (Google): для сравнения ответов и поиска альтернативных решений.

⦁ Claude (Anthropic): для работы с длинными текстами, например, анализ логов или документации.

Dynamic Prompts и шаблоны Jinja2.

Всем привет.

Вы заметили что в расширении «Dynamic Prompts» есть интересное подменю «Jinja2 templates»?

Jinja2 - это движок шаблонов, который позволяет использовать синтаксис в стиле Python в шаблонах. Эта возможность особенно полезна для подсказок Stable Diffusion, поскольку она позволяет создавать один запрос, который генерирует несколько запросов, генерировать рандомизированные элементы внутри запросов, итерировать по элементам, использовать подстановочные знаки и многое другое. Jinja2 может эмулировать результаты, для получения которых обычно требуются сложные скрипты Python.

Чтобы включить шаблоны Jinja2:

1. Установите Dynamic Prompts через браузер расширений.

2. Перезапустите Web UI.

3. Прокрутите вниз до скриптов и разверните аккордеон dynamic prompt.

4. Разверните аккордеон Jinja2 и включите его.

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

Операторы Jinja2 начинаются с {% и заканчиваются %} , выражения заключены в {{ }} , а комментарии содержатся в {# #} .

В Stable Diffusion (Automatic1111 или Forge) подсказки определяются с помощью тегов {% prompt %} и {% endprompt %}. Операторы и выражения внутри этих тегов не обязательно должны быть на отдельных строках, но разделены для лучшей читаемости. Эти программные подсказки могут быть длиннее традиционных подсказок, поскольку сгенерированные результаты, как правило, короче.

Тестирование инфраструктуры c pyATS #3.

Всем привет. 

Продолжаю нашу тему фреймворков для тестирования инфраструктры. Сегодня мой пост является беглым отчетом по выполнению работы "7.6.3 Lab - Automated Testing Using pyATS and Genie" из Cisco DevNet.

Знакомтесь - pyATS (https://developer.cisco.com/pyats/). Это экосистема сквозного тестирования, изначально разработанная компанией Cisco и ставшая открытой в конце 2017 года. Ранее библиотека pyATS называлась Genie; эти названия используются в одном и том же контексте. Ввиду своего происхождения этот фреймворк целиком и полностью ориентирован на тестирование сетей.

Фреймворк доступен в PyPI:

(venv) $ pip install pyats[full]

Для начала рассмотрим некоторые демонстрационные сценарии из GitHub-репозитория:

git clone https://github.com/CiscoTestAutomation/examples

Мы сходу можем прогнать тест-пустышку чтобы оценить как все происходит:

pyats run job examples/basic/basic_example_job.py

Следом можно охватить отчетность по всем проведенным PyATS-тестам в формате HTML:

pyats logs view

P.S.: имейте ввиду - порт web-сервера отчетов динамический.

Ок, реальные тесты начинаются с создания файла испытательной модели (testbed) в формате YAML. Создадим простой testbed-файл testbed-pyats.yml для нашего устройства CSR1000v. Он похож на файл реестра hosts, знакомый нам от Ansible:

testbed: 

    name: pyATS

    credentials:

        default:

            username: admin

            password: super

        enable:

            password: super

devices:

    CSR: 

        alias: CSR

        type: iosxe

        connections:

            defaults:

                class: unicon.Unicon  

            vty:

                ip: 192.168.1.19

                protocol: ssh -o KexAlgorithms=diffie-hellman-group14-sha1

Тестирование инфраструктуры с Testinfra #1.

Всем привет.

Создание модульных тестов для тестирования инфраструктуры - замечательная идея. Главное найти подхоящий инструмент с низким порогом вхождения. Я таких знаю два - это Testinfra  (Python) и Pester (Powershell). Разумеется оба бесплатны, но более простым для старта я считаю первый. Так что сегодня будет Testinfra.

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

Пожалуй начнем. Создайте новую виртуальную среду и активируйте ее:

$ python3 -m venv validator

$ source validator/bin/activate

Установите  pytest:

(validator) $ pip3 install pytest

Установите testinfra:

(validator) $ pip3 install pytest-testinfra

Установите paramiko:

(validator) $ pip3 install paramiko

Фикстуры pytest предоставляют всю тестовую функциональность проекта Testinfra.  Чтобы извлечь пользу из этого, вам необходимо правильно указать тип соединения. Поскольку  существуют различные типы соединений прикладных частей, то, если соединение не указано непосредственно, Testinfra использует определенные типы по умолчанию. Лучше указывать тип соединения явным образом в командной строке.

Вот список поддерживаемых Testinfra соединений на сегодня:

-local

$ py.test --sudo test_myinfra.py

-Paramiko (SSH-реализация на Python)

$ py.test --ssh-config=/path/to/ssh_config --hosts=server

-Docker;

$ py.test --hosts='docker://[user@]container_id_or_name'

-SSH;

$ py.test --ssh-config=/path/to/ssh_config --hosts='ssh://server'

-Podman;

$ py.test --hosts='podman://[user@]container_id_or_name'

-Salt;

$ py.test --hosts='salt://*'

-Ansible;

$ py.test --hosts='ansible://all' # tests all inventory hosts

-Kubernetes (через утилиту kubectl);

$ py.test --hosts='kubectl://mypod-a1b2c3'

-OpenShift;

$ py.test --hosts='openshift://mypod-a1b2c3'

-WinRM;

$ py.test --hosts='winrm://vagrant@127.0.0.1:2200?no_ssl=true&no_verify_ssl=true'

-LXC/LXD

$ py.test --hosts='lxc://container_name'

Vagrant с Ansible.

Всем привет. 

Допустим у нас есть десяток машин. Некоторые из них одинаковы - ноды с приложением и машины со средой для разработки. В данном случае имеет смысл использовать подготовку машин. Vagrant для этого позволяет использовать несколько решений:

• Puppet
• Ansible
• Salt
• Shell
• Chef
• Docker

При чём некоторые из них, например, Chef, Puppet, Salt имеют несколько вариантов использования (мастер-агент, без мастера, запуск локально).

Автоматически provision запускается только в двух случаях: vagrant up и vagrant reload. Если вы хотите запустить подготовку машин принудительно, то необхожимо это явно указать. Например:

vagrant resume --provision %machine_name%

vagrant provision %machine_name

Самый простой вариант - shell. Но сегодня мы рассмотрим вариант с Ansible.

Чтобы применить Ansible через vagrant необходимо сделать следующее:

- на хостовой машине должен быть установлен Ansible

- прописать в Vagrantfile примерно следующее:

Vagrant.configure("2") do |config|

  # Run Ansible from the Vagrant Host

  config.vm.provision "ansible" do |ansible|

    ansible.playbook = "playbook.yml"

  end

end

При этом, Playbook.yml должен находиться в одном каталоге с Vagrantfile. После того, как машина будет поднята, vagrant запустит Ansible. Так как сам по себе Ansible не требует никакого агента на целевой машине (ноде), то всё, что нужно сделать - указать верные данные в инвентори-файле. Если используется публичная сеть, то указываем ip ноды, если используется приватная сеть, то необходимо указать ip локалхоста (обычно 127.0.0.1) и порт. Для Ansible имеется достаточно много опций, узнать их можно на странице официальной документации vagrant. Помимо того, что можно запускать Ansible с хоста, его можно также запускать и в самой гостевой мащине. Называется это Ansible local. Преимущество в том, что нет необходимости устанавливать Ansible на хост. Вы можете просто загрузить роль с вашего репозитория или с Ansible galaxy и она выполнится. 

Недостатки - на каждую машину необходимо устанавливать Ansible, отсутствие централизованного управления. То есть, если в дальнейшем будет необходимость управлять машинами посредством Ansible, то этот метод не для вас.

По-умолчанию, vagrant попробует сам установить Ansible на гостевую машину, для этот предусмотрено несколько опций:

install_mode - по факту, это выбор репозитория, откуда будет устанавливаться Ansible. Если оставить значение default, то будет выбран:

1.ppa:ansible/ansible - для гостя Ubuntu + family

2.EPEL - RedHat-family

3.main repo - Debian, OpenSuse, FreeBSD, Arch, etc.

Есть другое значение - pip. Тогда установка будет производиться посредтсвом pip. vagrant сначала установит pip на гостя, а затем установит Ansible. Этот вариант предпочтительней, так как это гарантирует, что версия будет свежая и одинаковая для всех нод. Часть Vagrantfile, которая отвечает за Ansible local практически ничем не отличается от обычного Ansible:

Vagrant.configure("2") do |config|

  config.vm.provision "ansible_local" do |ansible|

    ansible.playbook = "playbook.yml"

  end

end

Автоматизация сетевых задач - Paramiko.

Всем привет.

Сегодня транслирую вам материал Никиты Туркова про автоматизацию работы сетевого администратора  с использованием пакетов Paramiko и Netmiko.

Автоматизация процесса обслуживания сетевых устройств невозможна без использования хтоя бы одного из языков программирования. Для 2021 года базовое знание Python это уже не преимущество кандидата (системного администратора, или сетевого инженера) , а одно из требований при трудоустройстве на работу.  Одно из весомых преимуществ языка Python - большое количество сторонних библиотек для решения задач из различных областей. Естественно, энтузиасты и разработчики в рамках работы с сетью и сетевым оборудованием написали достаточное количество модулей. Перечислим те из них, которые поддерживают режим взаимодействия CLI:

• telnetlib - встроенная библиотека, она используется для обеспечения доступа к сетевому устройству и отправке команд по Telnet протоколу (не является безопасным).

• pexpect - внешняя библиотека работает для передачи данных по протоколам: ssh, telnet, sftp и др. Считается универсальным инструментом для передачи команд как в ОС, так и на сетевое оборудование. Логика работы основана на ожидании получения соответствующей строки от устройства и дальнейшей отправки команды. 

• paramiko - внешняя библиотека, обеспечивающая организацию SSH-соединения. Работает в режиме клиента и сервера, соответственно в качестве передачи данных может использоваться только протокол SSH.

• netmiko - внешняя библиотека от сообщества сетевых инженеров и администраторов, была разработана специально для взаимодействия с сетевым оборудованием различных производителей (адаптация под сетевую ОС). Netmiko включает в себя paramiko, описанный раннее.

Наиболее популярные из них это Paramiko и Netmiko. Сегодня мы рассмотрим модуль Paramiko.

SSH и Paramiko.

Paramiko - это реализация протокола SSHv2 на Python. Paramiko предоставляет функциональность клиента и сервера. В рамках статьи будет рассматриваться лишь функциональность клиента, серверную часть возможно изучить самостоятельно.

Библиотека Paramiko не входит в список стандартных модулей для Python 3, поэтому ее требуется установить:

pip install paramiko

В Python3 есть отличная возможность тестировать ваши скрипты, отправляя одиночные команды, для этого достаточно лишь вызвать сам интерпретатор:

python3

Логика работы Paramiko: 

1. создание клиента подключения SSH;

2. настройка клиента подключения SSH;

3. выполнение подключения SSH;

4. переход в интерактивный режим отправки команд для подключения SSH.

Ansible-роль для Linux.

Всем привет.

После установки свежей Linux ей надо указать IP-адрес, временную зону, адрес DNS-сервера, адрес Proxy-сервера, локализацию консоли, прочее. И только после этого уже можно переходить к обновлению системы и установке прочего софта.

Эти шаги настолько обязательны что хочется их автоматизировать, чтобы исключить человеческий фактор. А почему бы и нет? Мои мысли прочитал Вячеслав Лохтуров и предложил для этого иcпользовать Ansible.

Он набросал Ansible-роль под именем "host". Роль использует следующие переменные назначение которых очевидно:

hostname: Linux-host

base_domain_prefix: mydomain

base_domain_suffix: net

base_net: 192.168.1

gateway_octet: 254

dns_ip: 192.168.1.1

proxy_ip: 192.168.1.1

proxy_port: 8080

А в список задач для исполнения включено следующее:

# /host/tasks/main.yml

- name: Create hosts file

  template: src=hosts.j2 dest=/etc/hosts

- name: Create resolv.conf file

  template: src=resolv.conf.j2 dest=/etc/resolv.conf

- name: Create hostname file

  template: src=hostname.j2 dest=/etc/hostname

- name: Create environment file

  template: src=environment.j2 dest=/etc/environment

- name: Create interfaces file CentOS

  template: src=interfacesC.j2 dest=/etc/network/interfaces

  when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat Enterprise Linux'

- name: Create interfaces file Ubuntu

  template: src=interfacesU.j2 dest=/etc/network/interfaces

  when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu'

- name: Update system locale CentOS

  timedatectl set-timezone Europe/Kyiv

  localectl set-locale LANG=ru_RU.utf8

  when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat Enterprise Linux'

- name: Update system locale Ubuntu

  timedatectl set-timezone Europe/Kiev

  echo LANG=ru_RU.UTF-8 > /etc/default/locale

  when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu'

Все задачи также очевидны по своему назначению, кроме, разве что, изменения hostname хоста. Я бы ее не применял. Все файлы роли после моих правок я выложил одним архивом: пользуйтесь, критикуйте, меняйте под себя.

Успехов.

How is doing patches and installation by Ansible.

Hi all.

How is doing patches and installation by Ansible? Next story by Janathan Lozada De La Matta.

So we’ve learned how to update a system, restart the VM, reconnect, and install a RPM. 

  - name: update the system

    yum:

      name: "*"

      state: latest

In the first line, we give the task a meaningful name so we know what Ansible is doing. In the next line, the yum module updates the CentOS virtual machine (VM), then name: "*" tells yum to update everything, and, finally, state: latest updates to the latest RPM. After updating the system, we need to restart and reconnect:

  - name: restart system to reboot to newest kernel

    shell: "sleep 5 && reboot"

    async: 1

    poll: 0

  - name: wait for 10 seconds

    pause:

      seconds: 10

  - name: wait for the system to reboot

    wait_for_connection:

      connect_timeout: 20

      sleep: 5

      delay: 5

      timeout: 60

  - name: install epel-release

    yum:

      name: epel-release

      state: latest

How to simplify daily tasks by Ansible.

Hi all.

How to simplify daily tasks by Ansible? Today short-story by Janathan Lozada De La Matta.

1. Managing users.

If you need to create a large list of users and groups with the users spread among the different groups, you can use loops. Let’s start by creating the groups:

- name: create user groups

  group:

    name: "{{ item }}"

  loop:

    - postgresql

    - nginx-test

    - admin

    - dbadmin

    - hadoop

You can create users with specific parameters like this:

- name: all users in the department

  user:

    name:  "{{ item.name }}"

    group: "{{ item.group }}"

    groups: "{{ item.groups }}"

    uid: "{{ item.uid }}"

    state: "{{ item.state }}"

  loop:

    - { name: 'admin1', group: 'admin', groups: 'nginx', uid: '1234', state: 'present' }

    - { name: 'dbadmin1', group: 'dbadmin', groups: 'postgres', uid: '4321', state: 'present' }

    - { name: 'user1', group: 'hadoop', groups: 'wheel', uid: '1067', state: 'present' }

    - { name: 'jose', group: 'admin', groups: 'wheel', uid: '9000', state: 'absent' }

Установка сторонних модулей в Ansible.

Всем привет.

Установка сторонних модулей с открытым исходным кодом или специализированных модулей выполняется достаточно просто. Рассмотрим эту установку на примере модулей NTC.

Для этого нужно выполнить следующие действия:

1. Выбрать путь в файловой системе Linux, то есть локацию для хранения всех сторонних модулей.

2. Открыть файл конфигурации Ansible (ansible.cfg) и добавить в путь поиска модулей новый каталог, в котором выполнялось клонирование. 

Если место расположения файла ansible.cfg неизвестно, то необходимо выполнить команду ansible --version в своей системе. Вывод может выглядеть приблизительно так:

ntc@ntc:~/projects$ ansible --version

ansible 2.3.1.0

  config file = /etc/ansible/ansible.cfg

  configured module search path = [u'/etc/ntc/ansible/']

python version = 2.7.6 (default, Jul 21 2020, 16:45:13) [GCC 4.8.2]

Вы также увидите строку library =. В этой строке нужно добавить каталог, в котором сохранены все клонированные репозитории (например, library = /etc/ntc/ansible/). При правильном обновлении файла конфигурации при следующем выполнении команды ansible --version вы увидите все внесенные изменения.

[defaults]

inventory = /etc/ansible/hosts

library = /home/ntc/projects/

Testing Ansible roles with Molecule.

Hi all.

Today we will speaking about how to automate your verifications of code using Python.

Story author - Jairo da Silva Junior.

Test techniques role in software development, and this is no different when we are talking about infrastructure as Code (iaC). Developers are always testing, and constant feedback is necessary to drive development. if it takes too long to get feedback on a change, your steps might be too large, making errors hard to spot. baby steps and fast feedback are the essence of tdd (test-driven development). but how do you apply this approach to the development of ad hoc playbooks or roles?

When you’re developing an automation, a typical workflow would start with a new virtual machine. i will use Vagrant [1] to illustrate this idea, but you could use libvirt [2], docker [3], Virtualbox [4], or Vmware [5], an instance in a private or public cloud, or a virtual machine provisioned in your data center hypervisor (oVirt [6], Xen [7], or Vmware, for example).

When deciding which virtual machine to use, balance feedback speed and similarity with your real target environment.

The minimal start point with Vagrant would be:

vagrant init centos/7 # or any other box

Then add Ansible provisioning to your Vagrantfile:

config.vm.provision "ansible" do |ansible|   

  ansible.playbook = "playbook.yml" 

end

In the end, your workflow would be:

1. vagrant up 2. edit playbook. 

3. vagrant provision 

4. vagrant ssh to verify Vm state. 

5. repeat steps 2 to 4. 

Occasionally, the Vm should be destroyed and brought up again (vagrant destroy -f; vagrant up) to increase the reliability of your playbook (i.e., to test if your automation is working end-to-end). Although this is a good workflow, you’re still doing all the hard work of connecting to the Vm and verifying that everything is working as expected. When tests are not automated, you’ll face issues similar to those when you do not automate your infrastructure. Luckily, tools like testinfra [8] and Goss [9] can help automate these verifications.

Ansible Ltd.

Всем привет.

Во время карантина как никогда стали востребованы различные службы доставки. Так сказать наступил их звездный час. Эта почемучка как раз такой службе и посвящается...

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

Броский дизайн очередной рекламной кампании с ярким текстом: 

"Уважаемый клиент! Мы - логистическая кампания Будущего, которое для вас может уже стать Настоящим. Мы - это новое слово в доставке чего угодно и куда угодно. Для Вас сегодня Акция - первые три посылки для Вас совершенно бесплатны. Любой формат, любое место назначение, 100% гарантия. Наш сервис Вас приятно удивит!"

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

"Наша миссия - сокращать расстояния!".

Буклет уже было готов был полететь в урну, но уж больно наклейки были хороши. Поэтому Джейк решил поделиться одной из них с Максом. Он взял конверт, запечатал в него чистый лист бумаги, написал сверху адрес и прикрепил наклейку. Он тут же понял что клеить ее, пожалуй, и не следовало, но... через секунду пискнул телефон вещающий о получении новой sms. Джейк, больше сейчас мечтающий про утренний кофе, и потому нехотя потянулся за телефоном,  взял его и прочитал текст:

"Ваша посылка доставлена. Мы рады что вы с нами."

В отправителях sms значилось: Ansible Ltd., четверг.

Джейк быстро вернул взгляд на стол, конверта там не оказалось. Чисто по привычке заглянул под стол, пошарил взглядом направо налево. Конверта не было. Прочитал еще раз смс. Слабо веря в новые веяния логистики он через пару минут решил еше раз перечитать буклет. От чтения его отвлек звонок Макса. Тот спрашивал что у него за шутки в 5-ть утра присылать чистые листы бумаги..., кое как промямлив в ответ, Джейк погрузился в раздумья: 

- Но сегодня пятница. - Я запечатал конверт полчаса тому.

- Хм, и что за странная sms? Эта фирма доставки не придает значения ни часам ни минутам, а? Может они и время считают по другому?

- Спокойно, это только доказывает, что их логистика находится в тропической стране. В тропиках время почти ничего не значит. Отметка "четверг" свидетельствует, что Ansible Ltd. в Центральной Америке. Если бы эта страна находилась в Индии или еще где-нибудь на востоке, в sms была бы "среда", согласен?

- Точно. Супер-скоростная почта! - воскликнул Джейк. - Еще бы! Да "Новая почта" ей в подметки не годится. Если за время, прошедшее от того, как я получил sms, до момента, когда оно упало в ящик Макса, письмо пропутешествовало не просто отсюда до него, а сначала побывало в Центральной Америке, было обработано и только потом попало к нему, тогда его средняя скорость будет...

- Ок, я знаю как вас вычислить. Посмотрим как вы поступите с недоставкой! - Джейк взял случайную книгу с полки, аккуратно завернул ее и написал только что выдуманный им адрес: "Mr. Jake Faraday, 711, Pаradise Road, Nirvana». Но чтобы вероятность возврата посылки была стопроцентной он указал в качестве адресата себя. Он прикрепил вторую наклейку и положил книгу на стол не сводя с нее взгляда. Секунда, другая, он даже зевнул, но она не исчезла.

- Ага, все таки развод! - заиграли эмоции у Джейка.- Какие только фокусы не придумают во времена карантина.

Еще через секунду пришла sms:

"Возврат отправителю. По указанному адресу получатель временно не проживает. Мы рады что вы с нами. Ansible Ltd., пятница."

- Вот черт! - вырвалось у Джейка. - Они издеваются? Что значит "временно не проживает"? Адрес был взят с потолка!

- Ладно ребята, но я так просто не отступлю, сейчас я вам устрою... любой формат, говорите?, Ну-ну..., - Джейк притащил с балкона большую коробку.

- Книга никуда не исчезла,- заверил он себя, - Вот мы сейчас все и проверим! - Пошлем еще раз по тому же адресу.

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

Телефон принял очередную sms: 

"Ваша посылка доставлена. Мы постоянно развиваем наш сервис - теперь в акции участвуют посылки с доставкой в места назначения где время отличается от вашего более чем на 24 часа. Мы рады что вы с нами. Ansible Ltd., суббота."

Поведенческие параметры в Ansible.

Всем привет.

Для описания хостов в файле реестра Ansible (Ansible.cfg) необходимо явно указывать имя хоста(или IP-адрес) и порт, к которому будет подключаться SSH-клиент Ansible. Это может быть важно если вы управляете хостами с помощью, например, системой Vagrаnt. В Ansible такие перемененные называются поведенческими параметрами (см. таблицу).

ansible_connection

Ansible поддерживает несколько транспортов - механизмов подключения к хостам. По умолчанию используется транспорт smart. Он проверяет поддержку локальным SSН-клиентом функции ControlPersist. Если SSH-клиент поддерживает ее, Ansible использует локальный SSH-клиент. Если локальный клиент не поддерживает ControlPersist, тогда транспорт smart будет использовать библиотеку SSH-клиента на Python с названием Paramiko.

Пользовательский модуль в Ansible.

Всем привет.

На данный момент вам может начать казаться, что управление сетевыми средствами в Ansible во многом зависит от обнаружения правильного модуля для своего устройства. Модули предоставляют некий способ абстрактного взаимодействия между управляемым хостом и самой управляющей машиной, в то время как он делает для вас возможным сосредоточиться на самой логике вашей работы. До этого момента мы знаем что все основные производители предоставляют некий широкий диапазон поддержки модулей для Cisco, Juniper и Arista.

Рассмотрим в качестве примера модули Cisco Nexus - помимо конкретных задач, таких как управление соседним BGP (nxos_bgp) и сервером aaa (nxos_aaa_server), большинство производителей также предоставляют способы исполнения произвольного отображения (nxos_config) и настройки (nxos_config) команд. 

Но что если используемое нами в настоящий момент устройство не имеет прямо сейчас никаких модулей, которые мы бы могли найти в сети? 

Поэтому мы рассмотрим способ которым можно устранить такую ситуацию написав свой собственный пользовательский модуль.

1-й пользовательский модуль.

Написание некоторого пользовательского модуля не обязательно усложнять, на самом деле он даже не обязан быть на Python. Но сегодня мы будем использовать Python для наших пользовательских модулей. Мы предполагаем, что данный модуль это то, что мы будем применять самостоятельно и в своей команде не обращаясь дополнительно к Ansible, таким образом игнорируя некое документирование и форматирование. По умолчанию, если вы создаёте некую папку библиотеки в том же самом каталоге, что и ваш плейбук, Ansible включит этот каталог в путь поиска модуля. Такие модули должны возвращать некий вывод JSON обратно в свой плейбук.

Ускоряем Ansible #4.

Всем привет.

Финальная часть по ускорению сценариев Ansible.

#4 Параллелизм.

Для каждой задачи Ansible устанавливает соединения параллельно с несколькими хостами и запускает на них одну и ту же задачу параллельно. Однако Ansible необязательно будет устанавливать соединения сразу со всеми хостами -уровень параллелизма контролируется параметром по умолчанию, равным 5. Изменить его можно одним из двух способов. Можно настроить переменную среды ANSIBLE_FORKS, как это показано в примере 11.

Пример 11 Настройка ANSIBLE_FORKS

$ export ANSIBLE_FORKS=20

$ ansible-playbook playbook.yml

Можно также изменить настройки в файле конфигурации Ansible (ansible.cfg), определив параметр forks в секции default, как показано в примере 12.

Пример 12 ansible.cfg. Настройка параллелизма

[defaults]

forks = 26

Ускоряем Ansible #3.

Всем привет.

Ну что, продолжим разгон?

#3 Кэширование фактов.

Если в вашем сценарии не используются факты, их сбор можно отключить с помощью выражения gather_facts. Например:

- name: an example play that doesn't need facts 

  hosts: myhosts

  gather_facts: False 

  tasks:

# здесь находятся сами задачи

Также можно отключить сбор фактов по умолчанию, добавив в файл ansible.cfg:

[defaults]

gathering = explicit

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

В примере 7 приводятся строки, которые необходимо добавить в файл ansible.cfg для включения кэширования фактов. Значение fact_caching_tineout выражается в секундах, в примере используется тайм-аут, равный 24 часам (86 400 секундам). Как это всегда бывает с решениями, использующими кэширование, существует опасность, что кэшированные данные станут неактуальными. Некоторые факты, такие как архитектура CPU (факт ansible_architecture), редко изменяются. Другие, такие как дата и время, сообщаемые машиной (факт ansible_date_tine), гарантированно изменяются очень часто. Если вы решили включить кэширование фактов, убедитесь, что знаете, как часто изменяются факты, используемые вашим сценарием, и задайте соответствующее значение тайм-аута кэширования. Чтобы очистить кэш до запуска сценария, передайте параметр --flush-cache утилите ansible-playbook.

Ускоряем Ansible #2.

Всем привет.

Продолжим наши гонки с Ansible. Рассмотрим конвейерный режим выполнения задач.

#2 Конвейерный режим.

Вспомним, как Ansible выполняет задачу:

1.Генерирует сценарий на Python, основанный на вызываемом модуле.

2.Копирует его на хост.

3.И запускает его там.

Ansible поддерживает прием оптимизации - конвейерный режим, - объединяя открытие сеанса SSH с запуском сценария на Python. Экономия достигается за счет того, что в этом случае требуется открыть только один сеанс SSH вместо двух. По умолчанию конвейерный режим не используется, потому что требует настройки удаленных хостов, но мне нравится использовать его, поскольку он ускоряет процесс. Чтобы включить этот режим, внесите изменения в файл ansible.cfg, как показано в примере 3.

Пример 3 ansible.cfg, включение конвейерного режима

[defaults] 

pipelining = True

1) Настройка хостов для поддержки конвейерного режима

Для поддержки конвейерного режима необходимо убедиться, что на хостах в файле /etc/sudoers выключен параметр requiretty. Иначе при выполнении сценария вы будете получать ошибки, как показано в примере 4.

Инсталлируем софт с помощью Ansible #3.

Всем привет.

Продолжим тему инсталлирования софта с помощью Ansible в Linux. Представим задачу что у нас есть сервер mysql который привязан на адрес 127.0.0.1. А мы хотим дать к нему доступ для всех. Т.е. имеем: [mysqld] bind-address  = 127.0.0.1. А хотим указать как: [mysqld] bind-address = 0.0.0.0.

1) Пишем  наш плейбук:

---

- name: Reconfigure MariaDB Server to listen for external connections

  lineinfile:

    path: /etc/mysql/mariadb.conf.d/50-server.cnf

    regexp: '^bind-address\s+='

    line: 'bind-address = 0.0.0.0'

    insertafter: '^\[mysqld\]'

    state: present

- name: Restart MariaDB to pick up configuration changes

  service:

    name: mariadb

    state: restarted

Давайте задачу lineinfile рассмотрим более подробно:

-path: Сообщает своему модулю какой файл настроек изменять.

-regexp: Применяется для определения имеющейся изменяемой строки, когда она присутствует, чтобы у нас не было двух конфликтующих директив bind-address.

-line: Значение строки для замены/ вставки в изменяемый файл настроек.

-insertafter: Когда не найдено соответствие regexp (то есть данная строка не представлена в изменяемом файле), данная директива обеспечит вставку модулем lineinfile некой новой строки после имеющегося оператора [mysqld], тем самым обеспечивая его наличие в верной части данного файла.

-state: Установка в значение present обеспечивает что данная строка присутствует в изменяемом файле, даже когда нет первоначального совпадения regexp - в такой ситуации в изменяемый файл добавляется некая строка в соответствии со значением line.

Ускоряем Ansible #1.

Всем привет.

Рано или поздно возникает потребность в ускорении выполнения сценариев Ansible. 

Для реализации этого есть несколько путей:

-мультиплексирование SSН, 

-конвейерный режим, 

-кэширование фактов, 

-параллельное выполнения задач, 

-асинхронное выполнения задач.

Рассмотрим их подробнее. В подготовке статьи использовались материалы из книги "Запускаем Ansible" авторов Мозер Р. и Хоштейн Л., 2018.

#1 Мультиплексирование SSH и ControlPersist.

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

OpenSSH - наиболее распространенная реализация SSH и SSH-клиент по умолчанию, который установлен на вашей локальной машине, если вы работаете в Linux или Mac OS X. OpenSSH поддерживает вид оптимизации с названием мультиплексирование каналов SSH, который также называют ControlPersist. Когда используется мультиплексирование, несколько SSH-сеансов с одним и тем же хостом использует одно и то же TCP-соединение, то есть ТСР­-соединение устанавливается лишь однажды.

Когда активируется мультиплексирование:

- при первом подключении к хосту OpenSSH устанавливает основное соединение;

- OpenSSH создает сокет домена Unix (управляющий сокет), связанный с удаленным хостом;

- при следующем подключении к хосту вместо нового ТСР­-подключения OpenSSH использует контрольный сокет.

Основное соединение остается открытым в течение заданного пользователем интервала времени, а затем закрывается SSH-клиентом. По умолчанию Ansible устанавливает интервал, равный 60 секундам.

Reboot Linux by Ansible.

Всем привет.

Хоть Linux и не требует своей перезагрузки так часто как Windows, но тем не менее такой вариант надо знать тоже. Мы инсталировали софт в Linux с помощью Ansible, значит и перегружать ее будем с помощью того же Ansible.

Итак, пишем наш плейбук:

 - name: Linux system reboot

  apt: name=git update_cache=yes

  hosts: test

  become: yes

  tasks:

#Первая задача: непосредственно сам ребут

  - name: Reboot host

    command: shutdown -r now "Ansible system reboot"

    async: 3600

    poll: 0

    register: linux_clone

#вторая задача: отследим когда ребут завершится - вариант первый

  - name: Wait for linux to complete

    async_status:

      jid: "{{ linux_clone.ansible_job_id }}"

    register: result

    until: result.finished

    retries: 3600

#вторая задача: отследим когда ребут завершится - вариант второй

  - name: Wait for the host to finish rebooting

    local_action: wait_for host={{ inventory_hostname }} state=started

    become: false

    delegate_to: localhost

#вторая задача отследим когда ребут завершится - вариант третий

  - name: Wait for the host to finish rebooting

    wait_for:

        host: "{{ inventory_hostname }}"

        state: started

        delay: 5

        timeout: 40

    delegate_to: localhost

где:

1) аsync говорит о том, что команду надо запустить асинхронно (т.е. продолжить выполнение, после ее запуска не дожидаясь ответа). Аsync = 3600 - выполнять не более 3600 секунд.

2) poll говорит о том, через сколько попробовать получить результат выполнения команды. 

poll = 0 - т.е. можно перейти к следующей задаче не ожидая окончания выполнения текущей

3) register: linux_clone - захватим результат чтобы работать с ним дальше

4) async_status: - читаем результат задачи linux_clone

5) jid: "{{ linux_clone.ansible_job_id }}" - по идентификатору

    register: result

6) until: result.finished - перечитываем результат повторно много раз.