Existe-t-il un logiciel de gestion de configuration distro-agnostique?


7

Je ne veux pas m'étiqueter sur des modules de gestionnaire de configuration spécifiques comme le aptmodule ou yummodule d' Ansible .

Existe-t-il un logiciel de gestion de la configuration distro-agnostique, ou au moins un avec du code distro-agnostic pour installer également les packages suivants pour Arch Linux ?

Je pose cette question car je n'ai pas trouvé de rôle galaxy Ansible approprié pour installer LAMP sur Arch Linux et le script Bash suivant pour Debian n'est pas adapté pour Arch:

#!/bin/bash

apt update -y
apt upgrade ufw sshguard unattended-upgrades wget curl git zip unzip tree -y

ufw --force enable
ufw allow 22,25,80,443

apt upgrade lamp-server^ ssmtp  -y
apt upgrade python-certbot-apache  -y
apt upgrade php-{cli,curl,mbstring,mcrypt,gd} phpmyadmin  -y

Réponses:


11

Techniquement, Ansible est cela; parce que c'est sans agent; Je l'ai utilisé pour gérer des routeurs, des commutateurs, des serveurs, etc.

Il semble que vous demandiez si le packagemodule prend en charge Arch Linux? Je suis trop paresseux pour tester si cela prend en charge Arch; mais si ce n'est pas le cas, il y a toujours le pacmanmodule ... Et si cela ne fonctionne pas ... Il y a toujours l'écriture de votre propre module.

Ce dont vous parlez cependant, c'est d'un problème plus important avec l'exécution de plusieurs distributions différentes dans un environnement de production . Il devient pénible de gérer à long terme. C'est pourquoi il est recommandé de ne pas exécuter plusieurs distributions en production, car du point de vue de la gestion (purement à partir du code), c'est beaucoup de travail. Le moyen le plus évident de contourner ce problème est d'utiliser Ansible whenen combinaison avec os_family:

    apt:
      name: apache2
    when: ansible_facts['os_family'] == "Debian"

    pacman:
      name: nginx
    when: ansible_facts['os_family'] == "Archlinux"

J'ai été dans une situation où je devais gérer des serveurs Debian et des serveurs CentOS en production; finalement j'ai fait le choix d'aller purement Debian parce que:

  • La base de code pour CM a été réduite de moitié (toute la logique des bizarreries spécifiques à la distribution a été supprimée).
  • Les tests sont devenus moins pénibles (si vous ne testez pas votre code CM, vous le faites mal).

Vous rencontrerez également des différences majeures de toute façon; par exemple:

  • Certains packages sont nommés différemment; httpd(RHEL) vs apache2(Debian).
  • Différents répertoires de configuration "par défaut"; /etc/default(Debian) vs /etc/sysconfig(RHEL).
  • Différents systèmes d'init; bien systemda largement pris le relais.
  • Pas de SSH; par exemple WinRM pour Windows.

Les systèmes de gestion de configuration sont un moyen d'abstraire l'environnement en code; et ils vous donnent la logique / les conditions pour le faire vous - même .


1
Le packagemodule appelle simplement le module défini dans le ansible_pkg_mgrfait pour ce système. Ainsi, tout système d'emballage pris en charge par Ansible fonctionnera.
Michael Hampton

6

Le maintien d'un gestionnaire de méta-paquets me semble être une tâche Sisyphe, car quelqu'un devrait maintenir une sorte de "apache2" dans Debian-likes est "httpd" dans RHEL-likes (et cetera) Rosetta Stone.

Cependant, il existe un module pacman pour Ansible qui est spécialement conçu pour utiliser Ansible (l'outil de gestion disto-agnostique que vous recherchez) pour gérer les packages sur des systèmes de type Arch. Dans la section Exemples de la documentation du module lié:

- name: Install package foo
  pacman:
    name: foo
    state: present

- name: Upgrade package foo
  pacman:
    name: foo
    state: latest
    update_cache: yes

- name: Remove packages foo and bar
  pacman:
    name: foo,bar
    state: absent

- name: Recursively remove package baz
  pacman:
    name: baz
    state: absent
    recurse: yes

2

le package est Ansible "Generic OS package manager".

Une option serait d'inclure list_of_packages spécifique au système d'exploitation

- include_vars: "{{ item }}"
   with_first_found:
     - files:
         - "{{ ansible_distribution }}-{{ ansible_distribution_release }}.yml"
         - "{{ ansible_distribution }}.yml"
         - "{{ ansible_os_family }}.yml"
         - "default.yml"
       paths: "{{ role_path }}/vars"

et installez les packages

- package:
    state: present
    name: "{{ item }}"
  loop: "{{ list_of_packages }}"

2

Nix est un gestionnaire de paquets autonome qui ne se lie pas étroitement à aucun système d'exploitation. Je l'utilise sur MacOS et aussi Ubuntu https://nixos.org/nix/

Saltstack (compatible Ansible) a une abstraction plus agréable avec pkg.installed et vous n'avez pas besoin de vous soucier que le système sous-jacent soit apt ou rpm ou arch ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.