要約 ：既存の構成システムのいずれかを学習させ、サーバー上のファイルの編集を手動で停止させる方法。

この投稿は、克服する必要がある精神的苦痛に捧げられています。 ポストにも少し技術的なものがありますが、ほとんどの場合、ポストはあなた自身との戦い、報酬の遅延、そしてあなたがどのくらいの量の運動記憶をコントロールしているかに専念します。

構成管理システムとは何かを聞いたことがない隠者の紹介

何年もの間（IT標準による-3世代）、サーバー構成プロセスを自動化できるプログラムがあります。 これらのプログラムはすべて複雑であり、管理者の聖なるものに侵入し、「すべてが以前と同じではない」ことを強制します。 彼らの研究と内在化（「必要であり、とても正しい」という認識）は、システム管理者のキャリアにおいて絶対に必要なものです。

構成管理システムの主な痛み

主な痛みは、構成管理システムが使い慣れた指の自動化を壊すことです。 以前は、画面を見ることなく、2分でWebサーバーを持ち上げることができました。 これで、構成管理システムを熟知している場合はまったく同じアクションに15〜20分を費やすか、学習する場合は数日（!!!!!）を費やすことができます。

これは個人の有効性に対する犯罪です。 それを10（0xA）倍に減らします-そして、彼らは何を進歩と呼びますか？

他のすべての議論に関係なく、この考えはいつもあなたを悩ませます。 年後でも。 同じことをするためにボタンを押すだけでなく、遅くする必要があり、コンピューターを待つ必要があります（エディターがファイルを「編集」し、Webサーバーを再起動するまで数十秒待つ必要はありません）。 さらに悪いことに、configでプリミティブコンストラクトを記述すると、DSL（学習する必要のある特別なバードプログラミング言語）の余分なスペースを処理する必要があります。 信じられないほど複雑な外部のゴミについて考える ロボットに特別なサービスを提供します。 デバッグは悪化し、うんざりします-構成のタイプミスによる通常のエラーメッセージの代わりに、2画面出力シートのオーバーシェアが不鮮明になり、「手作業で行う」よりも読むのに時間がかかります。

さらに悪いことに、これらのシートはあなたの行動に関係しないことが多いが、プロジェクトの他の場所での完全に一貫性のない変更です。 そして、あなたはそれらに対処することを余儀なくされます。 場合によっては、構成管理システムのバグでさえあり、直接作業を行う代わりにバグを修正/回避します。

さて、このテクノロジーをどのように「販売」しましたか？ 職場でそれを実装しようとすることからあなたの全力で反撃する準備ができていますか？

構成管理システムについて説明する前に、心理学の非常に実例となる例でマシュマロの実験を示したいと思います。 ウィキペディアを読むのが面倒な人のために、言い直し：子供たちはマシュマロを与えられ、彼らは15分以内にマシュマロを食べなければ、彼らは秒を与えられると言います（そして両方とも食べることができます）。 年長の子供ほど、15分間続く可能性が高くなります。 子供は自分を抑えてすぐにマシュマロを食べることはできませんが、それはmar辱になります。 この実験では、「遅れた喜び」のメカニズムをテストします。

これは、まさに構成管理システムが提供するものです。 3分で手でできる操作に30分費やし、3分もかからずに（必要に応じて）この操作を何度も実行できます。 そして最も重要なことは、頭を巻き込むことなく。 ほとんどの場合、この手順はCIサーバー（jenkins、buildbotなど）に委任され、これによりCI / CDと呼ばれる魔法の扉への最初のステップの扉が開かれます。

ステージング

そして、この小さなステップは「ステージング」と呼ばれます。 何もしないプロダクションのコピー。 「サーバーのバージョンを変更するとどうなりますか？」という質問に対する答えが表示されます。 制作を中断することなく、他の面白い実験を行います。

もちろん、構成管理システムなしでステージングを実行できます。 しかし、ステージングが本番に似ていることを誰が確認しますか？ さらに、あなたのばかげた実験の後、誰がそれに従うのでしょうか、ステージングは​​まだ生産のように見えますか？ 前の面白い実験の結果に対して面白い実験をしている場合、おそらくその結果は本番の後半で起こることとは異なるでしょう。

この質問は「誰が従うのか？」です。 実際にサブショットで。 ステージングをフォローしている人が数人いる可能性のある巨大な誇張状態がない場合、その答えは「誰もいません」です。 誰もフォローしていません。 どうする？

答え：「地面まで破壊します」とゼロから再作成します。 このプロセスで人が1分以上かかる場合、もちろん誰もこれを行いません。 「ばかげた実験」を修正するために何度も同じことをするのはあまりにも憂鬱です。

通常の考え：「なぜそれを上げます、今私はすべてを私の手に戻すでしょう、それはより速いです。」 出力は、「実験のコピー」ではなく、面白​​い実験とその修正の結果です。

しかし、「自分ですべてを実行する」ロボットがあれば、問題ありません。 行ってやった。

ステージングの伝播

ステージングを簡単にアップグレードできる場合は、別のインスタンスで上げてみませんか？ それはもっと簡単かもしれません。重要で複雑な重いコンポーネントはありませんが、あなたが今取り組んでいる適切な部品です。

