Блог

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

К сожалению, в настоящее время не все из нас смогли заменить наше «устаревшее» сетевое оборудование на все новые сетевые продукты, которые поставляются с API, потоковой телеметрией и т. д., которые помогают нам программно взаимодействовать с нашей сетью.

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

• Шаблоны NTC с использованием TextFSM
• Genie Parser от Cisco PyATS
• Ansible Native Parser
• Плагин настраиваемого фильтра Ansible
• NAPALM  геттеры
• Анализатор текста шаблона (TTP)

В этой серии статей мы подробнее рассмотрим, «как» анализировать неструктурированные данные.

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

Зачем мне нужны структурированные данные из моего интерфейса командной строки?

Синтаксический анализ – это акт перевода языка (неструктурированные данные, которые люди могут легко прочитать) на другой язык (структурированные данные, которые компьютер может легко прочитать). Ниже приведен пример того, как мы выполняем некоторую форму проверки неструктурированных данных:

>>> unstructured_data = """
... Capability codes:
...     (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
...     (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
... 
... Device ID           Local Intf     Hold-time  Capability      Port ID
... S2                  Fa0/13         120        B               Gi0/13
... Cisco-switch-1      Gi1/0/7        120                        Gi0/1
... Juniper-switch1     Gi2/0/1        120        B,R             666
... Juniper-switch1     Gi1/0/1        120        B,R             531
... 
... Total entries displayed: 4
"""
>>> neighbors = [
...     "S2",
...     "Cisco-switch-1",
...     "Juniper-switch1",
]
>>> for neighbor in neighbors:
...     if neighbor in unstructured_data:
...         print(f"{neighbor} on router")
S2 on router
Cisco-switch-1 on router
Juniper-switch1 on router
>>> neighbors = [
...     {"name": "S2", "intf": "Fa0/13"},
...     {"name": "Cisco-switch-1", "intf": "Gi1/0/7"},
...     {"name": "Juniper-switch1", "intf": "Gi2/0/1"},
...     {"name": "Juniper-switch1", "intf": "Gi1/0/1"},
... ]
>>> for neighbor in neighbors:
...     for cfg_line in unstructured_data.splitlines():
...         if neighbor["name"] in cfg_line and neighbor["intf"] in cfg_line:
...             print(f"Neighbor {neighbor["name"]} is seen on {neighbor["intf"]}")
Neighbor S2 is seen on Fa0/13
Neighbor Cisco-switch-1 is seen on Gi1/0/7
Neighbor Juniper-switch1 is seen on Gi2/0/1
Neighbor Juniper-switch1 is seen on Gi1/0/1

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

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

• Возможность хранить структурированные данные в базе данных временных рядов (TSDB) для телеметрии и аналитики, которые могут помочь вам быстро определить основную причину проблемы, с которой сталкивается сеть.
• Выполните определенные действия в зависимости от операционных данных, полученных с устройства, например, отключение интерфейса или включение однорангового узла BGP.
• Убедитесь, что каждое устройство совместимо с операционной системой, например, определите, что каждое устройство видит правильных соседей на каждом из своих интерфейсов.

Резюме

Каждая из следующих публикаций будет работать с неструктурированными данными LLDP, полученными от маршрутизаторов csr1000v и используемыми для утверждения, что соседи, которые видит устройство, являются допустимыми соседями в соответствии с переменной, которую мы определим в следующем сообщении. Это поможет определить, каких соседей мы ожидаем увидеть подключенными к каждому маршрутизатору. Мы захотим провести две разные проверки; что каждый сосед – это то, что мы ожидаем увидеть, и что нет никаких дополнительных соседей, которых мы не ожидаем увидеть.

После прочтения этих сообщений вы сможете анализировать любые неструктурированные данные, полученные с устройств, в структурированные данные, которые имеют значение для вас на пути к автоматизации сети!

 

Атомарность в компьютерных науках

Проще говоря, атомарная операция гарантирует, что действие полностью завершится успешно или полностью завершится неудачей. Если пойти дальше, приведенная цитата обеспечивает контекст и точность для описания принципа в правильной терминологии:

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

Атомарность – это гарантия изоляции от параллельных процессов. Кроме того, атомарные операции обычно имеют определение «успех или сбой» – они либо успешно изменяют состояние системы, либо не имеют видимого эффекта.

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

В информатике атомарность часто ассоциируется с базами данных и представляет собой букву «A» в ACID, которая описывает набор свойств для транзакций базы данных.

Пример

Типичный пример, используемый для иллюстрации эффекта этого принципа, — перевод денег с одного счета на другой. При переводе 100 долларов со счета Боба на банковский счет Салли было бы катастрофой, если бы деньги были удалены со счета Боба, но не зачислены на счет Салли для Боба и Салли, поскольку это привело бы к потере 100 долларов Салли. Транзакция была бы столь же проблематичной, если бы деньги были добавлены на счет Салли, но не были удалены со счета Боба в банке.

Достижение атомарности

Есть несколько механизмов для достижения атомарности, но для простоты основное внимание будет уделено блокировке. В упрощенном виде это можно увидеть как:

• Определите места в памяти, к которым будет осуществляться доступ.
• Создавайте замки на каждой локации.
• Выполните линейный набор транзакций и сохраните их в новом месте памяти.
• Дождитесь завершения всех транзакций.
• В одной транзакции поменяйте местами памяти.

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

Атомарные операции в Python

Официальная документация Python дает представление о том, какие операции являются / не являются атомарными.

Довольно интересно отметить, что даже присвоение переменных не гарантирует безопасность и атомарность.

Атомарная операция в сети

При использовании традиционного интерфейса командной строки Cisco IOS линейное применение конфигураций может быть проблематичным. Возьмем, к примеру, создание VTY ACL. Добавление одной строки в новый ACL может привести к неявному отказу и потенциально заблокировать оператор. Естественно, возможность атомарного применения конфигураций имеет очевидные преимущества.

К счастью, по крайней мере с 2007 года появилась функция, называемая «настройка замены», которая заменяет всю конфигурацию Cisco IOS. Более того, это используется в библиотеке NAPALM Python. Чтобы проиллюстрировать эффект, первая попытка не удастся протолкнуть конфигурации и продемонстрировать правильный откат, а вторая попытка будет работать, как задумано.

