小さな男たちはどのようにパペットを効果的に学び、使用できますか？[閉まっている]

6か月前、非営利プロジェクトで、システム管理のPuppet制御環境への移行を開始することを決定しました。これは、サーバーの数が今から1年後に大幅に増加することが予想されるためです。

決定が下されて以来、私たちのIT担当者は、少々イライラしすぎています。彼らの最大の異議は次のとおりです。

• 「私たちはプログラマーではなく、システム管理者です」;
• モジュールはオンラインで入手できますが、多くは互いに異なります。車輪は頻繁に再発明されていますが、どの車輪が法案に適合するかをどのように決定しますか
• リポジトリ内のコードは十分に透明ではないため、以前に自分自身で作成したマニフェストやモジュールを再帰的に処理するために必要な機能を見つけることができません。
• 1つの新しいデーモンでは、新しいモジュールを作成する必要があります。規則は他のモジュールと同様である必要があり、難しいプロセスです。
• 「実行して、動作を確認しましょう」
• コミュニティモジュールのほとんど知られていない「拡張機能」：「trocla」、「augeas」、「hiera」...システム管理者はどのように追跡できますか？

大規模な組織がシステム管理者をPuppetコースに派遣してPuppetマスターになる理由を理解できます。しかし、小さなプレーヤーがコースに行かず、基本的にブラウザーとエディターを介してそれを学習する場合、プロレベルのPuppetを学習するにはどうすればよいでしょうか？

私は新しいインフラストラクチャを展開する前にPuppetを使い始め、そのトピックに関する（評判の良い）本を購入しました。私はほとんどの人が実際にプロのパペットのトレーニングを受けているとは思わない。プロセスを自分の環境に合わせられるようになるまで、例に取り組みました。これは2011年12月だったので、数週間以内に基本を理解し、運用フレームワークを導入することができました。CFEngineのバックグラウンドを持つ私は、構成管理に慣れていませんでしたが、システム管理者の懸念の多くは共鳴しています。私は間違いを犯し、数回リファクタリングしなければなりませんでしたが、私は物事を満足に機能させることができました。

あなたのポイントに関するいくつかのメモ...

• 従来のシステム管理の役割は変化しています。適応するか取り残される。私は成功したシステムエンジニアでしたが、同様に改造する必要があります（たとえば、Pythonを学ぶ）。仮想化によるハードウェアの抽象化と、パブリックおよびプライベートクラウドサービスが注目を集めているため、個々のサーバーへの焦点は縮小しています。これは、システムタスクの自動化と、より多くのサーバーの制御を奪取するための構成管理の使用を意味します。DevOpsの概念をミックスに追加すると、顧客/エンドユーザーの期待と要件が変化していることがわかります。

• オンラインで利用可能なPuppetモジュールは、スタイルと構造が異なります。はい、多くの重複、冗長性、重複した努力が見られました。私が一緒に仕事をした開発者の一人は、「オンラインで機能するものを探している間に自分のツールを開発できたかもしれない」と言った。Puppetは、ベストプラクティスや正しい方法を探している管理者よりも、開発者のタイプにアピールしているように見えることに気付いたので、一時停止しました。

• 物事がどのように接続されているかを把握するために、文書化する。不安定な定義と標準的な方法の欠如を考えると、構成管理構造は実際に環境に固有です。その透明性を内部で開発する必要があります。

• サーバーとロールの編成方法に応じて、新しいデーモンに対応するモジュールを複製したり、既存のマニフェストにサービスを追加したりするのはかなり簡単だと思います。

• サーバーの大きなグループに変更をプッシュする前に、1つのターゲットでテストするのに多くの時間を費やしました。代表的なサーバーでpuppetdを手動で実行すると、変更をデバッグしてその影響を評価することができました。多分それは少し保守的ですが、それは必要でした。

• コミュニティモジュールにどれだけ依存するかわかりません。仕事のためにAugeasを使い始めなければならなかったのですが、CFEngineで当然のことと思っていた機能であるという事実を嘆きました。

結局のところ、Puppetに関しては、明確に定義された標準がないと感じています。Puppetmasterでディレクトリ構造を整理する方法の理解、証明書署名の管理方法の理解、あらゆる場所での適切なリバースDNSの取得、Puppetの環境への適切な拡張、コミュニティモジュールを活用するタイミングと独自のビルドを理解するのに苦労しました。それは思考の転換であり、それがシステム管理者をパニックにする方法を私は知っています。ただし、これはゼロから構築されたソリューションでもあったため、ツールを評価する余裕がありました。この方法で進むという決定は、マインドシェアとPuppetの背後にある勢いに基づいています。何か新しいことを学ぶのは努力の価値があった。