また、ローカルホスト、仮想マシンまたはコンテナに配置することもできます。 これにより、職場での待ち時間がほとんどなく（すてき）、オフラインサポート（便利）が得られます。 これには、構成管理システムで少し作業が必要になりますが、見かけよりはるかに少ないです。 それから-tyk-tykとあなたはプロダクションのコピー（またはgitaからの機能ブランチに固有のもの）の新鮮な部分を持っています。

リファクタリング

複数のサーバーを運用環境に変えるプロセスを書面で作成し、何度も何度も（少しの労力で）繰り返すことができたら、このプロセスの一部を（より便利な/正しい/ファッショナブルなプロセスに）自由に変更して、何が起こったのかを確認できます。

これには、構成管理システムの2番目の部分であるサーバー検証が必要です。 これについては後ほど説明しますが、今のところは単純なアイデアに焦点を当てます。サーバーの構成プロセスで何かを変更して、何が起こるかを確認することができます。 無料で。 （自分から：よくわからないときは、最適なものを選択するために、異なる段階で2〜3つのバージョンを並行して実行することがあります）。

コードレビュー

構成管理システムの指示をリファクタリングしてgitに保存すると、コードレビューを実施できます（チームに複数の人がいる場合）。 コードレビューはクールです！ 最初に、彼は曲率を残さないことを訓練します。 第二に、より良い方法をお互いから学びます。 第三に、プロジェクトとプロジェクトで行われた変更に関する相互知識を増やします。 ci / cd行を作成すると、一時的なインストールで提案された変更を実行した結果を見ることができます。また、ロボットは「すべてを壊す」ため、プルリクエストをラップできます。

テスト

構成管理システムに関する一連の指示がある場合は、結果を確認できます。 これには、testinfra、goss、inspec、serverspecなどの興味深いソリューションがたくさんあります。 実際、これらのテストでは、構成を適用した結果を検証できます。 たとえば、「ポート80でリッスンしている」、「監視で180個のチェックが表示された」、「ユーザーXがサーバーにログインできる」などです。 このようなテストが表示されたら、好きなだけプロセスを試すことができます。テストに合格したら、すべてを正しく行いました。 これにより、予期しないことを恐れずに新しい（厚かましい）ものを試すことができます（たとえば、「ああ、SSLを有効にするとすべての監視が中断されるとは思わなかった」）。

雇用保障

構成管理システムは、スキルの低いシステム管理者の仕事を直接脅かします。 以前に20人の管理者が必要で、それぞれが20台のサーバーを管理できた場合、3人のチーム（もう少し資格のある管理者）が400台のサーバーに完全に対応できます。 実際、対処することもできますが、2〜3はチームの能力を高め、低音の要因（1人の知識の集中）を減らし、仕事の質に対する相互の責任によりチームの雰囲気を改善します。 また、仕事のセキュリティを使用すると、すべてが簡単になります。 これら3人の管理者のリストに載っているのか、いないのかのどちらかです。

実際、私は少しcで、現実は通常次のように見えます：60台のサーバーの代わりに、3人の管理者が400（1000？2000？）台のサーバーを所有しており、「別の17人の管理者を雇う」オプションは予算上の理由から単に価値がありません。 しかし、これらは成長市場と有能な人材の不足の特徴ですが、一般的な議論は依然として残っています：構成管理システムは労働効率を高め、労働効率が高い人々は市場でより多くの需要があります。

注意が必要な別のプログラム

上記の必要性のすべての積極性のために、任意の構成管理システムは単なるプログラムです。 これは、バグがあることを意味します。 それをすることを要求するin辱的なものを含めることは、バグを回避するためだけに不便でいです。 これは、プログラマーがプロジェクトの方向性について異なるビジョンを持っているために、明らかなアーキテクチャー機能が実現されないことを意味します。 これは、ドキュメント部分の代わりに「ドキュメント」（ src



ディレクトリにある）があることを意味します。 他のプログラムと同様に、時間、能力（そしてさらに学習する時間）を与えて、内なる世界に注意を払う必要があります。

そして再びパラダイムシフトについて

このすべて（バグと深い内なる世界を含む）-思考をモデルに適応させる必要がありますが、これは構成管理システムによって決定されます。 構成管理は非常に侵襲的なエンティティであり、あらゆるものの中心になりたいため、このプログラムの要件に合わせて多くの作業プロセスを調整する必要があります。 悪化する境界の瞬間は多くあり（以前はより良く簡単にできました）、通常の作業の代わりに不条理な儀式を行う感覚が何度もあります。

しかし、これに伴い、もう1つの感覚があります。ボタンを押す回数が減り、思考が増えます。 「行って変更する」の代わりに、「このように変更するのが正しいのか？」、「なぜ変更する必要があるのか​​？」、アーキテクチャの詳細な議論があります（サーバーAで1つの値を変更し、サーバーBで別の値を変更できますか？これらの変更の間に共通点を見つけ、この共通点を新しいエンティティとして説明しますか？）

