IaC, CMS, CMDB (Chef, Puppet, Ansible, Nornir, CFEngine, Arista CVP)

CMDB (Configuration Management Data Base) — это база данных управления конфигурациями, которая включает в себя элементы ИТ-инфраструктуры и отражает их связи. Одна из главных особенностей CMDB — учет не только оборудования и ПО, но и конфигурационных единиц (КЕ).

Infrastructure as a Code (IaC), Configuration Management (CM), Centralized Management

Масштабируемость системы очень важный аспект для любой растущей системы. Пример – телеграм и жаловался на проблемы масштабирования из-за слишком бурного роста. Масштабирование может понадобиться на любой участке – вычисления, сеть, хранение. Могут быть как аппаратные, так и программные пороги, которые всплывут при масштабировании.
Every service growing too fast is bound to experience growing pains; unfortunately, Telegram is no exception, although we strive to be one.

Arista CVP – подробнее в NMS.

Chef/Puppet/SCCM microsoft – иснтрументы управления конфигурацией CMS (configuration management tool), обеспечивают возможность управления высокоуровневыми объектами, такими как сервисы.

Есть стандартные use cases CMS, для решения стандартных повторяющихся задач даже без знания программирования, но можно писать и скрипты. К примеру, можно написать chef recipe (скрипт) для автоматического разворачивания сервиса, например WEB-сервера с SQL-базой, причем база разворачивается первой т.к. она необходима для работы WEB-сервера.

В CM используется подход рассмотра IT инфраструктуры как кода, Infrastructure as code (IAC), только вместо кода используются конфигурационные файлы или целые системы (узел такой то имеет такую то версию конфигурации). Такой подход в своей основе подразумевает правила работы с конфигурацией, которые применяются к коду (т.е. работаем с конфигурациями как с кодом, именно поэтому это «как код»):

  • programming workflowдля конфигурации – planning, development, testing, deployment только после предварительных фаз (review/tests), совместная работа, code review – множество плюсов, включая разделение ответственности, информирование и проч.
  • отслеживание версионности (VCS) в централизованном репозитории – легко посмотреть кто что делал, легко откатить
  • удаление дублирования
  • унификация
  • тестирование

В результате CM могут применять git в качестве VCS для конфигурации, тестировать конфигурации, применять один конфиг на множество устройств, тем самым унифицируя инфраструктуру.

Пример использования CM в Cumulus Linux:

Configuration Management System (CMS) – системы по развертыванию конфигурации, ее тестированию, сбору информации о конфигурации на IT объектах. CMS решают вопросы, которые ставит задача CM, через реализованные в CMS инструменты. В качестве объектов могут быть сервера, сетевые устройства, устройства хранения или VM. Примеры CMS – Chef, Puppet, Ansible, Nornir, CFEngine. Выбор конкретного так же сложен как выбор языка программирования и большей частью определяется кейсом применения и background знаниями. Пример задач CMS
1) установка определенной версии антивируса/браузера на множество ПК и отслеживание, что эта версия не меняется
2) установка на ряде серверов сразу множества сервисов – apache + sql + php + wordpress

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

 

