У цій статті представлені поради щодо побудови інфраструктури для невеликих проектів без спеціального адміністратора/DevOps інженера.
Мене часто запитують, як побудувати інфраструктуру для невеликих проектів, коли в команді немає виділеного адміністратора або DevOps інженера. У цій статті я розповім про деякі організаційні міркування щодо вибору між виділеними серверами, хмарою або Kubernetes.
Планування для продакшну
Плануючи розгортання продакшну будь-якого додатку, важливо враховувати принаймні наступні п'ять бізнес-процесів/потоків створення цінності:
Розробка додатків
Конфігурація програми
Конфігурація сервера (або іншого середовища виконання)
Конфігурація процесу розгортання
Конфігурація допоміжних служб (наприклад, моніторинг, резервне копіювання тощо)
Компоненти виробничого середовища
Будь-яка інсталяція за межами ноутбука розробника буде складатися щонайменше з компонентів, показаних на ілюстрації (сині та зелені наклейки).
Кожен з цих компонентів налаштовується спочатку, до нього регулярно вносяться зміни, і з часом кожен компонент, швидше за все, буде виведено з експлуатації та замінено. Поточна підтримка кожного компонента також включає забезпечення його функціональності та реагування на інциденти.
Важливість процесу
Це компоненти кожного з наших п'яти основних процесів, загалом щонайменше 20 типових операцій або процесів, присутніх у будь-якій сучасній інсталяції.
Тому необхідно продумати, як ці операції будуть виконуватися, особливо для змін і постійної підтримки, оскільки це найбільш часті операції.
Бізнес-процеси проти потоків створення цінності
На початку статті я навмисно написав "бізнес-процеси/потоки цінності", тому що ми, як технічні лідери, визначаємо, якими вони будуть. Це можуть бути класичні інструкції з чек-листів або діаграми BPMN, і в цьому випадку доречно називати їх "бізнес-процесами". Це також можуть бути повністю автоматизовані програмно-визначені процеси, і в цьому випадку ми, швидше за все, будемо називати їх "потоками створення цінності". Часто, коли DevOps протиставляють "класичним ІТ", це означає зміну парадигми з "бізнес-процесів" на "потоки створення цінності".
Gart може з налаштуванням інфрастуктури для ваших проєктів! Отримайте поради експертів та спростіть розгортання.
Делегування сисадміну / DevOps інженеру
Або ж ми можемо повністю делегувати цей процес працівнику (сисадміну чи DevOps інженеру), не замислюючись над тим, що відбувається в процесі, і сподіваючись, що коли цей працівник врешті-решт звільниться, новий працівник зможе розібратися в цьому. Якщо ми приймаємо цей ризик, то нам байдуже, як цей працівник працює — копіює артефакти через FTP чи пише код в Ansible та Terraform.
Ключові міркування
Ключовим моментом тут є те, що для того, щоб наш продакшн та розробка поводилися передбачувано, ми повинні:
Визначити компоненти, що беруть участь у процесі розробки-поставки-експлуатації. На ілюстрації показано приклад такого розбиття на компоненти.
Вирішити для кожного компонента, як вноситимуться зміни, хто за це відповідає, і яку частину відповідальності делегувати цим людям або сценаріям.
Переконайтеся, що ми приймаємо такі ж рішення для будь-яких нових компонентів, які ми додаємо.
Для складних інсталяцій, природно, може бути більше компонентів. Наприклад, "Конфігурація програми" часто може бути розділена на "Секрети", "Кінцеві точки" і "Функціональну конфігурацію" (пов'язану з логікою програми). Або "Середовище виконання" може складатися як з "Віртуальних серверів", так і з "Оркестратора".
Інфраструктура як код
Для кожного з цих компонентів нам також потрібно розробити відповідний процес змін. Як згадувалося вище, залежно від обраного шляху, це можуть бути або докладні інструкції, або сценарії автоматизації. Або ж у нас можуть бути окремі сервіси, які керуватимуть цими компонентами і візьмуть на себе всю складність. Наприклад, якщо ми зберігаємо секрети у Vault, весь процес зміни секретів складатиметься щонайменше з двох кроків:
Зміна секрету через інтерфейс Vault.
Наші скрипти автоматизації розгортають ці секрети на всі сервіси.
Але тут виникає цікаве питання: що робити зі змінами в цій автоматизації? Відповідь проста — автоматизація по суті є кодом, тому ми застосовуємо підхід "Інфраструктура як код". Точніше, у нас є Інфраструктура як код як процес розробки, що не те саме, що Інфраструктура як скрипти, як це часто буває.
Висновок
Отже, що ми робимо з усіма цими знаннями?
Для невеликих інсталяцій з низькою частотою зміни інфраструктури:
Задокументуйте п'ять згаданих процесів у міру їх використання. Це може бути один рядок "зберіть всю команду і вирішіть, що робити", і це нормально.
Подумайте, чи можна покращити якийсь із цих процесів.
Оцініть, як довго ми можемо жити з цими процесами і коли ми почнемо досягати межі їхньої ефективності.
Для великих інсталяцій з великою кількістю змін в інфраструктурі:
Розробіть компоненти інфраструктури, використовуючи практику розробки програмного забезпечення (класичний "опис функцій -> беклог -> розробка -> тестування -> реліз -> стейджинг-> продакшн").
Визначте компоненти даних в інфраструктурі та задокументуйте процес роботи з ними (наприклад, конфігурацію, секрети тощо). Це може призвести до появи завдань у беклозі розвитку інфраструктури.
Визначити решту компонентів і процесів, для яких ми не застосовуємо IaC
Зосередьтеся на інноваціях, а не на інфраструктурі. Доручіть Gart розгортання ваших проектів, щоб ви могли швидше втілювати свої ідеї в життя!
