Що таке незмінні сервери?

Є кілька запитань щодо незмінних серверів , таких як:

• Як реалізувати незмінну схему сервера, не втрачаючи можливості робити посмертні справи?
• Яку роль відіграють інструменти управління конфігурацією у незмінній інфраструктурі?

Здається очевидним, що це стосується серверів (ту частину, яку я отримую). І лише перетравлюючи граматику незмінного , я думаю, що це має щось спільне з "неможливим приглушити ". Якщо ця здогадка близька, я б не мав поняття, що саме не можна вимкнути (і я сумніваюся, це стосується звукових карт чи чогось іншого).

Мої запитання :

• Що насправді є "незмінними серверами" (в контексті DevOps)?
• Для чого вони використовуються?

Незмінюваність - термін, який часто використовується в колах інформатики, який, як правило, зводиться до "неможливо змінити після створення". Зазвичай він використовується для посилань на паралелізм, паралельність та безпеку ниток.

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

Уявіть, якщо на Amazon ви розгортаєте веб-сервіс, вкладаючи його в машинне зображення (AMI - попередньо створений екземпляр, який ви можете повторно надавати). Він підключається до резервної бази даних за допомогою облікових даних, які виходить з реєстру при запуску. Він скидає журнали в інструмент для ведення журналів, як Splunk. Для звичайної щоденної роботи у вас немає причин забивати це поле. Якщо вам потрібно розширити масштаб цієї служби, ви просто створіть більше примірників цього AMI і налаштуйте балансир навантаження. Скручування його - це просто руйнування екземплярів та балансирів навантаження.

Для щоденної експлуатації це поле не має підстав змінюватись . Ми можемо просто розпалити AMI.

Що відбувається, коли вам потрібно забезпечити патч безпеки на рівні ОС? Це коли у вас є рішення прийняти ... чи ви запікаєте новий AMI з встановленим патчем і перерозподілите всі запущені екземпляри, або ви сш в існуючі зображення та оновите виправлення? Є багато людей, які просто б'ються. Прихильники "непорушної архітектури" просто кричали на мене, навіть припускаючи, що таке можливо.

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

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

Хмарні технології змістили кордон між апаратним та програмним забезпеченням, так що багато технічних операцій, які раніше були ексклюзивними громадянами світу апаратних засобів, також є предметом сфери програмного забезпечення. Спільні обчислювальні середовища можуть бути такими ж старими, як і самі комп’ютери ^1, але хмарні технології можуть популяризувати їх, пропонуючи зручні та звичні метафори для взаємодії з ними: користувачі хмари резервують екземпляр, повний комп’ютер або міміку, тоді як для старих спільних обчислювальних середовищ є все можливе непростих обмежень, і "ваша програма повинна бути завантажена на цей FTP-сервер, вона працюватиме в середовищі X (як правило, зі старою версією 10 років будь-якого програмного забезпечення, яке ви хочете використовувати), щонайменше 60 хвилин" може здатися знайомим колишнім або фактичним користувачам обчислювальних центрів.

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

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

Реалізація ароматизаторів

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

Примітка історії

Наскільки мені відомо, термін «незмінний сервер» був популяризований Кіефом Моррісом, але сама ідея набагато старша. У 1999 році в'язниці FreeBSD вже популяризували ідею повністю автоматизувати конфігурацію одноразових обчислювальних середовищ, саме так я почав реалізовувати схему "незмінного сервера" багато років, перш ніж почути це ім'я для опису цієї методики.

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

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

Ця концепція допомагає гарантувати, що ваш тест, розробка та сервер якості якості однакові, що важливо з кількох причин поза сферою цього питання. Ще одна перевага незмінних серверів - це можливість відкатати додаток на більш старий сервер. Наприклад, мені потрібно змінити K на виробничому сервері 1, тому я розгорнув сервер 2 і зміну K. Тепер через 10 хвилин я помічаю, що K зламав щось із моєю програмою, а не одразу виправляти це, що може зайняти години і потенційно може спричинити простої для моїх клієнтів, я перенаправляю трафік назад на сервер 1, тоді як я з'ясовую, що не так з 2.

Найкраще пояснення можна знайти (як завжди) у статті про Матіна Фаулера про Immutable Servers .

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

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

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

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

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

Перше середовище, де використовується таке зображення , було б середовищем, де зображення можна перевірити на роботу. Будь-які відхилення виявляються, і лише тоді таке зображення можна перенести у виробниче середовище, щоб замінити там сервери новою версією (яка, як відомо, працює добре).

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

Часто незмінні сервери навіть не включають жодного способу "ввести" їх, наприклад, наприклад, відсутній ssh-сервер. У цьому випадку також часто буває так, що вся метрологія сервера (метрики, журнали) надсилається до систем поза межами, таких як база даних метрик або служба агрегації журналів.

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

Почнемо з оберненого, що таке мутаційний сервер?

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

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

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

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

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