18 votes

Comment nettoyer le contenu des rôles qui ne sont plus utilisés sur un serveur ?

Supposons que j'aie un hôte qui soit, entre autres, un serveur web, où le rôle Ansible correspondant installe nginx effectue une configuration essentielle dans /etc/nginx et ouvre les ports 80 et 443 dans le pare-feu.

À un moment donné, je veux que cet hôte particulier ne soit plus un serveur web, parce que pour une raison quelconque, j'ai déplacé ce service ailleurs. Il suffit de retirer le serveur de [webservers] dans l'inventaire laisserait des déchets dans le serveur. Idéalement, je voudrais désinstaller nginx retirer le /etc/nginx (et quelques autres répertoires), et fermez les ports 80 et 443 dans le pare-feu.

Dans Puppet, je peux le faire. Un hôte qui est un serveur web aura quelque chose comme ceci dans sa configuration :

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

et tout ce que j'ai à faire est de remplacer "présent" par "absent". Si le nginx est bien écrite, elle annulera les modifications qu'elle a apportées. (Typiquement, un administrateur remplacera "présent" par "absent", et plus tard, quand il sera certain que tous les hôtes affectés ont annulé la configuration, il supprimera l'élément du manifeste).

De plus, je pense que le module pare-feu de Puppet supprime automatiquement les règles de pare-feu qui ne peuvent plus être trouvées dans le manifeste ; donc je pense que, pour le pare-feu, vous n'avez même pas besoin de faire cette chose "absente" ci-dessus, le pare-feu se fermera automatiquement de toute façon.

Comment puis-je réaliser ces choses avec Ansible ?

1 votes

Je pense que les questions hypothétiques n'ont pas vraiment leur place ici, même si votre question n'est pas dénuée de fondement. Au lieu de "Faisons comme si..." reformuler et dire par exemple "Dans Puppet, je peux changer le rôle d'un serveur et désinstaller nginx qui a été installé précédemment en changeant ensure => present a ensure => absent qui sera également... Comment faire la même chose avec ansible" etc. Idéalement avec un exemple de ce que vous avez déjà essayé.

2 votes

Je dirais qu'Ansible n'est pas vraiment conçu pour ce genre de choses. Il est destiné aux serveurs reproductibles et jetables. Si vous ne voulez plus qu'une machine soit un serveur web, il vous suffit de l'effacer (ou d'y mettre fin s'il s'agit d'une instance en nuage) plutôt que de la réaffecter.

0 votes

@ceejayoz Je n'ai jamais rien lu de plus sur les Ansibles que dans le livre d'Orson Scott Card. Le jeu d'Ender & séquentiels mais ce que vous dites a beaucoup de sens dans l'orchestration du nuage.

14voto

Gauthier Points 1

Avec Ansible, vous ne feriez pas vraiment différemment de ce que vous feriez avec Puppet.

Dans votre exemple, vous devez définir

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

vous vous fiez à l'auteur de ce module Puppet qui a écrit le code nécessaire pour gérer la suppression de tout. Ce n'est pas le cas de tous les modules Puppet.

De même, avec Ansible, vous pouvez avoir des rôles qui comportent à la fois les étapes nécessaires pour l'installer et pour le supprimer. La différence réside uniquement dans la manière d'invoquer les deux.

Une approche pourrait être celle où le rôle en question expose une variable pour basculer le comportement. Par exemple, le rôle nginx pourrait prendre une variable nginx_state qui prend les valeurs installed y absent .

Dans le rôle tasks/main.yml l'auteur du rôle pourrait avoir quelque chose du genre

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

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

avec la logique d'installation/désinstallation respective répartie entre ces deux fichiers à inclusion conditionnelle.

Les rôles Ansible peuvent également être imbriqués. Comme une autre façon de faire la même chose, un auteur de rôle pourrait par exemple fournir un rôle nginx avec un autre rôle à l'intérieur, appelé uninstalled . Vous pourriez alors le faire :

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

Ansible, par rapport à Puppet, a sans doute moins de règles et de directives sur la façon dont les choses doivent être faites. Les pratiques varient donc un peu plus dans la nature, mais les mêmes concepts s'appliquent.

1 votes

Bien qu'il soit techniquement possible de passer des arguments directement dans les rôles, je recommanderais d'utiliser le rôle imbriqué. Je trouverais vraiment étrange de voir dans un playbook un rôle qui sera en fait désinstallé lors de l'exécution du playbook puisque dans les variables il est défini comme tel. L'avoir explicitement via le rôle imbriqué semble tellement plus propre. Techniquement, il est possible de passer des arguments au rôle ( - { role: nginx, state: absent } ) mais il me semble extrêmement verbeux. Le seul inconvénient du rôle imbriqué que j'ai vu est que j'ai eu besoin de lier les vars par défaut du parent.

0 votes

Que faut-il faire pour que quelque chose comme roles: -nginx/uninstalled au travail ? J'ai cherché partout, mais je n'ai trouvé aucune documentation sur l'imbrication des rôles d'une manière qui me permettrait de le faire.

1voto

Mxx Points 2302

Puisque vous avez votre configuration/provisionnement dans Ansible, vous pouvez simplement faire sauter tout le serveur, réinstaller/provisionner un nouveau serveur et avoir un état propre connu pour travailler.

Si vous souhaitez réellement le "reconfigurer" à d'autres fins, vous devrez créer un nouveau playbook qui effectuera les tâches de nettoyage nécessaires.

Autant que je sache, tous les Ansible modules d'emballage soutien state=absent pour s'assurer qu'un paquet donné n'est pas installé sur votre serveur. De plus, apt Le module a purge=yes qui nettoiera tous les fichiers de configuration personnalisés restants.

Vous pouvez également créer des tâches pour confirmer que le port 80 est protégé par un pare-feu. Cependant, comme aucun processus ne s'exécute sur ce port, la mise en place d'un pare-feu ne fera aucune différence pour la sécurité de votre serveur.

0 votes

En outre, je parie que la plupart des pièces jouées dans ce rôle auraient pu state=absent ajouté. Il y a de fortes chances que cela supprime ou annule une bonne partie des modifications de configuration que vous avez apportées. En fonction de la taille du rôle, cela pourrait être un véritable PITA à tester.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X