Меню

Управління конфігурацією в практиці DevOps

configuration management devops practices

Спробуйте Наш Інструмент Для Усунення Проблем

Що таке управління конфігурацією в практиці DevOps?

Концепція Постійне тестування в DevOps було детально пояснено в нашому попередньому навчальному посібнику.

Ключовим моментом управління конфігурацією в DevOps є надання,

  1. Інфраструктура як код
  2. Конфігурація як код

Потрібно прочитати => Ексклюзивна серія підручників DevOps

найкращий завантажувач музики mp3 для комп'ютера -

Управління конфігурацією в практиці DevOps

У практиці DevOps є численні переваги «Інфраструктура як код» та «Конфігурація як код».

    • Конфігурації контролюються версіями
    • Автоматизований та стандартизований
    • Видаляє залежність
    • Безперебійна інфра настройка
    • Посилює співпрацю між командою з експлуатації та розвитку
    • Виправлення дрейфу конфігурації
    • Розгляд інфраструктури як гнучкого ресурсу
    • Автоматизоване масштабування інфраструктури
    • Збереження послідовності в налаштуваннях

ВІДЕО Частина 4 Блок 1: Управління конфігурацією- 23 хвилини 7 секунд

Стенограма:

У цій частині ми дізнаємось про Управління конфігурацією, управління випусками та моніторинг продуктивності додатків у DevOps.

Тут, у блоці 1, ми зосередимося на керуванні конфігурацією та зрозуміємо, що таке управління конфігурацією та чим воно відрізняється в DevOps та традиційних методах.

Для початку давайте знати, що таке управління конфігурацією?

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

Як ми знаємо, у нас є різні середовища впродовж SDLC в DevOps, починаючи з модульного тестування, тестування інтеграції, тестування системи, прийняття тестування та тестування кінцевих користувачів.

І я також пояснив у своїх попередніх підручниках, що середовище, налаштоване для цих тестів, поступово ускладнюватиметься, коли воно рухатиметься до передвиробничого та виробничого середовища.

Отже, в основному управління конфігурацією - це автоматизований процес управління всіма конфігураціями кожного з цих середовищ.

Тоді в чому різниця між традиційним управлінням конфігурацією та управлінням конфігурацією DevOps?

У наших традиційних методах управління конфігурацією команда використовувала для управління цими конфігураціями різних середовищ за допомогою офіційної документації, де кожна з конфігурацій раніше реєструвалась у документах, а команда конфігурацій або менеджер використовували для управління версіями цих документів.

І коли і коли воно зазнає змін, він також бере на себе відповідальність за налаштування середовища та управління конфігураціями вручну

Зараз у DevOps, як правило, всі ці процеси управління конфігурацією досить добре автоматизовані, і конфігурації інкапсулюються у вигляді коду або скриптів і контролюються за допомогою інструмента контролю версій.

У цьому контексті ми можемо назвати, що команда Operations інтегрована з розробкою в управління середовищами за допомогою єдиного інструменту контролю версій.

Отже, ключовим моментом управління конфігурацією в DevOps є надання,

      1. Інфраструктура як код
      2. Конфігурація як код

Що насправді означає «інфраструктура як код»? Він визначає все визначення середовища як код чи сценарій, а не запис у офіційному документі.

Тоді що включає визначення середовища? Визначення середовища зазвичай включає, налаштування серверів, налаштування мереж та налаштування інших обчислювальних ресурсів, які є частиною створеної ІТ-інфраструктури. Отже, всі ці деталі будуть виписані у вигляді файлу або у вигляді коду та перевірені в інструменті контролю версій.

Цей скрипт або код, який перевіряється в контролі версій, стане єдиним джерелом визначення середовища або навіть оновлення цих середовищ.

Просто дати просто Приклад , якщо нам потрібно додати сервер до конкретного середовища, все, що ми б зробили, це оновити цю інформацію до сценаріїв середовища та запустити конвеєр доставки, замість того, щоб вручну переходити і викручувати нове середовище з доданим сервером або шукати допомога системного адміністратора для цього.

Отже, краса тут полягає в тому, що розробник або тестувальник не повинен бути експертом системного адміністратора для налаштування своїх серверів для розробки або тестування.

Отже, інфраструктура, налаштована в DevOps, буде повністю автоматизована і в основному слідує сценарію, який перевіряється на контроль версій, починаючи від встановлення серверів, їх конфігурації та встановлення ОС, до встановлення каналів зв'язку цих екземплярів із розгорнутою програмне забезпечення.

Яка конфігурація як код?

Конфігурація як код - це не що інше, як визначення всіх конфігурацій серверів або будь-яких інших ресурсів як коду або сценарію та перевірка їх на контроль версій.

Ці сценарії конфігурації, які перевіряються в контролі версій, запускаються як частина конвеєра розгортання для автоматичного налаштування інфраструктури та її конфігурацій.

Ну, визначення конфігурацій включає параметри, що визначають рекомендовані параметри для успішного запуску програмного забезпечення. Або набір команд, які потрібно виконати спочатку для налаштування програмного забезпечення. Або навіть це можуть бути конфігурації кожного з компонентів програмного забезпечення, які потрібно встановити, або конкретні ролі користувачів, привілеї користувача тощо,

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

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

Для автоматизації інфраструктури на ринку доступно кілька інструментів. Мало хто з них - це шеф-кухар, маріонетка, тераформ тощо, шеф-кухар і лялька - це інструмент управління конфігурацією на основі рубіну, тоді як Terraform - інструмент підготовки.

Крім того, в наші дні, оскільки майже всі додатки розміщуються в хмарі, AWS, вони самі надають RESTAPI, які можна використовувати для цієї мети.