Первоначально «предполагаемая» конфигурация будет содержать эту надуманную неправильную конфигурацию.

vlan 499
 name printers
!
vlan 5000
 name users

Ошибочно введенный VLAN 5000 вместо 500 будет проблематичным. Давайте посмотрим, как реагирует NAPALM.

>>> import getpass
>>> from napalm import get_network_driver
>>> driver = get_network_driver('ios')
>>> hostname = 'ios-sw1'
>>> username = 'ntc'
>>> password = getpass.getpass()
Password:
>>> device = driver(hostname, username, password)
>>> device.open()
>>> device.load_replace_candidate(filename='ios-sw1')
>>> device.compare_config()
'+vlan 499\n  +name printers\n+vlan 5000\n +name users'
>>> device.commit_config()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/napalm/ios/ios.py", line 533, in commit_config
    raise ReplaceConfigException(msg)
napalm.base.exceptions.ReplaceConfigException: Candidate config could not be applied
Command rejected: Bad VLAN list - character #5 (EOL) delimits a VLAN
number which is out of the range 1..4094.
Failed to apply command vlan 5000
Aborting Rollback.

Rollback failed.Reverting back to the original configuration: flash:-Dec-14-13-05-59.491-0 ...

Total number of passes: 1
Rollback Done

The original configuration has been successfully restored.

>>>

Как видите, сравнение конфигурации указывает на попытку добавить сети VLAN 499 и 5000. Однако при попытке фиксации конфигурации конфигурация прерывается со следующим сообщениемCommand rejected: Bad VLAN list - character #5 (EOL) delimits a VLAN number which is out of the range 1..4094. Сбой вызывает откат и гарантирует, что обе сети VLAN не будут созданы.

Обновление VLAN 5000 до правильного VLAN 500 и повторный запуск процесса приводят к успешной операции.

>>> device = driver(hostname, username, password)

>>> device.open()

>>> device.load_replace_candidate(filename='ios-sw1')

>>> device.compare_config()

'+vlan 499\n  +name printers\n+vlan 500\n +name users'

>>> device.commit_config()

>>>

Это можно дополнительно проверить на коммутаторе, просмотрев конфигурацию.

vlan 499

 name printers

!

vlan 500

 name users

Хотя процессу «конфигурирования и замены», вероятно, не хватает целостности, присущей базе данных PostgreSQL или MySQL, он в значительной степени эффективен при создании атомарной операции.

Заключение

Атомарная операция, как правило, более безопасна и подразумевает ваше намерение, за исключением редких случаев использования. В базах данных это часто обрабатывается транзакциями, и на практике создание собственных атомарных действий часто требует блокировок. Возможно, Йода может лучше всего описать атомарность своей цитатой: «Делай или не делай. Нет никакой попытки ».

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

• Люди – часть системы. Дизайн должен соответствовать опыту, ожиданиям и ментальным моделям пользователя.
• Компонент принципа означает, что компонент системы должен вести себя так, как ожидает большинство пользователей; поведение не должно удивлять или удивлять пользователей.

Приведу несколько надуманных примеров:

• Вызываемая функция add_vlan()не должна настраивать все порты коммутатора для этой VLAN.
• Выполнение команды switchport trunk allowed vlan add 100не должно удалять другие сети VLAN из порта.
• Добавление строки в таблицу базы данных не приводит к удалению таблицы и ее воссозданию.

Приложение в реальном мире

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

Даже десятилетия спустя Windows XP, хотя и устарела, по-прежнему хвалится своим дизайном. Это в значительной степени связано с тем, что каждое приложение в системе следовало одним и тем же правилам. Всегда существовала одна верхняя панель навигации, которая подчеркивала букву, обозначающую сочетание клавиш. Позже офис Microsoft представит ленту вместо этой стандартной панели навигации и уберет индикатор подчеркивания. По отдельности вы можете утверждать, что новые системы лучше, но в целом у пользователя нет единого мнения.

Посмотрите этот пример:

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

Приложение для сетевой автоматизации

Хотя стиль рендеринга read the docs, который является реализацией sphinx, не совсем специфичен для сетевой автоматизации, он стал своего рода стандартом де-факто в отрасли. В любом конкретном случае, я подозреваю, что пользовательский интерфейс лучше, но если вы привыкли ко многим инструментам, используемым в сетевой автоматизации, таким как NetBox, NAPALM или библиотекам Ansible и Python, таким как Requests, Flask и netaddr, то тогда у вас будет согласованная структура и компоненты снижают барьер для входа и устанавливают ожидания для пользователей.

Заключение

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

 

Начало пути к автоматизации может показаться непосильной задачей. Мы часто слышим вопросы от наших клиентов, например: «С чего мне начать?» или «Как я могу убедиться, что с самого начала строю платформу правильно?» Всем отличные вопросы. Тем не менее путешествие – ключевое слово, когда дело доходит до автоматизации вашей сети. В этом сообщении в блоге я подробно расскажу о некоторых ключевых выводах, которые я обнаружил в последние несколько месяцев в рамках усилий по развитию бизнеса в Network to Code, и о том, как наши клиенты успешно внедряют эти изменения в своих средах.

Один из общих разговоров, которые мы ведем с новыми и существующими клиентами, связан с повторяемыми вручную рабочими процессами. Например, частый случай использования, с которым мы часто сталкиваемся, — это запрос на изменение политики брандмауэра. Во многих организациях есть ручной процесс, который затрагивает несколько команд и источников данных и может занять несколько недель. В сочетании с десятками запросов в неделю / месяц это создает огромную нагрузку на команду инженеров. Более того, эта проблема напрямую мешает бизнесу, поскольку сильно влияет на скорость выхода на рынок. Вариант использования запроса на изменение может показаться довольно простым с точки зрения решения. Однако, начав снимать слои, вы понимаете, что, вероятно, потребуется несколько инструментов. Например, ITSM может быть отправной точкой для отправки и отслеживания запроса,

