ディストリビューションにとらわれない構成管理ソフトウェアはありますか？

Ansibleのaptモジュールやyumモジュールなど、特定の構成マネージャーモジュールにラベルを付けたくありません。

ディストリビューションにとらわれない設定管理ソフトウェア、またはディストリビューションにとらわれないコードを持つ少なくとも1つのソフトウェアでArch Linuxの以下のパッケージをインストールすることはできますか？

Arch LinuxにLAMPをインストールするための適切なAnsible galaxy-roleが見つからず、次のDebian用のBashスクリプトが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

技術的には、Ansibleはそれです。エージェントレスだからです。ルーター、スイッチ、サーバーなどの管理に使用しました。

あなたが求めているように思われるのは、packageモジュールがArch Linuxをサポートしているかどうかです。Archをサポートしているかどうかテストするのが面倒です。しかし、それが存在しない場合は常にpacmanモジュールが存在します ...そして、それが機能しない場合は...常に独自のモジュールを作成します。

しかし、あなたが話しているのは、本番環境で複数の異なるディストリビューションを実行する場合のより大きな問題です。長期的に管理するのは大変です。これは、管理の観点から（純粋にコードから）、多くの作業であるため、運用環境で複数のディストリビューションを実行しないことが推奨される理由です。これを回避する最も明白な方法は、Ansibleをwhenと組み合わせて使用することos_familyです：

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

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

私は本番環境でDebianサーバーとCentOSサーバーを管理しなければならない状況にありました。最終的に私は純粋なDebianを選択しました：

• CMのコードベースが半分になりました（ディストリビューション固有の癖に関するロジックがすべて削除されました）。
• テストはそれほど難しくありませんでした（CMコードをテストしていない場合は、間違っています）。

とにかく、大きな違いにも出くわすでしょう。例えば：

• 一部のパッケージの名前は異なります。httpd（RHEL）対apache2（Debian）。
• 異なる「デフォルト」設定ディレクトリ。/etc/default（Debian）対/etc/sysconfig（RHEL）。
• 異なるinitシステム; systemd主に引き継いだものの
• SSHなし; たとえば、WinRM for Windows。

構成管理システムは、環境をコードに抽象化する方法です。そしてそれらはあなたにそれをあなた自身で行うための論理/条件を与えます。

meta-package-managerを保守することは、誰かがDebianのような「apache2」を保守する必要があるため、RHELのような（et cetera）Rosetta Stoneの「httpd」であるため、私にはSisypheanのタスクのようです。

しかし、そこにあるパックマン目的製アーチのようなシステム上のパッケージを管理するためにAnsible（あなたが探しているDISTOに依存しない管理ツール）を使用したためであるAnsibleのためのモジュールが。リンクされたモジュールのドキュメントのサンプルセクションから：

- 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

パッケージは、Ansibleの「汎用OSパッケージマネージャー」です。

オプションは、OS固有のlist_of_packagesを含めることです。

- 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"

そして、パッケージをインストールします

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

Nixはスタンドアロンのパッケージマネージャーであり、OSに緊密にバインドされていません。MacOSとUbuntuでも使用していますhttps://nixos.org/nix/

Saltstack（Ansible compatitor）は、pkg.installedとの抽象化が優れており、基盤となるシステムがaptまたはrpmまたはarchであるかどうかを気にする必要はありません...