Я маю величезний перелік переваг управління конфігурацією в DevOps, а не визначаю інфраструктуру та конфігурації як код.

Давайте пройдемося по одному по одному.

Всі конфігурації та деталі інфраструктури контролюються версіями, що є великою перевагою в реалізації DevOps.

# 1) Це допомагає команді керувати змінами на серверах та конфігурацією в автоматизованому режимі, а також допомагає швидко налагоджувати, якщо щось не вдається, протягом короткого проміжку часу, а також дозволяє швидко повернутися до попередньої версії, не створюючи жодних перешкод для клієнтів.

# два) Оскільки ці сценарії розташовані на центральному сервері, і всі в команді знають, що є в кожному з цих сценаріїв і які зміни внесені в кожну з цих версій. Це також дозволяє команді повернутися до попередньої версії, якщо в останніх версіях є якісь проблеми.

Уявіть, якщо трапився збій сервера, скільки часу знадобилося б, щоб відновити його вручну. І тепер, визначивши інфраструктуру як скрипт та контроль версій, ми можемо негайно відновити, перейшовши до попередньої версії.

# 3) Керування конфігураціями як коду також запобігає випадковому внесенню змін до системи та запобігає будь-яким збиткам, спричиненим пізніше у виробництві.

Оскільки управління конфігурацією повністю автоматизоване, ручне втручання або для налаштування, або для оновлення повністю виключається.

Уявіть собі вплив на вартість, якість та час, коли раніше люди раніше залежали від людських ресурсів, щоб виконувати ці конфігурації вручну, а коли певні конфігурації пропускаються або не встановлюються за необхідністю.

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

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

Або навіть для налаштування інфрачервоної панелі та конфігурацій, які повністю автоматизовані та контролюються версіями. Отже, будь-хто в команді, будь то розробник або тестувальник, може крутити сервер і виконувати конфігурації для своїх цілей розробки та тестування. Отже, налаштування сервера та конфігурацій стали незалежними від людини.

Це також гарантує, що одні й ті самі сервери не використовуються як розробниками, так і командами з контролю якості для своєї діяльності, як це зазвичай було раніше.

Інфраструктура та конфігурації, визначені як загальний код, а також автоматизація та контроль версій стандартизують усі середовища та налаштування. Отже, це не тільки полегшує розробникам завдання налагодження, а й усуває людські помилки, що призводять до безпомилкових інфра налаштувань, інакше це може завдати величезної шкоди, якщо не виявити її на ранніх термінах.

Тут ми чітко бачимо чітку співпрацю між Dev та Ops, де обидва вони покладаються на одне джерело для здійснення інфрачервоного налаштування, і обидві команди беруть активну участь в автоматизації та налаштуванні всього управління конфігурацією.

Ця спільна робота для досягнення спільної мети стимулює співпрацю між обома командами, розробниками та операціями.

Виправлення дрейфу конфігурації

Що таке дрейф конфігурації?

Невеликі відмінності та невідповідності між серверами, які іноді трапляються через ручне оновлення, яке накопичується протягом певного періоду, називаються дрейфом конфігурації.

Це не дуже хороша ситуація, оскільки ця невідповідність на серверах залишає певні програмні файли, такі як маніфест, playbook, щоб не працювати надійно на всіх серверах, а отже, призводить до збою автоматизації. Отже, цього слід уникати, щоб команда ефективно використовувала автоматизацію конфігурацій.

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

Таким чином, команду можна найкраще запевнити в подібних налаштуваннях конфігурації в розробці, що встановлена, як у виробничій. Це також допомагає їм моделювати виробничі проблеми в середовищі розробників.

Отже, це допомагає запобігти будь-яким несподіваним змінам, які будь-який з членів команди може спробувати зробити в інфрачервоному режимі, що може порушити налаштування, а також змусити команду не вносити жодних змін у налаштування, якщо вони не ввійшли як код до сховища.

Забезпечення інфраструктури та її конфігурації як коду дозволило команді керувати нею як гнучким ресурсом для задоволення динамічних бізнес-потреб замовника.

Це свого роду plug and play зараз. Команда може спеціально потрапити на певний сервер або мережу та внести до них зміни. Це може бути просто оновлення сервера надання послуг або додавання або модифікація сховища в певній мережі, або навіть оновлення ОС, і все можна самостійно оновити як гнучкий ресурс.

Раніше, щоб змінити один параметр конфігурації, це дійсно забирало багато часу, особливо в той час, як це потрібно було оновлювати на всіх серверах, але зараз це лише один крок. Оновіть сценарій і завантажте його в інструмент контролю версій, і все готово.

Існує гнучкість, щоб повністю відмовитись від існуючої інфраструктури та повністю створити іншу. Отже, керувати інфраструктурою та конфігураціями зараз стало досить просто. Ну, хмарні рішення дозволили інфраструктурі автоматично масштабуватися, додаючи додаткові обчислювальні ресурси або ресурси зберігання за необхідності та зменшуючи масштаби, коли вони не потрібні.

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

Нарешті, але не менш важливим є те, що інфраструктура, яка постачається у вигляді коду в контрольованому середовищі, допомагає підтримувати узгодженість середовищ у різних установках. Це також допомагає у налагодженні проблеми. Цю тему я також висвітлював раніше, певною мірою, говорячи про зміну конфігурації.

Ось і все, що закінчує нашу розмову про управління конфігурацією в DevOps, про те, що таке інфраструктура та конфігурації як код та які її переваги.

У нашому майбутньому підручнику ми обговоримо аспекти управління випуском у DevOps.

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^