☰

Puppet、Chef、またはAnsibleがパッケージマネージャよりも単純なソリューションの場合

tag-icon • tag-icon puppet ansible chef
Puppet、Chef、またはAnsibleがパッケージマネージャよりも単純なソリューションの場合

上記の展開および設定ツールを初めて使用します。通常、ターゲットコンピュータにカスタムおよび構成されたネットワークサーバー（リバースプロキシ、データベース、解釈された言語に必要なランタイムなど）をインストールしてアップグレードする必要があります。

私のディストリビューションにはすでに動作しているパッケージマネージャがあります。事前設定されたソフトウェアを含む独自のパッケージを作成および展開し、SSHを介してインストール/アップグレードできます。

このソリューションが十分ではないと予想し、言及されたツールを選択する必要があるのはどこですか？

ベストアンサー1

パッケージマネージャは決して設定管理を置き換えません。構成管理システムは、基本パッケージ・マネージャーとの対話を処理できます。パッケージに構成を適用する場合 a) すべてのサーバーが同じ構成を持つことを意図し、b) その構成に外部データが必要ない場合にのみ十分です。

基本インフラストラクチャを見てみましょう。内部Webアプリケーションがありますが、Webサーバーを使用してチケット追跡ソフトウェア（Redmineなど）を実行することもできます。内部WebアプリケーションはPHPで書かれていますが、RedmineはRubyアプリケーションです。これら2つの異なるWebアプリケーションは、異なるApache構成を持っています。構成をパッケージ化する場合は、apache-internalやapache-redmineなど、競合する2つのApacheパッケージをビルドする必要があります。この状況がどのようにすばやく管理できなくなるのかを簡単に確認できます。

人形マニフェストでこれがどのように見えるかを見てみましょう。

# internal PHP application
class { apache: }
# uses your OS package manager to install PHP
class {'::apache::mod::php':
  package_name => "php54-php",
  path         => "${::apache::params::lib_path}/libphp54-php5.so",
}

# redmine
class { apache: }
# uses your OS package manager to install mod_passenger
class { apache::mod::passenger: }
apache::vhost { $::fqdn:
  docroot     => '/path/to/directory',
  directories => [
    { path              => '/path/to/directory',
      passenger_enabled => 'on',
    },
  ],
}

もう1つの基本的な例は、インフラストラクチャにさまざまな環境があることです。パッケージマネージャの静的構成を使用してテンプレート構成ファイルを実行することはできません。開発環境と本番環境がある場合は、テンプレートを使用してアプリケーションが正しいデータソース（データベースなど）または特定の環境に接続するように指示する構成を作成できます。

最後に、カスタムリポジトリを追加し、各ホストに正しいパッケージをインストールする人は誰ですか？これはより不要なメンテナンスであり、構成管理によって解決されます。

おすすめ記事