このサイトも優れたリソースであることを忘れないでください。

以前の仕事で、私はPuppetのパイロット実装を行うタスクを割り当てられました。今、私にはプログラミングのバックグラウンドがありますが、Rubyではないので、他の人ほど問題はありません。

ただし、Puppetは宣言型であり、必須ではないため、非伝統的なパラダイムの経験のないプログラマーもPuppetに問題があることに注意してください。この意味で、Puppetは他の設定ファイルとほとんど同じように機能します。つまり、物事のあり方を言うと、Puppetが残りを処理します。

パイロットの後、私はPuppetで他の多くの管理者をトレーニングする機会があり、さらに2つのイベントでプレゼンテーションを行いました。その経験からの私の見解は、一部の管理者はそれを採用し、一部の管理者は採用しなかったということです。これらはすべて、プログラミングスキルやさまざまなレベルの専門知識を持たない従来の管理者でした。

特に気づいたのは、Puppetには常に練習が必要だということです。訓練を受け、モジュールを作成し、1〜2か月かけて何か他のことをしていた人々は、ほとんど役に立たないスキルでPuppetに戻ってきました。毎週小さなことをし続けていた人々は、能力を失うことはありませんでした。

これらの2つの観察に基づいて、毎週（できれば少なくとも2、3回）Puppetクラス、定義、またはモジュールを追加し続けることを確認することをお勧めします。まだそれに慣れることができない人は、本当にそれをするスキルを欠くかもしれません。

そして再び、もしパペットが彼らに上から課せられたなら、彼らは彼らが彼らの仕事をする方法に侵入しているマネジメントとして彼らが知覚するものに単に反応しているかもしれません-実際、それは十分真実です。使用する構成管理システムを選択できるようにすることで、状況が改善される可能性があります。いくつかの選択肢があります：

• ANSIBLE：これは新しいものですが、シェルコマンドとsshに基づいており、従来のシステム管理者を惹きつける可能性があります。
• Chef：おそらく彼らの問題は宣言的なスタイルであり、その場合、Rubyの経験があればChefの方が良いでしょう。
• SaltStack：Pythonベースのオープンソース
• CFEngine：古く、速く、伝統的-それらの理由で勝つかもしれません。

私が唯一のシステム管理者である小さな店で2年以上Puppetを使用しています。私が経験した最大のハードルは、ソフトウェアを適切に開発する方法を学ぶことです。開発者に何十回もしないように言ったことを、私が何かを台無しにしなかった一週間はありませんでした。あまりにも多くのコードをチェックインし、チェックインを分割せず、タグを付けず、分岐しませんでした。構文チェッカーを実行しませんでした。標準を使用しませんでした。 out以下のいくつかをお勧めします。

1. 方法がわからないか、パフォーマンスが悪いソフトウェアを開発していることを認識してください。これは新しいため、期待されています。
2. コードとしてのインフラストラクチャが現実であり、いったんこぶを乗り越えると、非常に強力になります。一部の開発者を招待し、現在の開発プロセス（またはその欠如）を見せ、眉を上げるときに不快感を抱かず、提案を真剣に受け止めます。完全に不適切でない限り、開発者が使用するシステムとプロセスを使用することをお勧めします。
3. Puppetサードパーティモジュールは、時間の90％を消費します。私はそれらを読みました。私は彼らからアイデアを盗みます。大幅な編集を行わなければ、システムにそれらを取り込むことはありません。ただし、いくつかの便利な機能を追加するパペットstdlibを使用します。
4. オージェとヒエラ。これらの2つを学びます。最初の方法では、既存のファイルを適切に編集できます。2番目は外部データストアです。
5. データからコードを分離します。これは、学ぶのが難しい概念の1つです。ホストの監視などの値をモジュールコードにハードコーディングするのは不適切です。モジュールが消費できるデータストア（db、yaml（Hieraはこれをデフォルトとして使用）、csvなど）に格納することは適切です。例は、Mysqlを使用するwebappです。これにより、コードとデータを別々にプッシュできるようになります。これにより、開発プロセスが簡単になります。
6. puppetパーサーは、コードチェックインプロセスの前または後の一部として、puppet-lintを検証します。また、速度が上がったらrspecテストもお勧めします。
7. スタイルガイド/コード標準を作成して使用します。「Apacheをインストールするコードはどこにありますか」はよくある問題です。モジュールがほぼ同じであれば、簡単です。

要約すると、私はこれらすべての問題にぶつかったので、システム管理者の友人のほとんどもそうでした。構成管理システムの使用に慣れるには時間がかかります。一度やれば、あなたはこれなしでどうやって生きてきたのだろうかと思うでしょう。「サーバーにログインして、手動で変更しますか？Ick。」