ansible
  • Очень многие до сих пор используют ansible в enterprise (дикси, эвалар, etc, etc). Можно даже сказать, что в основном именно он используется для деплоя, более «устаревшими» считаются Chef и puppet.
  • Пример usage из реальной жизни: Для выкатки и настройки серверов – ansible;
  • Часто используется в сетевой автоматизации, настолько, что “Увольняйся и ищи себе норм место – в 2016 году не использовать энсибл это дно”, тут скорее правильнее не используют автоматизацию т.к. по факту очень крупные не используют Ansible 🙂
  • При этом используется и для деплоя bare metal серверов Linux – разворачиваются сервера с помощью Ansible
  • При этом зачастую возникает задача кастомизации, которая заставляет писать свой модуль ansible и это то еще мучение – поэтому от ansible зачастую отказываются в пользу чистого python и каких либо инструментов с ним (напр. Nornir). В целом, кто залазил в Ansible, очень расстраивался – плейбуками все не сделать, а писать модуль Ansible очень нетривиально и костыльно (LinkMeUp о сетевой автоматизации)
  • Кто-то уже использует ansible для заливки vlan и просмотра show version на juniper на основе модуля Ansible для juniper – сейчас это делают через snmp или expect.
  • Роли ansible нужны для переиспользования кодовой базы в рамках разных playbook, по сути это функция которая может вызываться из других playbook, возможно в том числе создание playbook состоящего только из ролей без задач – по сути библиотеки с функциями. Пример playbook с задачами и ролями – playbook отвечающий за установку и настройку nginx, шаги по деплою/настройке нарезаны на роли и могут вызываться из других playbook при необходимости.
  • В ansible много мест, где можно указывать переменные – inventory файл в синтаксисе yaml/ini (не рекомендуется), groupvars, hostvars, внутри роли в defaults и в vars, include’ить из отдельного файла используя инструкцию vars, передавать из командной строки используя extravars параметр
  • Теги ansible нужны для исполнения части кода playbook – при запуске playbook ты указываешь какие участки кода будут запущены путем указания тегов этого кода, сужается набор задач которые запускаются в playbook:
    • tag и указание тега запускает только задачу с этим тегом/тегами; по умолчанию all,
    • skip-tags и указание тега запускает playbook без указанного тега,
    • always тег всегда запускает тег (если только явно его не исключить через skip-tags),
    • never тег всегда пропускает тег (если только явно его не включить)
--tags all — запускать все задачи, игнорировать теги (поведение по умолчанию) --tags [tag1, tag2] — запускать только задачи с тегом tag1 или тегом tag2 . --skip-tags [tag3, tag4] — запускать все задачи, кроме задач с тегом tag3 или тегом tag4 .
  • RedHat во всю пиарит свою автоматизацию на базе Ansible.

Что такое факты в ansible ?

Факты это переменные, которые собираются с управляемых машин (managed hosts) в начале выполнения каждого плейбука. Предоставляют подробную информацию о системе, такую как сетевые интерфейсы, IP-адреса, информацию о операционной системе, свободное пространство на дисках и другие системные характеристики.
Факты — это переменные, содержащие данные о управляемых системах. Они помогают делать плейбуки более интеллектуальными и адаптивными к разным условиям окружающей среды и системным конфигурациям. Это как разведчики, которые собирают информацию перед началом основных операций.

Сбор фактов
Собираются модулем setup в Ansible. Когда вы выполняете плейбук, Ansible по умолчанию автоматически вызывает этот модуль для сбора данных о всех управляемых машинах, если только сбор фактов не отключен. Вы можете отключить сбор фактов, используя gather_facts: no в начале плейбука, если вам не нужна информация о системе и вы хотите ускорить выполнение плейбука.

Использование:
Факты можно использовать для принятия решений во время выполнения плейбука. Например, можно создать условные задачи, которые будут выполняться только на определённых операционных системах, или настраивать настройки сети, основываясь на IP-адресе или MAC-адресе интерфейса.
- name: Gather facts about VMs
  hosts: all
  tasks:
    - name: Print OS family
     debug:
        msg: "The OS family is {{ ansible_facts['os_family'] }}"

В этом примере, после сбора фактов, плейбук выводит семейство операционной системы управляемого хоста, используя переменную ansible_facts['os_family'].

Преимущества:
1️⃣Автоматизация на основе контекста: Факты позволяют плейбукам адаптироваться к характеристикам окружения, что делает автоматизацию более гибкой и устойчивой.
2️⃣Упрощение управления конфигурациями: Используя факты для определения специфических характеристик системы, можно избежать жесткого кодирования параметров, что упрощает поддержку и обновление плейбуков.
3️⃣Условное выполнение задач: Факты могут быть использованы для определения, нужно ли выполнять определённые задачи на конкретном хосте, что повышает эффективность и точность выполнения плейбуков.

 

Chef
  • Pappet/Chef удобны для массовых изменений т.к. поддерживают модель pull, основной недостаток очевиден – их чаще нет на сетевых девайсах, чем есть 🙂

Chef использует ряд концепций и инструментов для реализации принципа IAC. Его используют крупные компании типа facebook для управления тысячами серверов. Chef масштабируем и легко кастомизируется под задачи.