Кроме того, данные, необходимые для автоматизации изменений, могут находиться в различных системах или таблицах. Вдобавок ко всему, для индивидуальной работы часто требуются базовые знания программирования для интеграции различных API-интерфейсов продуктов. Как насчет определения того, какие брандмауэры попадают в область действия изменения – следует ли делать вывод на основе данных об изменении, представленных в заявке? Часто именно здесь проявляется подавляющая эмоция, когда выявляются пробелы в знаниях о ресурсных продуктах.

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

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

С чего бы мне начать?

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

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

Как я могу убедиться, что с самого начала строю платформу правильно?

Обратиться за помощью к специалистам – отличный способ начать. Вместо того чтобы изобретать колесо, обратитесь к организации, которая имеет бесчисленные часы опыта внедрения рабочих процессов автоматизации в аналогичных средах. Другой вариант – использовать сообщество разработчиков ПО с открытым исходным кодом, чтобы задавать вопросы и находить отличные статьи и видео по определенной теме. Как правило, люди готовы помочь или, по крайней мере, указать вам правильное направление.

Как я могу доказать руководству, что нам нужна автоматизация?

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

 

Лично я очень увлечен принципами и определениями автоматизации / программирования. Во многом это потому, что я потратил так много времени на трудные вещи, даже не подозревая об этом. Не имея экспертной оценки и предоставленный самому себе, я только когда-либо создавал решение для решения текущей проблемы, никогда не строил структуру, на которой можно было бы построить. Изучение этих концепций коренным образом изменило мой образ мышления и программирования.

Цель этого сообщения – объявить о нашем намерении создавать контент, выпускаемый нерегулярно, и объединять ссылки на соответствующие блоги по мере их создания.

Принципы

Вы можете заметить, что это не все строгие принципы…. Что ж, вы были бы правы, но они следуют духу того, что здесь подразумевается, что дает читателю контекст, чтобы избежать ошибок.

• Атомарность

• Декларативный / Императивный

• Нормализация данных

• Моделирование данных

• СУХОЙ (Не повторяйся)

• Наследование

• Идемпотент

• Мутабельный против неизменяемого

• Принцип наименьшего удивления

• Принцип устойчивости

• Мифический человеко-месяц

• ЯГНИ (Вам это не понадобится) / Преждевременная оптимизация

 

 

Что такое жизнеспособность?

Если мы собираемся говорить о минимально жизнеспособном продукте для достижения ваших целей NetDevOps, нам нужно поговорить о концепции жизнеспособности в программном проекте. В частности, для наших сценариев использования NetDevOps под жизнеспособностью понимается продукт или решение, которое может обеспечить требуемый результат последовательно и в автоматическом режиме. Например, предположим, что ваша первоначальная цель – программно управлять резервированием и развертыванием VLAN на коммутаторах в ваших центрах обработки данных. Жизнеспособным решением этой проблемы было бы не просто зарезервировать VLAN, но также потребовалось бы развернуть конфигурацию на самих коммутаторах. Решение не будет считаться жизнеспособным, если будет достигнута только половина этой цели, возможно, просто назначение VLAN, но не конфигурация.

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

Многие проекты, предпринятые инженерами, занимающимися сетевой автоматизацией и NetDevOps, быстро переходят ко второму примеру и пытаются «вскипятить океан». Я был виноват в этом в прошлом, и, получив возможность снова выполнить некоторые из моих первых проектов автоматизации, я бы резко сократил объем и сосредоточился на предоставлении краткого и успешного результата для одного варианта использования. Затем, когда я заложил основу для своего MVP, я смог развить этот успех для быстрого масштабирования для решения дополнительных вариантов использования или рабочих процессов.

Определение минимально жизнеспособного продукта

Признавая, что создание MVP и его итерация является успешной стратегией создания платформы и инструментов NetDevOps, один из часто задаваемых вопросов: «Как вы оцениваете минимально жизнеспособный продукт?» Хотя каждая сеть в чем-то отличается, вот несколько простых идей, которые помогут вам определить минимально жизнеспособный продукт для применения методологий NetDevOps в вашей сетевой инфраструктуре. Если вы уже хорошо освоили внедрение концепций NetDevOps в своей сети, возможно, каждый раз, когда вы смотрите на включение дополнительного рабочего процесса в свои процессы, учитывайте приведенное ниже и планируйте его соответствующим образом. Хотя это ни в коем случае не является авторитетным планом, он предназначен для представления некоторых идей и концепций, которые следует учитывать при размышлениях о минимально жизнеспособном продукте на пути к NetDevOps.

Начни с малого

Возможно, в вашей сети всего 50 устройств, а может быть, в вашей сети 50 000. В любом случае вы всегда должны начинать с малого. Выберите несколько сетевых устройств, которыми вы можете манипулировать по своему желанию. При определении того, что ваш минимально жизнеспособный продукт решит для данной проблемы, подумайте, без какой части сети вы могли бы жить. Если ответить на вопрос: «Что будет, если я отключу эти устройства?» заставляет вас потеть, вероятно, не запускайте на этих устройствах.

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

Маленький – это не такой же простой

Оцените технологии, которые вам понадобятся для выполнения этого плана, и начните создавать их. Помните, что мы «начинаем с малого» и создаем минимально жизнеспособный продукт, не означает, что у нас нет потенциала для значительных усилий.

Возможно, вам понадобится:

• Приобретайте виртуальные машины Linux для промежуточных узлов, сред разработки и серверов приложений.
• Создайте / настройте инструмент CI / CD, такой, как Jenkins.
• Настройте локальный сервер Git для хранения вашего кода, конфигураций и любых других данных, требующих контроля версий.
• Проведите инвентаризацию устройства или Источника истины, например NetBox.
• Настройте сервер Ansible AWX для выполнения созданных вами сценариев.

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

Масштабирование быстро

Когда вы создали инструментальные средства для успешного управления портами коммутатора на вашей первоначальной партии устройств, вы можете начать расширять свою область действия, включив в нее дополнительные туалеты / этажи / здания во все возрастающих партиях. Я обнаружил, что, начиная с группы из 10–15 устройств и примерно удваивая это общее количество каждый раз, когда вы чувствуете себя комфортно для автоматизации против большего количества устройств, можно быстро передать даже самые большие группы устройств под управление инструментария NetDevOps.

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

MVP Включить тесты

