タグ付けされた質問 「puppet」

6か月前、非営利プロジェクトで、システム管理のPuppet制御環境への移行を開始することを決定しました。これは、サーバーの数が今から1年後に大幅に増加することが予想されるためです。 決定が下されて以来、私たちのIT担当者は、少々イライラしすぎています。彼らの最大の異議は次のとおりです。 「私たちはプログラマーではなく、システム管理者です」; モジュールはオンラインで入手できますが、多くは互いに異なります。車輪は頻繁に再発明されていますが、どの車輪が法案に適合するかをどのように決定しますか リポジトリ内のコードは十分に透明ではないため、以前に自分自身で作成したマニフェストやモジュールを再帰的に処理するために必要な機能を見つけることができません。 1つの新しいデーモンでは、新しいモジュールを作成する必要があります。規則は他のモジュールと同様である必要があり、難しいプロセスです。 「実行して、動作を確認しましょう」 コミュニティモジュールのほとんど知られていない「拡張機能」：「trocla」、「augeas」、「hiera」...システム管理者はどのように追跡できますか？ 大規模な組織がシステム管理者をPuppetコースに派遣してPuppetマスターになる理由を理解できます。しかし、小さなプレーヤーがコースに行かず、基本的にブラウザーとエディターを介してそれを学習する場合、プロレベルのPuppetを学習するにはどうすればよいでしょうか？

109 puppet  configuration-management 

PuppetおよびChefツールの新機能。彼らがやっている仕事は、シェルスクリプトでできるようです。これらが登場するまで、シェルスクリプトで行われたのかもしれません。 それらがより読みやすいことに同意します。しかし、読みやすいだけでなく、シェルスクリプトに勝る他の利点はありますか？

81 scripting  puppet  chef  configuration-management  provisioning 

「既存の実稼働EL5サーバーをEL6にアップグレードできますか？」 環境がまったく異なる2人の顧客からのシンプルな要求により、「はい、しかしすべてのシステムを調整して再構築する必要があります」という私のベストプラクティスの答えが得られました。 両方のクライアントは、システムの完全な再構築がダウンタイムとリソースの理由から受け入れられないオプションであると感じています...システムを完全に再インストールする必要がある理由を尋ねられたとき、私はそれ以上の良い答えを持っていませんでした...」 構成管理（「すべてを人形化する」が常に当てはまるわけではありません）またはクライアントがどのように計画を立てるべきかについての応答を引き出すつもりはありません。これは、実稼働環境で成長し繁栄した環境の実例ですが、OSの次のバージョンに移行するための明確な道はありません。 環境A： 40 x Red Hat Enterprise Linux 5.4および5.5 Web、データベースサーバー、メールサーバーを備え、Java Webアプリケーションスタック、ソフトウェアロードバランサー、Postgresデータベースを実行する非営利組織。すべてのシステムは、それぞれがHA、DRSなどを備えた、異なる場所にある2つのVMWare vSphereクラスターで仮想化されます。 環境B： 生産取引業務を実行し、社内開発およびバックオフィス機能をサポートする複数のコロケーション施設に200 x CentOS 5.xシステムを備えた高周波金融取引会社。取引サーバーは、ベアメタルのコモディティサーバーハードウェアで実行されています。メッセージングレイテンシを低減するために、多数の、、割り込みバインディング、およびドライバー調整が用意されています。カスタムカーネルやリアルタイムカーネルを備えているものもあります。開発者ワークステーションも同様のバージョンのCentOSを実行しています。sysctl.confrtctl どちらの場合も、環境は現状のまま正常に動作しています。アップグレードしたいのは、EL6で利用可能な新しいアプリケーションまたは機能が必要だからです。 非営利企業にとっては、Apache、カーネル、および開発者を喜ばせるものに結びついています。 商社では、カーネル、ネットワークスタック、およびGLIBCのいくつかの機能強化について、開発者を満足させます。 どちらもオペレーティングシステムを大幅に変更せずに簡単にパッケージ化または更新できないものです。 システムエンジニアとして、Red Hatはメジャーバージョンリリース間を移動する際に完全な再構築を推奨しています。クリーンスタートでは、途中でリファクタリングを行い、構成に注意を払う必要があります。 クライアントのビジネスニーズに敏感であるため、なぜこれが面倒な作業である必要があるのでしょうか。RPMパッケージングシステムはインプレースアップグレードを処理する以上の機能を備えていますが、それ/boot以上の詳細はありません：より多くのスペース、新しいデフォルトファイルシステム、RPMが途中でアップグレード、非推奨、廃止されたパッケージを破壊する可能性があります... ここでの答えは何ですか？他のディストリビューション（.debベース、ArchおよびGentoo）には、この機能またはより良いパスがあるようです。このタスクを正しい方法で達成するためのダウンタイムを見つけたとしましょう。 EL7がリリースされて安定した場合、これらのクライアントは同じ問題を回避するために何をすべきですか？ それとも、人々は数年ごとに完全な再建に辞任する必要があるのでしょうか？ これは、Enterprise Linuxが進化するにつれて悪化しているように見えます...または、私はただそれを想像していますか？ これにより、だれかがRed Hatおよび派生オペレーティングシステムを使用することを思いとどまらせましたか？ 構成管理の角度があると思いますが、私が見るほとんどのPuppetインストールは、高度にカスタマイズされたアプリケーションサーバーのある環境にうまく変換されません（環境Bは、ifconfig出力がこのように見える単一のサーバーを持つことができます）。ただし、組織がRHELのメジャーバージョンバンプを克服するのに構成管理を使用する方法についての提案を聞くのは興味深いでしょう。