По примеру того, как мы заказываем еду в ресторане, Chef использует intent-based automation paradigm, что подразумевает не указание всех конкретных команд Chef для исполнения (подключиться к серверу, создать файл, внести информацию в файл), чтобы достичь определенной конфигурации, а непосредственно каким должна стать эта конфигурация (какое состояние ресурса должно быть в результате). Это касается не всех операций – execute исполняет непосредственно команду. Кроме того операция execute в общем случае не реализует принцип idempotent операции, что реализуют большинство других операций Chef.

Большая часть кода Chef написана на Ruby, оставшаяся (сервера) на Erlang. Кроме того конфигурационный код Chef основан на Ruby – для написания Chef конфигурационных файлов Chef реализует Domain Specific Language (DSL), который описывает ресурсы в скрипте (recipe). Этот DSL основывается на Ruby. Это позволяет использовать Ruby код в Chef.

Для создания

Chef делает не так:
touch file.txt
echo “I’m string” > file.txt

А так:
file “/tmp/file.txt” do
content “I’m string”
end

ЭЛЕМЕНТЫ
Рецепт (recipe) – базовые инструкции Chef, которые пишуться DSL. В инструкциях описаны изменения состояния ресурсов (resources) и изменения, которые происходят с этими ресурсами (, напр. сервисы или пакеты). Ресурсы обычно состоят из четырех компонентов: тип (package, service, script и т.п. или даже custom), имя (apache2), настройки, действия. Часть ресурсов имеют дефолтные значения, например package по умолчанию в action имеет install. Поэтому можно установить пакет (или убедиться, что он установлен – idempotent) простой строкой package “apache2”.
Пример рецепта с настройкой двух ресурсов (package, service) – в первом проверяем что apache2 стоит, а во втором запускаем его и добавляем в автозагрузку. Можно так же добавить создание файла index.html через template (файл-источник) intex.html.erb в котором находится не статичный файл, а html код с переменными Chef, взятыми в особые скобки.

Меню (cookbook) – включают ряд рецептов вместе, в один “пакет”. Так же могут включать дополнительные элементы (напр. картинки, шаблоны, атрибуты).

Пример recipe в cookbook.

 mkdir chef-project
 mkdir chef-project/cookbooks
 cd chef-project/cookbooks
 chef generate cookbook apache2 # создает кучу папок и файлов (напр. recipes, файл .kitchen.yml), включает git repository
vi apache2/recipes/default.rb

apt_update 'update' do
  action :update
 end

apt_update 'Update the apt-cache daily' do # или можно так
  frequency 86_400 # или можно так
  action :periodic # или можно так
end # или можно так

package "apache2" do # можно без нижестоящих строк
 action :install
 end

service "apache2" do
 action [ :enable, :start ]
 end

template "/var/www/html/index.html" do
 source 'index.html.erb'
 end

Создаем template файл ‘index.html.erb’. Можно сделать вручную, но в Chef Development Kit есть специальная команда по генерации – chef generate template. Она создает папку templates с необходимым файлом.

cd chef-project/cookbooks/apache2
chef generate template index.html.erb
vi templates/index.html.erb
 <html>
 <body>
 <title> Hi! The name of this computer os <%= node['fqdn'] %> </title>
 <body>
 </html>

Желательно создать файл метаданными, там указать название cookbook, что мы делаем и версию.

chef-workstation:/share$ cat cookbooks/chef_apache2/metadata.rb 
name 'chef_apache2'
description 'Installs and configures apache2'
long_description 'Installs and configures apache2'
version '1.0'

ПЛАТФОРМА (CHEF PLATFORM на базе Chef Development Kit)
Узел (node) – узел, за CM процессами которого “присматривает” Chef. Может быть сервер, роутер или ноутбук. Главное, чтобы на него встал Chef client.

