[Django, IT-инфраструктура, Разработка под Linux, Системное администрирование] Как мы автоматизировали весь жизненный цикл серверов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться.
Если вы ещене читали пост про нашу инфраструктуру, то самое время! После прочтения этого поста я бы хотел рассказать о некоторых внутренних продуктах, которые мы разработали и внедрили.
В нашей компании, как и в любой другой, существуют свои регламенты и бизнес-процессы. Один из них – это тот, по которому мы создаем сервера или стенд серверов по заявке Jira ServiceDesk. У сервера есть функциональный администратор, т.е. владелец. У серверов также имеется статус (Тестовый, Продуктивный, UAT и т.д.). Из-за статусов и других характеристик сервера должны находится в своем сегменте, датацентре, датасторе, сети и прочее. А значит, чтобы создать сервер сначала требуется: создать сервер в VMware, задать ему имя, ip, dns и другие немаловажные параметры, а потом уже прокатить ansible-playbook.
История развития
Я пришел в НСПК в январе 2015 года и работал в ситуационном центре дежурным линуксоидом. В наши основные обязанности входило создавать и настраивать сервера, поддерживать сервера в работоспособном состоянии. Когда система мониторинга показывала какие-то перебои c серверами, обращались к нам. 1-линии поддержки для эскалации требовалась информация о сервере: его назначение, за какую систему отвечает, кому он принадлежит и т.д. В случае срабатывания критичных триггеров в системе мониторинга 1-линия описывала подробную информацию о причинах и состоянии системы. Подробная информация о серверах на тот момент находилась у нас, так как серверами занимались мы. А значит мы также передавали подробную информацию о серверах 1-линии.
Для учета серверов мы использовали excel-файл. Для учета ip использовали phpIPAM https://phpipam.net/. phpIPAM — open source продукт для учета адресным пространством. Еще некоторая информация могла находиться в самой системе мониторинга. Количество серверов насчитывалось не более 700.
В нашем отделе сотрудники отвечают за разные задачи: одни занимаются Виртуализацией и СХД, другие Windows, а мы Linux. Также есть отдел, где находятся сетевые инженеры и администраторы БД.
Создание серверов было не упорядочено. Продуктивные сервера создавались по заявкам, тестовые могли создаваться без них. Сервер создавался вручную. А значит:
1) Требовалось узнать в каком датацентре, датасторе, сети и прочее…
2) Создать сервер в требуемом сегменте через Vcenter
3) Прогнать bash-скрипты и некоторые ansible-playbook’и
4) Добавить корректные данные о сервере в excel-файл
5) Добавить ip в phpIPAM
6) Закрыть заявку, если она была
Через некоторое время стало понятно, требуется создавать все больше и больше серверов. И мы стали искать варианты систем для хранения информации и учета серверов.
На просторах интернета таких систем немало. Даже в phpIPAM можно хранить информацию о серверах. Но в таких системах неудобно смотреть и анализировать состояние серверов в разрезе. В них не было необходимых полей и связей, нет фильтров по полям как в excel, нет четкого разграничения прав на редактирование и просмотр определенных серверов.
Мне тогда нравился Python, и я хотел сделать что-то на Django. Поэтому решил написать свою CMDB для нужд отдела и компании. После ее создания мы решили автоматизировать процесс создания и настройки серверов. Что получилось? Об этом далее…
Мир серверов
Основная система хранения серверов. На данный момент у нас уже больше 5000 серверов. Система постоянно дорабатывается, интегрируется с бизнес-процессами и другими системами.
Так выглядит главная страница:
При переходе на страницу сервера можно посмотреть более подробную информацию, отредактировать поля, посмотреть историю изменений.
Кроме хранения данных о серверах Мир серверов имеет функционал:
- Разграничение прав доступа на просмотр и редактирование данных (по департаменту, по управлению, по отделу)
- Удобный просмотр серверов в табличном виде, фильтр по любым полям, показ/скрытие полей
- Разнообразные оповещения по почте
- Актуализация информации о серверах
- Ежедневный сбор данных о серверах и хранение для аналитики по ресурсам систем
- Поиск и сравнение установленных приложений на серверах
Интеграция Мира серверов с другими системами:
1) Автоматическое обновление ip в phpIPAM
2) Выполнение заявок Jira ServiceDesk на предоставление нового сервера (стенда серверов) через Мир серверов
3) Просмотр расположения физического сервера и правильность заполнения информации в системе dcTrack (https://www.sunbirddcim.com/)
1) Передача информации о серверах через REST API для Zabbix и других систем мониторинга
2) Передача информации о ПО установленного на серверах через REST API для нужд ИБ
3) Синхронизация владельцев серверов из 1С и Active Directory для получения ФИО, рабочей почты, принадлежность к подразделению, статусе сотрудника. Надо написать, что такие данные требуется для разграничения прав, а также для автоматического оповещения владельцев серверов о ряде событий, связанных с их серверами.
DitNet
Наша инфраструктура на данный момент имеет более 10 ЦОД. Из этого понятно, что Мир серверов не сможет в любом сегменте создать и настроить сервер из-за понятных требований PCI-DSS.
Поэтому при выполнении заявок на предоставление сервера мы формируем json с данными, которые требуется для создания в среде VMware. Передача json реализована через защищенный rsync или ftps — зависит от сегмента.
Надо заметить, что наш отдел провел очень большую работу. Убрали bashsible, переработали ansible на идемпотентные роли для настройки серверов, настроили molecule (https://molecule.readthedocs.io/), унифицировали все артефакты VMware и много чего другого. Стандартизация артефактов VMware потребовалась по большей части для серверных подсетей во всех ЦОДах (у нас их уже больше 900).
Как пример:
Раньше Distributed Switch мог называться «test2», а теперь 192.168.1.0|24_test2. Данное переименование требовалось, чтобы можно было на этапе формирования json сделать матчинг подсетей из phpIPAM и VMware.
Выполнение заявок по предоставлению серверов:
1) DitNet ежедневно или по запросу собирает все артефакты из VMware (кластеры, датасторы, сети, шаблоны и т.д). Упаковывает всю информацию в json и отправляет в Мир серверов
2) Мир серверов принимает данные и наполняет данные БД артефактами VMware
3) В Мире серверов имеется страница, которая обращается к Jira ServiceDesk и по jql-запросу получает список заявок на предоставление серверов со статусом «Очередь». На этой странице исполнитель заполняет таблицу артефактами VMware и другими ресурсами (Рис. Ниже). Часть данных автоматически заполняется данными, которые были указаны в заявке.
4) После заполнения и нажатия кнопки «Сотворить», заявка меняет статус в Jira ServiceDesk «В работе»
5) В этот момент Мир серверов формирует json с данными о создании ВМ (артефакты, dns, ip и т.д.) и перекладывает его в папку для своего сегмента (определяется по домену сервера)
6) Каждый DitNet в своем сегменте запрашивает данные из своей папки и обогащает данными таблицу с серверами на установку. В БД имеются дополнительные поля с информацией по статусу установки (по умолчанию: «готов к установке»)
7) На DitNet каждые 5 минут отрабатывает Celery beat, который по статусу установки определяет количество серверов, которые требуется установить и настроить
8) Celery worker запускает несколько последовательных задач:
a. Создает сервер в VMware (используем библиотеку pyvmomi)
b. Скачиваем или обновляем проект gitlab по настройке сервера
c. Запускается Ansible-playbook (используем данный гайд https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html)
d. Запускается Molecule
e. Отправка почты исполнителю и Миру серверов о статусе выполнения
9) После каждой задачи проверяется статус. Если все задачи выполнены – оповещаем исполнителя с сформированной ссылкой для закрытия заявки Jira ServiceDesk. Если какая-нибудь из задач провалилась, то оповещаем исполнителя с логом Vmware или Ansible.
Что еще умеет Ditnet на данный момент:
- Собирает все данные и ресурсы со всех серверов. Для данной задачи мы используем Ansible с модулем setup. На хостах кроме локальных фактов используем также кастомные. Перед каждым запуском формируем инвентарь для Windows и Linux.
- Собирает информацию SNMP о физических серверах. Сканируем определенные подсети и получаем серийный номер, версию BIOS, версия IPMI и т.д.
- Собирает информацию о группах серверов в Freeipa (HBAC, SUDO правила), о группах в Active Directory. Для сбора и контроля ролевой модели доступа пользователей к информационным системам
- Переустановка серверов
- А еще там на заднем фоне котики. Рисунок ниже:
Вся информация, которую собирает DitNet, отправляется в Мир серверов. А там уже и проходит вся аналитика и актуализация данных о серверах.
Как мы обновляемся
В данный момент над Миром серверов и DitNet тружусь уже не только я. Нас уже три человека.
Весь исходный код хранится в наших Gitlab для удобной параллельной разработки. В каждом из проектов имеется свой Ansible-playbook, который запускает Gitlab CI и обновляет приложение. Pipeline:
По pipeline видно, что не хватает unit-тестов. Но, думаю, мы в скором будущем это исправим.
Также Ansible-playbook можно запустить через Ansible Tower (AWX) на новых серверах, если требуется новая инсталляция.
В случае с DitNet мы используем docker, чтобы доставлять нужные библиотеки во все сегменты. Он описан docker-compose. А docker-compose services завернуты в systemd.
Планируется в будущем
- Автоматическое выполнение заявок на установку серверов без исполнителя
- Плановое автоматическое обновление серверов
- Добавление в Мир серверов сущности СХД и автоматический сбор данных
- Сбор информации с физических серверов о всех комплектующих для отправки в Мир серверов для контроля ЗИПа серверов
- Автоматическое оповещение об уходе из компании владельца сервера для последующей привязки серверов к будущему владельцу
- Продолжение интеграции с другими системами компании
…и много еще интересного!
P.S. Спасибо за Ваше время! Критика и комментарии приветствуются!
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование] Zimbra — Генерация HTML подписи на основе данных LDAP
- [Django, Python, Системы сборки] Как в компании развивался Python. Доклад Яндекса
- [Asterisk, IT-инфраструктура, Сетевое оборудование, Сетевые технологии] Обзор IP-телефона Snom D715
- [DevOps, Kubernetes, Системное администрирование] Валидация Kubernetes YAML на соответствие лучшим практикам и политикам (перевод)
- [DIY или Сделай сам, Open source, Разработка на Raspberry Pi, Электроника для начинающих] babooshka tv, как самодельный видео-показатор сместил «точку сборки» моих пожилых родителей
- [IT-инфраструктура, IT-компании, Законодательство в IT, Финансы в IT] Пакистан предложил IT-инвесторам «самую мягкую налоговую систему» в мире
- [IT-инфраструктура, Виртуализация, Резервное копирование] Чего ожидать от бета-версии Proxmox Backup Server
- [DevOps, Open source, Карьера в IT-индустрии, Учебный процесс в IT] Какой совет оказал наибольшее влияние на вашу карьеру в DevOps (перевод)
- [Open source, Системы обмена сообщениями, Управление сообществом, Учебный процесс в IT] 7 open source альтернатив Skype (перевод)
- [Информационная безопасность, Сетевые технологии, Системное администрирование] SIGRed — новая критическая уязвимость в Windows Server. Как защититься?
Теги для поиска: #_django, #_itinfrastruktura (IT-инфраструктура), #_razrabotka_pod_linux (Разработка под Linux), #_sistemnoe_administrirovanie (Системное администрирование), #_mir_plat.form (Мир plat.form), #_nspk (нспк), #_server (сервер), #_servernaja_optimizatsija (серверная оптимизация), #_servera_dlja_bolshoj_nagruzki (сервера для большой нагрузки), #_linux, #_sistemnoe_administrirovanie (системное администрирование), #_itinfrastruktura (ит-инфраструктура), #_infrastruktura (инфраструктура), #_open_source, #_ansible, #_django, #_python, #_blog_kompanii_mir_plat.form_(natsionalnaja_sistema_platezhnyh_kart) (
Блог компании Мир Plat.form (Национальная система платежных карт)
), #_django, #_itinfrastruktura (
IT-инфраструктура
), #_razrabotka_pod_linux (
Разработка под Linux
), #_sistemnoe_administrirovanie (
Системное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:46
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться. Если вы ещене читали пост про нашу инфраструктуру, то самое время! После прочтения этого поста я бы хотел рассказать о некоторых внутренних продуктах, которые мы разработали и внедрили. В нашей компании, как и в любой другой, существуют свои регламенты и бизнес-процессы. Один из них – это тот, по которому мы создаем сервера или стенд серверов по заявке Jira ServiceDesk. У сервера есть функциональный администратор, т.е. владелец. У серверов также имеется статус (Тестовый, Продуктивный, UAT и т.д.). Из-за статусов и других характеристик сервера должны находится в своем сегменте, датацентре, датасторе, сети и прочее. А значит, чтобы создать сервер сначала требуется: создать сервер в VMware, задать ему имя, ip, dns и другие немаловажные параметры, а потом уже прокатить ansible-playbook. История развития Я пришел в НСПК в январе 2015 года и работал в ситуационном центре дежурным линуксоидом. В наши основные обязанности входило создавать и настраивать сервера, поддерживать сервера в работоспособном состоянии. Когда система мониторинга показывала какие-то перебои c серверами, обращались к нам. 1-линии поддержки для эскалации требовалась информация о сервере: его назначение, за какую систему отвечает, кому он принадлежит и т.д. В случае срабатывания критичных триггеров в системе мониторинга 1-линия описывала подробную информацию о причинах и состоянии системы. Подробная информация о серверах на тот момент находилась у нас, так как серверами занимались мы. А значит мы также передавали подробную информацию о серверах 1-линии. Для учета серверов мы использовали excel-файл. Для учета ip использовали phpIPAM https://phpipam.net/. phpIPAM — open source продукт для учета адресным пространством. Еще некоторая информация могла находиться в самой системе мониторинга. Количество серверов насчитывалось не более 700. В нашем отделе сотрудники отвечают за разные задачи: одни занимаются Виртуализацией и СХД, другие Windows, а мы Linux. Также есть отдел, где находятся сетевые инженеры и администраторы БД. Создание серверов было не упорядочено. Продуктивные сервера создавались по заявкам, тестовые могли создаваться без них. Сервер создавался вручную. А значит: 1) Требовалось узнать в каком датацентре, датасторе, сети и прочее… 2) Создать сервер в требуемом сегменте через Vcenter 3) Прогнать bash-скрипты и некоторые ansible-playbook’и 4) Добавить корректные данные о сервере в excel-файл 5) Добавить ip в phpIPAM 6) Закрыть заявку, если она была Через некоторое время стало понятно, требуется создавать все больше и больше серверов. И мы стали искать варианты систем для хранения информации и учета серверов. На просторах интернета таких систем немало. Даже в phpIPAM можно хранить информацию о серверах. Но в таких системах неудобно смотреть и анализировать состояние серверов в разрезе. В них не было необходимых полей и связей, нет фильтров по полям как в excel, нет четкого разграничения прав на редактирование и просмотр определенных серверов. Мне тогда нравился Python, и я хотел сделать что-то на Django. Поэтому решил написать свою CMDB для нужд отдела и компании. После ее создания мы решили автоматизировать процесс создания и настройки серверов. Что получилось? Об этом далее… Мир серверов Основная система хранения серверов. На данный момент у нас уже больше 5000 серверов. Система постоянно дорабатывается, интегрируется с бизнес-процессами и другими системами. Так выглядит главная страница: При переходе на страницу сервера можно посмотреть более подробную информацию, отредактировать поля, посмотреть историю изменений. Кроме хранения данных о серверах Мир серверов имеет функционал:
Интеграция Мира серверов с другими системами: 1) Автоматическое обновление ip в phpIPAM 2) Выполнение заявок Jira ServiceDesk на предоставление нового сервера (стенда серверов) через Мир серверов 3) Просмотр расположения физического сервера и правильность заполнения информации в системе dcTrack (https://www.sunbirddcim.com/) 1) Передача информации о серверах через REST API для Zabbix и других систем мониторинга 2) Передача информации о ПО установленного на серверах через REST API для нужд ИБ 3) Синхронизация владельцев серверов из 1С и Active Directory для получения ФИО, рабочей почты, принадлежность к подразделению, статусе сотрудника. Надо написать, что такие данные требуется для разграничения прав, а также для автоматического оповещения владельцев серверов о ряде событий, связанных с их серверами. DitNet Наша инфраструктура на данный момент имеет более 10 ЦОД. Из этого понятно, что Мир серверов не сможет в любом сегменте создать и настроить сервер из-за понятных требований PCI-DSS. Поэтому при выполнении заявок на предоставление сервера мы формируем json с данными, которые требуется для создания в среде VMware. Передача json реализована через защищенный rsync или ftps — зависит от сегмента. Надо заметить, что наш отдел провел очень большую работу. Убрали bashsible, переработали ansible на идемпотентные роли для настройки серверов, настроили molecule (https://molecule.readthedocs.io/), унифицировали все артефакты VMware и много чего другого. Стандартизация артефактов VMware потребовалась по большей части для серверных подсетей во всех ЦОДах (у нас их уже больше 900). Как пример: Раньше Distributed Switch мог называться «test2», а теперь 192.168.1.0|24_test2. Данное переименование требовалось, чтобы можно было на этапе формирования json сделать матчинг подсетей из phpIPAM и VMware. Выполнение заявок по предоставлению серверов: 1) DitNet ежедневно или по запросу собирает все артефакты из VMware (кластеры, датасторы, сети, шаблоны и т.д). Упаковывает всю информацию в json и отправляет в Мир серверов 2) Мир серверов принимает данные и наполняет данные БД артефактами VMware 3) В Мире серверов имеется страница, которая обращается к Jira ServiceDesk и по jql-запросу получает список заявок на предоставление серверов со статусом «Очередь». На этой странице исполнитель заполняет таблицу артефактами VMware и другими ресурсами (Рис. Ниже). Часть данных автоматически заполняется данными, которые были указаны в заявке. 4) После заполнения и нажатия кнопки «Сотворить», заявка меняет статус в Jira ServiceDesk «В работе» 5) В этот момент Мир серверов формирует json с данными о создании ВМ (артефакты, dns, ip и т.д.) и перекладывает его в папку для своего сегмента (определяется по домену сервера) 6) Каждый DitNet в своем сегменте запрашивает данные из своей папки и обогащает данными таблицу с серверами на установку. В БД имеются дополнительные поля с информацией по статусу установки (по умолчанию: «готов к установке») 7) На DitNet каждые 5 минут отрабатывает Celery beat, который по статусу установки определяет количество серверов, которые требуется установить и настроить 8) Celery worker запускает несколько последовательных задач: a. Создает сервер в VMware (используем библиотеку pyvmomi) b. Скачиваем или обновляем проект gitlab по настройке сервера c. Запускается Ansible-playbook (используем данный гайд https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html) d. Запускается Molecule e. Отправка почты исполнителю и Миру серверов о статусе выполнения 9) После каждой задачи проверяется статус. Если все задачи выполнены – оповещаем исполнителя с сформированной ссылкой для закрытия заявки Jira ServiceDesk. Если какая-нибудь из задач провалилась, то оповещаем исполнителя с логом Vmware или Ansible. Что еще умеет Ditnet на данный момент:
Вся информация, которую собирает DitNet, отправляется в Мир серверов. А там уже и проходит вся аналитика и актуализация данных о серверах. Как мы обновляемся В данный момент над Миром серверов и DitNet тружусь уже не только я. Нас уже три человека. Весь исходный код хранится в наших Gitlab для удобной параллельной разработки. В каждом из проектов имеется свой Ansible-playbook, который запускает Gitlab CI и обновляет приложение. Pipeline: По pipeline видно, что не хватает unit-тестов. Но, думаю, мы в скором будущем это исправим. Также Ansible-playbook можно запустить через Ansible Tower (AWX) на новых серверах, если требуется новая инсталляция. В случае с DitNet мы используем docker, чтобы доставлять нужные библиотеки во все сегменты. Он описан docker-compose. А docker-compose services завернуты в systemd. Планируется в будущем
P.S. Спасибо за Ваше время! Критика и комментарии приветствуются! =========== Источник: habr.com =========== Похожие новости:
Блог компании Мир Plat.form (Национальная система платежных карт) ), #_django, #_itinfrastruktura ( IT-инфраструктура ), #_razrabotka_pod_linux ( Разработка под Linux ), #_sistemnoe_administrirovanie ( Системное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:46
Часовой пояс: UTC + 5