Як очистити речі від ролей, які більше не використовуються на сервері?


15

Припустимо, у мене є хост, який є, між іншим, веб-сервером, де встановлена ​​відповідна роль Ansible nginx, виконує деяку істотну конфігурацію в /etc/nginxі відкриває порти 80 та 443 в брандмауері.

В якийсь момент я хочу, щоб той конкретний хост більше не був веб-сервером, тому що я чомусь перенесла цю послугу в інше місце. Просто видалення сервера з [webservers]інвентарю залишатиме сміття на сервері. В ідеалі я хотів би видалити nginx, видалити /etc/nginxкаталог (та деякі інші каталоги) та закрити порти 80 та 443 у брандмауері.

У Ляльці я можу це зробити. Хост, який є веб-сервером, матиме щось подібне у своїй конфігурації:

class { 'nginx':
  ensure => present,
}

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

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

Як я можу досягти цих речей за допомогою Ansible?


1
Гіпотетичні питання насправді не є темою, я думаю, хоча саме ваше запитання не без поваги. Замість "давайте робити вигляд ..." перефразуйте і скажіть, наприклад, "У маріонетці я можу змінити роль сервера та видалити встановлений раніше nginx, змінивши ensure => present на ensure => absentякий також буде ... Як зробити те ж саме з ansible" тощо. Ідеально з прикладом усього, що ви вже пробували.
HBruijn

2
Я б стверджував, що Ansible насправді не створений для подібних речей. Він орієнтований на відтворювані одноразові сервери. Якщо ви більше не хочете, щоб машина була веб-сервером, просто витріть її (або скасуйте її, якщо це хмарний екземпляр), а не замінити її.
ceejayoz

@ceejayoz, що найбільше я читав про "Ansibles" - це гра " Ендер" Орсена Скотт-Карт-картки, але те, що ви говорите, має багато сенсу в хмарній оркестрації
HBruijn

@ceejayoz: На даний момент я не використовую Ansible для налаштування кількох серверів, але для налаштування невеликих автономних серверів. Я думаю, це правильне використання. Отже, сервер може мати nginx + django + PostgreSQL. Якщо пізніше я вирішу покласти nginx або nginx + django в інше місце, витираючи весь сервер і потрібно повернути PostgreSQL з резервної копії, здавалося б, неоптимально (не кажучи вже про простої).
Антоніс Кристофідес

Відповіді:


10

За допомогою Ansible ви насправді цього не зробите інакше, ніж як ви робите це з Лялькою.

У вашому прикладі, де ви б встановили

class { 'nginx':
  ensure => absent,
}

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

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

Один із підходів може бути таким, коли роль, про яку йдеться, піддає змінній для переключення поведінки. Наприклад, ця nginx роль може приймати змінну, nginx_stateяка приймає значення installedта absent.

У tasks/main.ymlролі автор ролі може мати щось уздовж ..

- include: install.yml
  when: nginx_state|default('present') == "present"

- include: uninstall.yml
  when: nginx_state|default('present') == "absent"

.. з розділенням відповідної логіки встановлення / видалення між цими двома умовно включеними файлами.

Відповідні ролі також можуть бути вкладені. Як інший спосіб зробити те ж саме, автор ролей може, наприклад, надати йому роль nginxз іншою роллю всередині нього uninstalled. Потім ви можете зробити:

- name: Uninstall nginx
  hosts: some_group
  roles:
    - nginx/uninstalled

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


1
Хоча технічно ви також можете передавати аргументи прямо у ролі, я б рекомендував використовувати вкладені ролі. Мені здається, що це дуже дивно, бачачи в ігровій книзі якусь роль, яка фактично буде видалена при виконанні книги, оскільки у змінних вона визначена як така. Наявність цього явного за допомогою вкладеної ролі здається набагато чистішим. Технічно можна передавати аргументи на роль ( - { role: nginx, state: absent }), але мені це здається надзвичайно багатослівним. Єдиним недоліком вкладеної ролі, яку я бачив, було те, що мені потрібно було пов’язати параметри за замовчуванням від батьківського.
bogdan.mustiata

Що потрібно зробити для чогось подібного roles: -nginx/uninstalledдо роботи? Я роздивився всюди, але не можу знайти жодної документації щодо вкладення ролей таким чином, який би дозволив мені це зробити.
aggregate1166877

1

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

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

Наскільки мені відомо, всі модулі упаковки Ansible підтримують, state=absentщоб певний пакет не був встановлений на вашому сервері. Крім того, aptмодуль має purge=yesпараметр, який очистить усі інші налаштовані конфігураційні файли.

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


Щоб додати до цього, я думаю, що більшість п'єс у цій ролі могла б state=absentдодати. Є хороший шанс, що видалить або скасує велику частину змін, які ви внесли в конфігурацію. Залежно від того, яка велика роль, це може бути справжнім ПДФА для перевірки.
Крістофер Карел
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.