web-dev-qa-db-ja.com

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

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

Distro-agnostic構成管理ソフトウェア、またはdistro-agnostic codeが付いた少なくとも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
shell-scriptdebianarch-linuxansiblestability
7
user149572

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

package module がArch Linuxをサポートしているかどうかを確認してください。 Archをサポートしているかどうかテストするのが面倒です。しかし、それがない場合は常に pacman module ...そしてそれが機能しない場合...常に独自のモジュールを作成しています。

あなたが言っているのは、本番環境で複数の異なるディストリビューションを実行する場合の大きな問題です。長期的に管理するのは大変です。これは、管理の観点から（純粋にコードから）、多くの作業であるため、運用環境で複数のディストリビューションを実行しないことが推奨される理由です。これを回避する最も明白な方法は、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。

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

11
user26053

Meta-package-managerを維持することは、someoneがDebianで何らかの「Apache2」を維持する必要があるため、私にはSisypheanのタスクのようです- RHELライク（et cetera）のRosetta Stoneでは、「liked」は「httpd」です。

ただし、Ansibleの pacman モジュールがあり、これはAnsible（探している不可解な管理ツール）を使用してArchのようなシステムでパッケージを管理することを目的としています。リンクされたモジュールのドキュメントのサンプルセクションから：

- 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
6
DopeGhoti

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

Saltstack（Ansible compatitor）はpkg.installedとの抽象化が優れており、基盤となるシステムがaptまたはrpmまたはArch ...であることに注意する必要はありません（httpdやApache2などのシステムで差分がある場合は、差分pkg名を設定する必要があります）。

2
HVNSweeting

package は、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 }}"
2
Vladimir Botka