過去5年間で、Chef / Puppet / Vagrant / Ansibleに基づいた展開および構成管理システムを構築するための「成功した」レシピに関する記事をたくさん目にしています。 私がその頃働いていた会社で自動展開タスクを解決するのに約7年を費やしましたが、今では多くの一般的なツールを批判するのに十分な経験があると思います。
私のアプローチを詳細に説明したいのですが、NDAと非開示の期限のために、多くの詳細を開示することはできません。 この記事では、一般的な原則とアイデアの概要を説明し、コメントで建設的な批判を得たいと思います。 以下に説明する例は、もちろん特定の企業には適用されず、単に例を提供することを目的としています。
この記事は非常に具体的であると考えられていましたが、突然非常に大きくなったことがわかったので、私は知覚を容易にするためにいくつかの部分に分け、同時に特定の部分に関するコメントを得ることにしました。
5〜10台のサーバーを運用している読者にアピールしたいのですが、それらはすべて「Webサーバー-ベース-アプリケーションサーバーのペア」モデルに限定されています。 この記事のトピックは非常に包括的である可能性があるため、私の機能を考慮してください。 中小企業の場合、Chef / Puppet / Vagrant / Ansible /を使用したソリューションがまだうまく機能する可能性があることに同意します。 できます。 私はこれらのツールがどれほど悪いのかを伝えようとはしていません。 ファッショナブルなソリューションに対する過度の熱意に警告し、実装する前に、これが本当に役立つか、他のオプションがあるかどうかを考えています。
私の主なアイデアは、さらに説明します。大企業の場合、独自の展開ソリューションの開発は、既成のツールを使用したり、プロセスに適応させるよりも、収益性が高く便利であることがわかります。
あなたの会社が十分に大きいが、それでも、この問題に対する独自のソリューションを開発するために、1人か2人、または5人から6人の開発者を選ぶ余裕がない場合-完成したものを選ぶ方が良いです。 または、サードパーティソリューションの害（つまり害！）を当局に納得させることもできます。 私はかつて十分な説得力がなかったので、私の意見では、このために3年を失いました。
自動展開の概要に関するプレゼンテーションとビデオ講義のほとんどは、「ローカルホストにphpファイルを展開するのがいかに簡単かを見てみましょう」などのことから始まります。 突然、この正常にデプロイされたファイルだけで終わり、最良のケースでは、ロールが割り当てられた2つのサーバーにapacheとmysqlをインストールすることがいかに簡単かを示しています。 これに関して、感銘を受けた視聴者は、それが本当にシンプルであると判断し、今すぐこのクールなshmappetを本番環境で使用してみましょう。
しかし、検討する価値があるだろう...
残念ながら、私たちの両方で同様のことが起こり、Chefを使用しようとする試みを防ぐことはできませんでしたが、私たちの側には、実装のイニシエーターに多くの危険な質問がありました。 時間内にタスクに接続したので、私はネガティブな影響を少し滑らかにし、将来的にシェフを取り除くことができました。 しかし、その時までに彼は従わず、パペットは私たちのところへ行きました。
環境。 「短い」紹介。
SaaSサービスを提供する会社を想像してみましょう。 同社は5〜10年にわたって市場に出ており、既に満足のいくユーザーを対象にした機能性の高い販売サービスを提供しています。 ある時点で、彼らの幸せはあふれ、より多くのユーザーとパートナーを引き付けます。 つまり、会社は急速に成長し始めます。
実稼働では20台のサーバーが使用されていたが、6台のサーバーで5つの構成を編集することは、週末にサーバーを更新するために3〜4時間停止するなど、非常に一般的なことでした。 サーバーは異なります-約80％はIIS5または自己署名サービスを介したASPを備えたWindows Serverです-サイトをホストしているだけでなく、テレフォニー、メッセージ、ファックスサポート、またはSkypeやその他のサービスと統合するためのあらゆる種類のソリューションがあります。 請求を忘れないでください。 もちろん、すべてがデータベースに関連付けられています。 彼女は今のところ対処しているようです。 開発者は車のコードを作成し、QAには2つの古いデスクトップが隅にあり、すべてのサービスが順番にテストされます。 すべてが穏やかで、年に2回のメジャーリリース、バグの修正、マイナーな機能がときどきあります。 開発者は、RDP / SSHを介して実稼働サーバーの1つに移動し、ログを収集したり、リモートデバッガーをインストールしたりするためのいくつかのファイルをアップロードするためのいくつかのアイデアをチェックすることをdaしません。 いつものこと。 誰もがサービスとその接続の構造全体を知っています。
サーバーが少ないので、請求サーバーのアドレスをサーバーの構成に登録してみませんか？ とにかく、彼は一人で、長い間変わっていません。 ベースを担当するこの陰鬱な男に、パラメーター付きのプレートを追加するように頼むことはありません-再び、彼は貴重なベースにすべてのゴミを保管し、常にスキームを変更することを叫ぶでしょう。 リファクタリング後に追加してから削除します。 課金サーバーでは、外部支払いゲートウェイのアドレスも設定に追加します-確かに常に同じですが、ハードコーディングするのは良くありません。また、データベースに定数を押し込むことはできません。
突然、成長のためには、サーバーの数を実稼働で100台にする必要があります。広告キャンペーンが成功した後、ユーザーの数が非常に増え始めたからです。 CEOが到着し、美しいプレゼンテーションを見せ、これはほんの始まりに過ぎないことをほのめかしました。 彼は、業界で最大の2つの新しいパートナーがいると語り、汚れに直面する必要はなく、一般に、この機能とこの機能を実行できるとすでに言っています。 1か月後のデモですが、これらの機能をゼロから実行できますか？
それは必要です-それはそれが必要であることを意味し、見通しは良いです。 プレミアムは良いことを約束します。 ワンツー-そして機能はすぐになります。 古いサービスを書き換えないように、2つの新しいサービスが表示されます。必要に応じてそれらを結合します。 残念ながら、これらのサービスは他のすべてのサービスと非常に強力に接続されています。請求、電話、およびWebが必要です。 しかし、ここでは常識が勝ち、すべてのサーバーのアドレスをデータベースに保存することにしました-そうでなければ、すでに多くのサーバーがありました。 これで、データベースからの起動時のすべてのサービスがサーバーのリストを取得し、後でそれを操作します。 便利に。 ただし、古いコンポーネントの構成にはまだ何かが残っていますが、後でクリーンアップします。
CEOおよびCTOには、他のマネージャーも多数同行し、非常に満足しています。 パートナーはデモを評価し、お金を与えました。 たくさん。 必要なサーバーを購入し、リファクタリングについて何と言ったのですか？ それで、フィガチム。 Javaは今流行ですか？ 成功したオフィスでJavaで書くのは慣習ですか？ これで成功しました-Javaをやってみましょう！ そして、すぐにそれを行い、APIを介して通信する複数のサービスに分割します。
[最初の1年半はリファクタリングとそのリファクタリングのためにスキップします]。
現在、200の運用サーバーと約50のテストサーバーがあり、異なる内部コンポーネントの数は約20です。多くは類似していますが、機能は異なります。 すべてが自己記述型です。
10人のシステム管理者全員が燃えています。 2〜3か月ごとにリリースする予定です。 お金があります。 ユーザーが来ています。 開発者とテスターはフローによって募集されますが、PMはインタビューから抜け出しません。
しかし、問題もあります。
続行するには...
ここで、息を吸い、コメントで議論を整理するのに最適な場所です。 多くの人が会社から何かを学んだと思います。
以下の部分では、自動化の最初の試み、Chefの登場、そして結論として、会社のほとんどの問題を解決できる理想的なサービスのアーキテクチャについての私の考えを説明します。