72 linux  centos  redhat  puppet  configuration-management 

私は一般に構成管理を通じて自分のやり方を学び、特にそれを実装するためにパペットを使用していますが、システムのどの側面がパペットで管理されるべきではないのでしょうか？ 例として、通常、システムをpuppetの管理に貸す前に、ホスト名がすでに設定されていることを当然のことと考えています。少なくともpuppetmasterに到達するために使用されるネットワークでは、基本的なIP接続が機能している必要があります。puppetを使用してDNSゾーンファイルを自動的に作成するのは魅力的ですが、DNSリバースポインターは、Thingを起動する前に既に配置されている必要があります。証明書は面白くなります。 したがって、PuppetからIP構成を除外する必要がありますか？または、パペットを初めて起動する前に設定する必要がありますが、それでもパペットでIPアドレスを管理する必要がありますか？複数のIPを備えたシステム（WAN、LAN、SANなど）はどうですか？ 何についてのIPMI？すべてではありませんが、ほとんどをipmitoolで設定すると、コンソールアクセス（物理、シリアルオーバーLAN、リモートKVMなど）を取得せずに済むため、Puppetで自動化できます。しかし、パペットエージェントを実行するたびにその状態を再確認することは私にとってはクールではありません。システムへの基本的なライトアウトアクセスは、他に何もする前に持っておきたいものです。 もう1つのストーリーは、更新プログラムのインストールに関するものです。私はこの特定のポイントには行きません。SFに関する多くの質問と、異なるシステム管理者の間の多くの異なる哲学が既にあります。私自身は、操り人形に物事を更新させないようにし（例のみensure => installed）、既に慣れているため手動で更新を行うことにしました。ミックス）。 これらは、今思い浮かんだほんの数例です。パペットから手の届かないところに残すべきシステムの側面はありますか？または、別の言い方をすれば、プロビジョニング時に設定する必要があるものと、システムで「静的に」設定されるものと、一元化された設定管理によって処理されるものとの境界はどこにありますか？

67 linux  puppet  configuration-management 

