Розмір шрифту: 

Олексій Клименко, [23.04.2024 23:23]DevOps (development and operations, розробка та експлуатація) – методологія або набір практик автоматизації технологічних процесів складання, налаштування та розгортання програмного забезпечення. Методологія передбачає активну взаємодію фахівців з розробки з фахівцями з інформаційно-технологічного обслуговування та взаємну інтеграцію їхніх технологічних процесів один в одного для забезпечення високої якості програмного продукту. Призначена для ефективної організації створення та оновлення програмних продуктів і послуг. Одним з підходів до автоматизації комп’ютерних мереж є використання практик DevOps. Останні показали продуктивність в першу чергу у розробці програмного забезпечення і стали, за великим рахунком, стандартом галузі. Проте постає питання, чи можна такі практики використовувати й в інших галузях ІТ та в якому обсязі.Основні складові частини DevOps. Plan – планування змін чи оновлень коду. Code – розробка коду, інструменти контролю версій, злиття коду. Build – інструменти безперервної інтеграції, статус складання. Test – інструменти безперервного тестування, що повідомляють про знайдені помилки чи потенційні проблеми. Release – керування змінами, затвердження випуску. Deploy – впровадження, розгортання змін у програмний продукт. Operate – власне функціональна робота продукту. Monitor – відстеження та підтримка коректної роботи і продуктивності.Ці етапи послідовні, відповідно з них можна створити так званий «pipeline» (конвеєр). Процес розробки циклічний. Отже, якщо зациклити ці етапи, то в результаті створюється CI/CD pipeline – це комбінація безперервної інтеграції (continuous integration) і безперервного розгортання (continuous delivery або continuous deployment) програмного продукту в процесі розробки [1].Для того, щоб комп’ютерну мережу можна було розглядати, як синонім програмному продукту, її потрібно трансформувати згідно практик IaC (Infrastructure as Code, Інфраструктура як код). IaC – це спосіб керування ресурсами методом їх опису у вигляді програмного коду, на відміну від налаштовування необхідного обладнання власноруч чи за допомогою інтерактивних інструментів. Це означає, що мережа має бути описана декларативно у файлах. При цьому бажано, щоб опис був вендеронезалежним, тобто міг використовуватись для будь-якого розробника мережевого обладнання. Кінцева конфігурація для обладнання має формуватися при об’єднанні описових файлів та шаблонів за допомогою шаблонізатора.У разі необхідності внесення змін у конфігурацію комп’ютерної мережі спочатку розробляється план змін. Потім для доведення конфігурації мережі до бажаного вигляду розробляється задача для системи управління конфігураціями, наприклад, Ansible або Nornir. Наступним кроком проводиться тестування. Це має бути як синтаксичне тестування, для уникнення помилок синтаксису команд операційної системи (ОС) обладнання, так і конфігураційне – перевірка того, що всі сервіси, які працюють через комп’ютерну мережу, будуть працювати надалі. За умови успішного проходження тестів система управління конфігураціями застосовує перевірену конфігурацію на обладнанні. Якщо попередній етап завершено без помилок, затверджується випуск, інакше – повернення до попередньої конфігурації. Після цього наступає етап звичайної функціональної роботи продукту та, обов’язково, моніторинг працездатності та продуктивності мережі. У моніторинг бажано включати повторні тести, щоб переконатися, що мережа працює належним чином. Наприклад, мережевий трафік ходить коректними маршрутами, протоколи знаходяться в потрібному статусі, ємність каналів відповідає заявленій тощо.
Олексій Клименко, [23.04.2024 23:23]Проте, однією з основних проблем є те, що комп’ютерна мережа, на відміну від програмного продукту, є фундаментальною інфраструктурою. Якщо допустити помилку при конфігурації обладнання, то можна втратити зв’язок з таким обладнанням або навіть з частиною мережі. Для усунення цієї проблеми потрібно використовувати деталізовані та глибокі тести. Нажаль, існує не так багато інструментів для попереднього тестування конфігурації мережевого обладнання, наприклад, Batfish. Його функціонал враховує багато перевірок мережевих протоколів, але, нажаль, не покриває всі можливі сценарії та не може передбачити наявність багів у ОС обладнанні. Крім того, є проблемою те, яким чином для перевірки отримати конфігурацію-кандидат. Найпростіший спосіб – відредагований текстовий файл. Проте, цей підхід немасштабований, більше того, він може займати більше часу, ніж конфігурація обладнання вручну. Відповідно, потрібні механізми, які здатні сформувати нову конфігурацію на базі поточної з урахуванням правок, що випливають із задачі. Подібні інструменти є, наприклад, у обладнанні від Cisco Systems [2] чи Juniper Network [3]. Таким чином виникає залежність від розробника обладнання.Як альтернативу такому тестуванню, можна використовувати лабораторію або пісочницю – віртуальну лабораторію. В них можна розмістити фізичне або віртуальне обладнання, яке використовується в інфраструктурі, та виконувати попереднє тестування на ньому. Однак, і таке тестування має багато недоліків. Наприклад, воно не враховує реальне навантаження на комп’ютерну мережу, можна виконати лише синтетичні тести. Також виникає питання, що робити, якщо в інфраструктурі задіяно обладнання від різних розробників та різних моделей. Крім того, навіть однакове обладнання може працювати під різними версіями ОС. Відповідно, тестування всіх можливих конфігурацій в лабораторії ускладнено.Отже, практики DevOps допомагають в процесі автоматизації комп’ютерних мереж, але потребують доопрацювання. Задля досягнення результату варто слідувати низці правил. Конфігурація мережевого обладнання має бути декларативно та вендеронезалежно описана окремими файлами. Потрібно застосовувати глибоке та комплексне тестування. Наприклад, поєднання програмних тестів конфігурації з лабораторними тестами. При розгортанні мережі потрібно дотримуватись корпоративних стандартів. Наприклад, обладнання, що виконує однакові завдання на мережі, бажано має складатися з однієї лінійки одного-двох розробників обладнання, які в свою чергу підтримують всі необхідні механізми для коректної роботи системи. При цьому ідентичні моделі такого обладнання мають мати ідентичну версію ОС (попередньо перевірену та протестовану).