Redhat_PHP チュートリアルでの Puppet の集中構成管理

Redhat による Puppet の集中構成管理

puppet の紹介
Puppet は、通常、C/S 構造であるため、C を使用することもできます。スター構造。すべての Puppet クライアントは同じサーバー上の Puppet と通信し、30 分ごとにサーバーに接続し (設定可能)、最新の構成ファイルをダウンロードし、その構成ファイルに従ってサーバーを構成します。構成が完了すると、Puppet クライアントはサーバーにメッセージをフィードバックできます。エラーが発生した場合、
2 番目のインストール環境
サーバー: 172.25.example.com puppet マスターにもメッセージがフィードバックされます。
client クライアント: 172.25.254.3 vm3.example.com puppet エージェント
クライアント: 172.25.254.4 vm4.example.com puppet エージェント
重要: サーバーとすべてのクライアントの間で解像度と時刻の同期が必要です。そうでないと検証が失敗します。

サーバー側:
まずこれらのパッケージをインストールします
[root@vm2 puppet]# yum install -y puppet-server-3.8.1-1.el6.noarch.rpm fater-2.4.4-1.el6.x86_64.rpm Ruby-augeas-0.4.1-3.el6.x86_64.rpm Rubygems-1.3.7-5.el6.noarch.rpm Rubygem-json-1.5.5-3.el6.x86_64.rpm Ruby-shadow-2.2.0 -2.el6.x86_64.rpm puppet-3.8.1-1.el6.noarch.rpm hiera-1.3.4-1.el6.noarch.rpm

サービスを開始します: [root@vm2 puppet]# /etc/ init .d/puppetmaster start
puppetmaster の起動: [ OK ]

ポート 8140 が開いているかどうかを確認します
[root@vm2 puppet]# netstat -anltp|grep Ruby
tcp 0 0 0.0.0.0:8140 0.0.0.0:* LISTEN 1118/ Ruby

クライアント:
これらのパッケージをインストールします: yum install -y puppet-3.8.1-1.el6.noarch.rpm Ruby-shadow-2.2.0-2.el6.x86_64.rpm fater-2.4.4- 1 .el6.x86_64.rpm hiera-1.3.4-1.el6.noarch.rpm Ruby-augeas-0.4.1-3.el6.x86_64.rpmrubygems-1.3.7-5.el6.noarch.rpm Rubygem-json - 1.5.5-3.el6.x86_64.rpm

認証の開始:
初めて認証を開始すると、サーバーがまだ同意していないため、証明書が存在しないことが表示されます



この時点では、サーバー上で認証リクエストを開始したユーザーを表示できます


証明書に署名します
証明書を削除します
puppet cert clean vm3.example.com


認証が成功したかどうかをクライアントで確認します
次の図は、それを証明しています認証は成功しました


3つのサーバーが自動認証を実装しています
サーバーターミナル上で
vim /etc/puppet/puppet.confmainの下に次の行を追加します
[main]
autosign = true

autosign.confファイルを作成します/etc/puppet ディレクトリに次の内容を含めます:
*.example.com # example.com ドメイン内のすべてのホストが許可されていることを示します
/etc/init.d/puppetmaster reload

クライアントでは、必要なのは直接適用して成功するには
puppet エージェント --server vm2.example.com --test



実際には、クライアントのホスト名が変更される場合があるため、証明書を再生成する必要があります:
1) で実行します。 server: puppet cert --clean vm3.example.com #削除する元のクライアントのホスト名
2) クライアント上で実行を終了します: rm -fr /var/lib/puppet/ssl/*puppet Agent --server =puppet.example.com

puppet の最初に実行されるコードは /etc/puppet/manifest/site.pp にあるため、このファイルが存在する必要があり、他のコードもこのファイルを通じて呼び出す必要があります。
4 つのサーバー リソース定義:
cd /etc/puppet/manifests
site.pp
file {
"/mnt/puppet-3.8.1-1.el6.noarch.rpm": クライアントの宛先
content => ; puppet:///files/puppet-3.8.1-1.el6.noarch.rpm"、サーバー ソース
モード => 600、クライアントはリソース権限を取得します
オーナー => Puppet クライアントはリソース ユーザー
}

cd を取得します。 .
mkdir ファイル
puppet-3.8.1-1.el6.noarch.rpm パッケージをこのディレクトリに配置します
vim /etc/puppet/fileserver.conf
以下を一番下に追加します
[files ]
path /etc/ puppet/files
allow *

クライアントの検証 この図は、/mnt
の下のリソースの変更を示し、サーバー構成も検証します



ソフトウェア パッケージとサービス定義
今すぐ site.pp ファイルの編集を続行し、次の内容を追加します
package { ## ソフトウェア パッケージ定義
"vsftpd": ensure => present (インストールは存在、アンインストールは存在しない)

}

service {## サービス定義
"vsftpd" ":
ensure => running
}

ファイル {
"/etc/vsftpd/vsftpd.conf":
ソース => "puppet:///files/vsftpd.conf",
モード => 600,
通知 => は、クライアントでテストします
}
ユーザーの作成
site.pp ファイルの編集を続けて次の内容を追加します user { "xp": uid => 900, ##Create user
home => "/home/test",
shell => "/bin/bash ",
provider => useradd,
managehome => true,
ensure => present,
password =>westos
}


#exec { "echo passwd --stdin xp": ##パスワードの変更 暗号化方法は、パスワードが /etc/shadow
#path => "/usr/bin:/usr/sbin:/bin",
#onlyif => の下に平文で保存されるようにします。 "
#}
顧客側の検証



crontabタスク
サーバー側の古いルール、site.ppファイルのコンパイルを続行しますcron { echo:
command => "/bin/echo `/bin/date ` >> /tmp/echo ",
user => root,
hour => ['2-4'],
分 => '*/10'
}

タスクが生成されますクライアントの /var/spool/cron ディレクトリにあります
クライアントで確認してください



つまり、puppet は優れた管理システムであり、将来の自動運用とメンテナンスに不可欠なツールです。lnmp アーキテクチャは自分で構築できます。ソースコードをインストールします
後ほど公開しますので、皆さんで議論しながら進めていただければと思います。

















http://www.bkjia.com/PHPjc/1110195.html

www.bkjia.com

tru​​ehttp://www.bkjia.com/PHPjc/1110195.html技術記事 Redhat での puppet の集中構成管理 - puppet の概要 通常、puppet は C/S 構造です。もちろん、ここには C がたくさんある可能性もあります。。