オントロジー、または2番目の難しい問題

オントロジーの問題は完全に成長するでしょう。 「さまざまな変化に共通する」ことを考えると、常に新しいものが出現し、新しいものには名前が必要になります。 ご存知のとおり、名前を思い付くには、これがITの2番目の困難な問題であり（1つはキャッシュの無効化です）、名前の造語がオブジェクトのプロパティと期待を決定するため複雑です。 そして、そのたびに苦労して名前を考え出す必要があります。 すべての間違いは、建築における湾曲の一部です。 以前の変更が「変更する必要があるため」だった場合、「セプタムのプロパティを実装する必要がある」ため、変更が行われます。 私は（人生から）逸話的な例を避けようとしましたが、それでも与えます。 1つのプロジェクトで「システム構成」という名前を思い付くまでに3週間かかりました（サーバー設定に影響し、「ソフトウェア構成」ではなくansibleの使用を必要とする変更の部分を記述し、介入を必要としない部分を記述しました） ansible）。 アイデアは合理的であり、不可能にバインドされた依存関係のバンドルを分離するのに役立ちました。「サーバーAで変更する必要があります。ただし、ユーザーがインターフェイスでBを変更した後のみ、およびB。したがって、サーバー構成とアンサンブルによって構成されていない部分の両方を何らかの方法で変更する必要があります。 うーん...長い間忘れられていた恐怖。 その中の別のエンティティの名前を感じ、考え、見つけ出すことが必要でした。

フロンティアからバックオフィスへの移動

サーバー上の設定を変更するためのボタンが小さくなり、アブストラクトについてますます考えるようになったため、 ssh user@server



からgit commit



へと徐々に生活が変わっていきssh user@server



。

これは、構成管理システムに従うことは、プログラマーの生活から多くのことを意味します。 コードの構造（コード!!）、テスト、表現力とわかりやすさ、コードレビュー、コードの準備と安定性（コード!!）TKの予期しない変更、TK自体は何らかの形で現れ始めます。 「今すぐ修正」する必要はないが、「修正方法を明確にした」問題、技術的な負債が表示される（今は書き直す必要がある）、バックログが表示される、よく知られているバグが表示される。 例：..​​、yes、yes、現在の構成ではディスクのキャッシュオプションが正しく構成されていないことがわかっていますが、変更を行うには、まずブロックデバイスの分類を担当する部分を書き換える必要があります。 これは、通常の管理者がずっと前にループで400台のサーバーでhdparm -W 0 /dev/sda



を実行していたという事実にもかかわらずです。 おそらく、300サーバーにとって、sdaは仮想CD-ROMである場合があり、属性が設定されている各サーバーで確認する必要があることを理解するでしょう...しかし、これは別の話です。

管理者の寿命は、管理者の寿命にますます近づいています。 専門職は、構成を書く人とそれに付随する人に分けられます（つまり、彼らはサーバーと一緒にフロンティアにとどまります）。 これらはSREと呼ばれることもあり、特定の時点でのプロジェクトの重要度に応じて、非常にクールで重要な職業、または「アップグレードされたサポート」になります。

どこから始めますか？

少しやる気になったのに、どこから始めればいいかわからない場合は、好きな構成管理システムを探して始めてください。 これらは、Ansible、cfengine、Chef、Juju、Puppet、SaltStack、Quattorなどです。 ほとんどの場合、リストは完全ではありません。 これらの解決策はどれも（私の意見では）良いものではありませんが、私たちが持っているものの中で最良のものです。 そのようなシステムの選択の一部は、よく知られているプログラミング言語（これが私の見方です）、プロジェクトの構文と実行可能性の感覚に基づいている必要があります。

ソフトウェアを選択した後、頭を急がないでください。 このようなシステムでスマートブックを読む必要があり、難易度を問わずプレイすることもできますが、状況の制御を失うことなく、実装に非常に制限されています。 これは、長期的なアクションの単純な自動化（構成管理システムの言語でお気に入りの展開スクリプトを書き換える）から始め、手で行うことの少なくとも一部を書き込もうとすることを意味します。

追記

構成管理システムで最も興味深いライフハックの1つである私は、実験室アプリケーションを検討します。 新しいソフトウェアを調査する場合、構成管理システムを使用したこのソフトウェアの構成により、「再試行」することができます（ソフトウェアがサーバーに副作用を及ぼすかどうか不明な場合）。

同時に、ロボットの「何をすべきか」という説明は、概念的な実装プロジェクトの役割に完全に適合しています。 あるとき、私はcorosyncをデバッグしていました。これは、未知のユニキャスト/マルチキャストに制限があるネットワークで動作したくありませんでした。 デバッグ中に、数十回再クラスター化する必要がありました。 これが可能になったとき、「数十回」は偉業にならなかったが、「実験室を再開する」ようなものになった。

構成管理システムを毎日使用するには、サーバーを操作する最も基本的な本能を再構築する必要がありますが、非常に不快な学習曲線ではなく、労働効率を高めるツールであるだけでなく、行動と思考モデルをより効果的なものに変更します。 これは非常に難しい手順ですが、実行する必要がある手順です。