Предположим, вы настроили инструменты для автоматического применения известной «золотой» конфигурации к портам коммутатора ваших пользователей; однако новая версия операционной системы сетевого устройства использует немного другой синтаксис. Откуда вы знаете, что это проблема, прежде чем нарушить доступ к сети для тысяч пользователей? Тестирование, тестирование, тестирование !

Даже если вы создаете что-то простое и небольшое, вы должны включать тесты как на уровне кода (модульные тесты), так и на уровне сети (интеграционное тестирование). Наличие хорошо продуманного, автоматизированного и полностью реализованного плана тестирования абсолютно необходимо для того, чтобы можно было доверять вашей инфраструктуре, процессам и рабочим процессам NetDevOps. Без тестирования вы просто надеетесь, что в вашей сети ничего не изменится, и все мы знаем, что это просто принятие желаемого за действительное.

Минимально жизнеспособный продукт

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

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

В этом посте мы собираемся погрузиться в концепцию инфраструктуры как кода или IaC и как ее можно применить в вашей сети.

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

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

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

Основы инфраструктуры как код

Чтобы построить решение NetDevOps на основе «Инфраструктура как код» в вашей собственной сети, важно понимать ключевые базовые компоненты, или столпы, «Инфраструктура как код». Твердое понимание основных компонентов, их взаимодействия и того, какие инструменты и какие компоненты принадлежат, позволит вам создать мощное и надежное решение IaC в вашей среде.

Инфраструктура как код обычно строится на четырех основных столпах.

1. Источник истины (SoT) – SoT часто представляет собой комбинацию следующих компонентов:
   • Системы контроля версий, иногда также называемые системой контроля версий, для поддержки текстовых файлов, представляющих конфигурацию элементов вашей инфраструктуры.
   • Системы записи , которые могут быть инструментами базы данных управления конфигурацией (CMDB) или управления инвентаризацией центра обработки данных (DCIM), например ServiceNow CMDB или NetBox.
2. CI / CD – CI / CD означает непрерывную интеграцию и непрерывное развертывание или доставку и описывает системы, используемые для управления и выполнения изменений или развертывания вашей инфраструктуры.
3. Тесты – тесты позволяют вам двигаться вперед с уверенностью, что изменения, выполненные в этом процессе, будут успешными и не вызовут нежелательных или непреднамеренных изменений в вашей инфраструктуре.
4. Инструменты развертывания и настройки – эти инструменты разнообразны и могут принимать разные формы в зависимости от создаваемой системы IaC. Для NetDevOps это часто будут инструменты или системы, которые могут взаимодействовать с уровнем управления сетью (через SSH или HTTPS) для внесения изменений.

Если бы мы строили Инфраструктуру как «дом» Кодекса, считайте Источник Истины чертежами. Система CI / CD – это прораб или генеральный подрядчик, наблюдающий за строительством, а тестеры – это строительный инспектор. Вашими инструментами развертывания и настройки являются электрик, сантехник и плотник, которые строят дом!

Существует множество потенциальных комбинаций инструментов Source of Truth, CI / CD, тестирования и развертывания, поэтому не беспокойтесь, если возможности поначалу кажутся ошеломляющими. Например, Source of Truth и CI / CD будут иметь целые статьи в этой серии. Чтобы лучше познакомиться с доступными вам инструментами, в конце этого поста мы собрали приложение под названием «Lay of the Land» с инструментами в каждом из этих столпов и ссылками для дальнейшего исследования.

Пример действия столпов

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

Система, построенная на этих основах, часто использует файлы конфигурации и метаданных, хранящиеся в системе контроля версий, такой как Git, для генерации конфигураций устройств на основе фактов, хранящихся в системе записи / DCIM, такой как NetBox. Вместе эти элементы образуют Источник истины для части инфраструктуры. Инженеры вносили изменения в файл или файлы в Git, чтобы описать желаемые изменения состояния инфраструктуры. Прежде чем эти изменения будут внесены в инфраструктуру, они потребуют экспертной оценки и прохождения любых тестов, запускаемых системой CI / CD.

Когда эти предлагаемые изменения вносятся в соответствующую область вашего Источника истины, инструмент CI / CD, такой как Jenkins, обнаружит изменения или получит уведомление об этих изменениях. Затем инструмент CI / CD выполнит серию шагов (часто называемых «конвейером»), чтобы должным образом протестировать эти предлагаемые изменения в инфраструктуре.

Внутри конвейера тесты выполняются до того, как будут внесены какие-либо изменения в инфраструктуру, чтобы проверить их потенциал для успеха и любое влияние, которое они могут вызвать. Простые тесты обычно используются для проверки (или « lint ») того, что сами измененные файлы синтаксически и логически действительны. Кроме того, в конвейере Network IaC тесты часто запускаются с помощью такого инструмента, как Batfish.который может анализировать и понимать конфигурацию сетевого устройства. Эти расширенные тесты позволяют убедиться, что потенциальные изменения не повлияют на неожиданный элемент вашей сети. Они позволяют вам, прежде чем касаться самой сети, быть уверенным, что эти изменения не вызовут неблагоприятного воздействия или непреднамеренных изменений политики безопасности. Пройден или не пройден, статус этих тестов возвращается в Git для отображения или может быть передан на платформу чата, такую ​​как Slack.

Если тесты прошли успешно, и в этом примере изменения утверждены и объединены в Git, изменения можно будет реализовать с помощью инструмента развертывания, такого как Terraform или Ansible (или оба), или даже простой Python. Этот шаг не обязательно должен происходить немедленно, и конвейер в вашем инструменте CI / CD можно легко заставить ждать, пока не появится заранее определенное окно изменений, чтобы выполнить отложенные изменения. Как только конвейер будет готов к развертыванию изменений или самой инфраструктуры, средство развертывания развернет или настроит элементы вашей инфраструктуры на основе изменений, записанных, утвержденных и протестированных из Источника истины.

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

Сетевая инфраструктура как код

Если говорить конкретно о внедрении инфраструктуры как кода в мир NetDevOps, можно выделить два общих типа сценариев использования.

Первый тип использует IaC для развертывания самой виртуальной сетевой инфраструктуры. Это может включать, например, автоматическое выделение ресурсов AWS VPC для завершения работы VPN в вашей организации или запуск виртуального брандмауэра в ESX.

