Управління конфігурацією для "адміністраторів декількох серверів"

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

В принципі, ідея полягає в тому, що цей сервер більшу частину часу залишатиметься наодинці, коли люди додають або змінюють речі один раз у синій місяць. Це робить дуже важливим те, що все, що налаштовано та працює на сервері, є добре задокументованим та зрозумілим, оскільки люди, які не адмініструють систему, часто зобов'язані втратити огляд (не кажучи вже про деталі). Крім того, з часом склад групи людей, які будуть адмініструвати цей сервер, змінюватиметься (коли люди залишають і приєднуються до «комітету»).

Ми почали з чистої установки, додаючи ролі в ansible, коли хотіли щось встановити (nginx, phpfpm, postfix, брандмауер, sftp, munin, ..). Можливо, через наш недосвідчений досвід, ми, звичайно, ніколи не можемо набрати набір відповідальних завдань саме так, як нам це потрібно, за один раз, також тому, що конфігурація - це процес проб і помилок. Це означає, що на практиці ми зазвичай спочатку налаштовуємо будь-яку службу, яку ми хотіли запустити на сервері , а потім переводимо на відповідні завдання. Ви можете бачити, куди це йде. Люди забувають потім перевірити завдання, або бояться зробити це, ризикуючи зламати речі, або ще гірше: ми забуваємо або нехтуємо, щоб додати речі до аніси.

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

В даний час я бачу три основні проблеми:

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

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

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

EDIT: Ми вважали, що покладаємо /etcна git. Чи є розумний спосіб захистити секрети (приватні ключі тощо) таким чином, але все-таки є сховище конфігурації доступним поза сервером?

ansible configuration-management

— Джост
джерело

Відповіді:

Просто розгорніть тестовий / постановочний VM, який ви можете використовувати для підтвердження змін. Ваш поточний метод здійснення змін вручну спочатку безнадійно порушений і приречений на провал. Ви та ваша команда повинні взяти на себе зобов’язання правильно використовувати CM, і частина цього має наявність тестової системи. Навіть просто місцевого бродячого ВМ було б достатньо.

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

Щодо збереження / etc / in git: ні, не робіть цього. Цей каталог є лише крихітною частиною того, що змінюється в ansible, а наявність git на місці лише спонукає людей до місцевих змін.

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

— EEAA
джерело

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

— Joost

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

— EEAA

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

— EEAA

ІМХО, так, ви повинні взяти на себе зобов'язання. Ви можете переконати своїх колег чи ні, але інше питання. Не існує легкого способу зробити це, який не вимагає певного рівня навмисності від тих, хто керує сервером. З сучасних систем СМ, ansible - це найпростіший придумати швидкість. Ви дійсно хочете , щоб відстежувати зміни сервера з плином часу. Єдиний спосіб зробити це надійно - використовувати CM.

— EEAA

@ThomWiggers Я вважаю, що ви двоє в одній команді, оскільки ви використовували "ми". Гаразд, ви запитали, як це зробити правильно. Я дав відповідь. Або ви хочете зробити це правильно, або ні. Правильне виконання CM вимагає часу, грошей та навмисності. Якщо у вас є такі вимоги, як закупівля та розгортання сертифікатів через LE, тоді створіть віртуальну машину на 5 доларів США на місяць з Digital Ocean та використовуйте її для тестування. Чорт забирай, ти навіть можеш просто розгорнути його на вимогу, коли хочеш перевірити зміни, а потім вбити.

— EEAA

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

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

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

Внесіть зміни до завдань Ansible.
Запустіть ігрову книжку.
Перевірте систему, і якщо вона неправильна, поверніться до кроку 1.
Здійсни мої зміни.

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

— Бойкот SE для Моніки Cellio
джерело

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

— EEAA

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

— Joost

Інша проблема, з якою я зіткнувся з цим ітераційним процесом, трапляється, коли ви пишете завдання, яке вносить зміни, вносите зміни на сервер, виявляєте, що зміни неправильні, оновлюєте завдання та повторно застосовуєте програму. Тепер сервер містить сукупність двох наборів змін: тих, що були з першої ітерації завдання, і тих, які є з другого. Зазвичай друга ітерація замінює першу, але не обов'язково завжди. Чи є розумний спосіб "очистити", а не 1) вручну SSH, щоб скасувати, або 2) починаючи з чистої установки щоразу?

— Joost

Крім того, витіснення сервера часто не є тривіальним, якщо у вас є лише один

— Thom Wiggers

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

— Бойкот SE для Моніки Селліо

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

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

Набір інструментів CM не може бути спроектований адміністраторами. Це я щойно зрозумів. Вони можуть повторно використовувати існуючу роботу або МОЖЛИВО розповсюджуватись на надійній базі, але навіть тоді це потребуватиме обтяжливої кількості практичних норм. Що може зробити Інженер, це просто НЕ, що може зробити адміністратор. Багато понять в Ansible майже такі ж, як у кодовій базі, чи можна навчити адміністратора пітона та очікувати грамотних результатів? Ні, я, звичайно, ні, я б очікував, що робота над злом, тому вам потрібно зробити завдання структурованим достатньо, щоб робота злом була терпимою.

Тому вам потрібно налаштувати справи на успіх, інженерні рішення для непотрібного адміністрування. Торгівля систем низького рівня для речей, які адміністратор може насправді зробити успішно. Набір інструментів CM НЕ врятує вас від невідповідностей архітектури та дизайну.

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

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

— Дж. М. Беккер
джерело