Сегодня мы поговорим о том, что такое SCM, и расскажем несколько историй, через призму которых рассмотрим Ansible, SaltStack, Chef и Puppet, выбирая лучший вариант для конкретной задачи.
Материал основан на расшифровке репортаж Андрея Филатова , ведущий системный инженер EPAM Systems, с октябрьской конференции DevOops 2017.
Что такое СКМ и с чем его едят?
Что такое СКМ? Прежде всего, это вещь, которая позволяет нашей инфраструктуре перейти из состояния А в состояние Б, выполняя некоторый код. Многие разработчики, которые на практике не являются DevOps-инженерами, думают, что в инфраструктуре что-то происходит каким-то «автоматическим» образом.
«Автоматический» метод у нас реализует SCM (Управление конфигурацией системы).
Для чего это? Прежде всего, для того, чтобы построить повторяемую и согласованную инфраструктуру.
SCM хорошо расширяет процессы CI/CD. Поскольку это код, его можно хранить в любой системе контроля версий: Git, Mercurial. Его довольно просто разрабатывать и поддерживать.
И последнее — замкнутый цикл автоматизации: все можно делать автоматически, от создания инфраструктуры до ее развертывания и развертывания кода.
Что такое SCM:Ansible
Давайте рассмотрим наших претендентов.
Первый из них — Анзибль.
Он имеет безагентную архитектуру, если мы говорим о версии с открытым исходным кодом, написан на Python, имеет Yaml-подобный DSL, легко расширяется через модули, написанные на Python, очень простой и легкий.
У Ansible самый низкий порог входа — научить можно кого угодно.
Есть опыт, когда человек, не зная Python, ничего не зная о SCM, зашёл в Ansible всего за два дня и уже начал что-то делать.
Ниже приведен пример уведомления ChatOps: в Slack. Код на Ansible, кто видел Yaml, ничего нового.
- block: - name: "SlackNotify : Deploy Start" local_action: module: slack token: "{{ slack_url }}" attachments: - title: "Deploy to {{ inventory_hostname }} has been Started" text: "<!here> :point_up_2:" color: "#551a8b" - include: configure.yml tags: - configure - include: remote-fetch.yml tags: - remote - include: assets.yml
Что такое СКМ: Шеф-повар
Chef — это клиент-серверная архитектура, есть сервер Chef и клиент Chef. Конфигурация основана на поиске, написана на Ruby и имеет Ruby DSL. Соответственно, вы можете использовать всю мощь Ruby внутри своих кулинарных книг и рецептов, но я не рекомендую этого делать.
У Chef огромное сообщество и самый большой набор инструментов среди всех SCM. Вот как выглядит код Chef, это развертывание Jetty. #
# Cookbook Name:: dg-app-edl
# Recipe::fe
#
node.normal[:jetty][:home] = "/usr/share/jetty"
node.normal[:jetty][:group] = "deploy"
include_recipe "dg-auth::deploy"
include_recipe "newrelic::repository"
include_recipe "newrelic::server-monitor"
include_recipe "dg-jetty::jetty9"
include_recipe "newrelic::java-agent"
directory "edl" do
action :create
owner
group "deploy"
mode "0775"
path "/usr/share/where/edl"
recursive true
end
Что такое SCM: SaltStack
SaltStack имеет как безагентную архитектуру, которая работает в режиме push с использованием Salt-SSH, так и клиент-серверную архитектуру, где есть Salt-мастер и Salt-миньон.
Акцент сделан на автоматизацию в реальном времени, имеет параллельное выполнение всех процессов «из коробки» и написан на Python. Это также язык, похожий на Yaml, код очень похож на Ansible. #ntp-packages:
pkg.installed:
- pkgs:
- ntp
- ntpdate
#/etc/ntp.conf:
file:
- managed
- source: salt://common/ntpd/ntp.conf
- template: jinja
- mode: 644
#/etc/sysconfig/ntpd:
file:
- managed
- source: salt://common/ntpd/ntpd
- template: jinja
- mode: 644
#ntp-service:
service.running:
- name: ntpd
Что такое SCM: Марионетка
Последний из наших претендентов — Puppet. Также имеет клиент-серверную архитектуру, как и Chef, конфигурация основана не на поиске, а на «фактах», которые поступают от Puppet-master, написан на Ruby, имеет Ruby-подобный DSL. Но ребята из Puppet не допускают использования чистого кода Ruby в своих манифестах.
Это и плюс, и минус.
Вот как выглядит код манифеста Puppet: class { 'mysql::server' :
root_password => 'password'
}
mysql::db{ ['test', 'test2', 'test3']:
ensure => present,
charset => 'utf8',
require => Class['mysql::server'],
}
mysql::db{ 'test4':
ensure => present,
charset => 'latin1',
}
mysql::db{ 'test5':
ensure => present,
charset => 'binary',
collate => 'binary',
}
СКМ на практике
SaltStack в демилитаризованной среде
Прежде всего, я хотел бы поделиться проектом, написанным на SaltStack. Это наш предыдущий проект и самая последняя боль, а самая свежая боль всегда самая болезненная.Наш заказчик занимается хранением данных — производит аппаратные серверы для хранения данных на GPFS, GlusterFS, но сборки кастомные.
Он пришел к нам со следующими задачами:
- Создание установщика USB/DVD. Вам необходимо создать носитель, с которого все будет установлено.
Это делается для клиентов заказчика, которые проживают на закрытых территориях, где на серверах чаще всего нет интернета.
Нам нужно упаковать его в один ISO и отправить инженерам по эксплуатации, которые развернут все необходимое на месте.
- Развертывание кластера с продуктом.
У клиентов есть несколько крупных продуктов, мы должны иметь возможность развернуть их в режиме кластера.
- Управление, настройка и обслуживание кластера с помощью утилиты CLI. Наша структура должна помочь полевым инженерам управлять кластером.
Прежде всего, он обладает огромным опытом работы в Python, фактически только разработчиками C и Python. Заказчик сразу сказал: «Мы хотим SaltStack», не оставив выбора.
С чем мы имеем дело? У заказчика имеется в установке несколько изделий, каждое из которых должно быть оснащено Salt-Masters. Но мы столкнулись с проблемой масштабирования конфигурации Multi-Master. Например, у нас в NODE Info (состояние конкретного сервера) при конфигурации с двумя мастерами он выбирался за миллисекунды, с тремя — уже секунды, а с пятью мы так и не дождались завершения операции.
MultiMaster — хорошая функция, но она плохо масштабируется.
Вторая проблема, с которой мы столкнулись, — это командная работа: в SaltStack есть Runner и Module. Модуль — это расширение, которое работает на Salt Minion на стороне машины.
Runner работает на стороне сервера.
У нас очень часто возникали сражения: что делать Раннеру, а что Модулям.
Затем нас ждал небольшой сюрприз отcache.mine: ime = ImeActions()
id = __grains__['id']
if id == ime.master_id:
ret = __salt__['mine.get'](id, 'ime_actions.make_bfs_uuid')
ime_dict = ret.get(id, None)
if not ime_dict:
try:
result = __salt__['mine.send']('ime_actions.make_bfs_uuid')
except Exeption, e:
log.error("Failed to generate uuid: {0}.
".
format(str(e)))
result = False
else:
У нас есть утилита, написанная на C. Запускаем ее, она генерирует случайный идентификатор.
Он должен быть уникальным среди всех членов кластера; соответственно, нам нужно сделать это один раз на мастере, а потом распределить по машинам.
Для этого мы использовали кэш.
майн.
Как оказалось, перезагрузку он не выдерживает. 
«Состояние гонки».
Распараллеливание — это хорошо, но в базовой конфигурации state.orchestrate переходит в состояние.
sls запускается, если происходят длительные процессы.
Из-за таймаута он считает, что State уже выполнен, хотя еще выполняется, и пытается запустить следующий.
Возникает ошибка.
И эта проблема до сих пор не решена.
Может посмотри на GitHub .
Что мы могли бы использовать, кроме SaltStack?
SaltStack в среде DMZ
- ДМЗ.
Шеф хорошо упаковывает вещи, как и Марионетка.
А проблема Ansible в том, что если нет Tower, то нет возможности запустить конфигурацию в режиме Pull с наших нод, что нужно делать в демилитаризованной зоне.
- Фреймворк для CLI (на Python).
Chef и Puppet не очень подходят, но если вы не ограничены использованием только Python, вы можете написать на Ruby и использовать Chef или Puppet API. Ansible не поддерживает такие инструменты.
- Кластерное управление.
Chef хорош для управления кластерами, Puppet тоже хорош, а Ansible изначально был написан для управления кластерами в Amazon.
Шеф-повар в большой и динамичной среде
Заказчик пришел с задачей объединить все ресурсы в одном облаке — это был Openstack. До этого все было разбросано: что-то на Rackspace Cloud, что-то на выделенных серверах или в собственных частных дата-центрах.Им требовалось полностью динамическое управление ресурсами и возможность приложениям увеличивать емкость при необходимости.
То есть вам нужна полностью динамическая инфраструктура и полностью динамическая среда как сверху, так и снизу.
Чтобы правильно построить процесс компакт-диска, вам нужна полностью автоматизированная среда.
Мы создали для них SDLC — жизненный цикл разработки программного обеспечения — и применили его, среди прочего, к SCM. Они проводят интеграционные тесты не только приложений, но и инфраструктуры.
Соответственно, когда у нас что-то идет не так, мы должны, как ребята из Netflix, уметь убивать бракованные ресурсы и восстанавливать на их место свежие и гарантированно рабочие.
С какими проблемами мы столкнулись:
- Это был 2013 год, мы использовали Chef 10, у которого медленный поиск.
Мы провели поиск, перебрали все машины, и это заняло целую вечность.
Мы попытались решить проблему, используя соглашение об именах, а также выбор и поиск по fqdn. Это сузило зону поиска, заставив его ускориться.
Но некоторые операции необходимо выполнить над всей средой.
Соответственно, поиск запускался один раз в самом начале, результат сохранялся в атрибуте, и с помощью Ruby мы фильтровали результаты: парсили нужные нам куски и делали то, что нужно.
if !Chef::Config[:solo] search(:node, "fqdn:*metro-#{node[:env]}-mongodb*").each do |mongo| @mongodbs << mongo.fqdn end else @mongodbs = ["lvs-metro-#{node[:env]}-mongodb3001.qa.example.com"] end
Итог: используйте соглашения об именах, запустите поиск один раз, используйте Ruby для фильтрации нужных результатов. - Использование «node.save» небезопасно, будьте осторожны и осторожны.
Мы столкнулись с этой проблемой, когда развернули кластеры MySQL и использовали node.save внутри рецепта на не полностью настроенном узле MySQL. А во время Scale-up некоторые приложения выдавали ошибку 500. Оказалось, что мы сохранили ноду не в тот момент: она уходит на Chef-сервер, а потом Chef-клиент на UI подхватывает новую ноду, не настроенную на рабочий режим.
- Отсутствие «splay» может убить шеф-сервер.
Splay — это параметр клиента Chef, который позволяет вам установить диапазон, когда клиент обращается к серверу для настройки.
При большой нагрузке, когда нужно развернуть много нод одновременно, это не позволит вам убить сервер.
- Динамическое обеспечение.
SaltStack идеален, потому что у него есть SaltCloud, который идеально интегрируется где угодно.
Puppet имеет аналогичную функциональность, но доступна только в Puppet Enterprise за определенную плату.
Ansible хорошо подходит, если компания «живет» на Amazon, если что-то еще, можно связать его с альтернативами, но это не так удобно.
- СДЛК.
В Chef есть все: от тестовой кухни до набора инструментов интеграционного тестирования.
В SaltStack есть все доступные инструменты Python, а теперь все есть и в Puppet. В Ansible есть спецификация ролей, вы можете использовать Test Kitchen от Chef, но это не встроенный инструмент.
- Замена ресурса.
В Chef все работает хорошо, в SaltStack можно настроить SaltCloud до нужного состояния, в Puppet инструменты есть только в версии Enterprise, а Ansible хорошо работает только с Amazon.
Частное облако EPAM с Chef
За полтора года до появления AWS OpsWorks мы хотели создать расширенную Amazon CloudFormation, интегрировав Chef, чтобы ресурсы не только развертывались, но и настраивались.
Вторая глобальная задача — создать каталог услуг, чтобы клиенты и пользователи могли использовать CLI, например, для развертывания полностью готового к использованию стека LAMP. 
Мы выбрали Chef, но проект должен был поддерживать разные SCM. Мы начали со встроенного Chef-Server, и пользователи также могли использовать свой собственный Chef-Server, который размещается где-то у них дома.
То есть мы не получили доступ к пользовательским ресурсам и ноутбукам, но всё равно работало.
Для реализации CloudFormation + OpsWork можно использовать любой SCM, подойдут все.
Для создания каталога — с этой задачей хорошо справится все, кроме SaltStack. У SaltStack есть некоторые нюансы: найти специалиста, который хорошо знает SaltStack и сможет создать сервис и наполнить каталог, крайне сложно.
Популярность SCM в EPAM
Это статистика популярности SCM в EPAM. SaltStack очень сильно отстает. На первом месте стоит Ansible, он самый простой и имеет низкий барьер входа.
Когда мы пытаемся найти на рынке кого-то со знанием SCM, рынок выглядит примерно так же.
Работа с Ансиблом
Советы, которые я могу дать при работе с Ansible:- Используйте «ускорение», оно разворачивает конфигурации в 2-6 раз быстрее, чем SSH (для el6).
Для всех остальных существует «конвейерная обработка».
Для обратной совместимости он отключен, но включить «конвейерную обработку» обратно очень легко, рекомендую это сделать.
- Используйте «with_items»
- name: project apt dependencies installed apt: name: "{{ item }}" become: yes with_items: - build-essential - acl - git - curl - gnupg2 - libpcre3-dev - python-apt - python-pycurl - python-boto - imagemagick - libmysqlclient-dev # needed for data import
В этом примере мы устанавливаем пакеты, эту схему можно использовать для создания пользователей и подобных операций. - Используйте «local_action» и «делегировано» осторожно.
Первый позволяет получить что-то похожее на SaltStack Runner, второй может делегировать задачи конкретным машинам.
- name: create postgresql database postgresql_db: name: "{{ database_name }}" login_host: "{{ database_host }}" login_user: "{{ database_master_user }}" login_password: "{{ database_master_password }}" encoding: "UTF-8" lc_collate: "en_US.UTF-8" lc_ctype: "en_US.UTF-8" template: "template0" state: present delegate_to: "{{ groups.pg_servers|random}}"
Это статья о создании баз данных.Без последней строки операция будет выполнена несколько раз и завершится неудачно при второй попытке создать ту же самую базу данных.
- Оптимизируйте свои роли и выполнение с помощью тегов.
Это может значительно сократить время выполнения.
выводы
Лично для меня Ansible — мой фаворит. SaltStack очень хорош, очень гибок, но требует знания Python, без которого SaltStack лучше не использовать.Chef — универсальное решение для любой задачи и любого размера, но требует больше знаний, чем Ansible. Я не знаю, кто использует Puppet. В принципе, он очень похож на Chef, но со своими нюансами.
Минута рекламы.Теги: #ИТ-инфраструктура #Системное администрирование #Конференции #DevOps #ansible #puppet #chef #devoops #devoops2017 #saltstackЕсли вам понравился отчет о конференции DevOops — обратите внимание, что 14 октября в Санкт-Петербурге пройдет новое мероприятие DevOps 2018 , в его программе тоже будет много интересного.
На сайте уже есть первые спикеры и доклады.
-
Аммиак
19 Oct, 24 -
Как И Почему Я Отключил Свой Значок
19 Oct, 24 -
Голанг И Ооп
19 Oct, 24