6か月前、非営利プロジェクトで、システム管理のPuppet制御環境への移行を開始することを決定しました。これは、サーバーの数が今から1年後に大幅に増加することが予想されるためです。

早めに始めるのはいいアイデアのように聞こえます-Puppetは単なる構成管理ではなく、ドキュメントの形式です。

決定が下されて以来、私たちのIT担当者は、少々イライラしすぎています。

彼らは態度の調整が必要です。

"We're not programmers, we're sysadmins";

再び、態度。サーバーのconfファイルを作成できますか？ニーズと複雑さが進化するにつれて、テンプレート化/「プログラマー」に慣れることができます。

モジュールはオンラインで入手できますが、多くは互いに異なります。車輪は頻繁に再発明されていますが、どの車輪が法案に適合するかをどのように決定しますか

答えが難しい-私は常にほとんどの場合よりpuppetlabsモジュールを好む-そしてそれでさえ、私はそれほど多くを使用しない。判断は確かに呼び出します。私の意見では、いくつかのモジュールは「あまりにもフリル」です。

リポジトリ内のコードは十分に透明ではないため、以前に自分自身で作成したマニフェストやモジュールを再帰的に処理するために必要な機能を見つけることができません。

これはパペットの問題のようには聞こえませんが、組織やドキュメントの問題ではありませんか？

1つの新しいデーモンでは、新しいモジュールを作成する必要があります。規則は他のモジュールと同様である必要があり、難しいプロセスです。

そのデーモンは、管理するのに十分簡単であれば、クラスになり得ます。私はあなたが規則によって何を意味するのか分かりません、人形はあなたに規則をかなり強制しますよね？それとも、コードのフォーマットの行に沿って話しているのですか？

"Let's just run it and see how it works"

ゆっくりと安全に考えれば、それほど悪くはありません。物事の要点をつかむために、私はまだVMから始めます。

コミュニティモジュールのほとんど知られていない「拡張機能」：「trocla」、「augeas」、「hiera」...システム管理者はどのように追跡できますか？

postfix、exim、sendmail、mysql、postgresql、iftop、iptraf、perl、perlモジュール..必要なものを選択して使用しますか？この音は再び態度のようなものだと思います...

大規模な組織がシステム管理者をPuppetコースに派遣してPuppetマスターになる理由を理解できます。しかし、小さなプレーヤーがコースに行かず、基本的にブラウザーとエディターを介してそれを学習する場合、プロレベルのPuppetを学習するにはどうすればよいでしょうか？

私はどのコースにも参加していません-私はシステム管理者以上のプログラマーですが、何かを達成するのにプログラミングスキルは必要ないことがわかりました。

Puppetのドキュメントは、非常に徹底しています。組み込みのタイプに注意を払い、他のモジュールがどのように組み合わされるかを見てください。とても簡単だとは言いませんが、難しいことでもありません。インフラストラクチャをPuppetに対応させるのは少し時間がかかりますが、投資する時間は拡張時に十分に費やすことが保証されています。

KISS（単純な愚かさを保つ）-新しいテクノロジーが必要だからという理由だけでなく、展開に必要な最低限の機能を使用し、必要に応じて更新するので、新しいテクノロジーを使用しないでください。縁。基本的なセットアップから始めてその上に構築する場合、移動するときに簡単にピックアップでき、コースは必要ありません（これらも利用可能ですか？）。

あなたが見ることができる他の領域はあなたのシステム管理者です。プログラミングができない場合、使用するツールに関係なく、ほとんどの作業をスクリプト化する必要がある大規模な展開に十分対応できますか？

私も非営利で働いており、最初にLinuxボックスを社内に持ち込み、その後すぐにそれらを管理するためにPuppetを担当しました。私たちがやった特定の事柄がいくつかありますが、それは本当に物事を動かすのに役立ちました。

何よりもまず、サードパーティのモジュールから離れようとしました。組み込みツールは、管理の90％を処理します。私が使用する最大のサードパーティユーティリティは、ファイアウォールモジュールです。カスタムファクトなどは、チーム全体で開発されます。テンプレートモジュールを開発し、ファイル管理、パッケージ、サービスなどをすべてこのテンプレートから標準化しました。

第二に、組み込みモジュールの使用を標準化した後、すべての構成変更のレビューを実行するために、GitとAtlassianのCrucibleを使用しました。これにより、必要な透明度が提供されます。