Клиент Chef – локально установленный софт на узел, которым осуществляется управление посредством Chef. Chef client написан на Ruby. Скачивает новые cookbooks с сервера и применяет их. По сути отвечает за конвергенцию локальной системы, на которой установлен, до состояния, указанного в cookbooks/recipe. Именно он применяет конфигурацию к локальному узлу, а не сервер. Так же он регистрирует и аутентифицирует клиента на Chef Server. Клиент для учебных/тестовых задач можно запустить в local mode без сервера, в таком случае Chef client будет применять код, созданный на самом компьютере без работы с Chef server.
mkdir test_chef_dir
cd test_chef_dir
vi test_recipe.rb
file “/tmp/file.txt” do
content “I’m string”
end
chef-client –local-mode test_recipe.rb
Удаляем файл
vi test_delete_recipe.rb
file “/tmp/file.txt” do
action :delete
end
chef-client –local-mode test_delete_recipe.rb

Chef client скрипт – можно написать скрипт по постоянному адпейту данных с сервера на клиент, используя resource script (исолнение произвольного кода, на разных интерпретаторах – bash, ruby, python). Используя такие скрипты можно сделать что угодно: изменить экран приветствия, цвет терминала SSH, алармы при каких-то действиях пользователя (напр. запуск knife ssh с командой rm -rf), сделать скрипт по автоадейту клиента на сервере.

Сервер Chef – софт на сервере Chef, написан на Erlang. Хранит на себе необходимые cookbooks. Передает Chef Client конфигурацию в виде recipe/cookbook, которую тот должен применить на узле. Таким образом сервер не загружается лишними задачами и один может обслуживать большое количество (тысячи) клиентов (узлов).

Ohai – один из модулей Chef client (или если быть точным один из элементов Chef Development Kit) с помощью которого Chef узнает состояние системы, которой он управляет. Запускается при каждом запуске Chef. Сохраняет информацию в аттрибутах.
Конвергенция (convergence) – последовательность шагов, описанных в каждом recipe, по приведению системы в желаемое состояние.
Неизменность операций (idempotent) – CMS в общем случае стремяться к неизменности результата операций, стараются сделать результат операции idempotent (неизменяемыми). Под этим подразумевается то, что действие всегда приводит к одному результату. К примеру, если в системе уже насроен данный параметр, Chef не настраивает его заного (не создает файл, не меняет конфиг, не включает сервис), потому что перед началом изменения чего-либо он проверит, что это что-то уже не имеет настройку (наличие файла, наличие строки, наличие пакета, состояние пакета и прочее), которую мы хотим произвести. Таким образом, в случае запуска скрипта и отваливания его на середине (напр. из-за проблемы с сетью), повторный запуск не приведет к каким то проблемам – параметры не будут перенастроены.

Test kitchen – тестовая платформа Chef, входящая в стандартный Chef Development Kit, которая используется для тестирования recipe и cookbook в sandbox (программно-изолированной среде). Test kitchen работает с инструментами виртуализации для создания sandbox, который представляет собой одноразовые виртуальные машины. В созданной тестовой среде можно убедиться что Chef recipe/cookbook работают до деплоя на продакшн серверах. т.к. Test kitchen полагается на виртуализацию – для его работы нужно поставить инструменты виртуализации. Ему нужна сама среда в виде гипервизора, например такого как VirtualBox и инструмента создания/управления виртуальными машинами, такого как Vagrant. Конфигурация Test kitchen происходит через файл .kitchen.yml, обычно находящегося в директории cookbook.

Есть полностью автоматизированные альтернативы, которые автоматически проверяют recipe/cookbooks – ChefSpec (базовые проверки, но очень быстро), ServerSpec. Они автоматически делают unit test вещей, которые вы собрались наконфигурировать и в том числе сами запускают test kitchen.

Команда kitchen create (вызывать нужно из директории в которой находится файл с конфигом .kitchen.yml т.к. оттуда забираются параметры VM) используется для создания VM.

Команда kitchen list используется для проверки после создания, что все ок. Показывает ОСь (ubuntu 16), драйвер по работе с ней (vagrant) и прочую инфу, в конце которой наличие или отсутстие ошибок.

Команда kitchen converge использует файл .kitchen.yml чтобы применить cookbooks из run_list .kitchen.yml на созданной VM, через пересылку этих cookbooks на исполнение созданному в VM Chef клиенту. Проверить что все ок можно по отсутсвию ошибок во время converge, автоматизированным тестам или ручной проверки того, что должно было поменяться.

Команда kitchen exec позволяет применить любую команду на созданной через create VM.
kitchen exec -c “curl localhost”

