Как мы автоматизировали весь жизненный цикл серверов

    Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться.


    Если вы еще не читали пост про нашу инфраструктуру, то самое время! После прочтения этого поста я бы хотел рассказать о некоторых внутренних продуктах, которые мы разработали и внедрили.


    image


    В нашей компании, как и в любой другой, существуют свои регламенты и бизнес-процессы. Один из них – это тот, по которому мы создаем сервера или стенд серверов по заявке 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 серверов. Система постоянно дорабатывается, интегрируется с бизнес-процессами и другими системами.
    Так выглядит главная страница:


    image


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


    image


    Кроме хранения данных о серверах Мир серверов имеет функционал:


    • Разграничение прав доступа на просмотр и редактирование данных (по департаменту, по управлению, по отделу)
    • Удобный просмотр серверов в табличном виде, фильтр по любым полям, показ/скрытие полей
    • Разнообразные оповещения по почте
    • Актуализация информации о серверах
    • Ежедневный сбор данных о серверах и хранение для аналитики по ресурсам систем

    image


    • Поиск и сравнение установленных приложений на серверах


    Интеграция Мира серверов с другими системами:


    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. Для сбора и контроля ролевой модели доступа пользователей к информационным системам
    • Переустановка серверов
    • А еще там на заднем фоне котики. Рисунок ниже:

    image


    Вся информация, которую собирает DitNet, отправляется в Мир серверов. А там уже и проходит вся аналитика и актуализация данных о серверах.


    Как мы обновляемся


    В данный момент над Миром серверов и DitNet тружусь уже не только я. Нас уже три человека.
    Весь исходный код хранится в наших Gitlab для удобной параллельной разработки. В каждом из проектов имеется свой Ansible-playbook, который запускает Gitlab CI и обновляет приложение. Pipeline:


    image


    По pipeline видно, что не хватает unit-тестов. Но, думаю, мы в скором будущем это исправим.
    Также Ansible-playbook можно запустить через Ansible Tower (AWX) на новых серверах, если требуется новая инсталляция.


    В случае с DitNet мы используем docker, чтобы доставлять нужные библиотеки во все сегменты. Он описан docker-compose. А docker-compose services завернуты в systemd.


    Планируется в будущем


    • Автоматическое выполнение заявок на установку серверов без исполнителя
    • Плановое автоматическое обновление серверов
    • Добавление в Мир серверов сущности СХД и автоматический сбор данных
    • Сбор информации с физических серверов о всех комплектующих для отправки в Мир серверов для контроля ЗИПа серверов
    • Автоматическое оповещение об уходе из компании владельца сервера для последующей привязки серверов к будущему владельцу
    • Продолжение интеграции с другими системами компании
      …и много еще интересного!

    P.S. Спасибо за Ваше время! Критика и комментарии приветствуются!

    Комментарии 12

      0

      Всё замечательно, сверху. А снизу? Когда вы последний раз обновляли прошивку у процессора? (А там, между прочим, конкретные уязвимости, актуальные для платёжной системы, каждые несколько месяцев новые). А у BMC? Вы уверены, что ваш impi/drac/ilo не светит наружу wormable cve с эскалацией до админа BMC? Кто следит за логами рейд-контроллера?

        0
        Я люблю слово wormable.
          0

          червячная передача, всё такое.

          0
          Обновление прошивок, как и ОС, происходит на периодической основе.
          Версии прошивок тоже централизованно собираются и анализируются на наличие известных уязвимостей, обновляются регулярно, хоть и в ручном режиме.
          Все события, включая IPMI, отправляются и анализируются в SIEM.
          Все логи приходят в системы мониторинга и аналитики.
          В нашем случае, у нас полная автоматизация цикла виртуальной фермы серверов.
            0

            Меня в этом смысле смущает слово "виртуальная". Virtual или baremetal? Я не уверен, что имеет смысл обновлять прошивки ipmi на виртуальных серверах.

          0
          Насколько понял, удаляете данные о ресурсах вручную т.к. есть опасность сформироать jsonку не туда. В vmware ведь вроде есть встроенные средства учета VM и описание можно добавить, интересно как тут прошла интеграция вашего софта и как мы знаем при обновлении версии очень часто это апи ломается.
          Также хочется узнать, какие именно вы используете сервера HP, DELL, SuperMicro — ведь там разные средства для удаленной диагностики и не все данные можно забрать по snmp.
            +1
            Удаляем VM вручную. Учет не делали через VMWare по причине того, что у нас имеются и физические сервера. А хотелось сделать универсально для всего. Поэтому учет серверов реализован через ansible. С api больших проблем не наблюдали, при изменениях в инфраструктуре тестируем.
            Все верно, у snmp ограниченные возможности. Но у ipmi есть REST API, поэтому планируем в ближайшее время перейти на него.
            0
            вот прям отдельное спасибо за phpIPAM. не знал про него. с ходу написали docker-compose, подняли под traefik и полетели на него переводить тонну экселевских файликов по объектам. дико удобно. и апи не может не радовать. думаю как заведем базу, начнем тыкать в апи палкой.
              +2

              а netdisco/opennms не смотрели? с первого взгляда похоже, но эти двое умеют автоматически находить что есть в сети (по lldp).

                0
                не смотрел. теперь посмотрел, спасибо.
                но и то и другое — скорее системы мониторинга и нотификации. а у нас для этого забикс.
                нужна была именно система учета — БД, в которую удобно вносить, удобно искать и в целом сразу видеть где сколько ипов занято (и зачем).
                а вот ее (phpIPAM) апи возможно даст некую автоматизации между ней и тем же заббиксом, к примеру.
                еще не копал в эту сторону, но в планах.
                  0
                  кстати, делюсь своим docker-compose (1 и 2), может кому надо…
                  там +1 контейнер для настройки ДНС записи на сервере с ISPManager Pro
                    0
                    но и то и другое — скорее системы мониторинга и нотификации.

                    мониторинг там побочная функция, это системы инвентаризации сети.

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

              Самое читаемое