私はpuppetを使用して、debianサーバーのクラスターを管理しています。クラスター上の各マシンのタイムゾーンを変更する必要があります。これを行う適切なdebianの方法はを使用することdpkg-reconfigure tzdataです。しかし、ダイアログを使用する場合にのみ変更できるように見えます。これをシェルから自動化する方法はありますか？Execを書くだけで簡単にできますか？ そうでない場合、私は次の最善の方法は、おそらく人形を配布持っているだろうと思う/etc/timezoneと/etc/localtime、クラスタ全体で正しいデータで。 どんな入力でも歓迎します！

60 debian  puppet  timezone  dpkg  debconf 

私はすでにグーグルで「人形に、またはシェフに」という記事を読みました。 私は、ユースケース、つまり人々が実際の問題に基づいてどちらかを選択した現実世界の実装に興味があります。 私は特にコブラーの問題との統合に興味があります（この方向ではパペットがはるかに標準的なアプローチであることはわかっています）。cobbler-chef統合の経験はありますか？ 前もって感謝します

56 rhel5  puppet  configuration-management  cobbler  chef 

puppet agent新しいイメージから呼び出しを行うと、err: Could not find class custommodエラーが発生します。モジュール自体は、/etc/puppet/modules/custommod私たちが呼び出している他のすべてのモジュールと同じですが、これは頑固です。 [site.pp] node /clunod-wk\d+\.sub\.example\.local/ { include base include curl include custommod class{ "custommod::apps": frontend => "false} [...] } puppetmasterをデバッグ出力で実行すると、baseおよびcurlの情報が明確に見つかります。 debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production debug: Automatically imported base from base into production debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production debug: Automatically imported curl from …

31 puppet  puppetmaster 

私の組織では、NOCスタッフのグループ、新進気鋭のジュニアエンジニア、少数のシニアエンジニアと協力しています。すべてLinuxに焦点を当てています。会社が才能を伸ばす方法の1つの興味深いステップは、NOCから上級エンジニアリングランクへの道があることです。人材プールを相対的な新参者とみなすと、スキルセットに分裂があり、時間とともに成長する傾向があることがわかります... 1つまたは複数の特定の技術を熟知し、常に没頭しているエンジニアがいます。たとえば、MySQL、ファイアウォール、SANストレージ、ロードバランサーなどです。 ジェネラリストであり、複数のテクノロジーをナビゲートできる人もいます。 すべての人が、必要なことを実行して日常的に使用するのに十分なLinux（コマンド、プロセス）を学習します。 一部のスタッフ間の差別化要因は、スクリプト、自動化、および構成管理の方法論をどれだけうまく取り入れているかです。たとえば、Amazon AWS CloudFormationの大部分の作業を行う2人のエンジニアと、Puppetインフラストラクチャのほとんどを処理するエンジニアがいます。おそらくエンジニアの4分の1がBASHシェルスクリプトに精通しています。 雇用市場でのDevOpsスキルに対する非常に高い需要の文脈でこれを見ると、他の組織がどのようにこれらのスキルの開発を促進し、社内の才能を伸ばしているのか興味があります。スクリプティングは、特に教えることのできる概念とは思えません。 システム管理者はシェルスクリプトをどのように改善しますか？ DevOpsパラダイムに遅れている/遅れているエンジニアのための場所はまだありますか？ これらの技術が進化するにつれて、一部の人々が取り残されると単純に想定していますか？それは大丈夫ですか？

30 linux  scripting  puppet  automation  configuration-management 

私はシェフまたはパペットを使用して管理を行います（若いため、シェフのことを考えているので、より良い気持ちになります）。 どちらのホームページにも、お金がかかる「エンタープライズ版」があり、何も買おうとは思っていませんでした。シェフ/パペットを買わないと見逃しますか？ 正確にお金がかかるシェフが提供するものは何ですか？ 正確にお金がかかる人形は何を提供しますか？ それは彼らのウェブサイトから私にはあまり明確ではありませんでした。

30 puppet  chef 

これはおそらく、構成管理ツールを既に実行しているユーザーにとっては簡単な質問です。PuppetやChefなどの構成管理ツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？ 主にDebianとUbuntuに基づいた多数のサーバーを実行するとします。構成管理ツールを使用すると、セキュリティの更新やバグ修正が行われたときにリポジトリからインストールされたパッケージを簡単に更新できますか？ 現在、システムにセキュリティ更新プログラムを自動的にインストールさせるために「無人アップグレード」を実行していますが、それでもサーバーに接続してaptitude update && aptitude safe-upgrade頻繁に実行する必要があります。当然、これは退屈で退屈でエラーが発生しやすくなります。 PuppetやChefなどのツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？これらのツールを使用aptitudeして、15台のサーバーで手動または同等のツールを実行しないようにしていますか？これらの質問に対する答えは「もちろんです！」です。 しかし、この特定のユースケースに関する詳細情報はどこで入手できますか？PuppetやChefを詳しく調べる時間はまだありません。サンプルのクックブックまたはクラスでは、sshなどの特定のパッケージをインストールするというささいな例しか示していません。公式のドキュメント以外に、推奨するリソースはありますか（もちろん、もしあれば、どのツールが自分に適しているかがわかったらドキュメントを勉強します）。

28 ubuntu  debian  puppet  configuration-management  chef 

ローカルソースdebファイルからpuppetを使用してdebパッケージを更新/アップグレードする適切な方法を見つけようとしています。私の現在の設定は次のようになります... class adobe-air-2-0-4 { file { "/opt/air-debs": ensure => directory } file { "/opt/air-debs/adobeair-2.0.4.deb": owner => root, group => root, mode => 644, ensure => present, source => "puppet://puppet/adobe-air-2-0-4/adobeair-2.0.4.deb" } package { "adobeair": provider => dpkg, ensure => installed, source => "/opt/air-debs/adobeair-2.0.4.deb" } } 最初にdebファイルをクライアントマシンにコピーしてから、プロバイダーを「dpkg」に設定して「package」を使用します。これは機能し、正しいバージョンがインストールされます。 私の質問は、今後このパッケージを更新する適切な方法は何ですか。ソースファイルを変更するだけで、人形はそれが異なるバージョンであることを認識し、このパッケージを更新できますか？puppetは、インストールしたパッケージのバージョンとソースdebファイルのバージョンをどのように判断しますか？ 私はpuppetが初めてなので、既存の設定を改善するための提案があれば、とても感謝しています。

27 debian  package-management  puppet  update  dpkg 

パペットに特定のことを最初に強制する方法はありますか？たとえば、パッケージをインストールする前に、すべてのサーバーにRPMをインストールしてyumリポジトリー（IUSコミュニティー）を追加する必要があります。

26 puppet 

バックグラウンド： 私はついに、21世紀に参加してPuppetを見る時間を取っておきます。 現在、私たちはオフィスで内部的に保持されているリポジトリ内のすべてのサーバー構成をバージョン管理しています。更新を行う必要がある場合、変更はリポジトリにチェックインされ、問題のマシンに手動でプッシュされます。これは通常、リモートマシンにSFTPを実行し、関連する権限でシェルからファイルを所定の場所に移動することを意味します。 ですから、Puppetが私たちが既に持っているもののシンプルでありながら驚くべき拡張になることを期待しています。 今、私たちは現在、合理的に安全でなければならないプロセスを検討します。私たちの内部ネットワークは、データセンターのパブリックネットワークよりも常に比較的安全であるという前提で。 プロセスは常に一方向です。変更は安全な環境から安全でない環境へと行き来し、その逆はありません。 マスターストアは可能な限り安全な場所にあります。構成を盗んだり、悪意のある変更を送信したりすることによる侵害のリスクが大幅に削減されます。 質問： 私がPuppetサーバー/クライアントモデルについて理解しているのは、クライアントがサーバーから更新を直接ポーリングしてプルするということです。トラフィックはSSLでラップされているため、傍受やなりすましはできません。ただし、Puppetサーバーは公共の場所でホストする必要があるため、現在の処理とは異なります。中央、または当社が管理する各データセンターサイトに1つ。 だから私は疑問に思っています： プッシュからプルへの変更について不必要に偏執的ですか？ その情報のすべてをパブリックネットワークに一元的に保存することについて、私は不必要に妄想的ですか？ 他の人はどのように複数のネットワークを維持していますか？各サイトに別々のサーバー？ 更新日30/07/09： 私の他の大きな懸念の1つが置かれていると思うので、単一のマシンを信頼する必要があります。操り人形師は、ファイアウォールで保護され、保護されます。それでも、リスニングサービスを備えたパブリックマシンには、特定のサイズの攻撃対象領域があります。 おそらく、マスターがパペットクライアントのいずれかのファイルを更新する権限を持っている場合、その侵害は最終的にすべてのクライアントの侵害につながります。いわば「王国への王」。 その仮説は正しいですか？ 軽減できる方法はありますか？

26 networking  security  puppet 

サーバーフォールトで回答できるため、 この質問はStack Overflowから移行されました。 9年前に移行され ました。 Puppetでは、管理対象のクライアント（puppet）とサーバー（puppetmaster）の間に証明書が必要です。クライアントで手動で実行してからサーバーに移動して証明書に署名することはできますが、クラスター/クラウドマシンのこのプロセスをどのように自動化しますか？

26 cluster  puppet  cloud 

PuppetやChefなどのより確立された構成管理（CM）システムは、プルベースのアプローチを使用します。クライアントは、更新のために集中マスターを定期的にポーリングします。それらのいくつかは、提供マスターレスのそれは（Saltstack）や「以下スケーラブル」（人形）の生産のためではない」であること（そう、プッシュベース）にもアプローチしますが、状態。私が知っている唯一のシステムは、最初からプッシュベースです。次点のAnsibleです。 プルベースのシステムの特定のスケーラビリティの利点は何ですか？プッシュエージェントよりもプルマスターを追加するほうが簡単なのはなぜですか？ たとえば、agiletesting.blogspot.nlは次のように記述します。 「プル」システムでは、クライアントは互いに独立してサーバーに接続するため、システム全体は「プッシュ」システムよりもスケーラブルです。 一方、Rackspace は、プッシュベースのモデルで15Kシステムを処理できることを実証しています。 infastructures.orgの書き込み： SUP、CVSup、rsyncサーバー、またはcfengineなどのツールを使用して、インフラストラクチャを維持するためのプル方法論を誓います。クライアントに変更をプッシュするのではなく、個々のクライアントマシンは、起動時およびその後定期的にゴールドサーバーをポーリングして、独自の回転レベルを維持する必要があります。この観点を採用する前に、ssh、rsh、rcp、およびrdistに基づいたプッシュベースの広範なスクリプトを開発しました。rコマンド（またはssh）で見つかった問題は次のとおりです：rコマンドベースのスクリプトを実行してターゲットマシンに変更をプッシュすると、30を超えるターゲットホストがある場合、そのうちの1つがいつでもダウンしている。委託されたマ​​シンのリストを維持することは悪夢になります。これを修正するコードを書く過程で、あなたは対処するための精巧なラッパーコードになります：死んだホストからのタイムアウト。デッドホストのロギングと再試行。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで使用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その場合、将来インストールするすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得するだけでなく、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題があります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで使用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その場合、将来インストールするすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得するだけでなく、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題があります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。またはそのことについて他のプッシュメカニズムを使用します。プルベースの方法と同様にスケーリングしません。またはそのことについて他のプッシュメカニズムを使用します。プルベースの方法と同様にスケーリングしません。 それは、アーキテクチャの問題ではなく、実装の問題ではありませんか？スレッドプルサーバーよりもスレッドプッシュクライアントを記述する方が難しいのはなぜですか？

22 puppet  chef  configuration-management  ansible  saltstack