第三に、Puppetのセットアップを自動化して、新しいホストをデフォルトのオプションセットで自動的に追加できるようにしました。これに対処する方法はいくつかあります。すでに完全なキックスタート環境があったので、そこにスクリプトを追加することにしました。

「私たちはプログラマーではなく、システム管理者です」

悪い方のために私の時間が変更されているか、：私のような老いをされた期待のプロのプログラマーより良いプログラマである、または他のために合格することができたことがないだろう、システム管理者。

現在、「システム管理者」がいます。これは基本的にWindowsデスクトップユーザーであり、ある時点でLinuxに変換されており、プログラミングできず、それに関して何も問題はありません。

部屋の象は、経営者がそのような破壊的な態度を容認する理由です。誰に、または何を破壊しますか？ビジネスとインフラストラクチャへ。

Puppet [、CFEngine、Chef]の主題に戻ります。そのようなソリューションを設定するとすぐに負けます。みんな負けます。どうして？アイデアを思いついた人はだれでも、すてきできれいなKickstart [、JumpStart、自動インストーラ、AutoYaST、Ignite-UX、NIM]オペレーティングシステムパッケージの形でカプセル化された構成管理を設計することができません。Puppet（またはChef、またはCFEngine）のような自動化されたハッキン​​グツールを使用する必要がある場合、同じ設計により完全に初期状態を維持し、管理対象システムを完全に消すプロセスを設計および実装する場所が不足していることを意味します自動化され、完全に非インタラクティブです。

もう1つの重要な点は、システムまたはアプリケーションの構成をハッキングする誰かを手作業で修正するために Puppetまたはそのようなソリューションが必要な場合、プロセスを設計する経験がなく、そのプロセスで構成がパッケージ化されたフレームワークを使用することに戻ることです個別のコンポーネントに。実際、Puppetなどを実装する人は誰でも、コンポーネントの所有者、リリース、構成管理、Capability Maturity Modelの概念を持ちません。これは、業界で非常に深刻な問題に急速に発展しています。

Puppetを使用することで、Rubyを学ぶことができました。これは、Bashをデフォルトのシステムツール言語として置き換えるようになりました。」

Bourneシェルプログラム、AWK、sedを使用するだけで、包括的なエンドツーエンドの構成管理をオペレーティングシステムパッケージのプレインストール、ポストインストール、プレ削除、ポスト削除セクションにカプセル化できるのに、なぜRubyが必要なのですか？誰かがRubyの難解な言語、そしてPuppetの文脈におけるその方言を習得することを完全に不要にすることは完全に不要です。構成管理の問題は、シェルプログラムとAWK、および接着剤としてのsed（1）のあちこちで簡単に解決できます（つまり、解決済みです）。

Puppetマニフェストがマシン全体または新しいサービスをゼロから設定するのを見るのはクールな気持ちです。

Kickstart、AutoYaST、またはJumpStart でコードを1行も使わずに実行でき、難解なソフトウェアや追加のソフトウェアを必要とせず、組み込みツールを使用してオペレーティングシステムにクエリを実行できるので、クライアントサーバーは不要です。必要なアーキテクチャ（SSHは非常に優れており、はるかに優れています）、およびオペレーティングシステムがそれに加えられたすべての変更を認識していることを確認します。

5.データからコードを分離します。これは、学ぶのが難しい概念の1つです。ホストの監視などの値をモジュールコードにハードコーディングするのは不適切です。モジュールが消費できるデータストア（db、yaml（Hieraはこれをデフォルトとして使用）、csvなど）に格納することは適切です。例は、Mysqlを使用するwebappです。これにより、コードとデータを別々にプッシュできるようになります。これにより、開発プロセスが簡単になります。

...それとも単に可能性テンプレート（例えば、シェル変数でも、バッククォートをコンフィギュレーションファイルをls -1 ...）とはeval（1）を呼び出すことにより、強力な正確に同じを活用し、テンプレート内のすべての変数を展開するAWKを使用してシェルスクリプトを書きますシェルに組み込まれているパーサー。本当に簡単にできるのに、なぜ複雑にするのですか？構成値をどこに保存しますか？たとえば、pkginfo（4）ファイル、Oracleなどのデータベース、またはほぼどこでも、どこでも好きな場所に。超複雑なソリューションは必要ありません。私は上記の言及ライブラリが簡単にでき調達することにより、重複を除去して、コードの中央部分を活用して、オペレーティングシステムのパッケージにプリインストールまたはインストール後のセクションから...

しかし何よりも、上記の引用は、システム管理者ではなくシステムエンジニアによる個別指導を必要とする次世代のシステム管理者の例であることがわかりました。自分で白ひげを見つけ、見習いとしてサインオンします。