За останні два тижні словосполучення "Інфраструктура як код" неодноразово згадувалося в різних контекстах. Що насправді означає, що в практичному розумінні мати інфраструктуру як код?
За останні два тижні словосполучення "Інфраструктура як код" неодноразово згадувалося в різних контекстах. Що насправді означає, що в практичному розумінні мати інфраструктуру як код?
Відповіді:
TL; DR : Інфраструктура як код - це спосіб автоматизації та резервного копіювання вашого середовища. В ідеальному випадку після катастрофи ви можете відновити свою інфраструктуру повністю та автоматично , надавши нові ресурси, відновивши конфігурацію з сховища коду та відновивши дані з резервного копіювання.
Інфраструктура як Кодекс спирається на три основні поняття:
Автоматизація управління конфігурацією , яка називається Автоматизація безперервної конфігурації, полем, провідним проф. Марк Берджесс
Сховище коду для змін в інфраструктурі, де зміни спочатку здійснюються, документуються, переглядаються, перевіряються, а потім розгортаються за допомогою автоматизації.
Надання керованої інфраструктури . Інфраструктура як послуга (IaaS). Через хмарні обчислення , приватні або керовані хмари або керовані сервіси обробки даних
Управління конфігурацією - це третє покоління інструментів. На основі CFEngine зараз широко застосовується новий набір інструментів для автоматизованого керування конфігурацією. Найбільш популярні в алфавітному порядку - Ansible, CFEngine, Chef, Puppet, PowerShell DSC та SaltStack . Кожен матиме мову для опису стану вашої інфраструктури, модулі коду, щоб застосувати ці зміни та забезпечити можливість розширення інструментів, деякі агенти для виконання цих на серверах та центральному сховищі інформації.
Вони, як правило, працюють в режимі "push" або "pull", або підключаючись до серверів з центрального місця (локацій), і виконуючи зміни віддалено, або виконуючись на кожному сервері, і витягують інформацію про стан з центрального місця розташування, або в клієнтській / серверній моделі, або в розподіленій шлях.
Важливе поняття для системного адміністратора або інженера надійності сайту , щоб не вносити зміни безпосередньо в інфраструктуру, але нехай автоматизація робити зміни. Все, що зроблено людиною вручну, слід вважати або швидкопсувним, невдовзі виправленим за допомогою автоматики, або в більш жорсткій формі, що порушує цілісність інфраструктури та викликає руйнування та відновлення уражених компонентів.
Репозиторій коду, ідеально відокремлений від програмного забезпечення, що містить сховище, буде використовуватися для управління всіма змінами інфраструктури та пов'язаної з ними автоматизації. Він повинен містити файли та шаблони конфігурації, книги для записів (кулінарні книги), що описують процес змін, що підлягають перегляду, код, що розширює інструменти автоматизації CM, надання конфігурацій, тести інфраструктури та сповіщення, тестування етапів / розгортання, документація, керівництво (ще не автоматизовано) .
Важлива концепція полягає у запровадженні експертних перевірок на зміни, для запису всіх змін та можливості автоматичного повернення до попереднього стану у разі непередбачуваних та / або неперевірених проблем, можливості розгортання до середовища інсценізації та тестування змін конфігурації та можливості автоматичного розгортання зміни без змін, викликані помилками людини.
Управління фізичною інфраструктурою - це реальна задача світу, яка виходить за рамки програмного забезпечення та вимагає дуже різного набору навичок. Маючи змогу абстрагувати цей шар за допомогою хмарних обчислень або керованого центру обробки даних, ви маєте свою команду зосередити увагу на частині управління інфраструктурою, яка додає ділової цінності.
У той час як Cloud Computing пропонує спосіб швидкого запуску та масштабування на більш пізньому етапі, компанії часто усвідомлюють певні переваги та навіть значну економію при переміщенні частин інфраструктури у власних центрах обробки даних для гібридної моделі. Володіння або оренду обладнання не означає, що вам також доведеться працевлаштовувати людей, які ним користуються. У такому масштабі вам потрібні центри обробки даних, які географічно розподіляються по всьому світу, і мати людей з усіма необхідними навичками в усіх місцях було б дуже дорого. Політ над ними по всьому світу додає високої затримки до будь-яких змін та додаткового рівня експлуатаційної неефективності, що є ще однією причиною для аутсорсингу управління центром обробки даних.
Важливим рішенням є те, що керована фізична інфраструктура часто забувається або не помічається , але так само важливо. Навіть якщо у вас є все автоматизоване, вся конфігурація зберігається в резервному сховищі коду, якщо у вас немає способу швидкого забезпечення , у вас є величезне вузьке місце , яке може легко стерти всі переваги, які ви отримали за допомогою двох інших кроків .
Перш ніж пояснити, що це саме, дозвольте навести справді приємне визначення прямо з Вікіпедії :
Інфраструктура як код (IaC) - це процес управління та надання обчислювальної інфраструктури (процеси, голі металеві сервери, віртуальні сервери тощо) та їх конфігурації за допомогою файлів визначення, оброблюваних машиною, а не фізичної конфігурації обладнання або використання інтерактивної конфігурації інструменти.
Гаразд, тепер давайте подивимось на один такий інструмент IaC, Terraform, щоб зрозуміти концепцію краще: https://www.terraform.io/
Крім того, це те, що Terraform говорять про себе:
Terraform дозволяє безпечно та передбачувано створювати, змінювати та вдосконалювати виробничу інфраструктуру. Це інструмент з відкритим кодом, який кодифікує API в декларативні файли конфігурації, якими можна ділитися серед членів команди, трактуватись як код, редагувати, переглядати та переглядати версії.
Це означає, що можна кодувати всю інфраструктуру. який включає створення хмарних (/ інфра) ресурсів, таких як екземпляри сервера, балансири завантаження тощо, а також повну конфігурацію (яка включає основні настройки параметрів, налаштування безпеки, регіони тощо) як код, який можна редагувати, перетворювати і звичайно, оглядова.
Це зразковий приклад коду Terraform для забезпечення ресурсів AWS:
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
Бонусний PS : Також потрібно розуміти відмінності між засобами забезпечення та оркестрування . Деви дуже часто плутають одне за іншим і, як правило, роблять помилку, намагаючись налаштувати та використовувати інструмент для того, для чого не призначено.