Інфраструктура як код та TDD

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

У Salt Stack ці біти називаються станами . Якщо стан не відповідає дійсності, інструмент вирішить це за нас. Іншими словами - ми пишемо тест на нашу інфраструктуру, і якщо тест не вдасться, інструмент виправить це самостійно. Принаймні, це ідея.

XP вчить нас використовувати TDD, і питання полягає в тому, чи застосовний він до інфраструктури? Інструменти припускають, що це так.

Я можу уявити собі кілька типів тестів, які можуть бути дуже корисними.

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

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

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

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

Коротше кажучи, я бачу дві категорії тестів для вашої інфраструктури: 1) чи є в ньому все необхідне для запуску вашої програми та 2) чи не має зайвих речей.

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

По-друге, особливо з точки зору безпеки, ви можете писати тести на вашу інфраструктуру. Тобто, якщо однією частиною вашої інфраструктури є VM під управлінням Linux, ви можете написати тест, який виконує сканування портів проти цієї VM, щоб переконатися у відсутності ненавмисних портів, які, можливо, були встановлені випадковим apt-get installпобічним ефектом . Або ви можете написати тести, які перевіряють, чи були змінені будь-які несподівані файли після завершення належного тестового набору. Або ви можете перевірити psвиходи ваших віртуальних машин або контейнерів Docker на предмет несподіваних процесів і подібного, створити білі списки тощо, і, таким чином, отримати автоматичне сповіщення, якщо якийсь сторонній пакет змінився недокументованим (або непоміченим способом) під час оновлення.

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

IMHO досить зайвим писати тести TDD для предметів, повністю охоплених специфікацією стану IaaC. Це означає, що ефективність IaaC сумнівна - навіщо ви використовуєте його, якщо так?

Дивлячись на це з іншого потенційного самого IaaC (якщо / коли це зроблено правильно), є можливості, які вже перевірені та вважаються надійними. Що це робить його привабливим і що робить написання тестів на відповідність TDD зайвими.

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

Зауважте, що моя відповідь не націлена на TDD або будь-який інший тип тестування, який перевіряє, чи відповідає ваша конфігурація IaaC в цілому. Це залишається дійсним і може бути використане при проведенні TDD, CI або подібних перевірок під час розробки цієї специфікації IaaC - я вважаю, що відповідь @ AnoE застосовна в такому випадку.

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

Пам’ятаю картину, на якій сказано: «Пробігла відповідна книжка, все добре» із будівлею, що горить на задньому плані ...

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

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

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

Тому я б сказав, що так, модульний тест є корисним навіть у середовищі, що управляється IAC.

EDIT

Що щодо нерегресійної сторони гілки розробок бази коду IaC? тож ви внесете зміни до свого коду у відділення розробки та об'єднаєте його у галузь prod, сподіваючись не зламати все? Тест одиниць настільки цінний, і зазвичай простий у виконанні, я не бачу, чому можна було б кодувати без цієї функції.

Довідка (французькою вибачте за це): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

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

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

Якщо ви переходите на окремі сервери, справи стають ще гіршими ... як ви перевірите доступність у всіх мережевих налаштуваннях? Включаючи роздільну здатність DNS, маршрутизацію та брандмауер? Навіть якщо API ваших постачальників послуг IaaC працює як очікувалося (я бачив проблеми з дротом в цій області), мені дуже подобається TDD в цьому випадку.

Оскільки в цій галузі я не знайшов інструментів для тестування, ми написали його у вільний час: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Тому я думаю, що TDD дійсно важливий у світі DevOps!