Второй тип – использование IaC для развертывания конфигураций в существующей сетевой инфраструктуре (включая физическое оборудование). Это может быть сохранение списка ваших одноранговых узлов BGP в файле в системе управления версиями, а затем применение соответствующей конфигурации к маршрутизаторам в вашей сети при внесении изменений в этот файл.

Выбор того, над какой из этих двух областей вы хотите работать в первую очередь, будет зависеть от вас, хотя чаще всего в корпоративных сетях мы видим, что предпринимается позднее (настройка физического оборудования), поскольку это самая большая возможность повлиять на повседневную дневные операции. Устранение необходимости вручную настраивать VLAN и простое внесение изменений в файл в системе управления версиями с помощью инструмента CI / CD, выполняющего все остальное, является чрезвычайно привлекательным для многих организаций.

 

Приложение: Lay of the Land

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

Во-вторых, некоторые инструменты (такие как Github или GitLab) представлены в нескольких столбцах ниже, поскольку они предоставляют несколько областей функциональности. Это происходило чаще в последние несколько лет, поскольку, например, более тесная интеграция Source Control и CI / CD стала стандартными функциями. Ничего не написано на камне, что просто потому, что вы используете GitHub для управления версиями, вы также должны использовать его для CI / CD. Оценивайте каждый инструмент, основываясь на его сильных сторонах, а также на вашем опыте / знакомстве с ним.

Источник Истины

Учитывая, что на практике Источник истины обычно собирают из нескольких мест, я разбил его ниже на разделы для управления версиями и для систем записи. Соответствующими системами записи в корпоративной среде часто являются инструменты CMDB / DCIM (база данных управления конфигурацией / управление инфраструктурой центра обработки данных), поэтому они описаны ниже.

Управления источником

Хотя Git, безусловно, является наиболее часто используемой системой управления версиями (с множеством различных служб и реализаций, как показано ниже), полезно также понимать некоторые другие доступные инструменты управления версиями.

• Git
  • GitHub и GitHub: предприятие
  • GitLab
  • BitBucket
  • Azure Repos
  • AWS CodeCommit
• SVN – Apache Subversion
• CVS – Система одновременных версий
• Mercurial

 

Система записи

Часто в категории «Система записи» их может быть несколько внутри крупной организации. Не все элементы сетевой инфраструктуры представлены в каждой системе, и некоторые из них могут синхронизировать данные между собой. Кроме того, хотя CMDB или DCIM служат разным целям в среде, данные, которые они могут иметь, частично совпадают, и, таким образом, они могут выполнять часть той же роли в инфраструктуре, что и развертывание кода. Некоторые крупные предприятия даже создали свои собственные инструменты DCIM или CMDB, и степень интеграции с этими инструментами будет широко варьироваться.

• NetBox
• ServiceNow CMDB
• Device42
• Служба поддержки SolarWinds
• RackTables
• ManageEngine Asset Explorer

 

CI / CD

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

• Jenkins
• Travis CI
• CircleCI
• GitLab
• GitHub
• AWS CodePipeline
• Azure Pipelines

 

Инструменты развертывания и настройки

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

• Terraform
• Puppet
• Ansible
• SaltStack
• AWS CloudFormation

Стоит отметить, что существует ряд инструментов / библиотек Python, которые обычно используются (часто в комбинации) для создания собственных инструментов конфигурации для сетевого оборудования:

• Nornir
• Napalm
• Netmiko

 

Инструменты и фреймворки для тестирования

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

Во-первых, это инструменты, которые статически проверяют / проверяют сами файлы конфигурации или кода. Это означает, что инструменты, которые проверяют содержимое каждого файла и гарантируют, например, что файл, заявленный как формат YAML, действительно является действительным YAML.

• YAMLLint
• Schema JSON
• Black

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

• EVE NG
• GNS3

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

• BatFish

 

По мере того как сетевая индустрия переходит на NetDevOps, часто используется много терминов, с которыми сетевые специалисты не знакомы. Это может привести к тому, что многие люди не будут уверены в том, какую роль новая технология может сыграть в их организации, или даже будут бояться просить ясности по обсуждаемой концепции. Фактически, есть несколько вопросов, которые нам задают снова и снова.

«Что такое CI / CD, зачем ему конвейер и какое отношение он имеет к моей сети?»

“Что означает IaC или SoT?”

Или даже: «Что такое NetDevOps и почему меня это должно волновать?»

Что такое NetDevOps?

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

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

• Непрерывная интеграция / непрерывное развертывание (CI / CD)
• Инфраструктура как код (IaC)
• Источник истины (SoT)
• Минимально жизнеспособный продукт (MVP)
• ChatOps

Что касается этих концепций в действии, предположим, что вам необходимо развернуть новый сайт в корпоративной VPN. Без подхода NetDevOps к управлению вашей сетью вы могли бы потратить неделю на борьбу вручную за создание правильных настроек IKE / ISAKMP для туннеля и документирование сайта в ваших системах, применение изменений, а затем тестирование, чтобы убедиться, что все работает.

Однако, если вы используете несколько ключевых концепций NetDevOps для управления своей сетью, ваш процесс может выглядеть примерно так:

• Сообщение новый VPN – сайт, чтобы 

@my_netdevops_bot в вашем чате приложения (люфт / MS Команда / WebEx команда)

• Введите имя сайта, тип оборудования и другие метаданные по запросу бота.
• @my_netdevops_bot использует эту информацию для:
  • Создайте сайт в своем Источнике истины (SoT)
  • Объедините шаблон Jinja с соответствующими данными из вашей SoT
  • Представляем вам визуализированную конфигурацию в приложении чата
• После утверждения изменения

 @my_netdevops_bot подключится к устройствам и развернет эти изменения конфигурации.

• @my_netdevops_bot затем запрашивает сеть (или другие системы, такие как системы мониторинга), чтобы определить, было ли изменение успешным, и представляет вам подтверждение в чате.
  • Если изменение не удалось по какой-либо причине, вы @my_netdevops_bot можете начать устранение некоторых основных проблем от вашего имени и также предоставить эту информацию вам.

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

“Но…”