Команда kitchet destroy используется на конечной стадии, она убивает VM.

Пример файла .kitchen.yml:
driver:
name: vagrant

provisioner:
name: chef_zero

platforms:
– name: ubuntu-16.04

suites:
– name: default
run_list:[your_cookbook_here::default]
attributes:

Knife tool – командная утилита, используется для взаимодействия админа с workstation с Chef сервером и Chef клиентами. С помощью нее можно закачивать Cookbooks на Chef server, разворачивать новые узлы путем установки Chef client на них (причем одновременно на нескольких узлах). Авторизация на сервере Chef происходит при использовании двух файлов
key (RSA key) и certificate (SSL certificate), которые находятся в папке ~/.chef с knife.rb. Для конфигурации knife tool используется файл small.rb. В этом файле указывается адрес Chef server’а, местонахождение cookbooks и прочее. Этот файл читается каждый раз при запуске knife tool, обычно он находится в директории ~/.chef.
Пример файла:
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name “admin”
client_key “#{current_dir}/admin.pem”
chef_server_url “https://chef-server.test/”
cookbook_path [“#{current_dir}/../cookbooks”]

Пример использования тулзы – заливаем cookbook на сервер:
knife cookbook upload apache2

Проверяем что сервер имеет новый cookbook:
knife cookbook list

Через knife можно подключаться по ssh к Chef client и делать любые команды:
knife ssh ‘name:node_name’ –sh-port 22 –ssh-user test –ssh-password test ‘uptime’

И даже к нескольким серверам с исполнением одной команды на них в один момент времени:
knife ssh ‘name:*’ –sh-port 22 –ssh-user test –ssh-password test ‘uptime’

Информируем клиент он новом run_list (Chef client после запуска заберет нужный рецепт default из указанного cookbook apache2 с сервера вместе с необходимыми template файлами). Команда обязательна только если не настроен автоматический апдейт конфигурации на Chef client (скрипт периодически клиент забирает с сервера новые данные автоматически – см. в chef client подробнее).
knife node run_list add node_name ‘recipe[apache2::default]’

Запускаем Chef client:
knife ssh ‘name:node_name’ –sh-port 22 –ssh-user test –ssh-password test ‘sudo chef-client’

Можно сделать Knife плагин для управления узлами в aws.

Food critic – проверка кода ваших recipe на стиль и общие проблемы.

Chef supermarket – платформа Chef по аналогии с ruby gems. Тут можно скачать разные cookbook других людей под разные кейсы.

__FILE__ – крутая переменная в руби, по ней можно понять название скрипта. По ней можно понять например номер процесса или текущую директорию.
current_dir = File.dirname(__FILE__)

Последовательность использования CMS:
1) Создать и протестировать конфиг на тестовом сервере
2) Отправка конфига не Chef Server
3) Chef server распределяет конфиг на клиенты

 

ЧТО МНЕ НЕ ПОНРАВИЛОСЬ

Не получил я такого удовольствия от chef, как например от git.

1. Мало какое сетевое оборудование пока поддерживает развертывание chef client – не съехать на него со своих/вендорских/NMS скриптов по настройке.

2. Заливать Chef сервера и хосты через sh-скрипты в 120 строк (а именно так делает Google в обучении Coursera) – нуууу я хз, хотя это и разово написанные скрипты, но от этого говорить что можно работать с Chef без знаний программирования – бред:

Сначала пишем sh-скрипт get_chef_key.sh в 20 строк чтобы цепануть pem ключ по scp с Chef сервера на Workstation и происталить инфу о сервере на Workstation.

Потом пишем sh-скрипт manage_nodes.sh в овер 100 строк чтобы :

  1. при запуске проверяет наличие и корректность переменных на STDIN
  2. при запуске проверяет конфиг Workstation (конфиг knife, наличие pem ключа, SSL, cookbook)
  3. по опции с Workstation разворачивает Chef client на управляемых девайсах
  4. по опции с Workstation говорит развернутому клиенту обновись с сервака, возьми такие то конфиги (cookbook/recipe)

p.s. Google и Coursera отдельный респект – давать 7 серваков с белыми IP чисто “поиграться” с Chef и loadbalancing – это реально круто.

Leave a Reply