Обычно по этому поводу в разговоре за кулисами прячется «Но…». Вот некоторые из лучших хитов: «Но моя сеть слишком старая» или «Но моя сеть слишком уникальна». Мои личные фавориты: «Но моя сеть слишком велика / слишком мала!» как будто существует мифическая зона Златовласки, где применяются эти концепции. Этот список можно продолжить, но почти для каждого возникшего исключения есть ответ. На большинство из них можно ответить двумя основными ответами.

Во-первых, никто не предлагает вам сразу перейти с нуля к описанному выше сценарию. Принятие менталитета NetDevOps и подхода к работе в сети – это итеративный процесс. Применение всего лишь нескольких из этих концепций (и не всех из них) к одному небольшому элементу вашей сети – лучший способ начать свое путешествие в NetDevOps. Даже небольшие простые шаги могут принести большие дивиденды. Если вы вручную генерируете конфигурации устройства, начните с создания системы шаблонов для конфигураций вашего устройства и хранения ее в виде кода в репозитории Git. Этот первый шаг, заключающийся только в создании конфигураций, оставляя инженера на самом деле квалификацию и применение их, может проложить путь для многих других шагов в будущем. Даже сам по себе,

Во-вторых, никакая сеть не является слишком особенной, чтобы воспользоваться этими концепциями. Ваша сеть очень большая и сложная? Буквально каждый компонент уникален? Выберите одно место в вашей сети, чтобы начать реализацию Источника истины (например, NetBox). Наличие данных в легкодоступном API и / или графическом интерфейсе и в известном стандартном формате немедленно покажет ценность для любых других концепций, которые вы хотите применить. В вашей сети отсутствуют согласованные стандарты? Начните применять их в одном элементе конфигурации, таком как конфигурация AAA, через Инфраструктуру как участников кода. Обеспечение постоянного / ожидаемого значения конфигурации AAA на всех устройствах чрезвычайно важно с точки зрения эксплуатации и безопасности. Ваши комплаенс-аудиторы будут вам благодарны!

Каждая из вышеперечисленных стратегий основана на концепции минимально жизнеспособного продукта. Когда вы начинаете осваивать концепции NetDevOps для управления своей сетью, не ожидайте, что вы решите все свои проблемы с первого раза. Выберите одну простую проблему, которую нужно решить. Создайте свои решения и инструменты для решения этой проблемы, а затем начните использовать их в своей повседневной работе. В случае успеха попробуйте адаптировать свои инструменты для решения дополнительных проблем. Как описано выше, возможно, вы сначала займетесь только конфигурацией AAA. Когда это полностью управляется в Источнике истины и в виде кода вместо исходной конфигурации устройства, вы также можете перейти к управлению конфигурацией SNMP на всех ваших устройствах. Затем вы можете заняться управлением ACL для ваших устройств или настройками NTP и DNS, на самом деле это зависит от того, что имеет смысл в вашей сети.

MongoDB — популярная NoSQL/документоориентированная база данных, поєтому ее часто используют в различных продуктах, в production, в том числе. Давайте разберемся, какие варианты для запуска Mongo в K8s существуют и в  их особенностях.

Kubernetes позволяет очень удобно масштабировать и администрировать приложения, но также важно уделить внимание должному планированию, иначе неприятностей можно получить больше, чем пользы. То же самое относится и к MongoDB в Kubernetes.

Основные моменты

При размещении Mongo в кластере стоит учитывать:

1. Хранилище. Идеальный вариант для гибкой работы в Kubernetes для Mongo — удаленные хранилища, переключаемые между узлами, если нужно будет перемещение Mongo при обновлении узлов кластера или удалении узлов. Но удаленные диски часто доступны с более низким показателем iops (если сравнивать их с локальными). ЕслиУ вас высоконагруженная база и важны хорошие показания по latency, то обратите на это внимание.
2. Корректные requests и limits на pod’ах с репликами Mongo (и соседствующих с ними pod’ами на узле). Важна их правильная настройка, иначе можно получить нежелательное поведение — при внезапно возросшей нагрузке на узле Kubernetes начнет убивать pod’ы с репликами Mongo и переносить их на соседние, менее загруженные. А пока pod с Mongo поднимется на другом узле, может пройти значительное время, так что это не очень приятно. А если упавшая реплика была primary, то результат может быть совсем плачевный — это приведет к перевыборам: вся запись встанет, а приложение должно быть к этому готово и/или будет простаивать.
3. Если случился пик нагрузки, в Kubernetes есть возможность быстро отмасштабировать узлы и перенести Mongo на узлы с большими ресурсами. Не забывайте про podDisruptionBudget, это не даст удалять или переносить pod’ы все вместе и будет поддерживать нужное количество реплик в рабочем состоянии.

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

При выборе хранилища у провайдера, отдавайте приоритет сетевым дискам, это позволит динамически расширять кластер MongoDB. Но стоит отметить, что они проигрывают в производительности локальным. Пример из Google Cloud:

 

Также есть зависимость от дополнительных факторов:

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

Хотя зачастую для большинства задач для MongoDB достаточно ресурсов, предоставляемых провайдерами.

Как поднять MongoDB в Kubernetes?

Конечно, можно обойтись кастомным решением, подготовив несколько манифестов со StatefulSet и init-скриптом. Но мы рассмотрим уже существующие подходы проверенные и рабочие.

1. Helm-чарт от Bitnami

Первый вариант — это Helm-чарт от Bitnami. Это довольно популярное решение.

Чарт позволяет запускать MongoDB несколькими способами:

1. standalone;
2. Replica Set (здесь и далее по умолчанию подразумевается терминология MongoDB; если речь пойдет про ReplicaSet в Kubernetes, на это будет явное указание);
3. Replica Set + Arbiter.

Используется свой (т.е. неофициальный) образ.

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

Необходимый минимум по конфигурации:

1. Указать архитектуру (Values.yaml#L58-L60). По умолчанию это standalone, но нас интересует replicaset:

...
architecture: replicaset
...

        2. Указать тип и размер хранилища (Values.yaml#L442-L463):

...
persistence:
  enabled: true
  storageClass: "gp2" # у нас это general purpose 2 из AWS
  accessModes:
    - ReadWriteOnce
  size: 120Gi
...

Далее через helm install мы получаем готовый кластер MongoDB с инструкцией, как к нему подключиться из Kubernetes:

NAME: mongobitnami
LAST DEPLOYED: Fri Feb 26 09:00:04 2021
NAMESPACE: mongodb
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

MongoDB(R) can be accessed on the following DNS name(s) and ports from within your cluster:

    mongobitnami-mongodb-0.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017
    mongobitnami-mongodb-1.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017
    mongobitnami-mongodb-2.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017

To get the root password run:

    export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace mongodb mongobitnami-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)

To connect to your database, create a MongoDB(R) client container:

    kubectl run --namespace mongodb mongobitnami-mongodb-client --rm --tty -i --restart='Never' --env="MONGODB_ROOT_PASSWORD=$MONGODB_ROOT_PASSWORD" --image docker.io/bitnami/mongodb:4.4.4-debian-10-r0 --command -- bash

Then, run the following command:
    mongo admin --host "mongobitnami-mongodb-0.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017,mongobitnami-mongodb-1.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017,mongobitnami-mongodb-2.mongobitnami-mongodb-headless.mongodb.svc.cluster.local:27017" --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD

В пространстве имен увидим готовый кластер с арбитром (он enabled в чарте по умолчанию):

Этот минимум не отвечает главным вызовам, перечисленным в начале статьи, так что включим в нее дополнительно:

1. Установить PDB (по умолчанию он выключен). Мы не хотим терять кластер в случае drain’а узлов — можем позволить себе недоступность максимум 1 узла (Values.yaml#L430-L437):

   ...
   pdb:
     create: true
     maxUnavailable: 1
   ...
   

    

2. Установить requests и limits (Values.yaml#L350-L360):

   ...
   resources:
     limits:
       memory: 8Gi
     requests: 
       cpu: 4
       memory: 4Gi
   ...
   

   Также рекомендуем повысить приоритет у pod’ов с базой относительно других pod’ов (Values.yaml#L326).

3.  По умолчанию чарт создает нежесткое anti-affinity для pod’ов кластера. Scheduler будет стараться назначать pod’ы на разные узла, но если выбора не будет, то начнет размещать туда, где есть место.

   При достаточно количестве ресурсов и узлов, стоит не выносить две реплики кластера на один и тот же узел (Values.yaml#L270):

   ...
   podAntiAffinityPreset: hard
   ...
   

   Запуск кластера в чарте происходит так:

1. Запускаем StatefulSet с нужным числом реплик и двумя init-контейнерами: volume-permissions и auto-discovery.
2. Volume-permissions создает директорию для данных и выставляет права на неё.
3. Auto-discovery ждёт, пока появятся все сервисы, и пишет их адреса в shared_file, который является точкой передачи конфигурации между init-контейнером и основным контейнером.
4. Запускается основной контейнер с подменой command, определяются переменные для entrypoint’а и run.sh.
5. Запускается entrypoint.sh, который вызывает каскад из вложенных друг в друга Bash-скриптов с вызовом описанных в них функций.

В конечном итоге инициализируется MongoDB через такую функцию:

mongodb_initialize() {
       local persisted=false

       info "Initializing MongoDB..."

       rm -f "$MONGODB_PID_FILE"
       mongodb_copy_mounted_config
       mongodb_set_net_conf
       mongodb_set_log_conf
       mongodb_set_storage_conf

       if is_dir_empty "$MONGODB_DATA_DIR/db"; then
               info "Deploying MongoDB from scratch..."
               ensure_dir_exists "$MONGODB_DATA_DIR/db"
               am_i_root && chown -R "$MONGODB_DAEMON_USER" "$MONGODB_DATA_DIR/db"

               mongodb_start_bg
               mongodb_create_users
               if [[ -n "$MONGODB_REPLICA_SET_MODE" ]]; then
               if [[ -n "$MONGODB_REPLICA_SET_KEY" ]]; then
                       mongodb_create_keyfile "$MONGODB_REPLICA_SET_KEY"
                       mongodb_set_keyfile_conf
               fi
               mongodb_set_replicasetmode_conf
               mongodb_set_listen_all_conf
               mongodb_configure_replica_set
               fi
               mongodb_stop
       else
               persisted=true
               mongodb_set_auth_conf
               info "Deploying MongoDB with persisted data..."
               if [[ -n "$MONGODB_REPLICA_SET_MODE" ]]; then
               if [[ -n "$MONGODB_REPLICA_SET_KEY" ]]; then
                       mongodb_create_keyfile "$MONGODB_REPLICA_SET_KEY"
                       mongodb_set_keyfile_conf
               fi
               if [[ "$MONGODB_REPLICA_SET_MODE" = "dynamic" ]]; then
                       mongodb_ensure_dynamic_mode_consistency
               fi
               mongodb_set_replicasetmode_conf
               fi
       fi
       mongodb_set_auth_conf
       }

2. «Старый» чарт

Также доступен и старый чарт в главном репозитории Helm. Сейчас он уже deprecated, но при этом поддерживается и используется некоторыми организациями.

Он не умеет запускать Replica Set + Arbiter и использует маленький сторонний образ в init-контейнерах, но в остальном достаточно прост и отлично выполняет задачу деплоя небольшого кластера. 

Минимальная конфигурация сильно схожа с предыдущим чартом, стоит только отметить, что affinity нужно задавать вручную (Values.yaml#L108):

affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
               app: mongodb-replicaset

Алгоритм его работы схож с чартом от Bitnami, но менее нагружен (нет такого нагромождения маленьких скриптов с функциями):

1. Init-контейнер copyconfig копирует конфиг из configdb-readonly (ConfigMap) и ключ из секрета в директорию для конфигов (emptyDir, который будет смонтирован в основной контейнер).
2. Секретный образ unguiculus/mongodb-install копирует исполнительный файл peer-finder в work-dir.
3. Init-контейнер bootstrap запускает peer-finder с параметром /init/on-start.sh — этот скрипт занимается поиском поднятых узлов кластера MongoDB и добавлением их в конфигурационный файл Mongo.
4. Скрипт /init/on-start.sh отрабатывает в зависимости от конфигурации, передаваемой ему через переменные окружения (аутентификация, добавление дополнительных пользователей, генерация SSL-сертификатов…), плюс может исполнять дополнительные кастомные скрипты, которые нужно запускать перед стартом базы.
5. Список пиров получают как:

    args:
               - -on-start=/init/on-start.sh
               - "-service=mongodb"
   log "Reading standard input..."
   while read -ra line; do
       if [[ "${line}" == *"${my_hostname}"* ]]; then
           service_name="$line"
       fi
       peers=("${peers[@]}" "$line")
   done
   

    

6. Выполняется проверка по списку пиров: кто из них — primary, а кто — master.
   • Если не primary, то пир добавляется к primary в кластер.
   • Если это самый первый пир, он инициализирует себя и объявляется мастером.
7. Конфигурируются пользователи с правами администратора.
8. Запускается сам процесс MongoDB.

3. Официальный оператор

В 2020 году вышел в свет официальный Kubernetes-оператор community-версии MongoDB. Он дает возможность легко разворачивать, обновлять и масштабировать кластер MongoDB. Также оператор сильно проще чартов в первичной настройке.

Но мы рассматриваем community-версию и она довольно ограничена в возможностях и не подлежит сильной кастомизации по сравнению с чартами выше. Это логично, учитывая, что существует и enterprise-редакция.

Архитектура оператора:

Тут потребуется установить сам оператор и CRD (CustomResourceDefinition), что будет использоваться для создания объектов в Kubernetes.

Установка кластера оператором выглядит следующим образом:

1. Оператор создает StatefulSet, содержащий pod’ы с контейнерами MongoDB. Каждый из них — член ReplicaSet’а в Kubernetes.
2. Создается и обновляется конфиг для sidecar-контейнера агента, который будет конфигурировать MongoDB в каждом pod’е. Конфиг хранится в Kubernetes-секрете. 
3. Создается pod с одним init-контейнером и двумя основными.
   1. Init-контейнер копирует бинарный файл хука, проверяющего версию MongoDB, в общий empty-dir volume (для его передачи в основной контейнер).
   2. Контейнер для агента MongoDB выполняет управление основным контейнером с базой: конфигурация, остановка, рестарт и внесение изменений в конфигурацию.
4. Далее контейнер с агентом на основе конфигурации, указанной в Custom Resource для кластера, генерирует конфиг для самой MongoDB.

Вся установка кластера укладывается в:

---
apiVersion: mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: example-mongodb
spec:
  members: 3
  type: ReplicaSet
  version: "4.2.6"
  security:
    authentication:
      modes: ["SCRAM"]
  users:
    - name: my-user
      db: admin
      passwordSecretRef: # ссылка на секрет ниже для генерации пароля юзера
        name: my-user-password
      roles:
        - name: clusterAdmin
          db: admin
        - name: userAdminAnyDatabase
          db: admin
      scramCredentialsSecretName: my-scram

# учетная запись пользователя генерируется из этого секрета
# после того, как она будет создана, секрет больше не потребуется
---
apiVersion: v1
kind: Secret
metadata:
  name: my-user-password
type: Opaque
stringData:
  password: 58LObjiMpxcjP1sMDW

Преимущество данного оператора в том, что он способен масштабировать количество реплик в кластере вверх и вниз, а также выполнять upgrade и даже downgrade, делая это беспростойно. Также он умеет создавать кастомные роли и пользователей.

При этом у него нет встроенной возможности отдачи метрик в Prometheus, как у предыдущих вариантов, а вариант запуска только один — Replica Set (нельзя создать арбитра). И его не получится сильно кастомизировать, т.к. практически все параметры регулируются через кастомную сущность для поднятия кластера, а сама она ограничена.

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

Enterprise-версия оператора предоставляет большие возможности — установку не только Replica Set’ов, но и shared-кластеров с настройками шардирования, конфигурации для доступа извне кластера (с указанием имен, по которым он будет доступен извне), дополнительные способы аутентификации т.д. И, конечно же, документация к нему описана гораздо лучше.

Саммари

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

У разных вариантов запуска MongoDB есть разные плюсы. Чарты легко модифицировать под ваши нужды, но вы столкнетесь с проблемами при обновлении MongoDB или при добавлении узлов, т.к. всё равно потребуются ручные операции с кластером. Способ с оператором в этом смысле лучше, но ограничен по другим параметрам (по крайней мере, в своей community-редакции). Также ни в одном из описанных вариантов нет возможности из коробки запускать скрытые реплики.

 

Текстовый редактор – это программа, с которой вы будете проводить большую часть своего времени при автоматизации сетей. Здесь я хотел бы сделать обзор самых популярных современных текстовых редакторов.

Код VS

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

VS Code – это бесплатный текстовый редактор с открытым исходным кодом, созданный на Electron и принадлежащий Microsoft. Первоначально он был выпущен в 2015 году.

Атом

Atom – еще один настраиваемый текстовый редактор с открытым исходным кодом, созданный GitHub. Поскольку GitHub был приобретен Microsoft, Atom теперь также является продуктом Microsoft.

Atom также бесплатен, имеет открытый исходный код и построен на Electron. Первоначально он был выпущен в 2014 году.

PyCharm

PyCharm – это полноценная среда разработки Python от JetBrains. Я слышал много похвал в его адрес в контексте разработки Python, но сам никогда не пробовал. PyCharm поставляется в двух версиях: полнофункциональная Professional (лицензия на подписку 89 долларов в год) и менее функциональная, но бесплатная Community Edition.

PyCharm был первоначально выпущен в 2010 году.

Возвышенный текст

Sublime – самый старый текстовый редактор в списке. Он имеет несколько замечательных функций, таких как многострочное редактирование и команда «Перейти к чему угодно», которая позволяет быстро перейти к определенной части текста на любой открытой вкладке. Его также можно расширить с помощью плагинов, но менеджер пакетов не включен по умолчанию, и вам придется сначала установить его вручную.

Sublime Text – это проприетарное платное программное обеспечение, написанное на C ++ и первоначально выпущенное в 2008 году. Оно имеет 30-дневный пробный период. После этого вам время от времени будут напоминать о необходимости купить лицензию за 80 долларов.

Резюме

Научиться пользоваться новым текстовым редактором со всеми его ярлыками и плагинами – это долгосрочное вложение времени. Если вы не использовали ни один из этих текстовых редакторов, я рекомендую выбрать VS Code как наиболее перспективное и всестороннее решение.