リポジトリから本番環境のCI / CDインフラストラクチャまで1週間で

通常、「サポート」という用語の意味は1つだけです。ホスティング、不良ドライブの交換、WebサーバーとDBMSのセットアップ、および一般的な日常の管理に関する問題への対応です。 しかし、実際には、これはインターネットプロジェクトの安定性制御の最初のレベルにすぎません。



確かに、すべての重要なデータの冗長性と自動feyloverを備えた、異なるデータセンターの複数のサーバーのフェイルセーフクラスターを既に構成している場合でも、実稼働サイトのデバッグされた作業が深刻に中断される可能性があります。 これの代わりにどれくらいの頻度で見ましたか：







ここにあります：





そして、この投稿について-開発の安全性と安定性、およびそれらが提供できるシステムと原則について。 または、流行語を使用するには-DevOpsとCI / CDについて。

なんで？

基本スキームでは、サイト自体、そのベース、およびキャッシングや検索などの他のすべての関連サービスがスピンしているサーバーが1つしかない場合、ほとんどすべてを手動で実行できます-リポジトリからコードの更新を取得し、サービスを再起動します、検索ベースとその他すべてのインデックスを再作成します。







しかし、プロジェクトが大きくなったらどうしますか？ 縦と横の両方。 Webを備えた10台のサーバー、ベースを備えた3台のサーバー、および検索用の複数のサーバーが既にある場合。 また、顧客がどのようにサービスを使用しているかを正確に把握し、データベース、フロントエンド、および定期的なタスクで個別の分析を取得することも決定しました。 そして今、私たちは1つのサーバーではなく、例えば30を持っています。 手ですべてのささいなことをし続けますか？ 管理者のスタッフを増やす必要があります。なぜなら すでに物理的にサポートされているすべてのシステムに十分な時間と注意がありません。



または、管理者クラフトワークショップであることをやめて、生産チェーンの構築を開始することもできます。 次の抽象化レベルに進み、個々のサービスやプログラムではなく、サーバー全体をシステム全体の最小単位として管理します。



DevOpsとCI / CDの方法論が発明されたのはこのためです。 CI / CDは、開発用の別個のプラットフォーム、別個のステージング、および別個の販売の存在を意味します。







また、各リリースは手動または自動テストであるかどうかにかかわらず、特定のライフステージを経なければならないことを意味します。 これにより、展開自体で何かがうまくいかない可能性が排除されます。間違ったブランチ、間違ったカブ、間違ったサーバーなどを引き出しました。すべてが事前に予測および構造化され、人的要因の影響は最小限です。 コード自体の品質とプロジェクトの内部ロジックの動作を監視するだけです。



これにより、管理者は開発および計算プロセスに一切干渉せず、将来のアーキテクチャの拡張方法について監視および思考する当面の責任を引き受けることができます。



通常、そのようなことは理論的にはもっと言われます。 ここで、彼らは言う、Dockerのようなものがある。 ここでは、コンテナを安価に作成できます。 不要なレイヤーやサービスを読み込まずに、親システムの重要な部分に触れることなく、すべてを簡単に作成、更新、ロールバックできます。 そして、別の記事で-しかしKubernetesがあります。 彼は、手動で介入することなく、自分でプロジェクトにドッカーブリックを挿入および引き出し、構成の仕組みを説明するだけです。 公式ドキュメントの3行です。 そして、このスタイルでは、ほぼすべての材料。 メカニックに安全で安定した開発を提供するという本当のタスクから始めて、これが実際の生活の中でどのように起こるかについてお話したいと思います。

誰について？

Facebook Messengerのボットを使用して英語を学習するのに役立つEdwinサービスの例について説明します。 @EnglishWithEdwinボットは、英語のレベルを決定し、各生徒の進歩と速度に基づいてカリキュラムをパーソナライズします。



この瞬間までに、同社は数か月間開発を続けていましたが、急速に開発されている実用的な製品があり、最初の公開リリースの準備をしていました。 開発サイトでは、Dockerコンテナのサービスが既に開始されており、AWSのデータベースが作成され、これらすべてが機能していました。



Edwinの開発マネージャーであるSergey Vasilievは、市場にある既存のオファーを慎重に分析し、製品のアーキテクチャと運用上の信頼性の要件について説明しました。 24時間体制のサービスサポートに加えて、ステージングサイトと運用サイトを詳細に調査し、快適な更新と一般的なインフラストラクチャ管理を可能にする必要がありました。



当時の実稼働環境でのコンテナの使用は大規模ではなく、チャットボットの開発が始まったばかりでした。 したがって、私たちにとっては、本物の興味深い製品を例に現代のツールを実践する絶好の機会でした。

プロジェクト構造

Edwinはどのように内部構造化されていますか？ キーワード-Python、PostgreSQL、Neo4j、RabbitMQ。 従来、アーキテクチャは、トランスポート、論理、分析の3つの大きなブロックに分割できます。





最初のブロック-pythonで記述されたドッキングされたメーリングリストアプリケーションは、Facebook Gatewayを介してソーシャルネットワークからメッセージを受信し、データベースに保存して、RabbitMQキューにイベントを追加します。



2番目のブロックには、ボット自体のコンテナがあり、キューから3番目のブロックでキューからデータを読み取り、3番目のブロックで分析用のデータを収集します。また、スケジューラ-プッシュ通知やセッションの有効期限。



3番目のブロック-分析用のデータを含むデータベースと、ボットからデータを集約し、Googleアナリティクスや他の場所にアップロードするサービスを備えたいくつかのコンテナ。



しかし、これは想定される構造にすぎません。なぜなら、 Edwinは私たちのところに来て、まだプロジェクトのリリースバージョンを持っていないので、彼は本番で輝いていませんでした。 ステージ/製品環境のセットアップが必要でした。



一般的に、これは1つではなくてもそれほど難しくはありませんでした-導入の詳細はすべて議論されましたが、期限は容赦なく近づいており、すべての願いを実現するのに1週間しか残っていませんでした。

CI / CDセットアップ

最初に心に留めておくべきことは、すべてが遠くから見えるほど複雑ではないということです。 主なことは、あなたがしていることとその理由を理解することです。 本当に重要なニーズにのみツールを選択し、実際のニーズと機会を適切に評価します。



システム全体の基盤は、サービスとビジネスロジックを備えたドッカーコンテナです。 インフラストラクチャ管理の汎用性とモビリティを高めるために選択されたコンテナ。 現在、Dockerコンテナをジャグリングするための最も人気のあるツールは、GoogleのKubernetesです（少なくとも最も広く知られています）。 しかし、私たちにはあまりにも混乱し、構造的に複雑であるように思われたため、作業能力を維持するためにあまりにも多くの体の動きが必要になりました（そして最初の理解には時間がかかりすぎました）。 そして以来 CI / CDシステム全体の運用期限を最小限に抑えたため、よりシンプルで軽量なソリューションを探すことにしました。



コンテナテンプレートを保存するために、Amazon EC2 Container Registryを取得することが決定されました（実際、それを取得するのではなく、開発者を選択しておくだけです）。 一般に、ローカルホストで個人的に作成されたレジストリと大差はありません。 基本的に、ローカルホストで個人的に持ち上げる必要がないという事実。



そのため、コンテナテンプレートを含むリポジトリがあります。 展開されたコンテナが常に相互に認識し、ネットワーク構成が変更された場合でも相互に通信できるようにするにはどうすればよいですか？ 同時に、コンテナ自体とその構成の内部に絶えず干渉することなく？



これには、サービス発見などの種類のソフトウェアがあります-おそらく、理解を容易にするために、「ビジネスロジックルーター」と呼ぶことができますが、技術的にはこれは完全に正しい定義ではありません。 単一の要求配信センターが確立され、すべてのサービスが近隣の場所のデータに適用されます。このセンターのエージェントは最初にコンテナ内に配置されます。 そして、起動時のすべてのサービスは、場所と状態をルーターに通知します。



コンテナ用の新しいマシンをすばやく準備する方法は？ 結局のところ、ホストもネットワーク負荷などのために正しく構成する必要があります。デフォルトのカーネルパラメータも、実稼働環境で見たいものからかなり離れていることがよくあります。 このために、新しいサイトの準備にかかる時間を大幅に短縮するいくつかのAnsibleレシピが作成されました。



サーバーをコンテナ用に構成すると、必要なすべてのサービスがドッキングされます。実際には、30分ごとに500個のボタンを押さずに「継続的統合」を整理する方法を理解するだけです。 その結果、GoCDや小さなスクリプトバインディングなどのシステムに落ち着きました。 なぜGoCDなのか、Jenkinsではなく私に尋ねるのですか？ 以前、他のプロジェクトでは、一方と他方に対処する必要があり、相互作用の合計は、JenkinsよりもGoCDの方が簡単に構成できそうでした。 タスクとパイプラインのテンプレートを作成し、それに基づいて、さまざまな環境に合わせてさまざまな本番チェーンを生成できます。

開発プロセス

2月6日月曜日

一般的に、最初の日は穏やかでした。 やっと私たちがやらなければならないことのTKを手に入れました。



ここでは、もちろん、ちょうど1週間はまだ少しのトリックであるという予約をする価値があります。 結局のところ、私たちが存在するのは真空ではありません！ 管理者は、どのような種類のプロジェクトがサポートされるようになるのか、そもそも一般的にどのタスクがタスクになるのかを事前に認識していました。 そのため、ツールを選択する可能性について少し整理する時間がありました。



その結果、その時点でプロジェクトが開発されていた既存のサーバーを静かに測定しました。 監視を重視し、何が実行されているか、どのように動作するかを把握します。



受信した情報に基づいて、Ansibleレシピを作成し、本番用にサーバーのインストールを開始します。開発中の不注意なアクションを回避するために、既存の開発環境と交差しないAmazonに別のVPCをセットアップします。 必要なすべてのサービス（PostgreSQL、Neo4j、プロジェクトコード）を含むコンテナをデプロイします。



ところで、同僚は開発中にAmazon RDSの形でPostgreSQLを使用していましたが、本番環境では、共同合意により、PostgreSQLを使用して通常のインスタンスに切り替えることを決定しました-これにより、システムのすべての要素の動作を可能な限り管理できる管理者にとって状況がより透明になりました負荷のその後の成長の時間。



実際、ほとんど労力をかけずにプロジェクトを行っており、専任の管理時間がない場合は、RDSも使用できます。RDSは非常に適しています。同時に、より緊急のタスクのためにリソースを解放できます。

2月7日火曜日

別のサーバーに、基本バージョンのGoCDデプロイメントパネルとConsulサービス検出をインストールします。



前述したように、エドウィンは開発のためのある程度の準備が整ったインフラストラクチャを手に入れました。 コンテナをジャグリングするために、彼らはAmazon ECS、別名EC2 Container Serviceを使用しました。 Kubernetes-as-a-Serviceのようなもの。 プロジェクトの将来の構造について開発者の希望を話し合い、計算を行った後、ECSを放棄することが決定されました。 多くのクラウドのように、内部で何が起こっているかを制御するのに十分に透明ではないことが判明しました。同じコンテナに設定された環境パラメーターなど、現在の状況では非常に有用なものはありませんでした すなわち 異なるパイプラインで同じコンテナを使用する方法はなく、単に環境を再定義するだけです。 Amazonパラダイムでは、環境ごとに個別のコンテナーを作成する必要があります。



また、何らかの理由で、異なるチェーンで同じタスクを使用することは不可能です。 一般的に、GoCDははるかに柔軟性がありました。



残りの時間は、GoCDの販売環境のパイプラインを作成および設定します。コードの構築、コンテナーの再作成、新しいコンテナーの製品への展開、更新されたサービスの領事への登録。

2月8日水曜日

昨日の設定を再確認し、テスト計算を実行し、システム接続を確認します。コードがリポジトリから正しく取得されること、同じコードがコンテナに正しく収集されること、コンテナが正しいサーバーで起動されること、そして領事にそのステータスを通知します。



一般的に、現時点では、確立された基本インフラストラクチャをすでに準備しており、その中で既に新しいパラダイムに取り組むことができます。 GoCD展開パネルがあり、本番環境でプロジェクトを組み立ててレイアウトするためのメカニズムがあります。Consulを使用すると、既存のインフラストラクチャに新しいサーバーやサービスを追加時間と人件費を追加することなく有機的にできます。



すべてが正常に機能することを確認した後、隣接するアベイラビリティーゾーンのデータベースのバックアップレプリケーションを開発者とともに設定し、作業データを本番データベースにアップロードします。

2月9日木曜日

先ほど言ったように、この時点で、一般に、CI / CDシステムの必要最小限の要素はすべてインストールされ、構成されています。 結果のシステムの構造に関するすべてのデータを開発者に渡します;彼らの部分では、プロジェクトのすべてのアセンブリおよび計算メカニズムのテストを開始します。



ところで、ToRをコンパイルするときに、すべてのコンテナとサービスからのすべてのシステムログの集中収集などの重要なポイントを忘れていたことがわかります。 これは、プロジェクトの全体的な状況のバックグラウンド分析や、潜在的なボトルネックや差し迫った問題の追跡に役立ちます。



ログは、あらゆる種類の分析に非常に便利なインターフェイスであるKibanaで収集することにしました。 サードパーティのプロジェクトで繰り返し遭遇し、社内プロジェクトで使用しました。



数時間でKibanaを上げ、サービスからのログの収集を構成し、製品上のすべての重要なサービスの監視を構成します。

2月10日金曜日

ほとんどの場合、すべてが組織側から金曜日に準備ができていました。 当然ながら、さまざまな小さなバグやグリッチに遭遇しましたが、継続的インテグレーションのシステムとは関係がありませんでした。

結果

その結果、何が得られましたか？ 3つのステージと環境（dev、stage、prod）で構成されるモジュール式プロジェクト開発システム。 プロジェクト全体が個別のマイクロサービスに分割され、それぞれに独自のパイプラインがあります。



開発者が新しいバージョンをリリースすると、GoCDパネルに移動し、対応するパイプラインを起動するだけです。 たとえば、「ステージで新しいロガーをロール」し、そこでテストし、すべてが正常に機能することを確認してから、製品にロールオーバーします。 突然何かがおかしくなった場合は、自分でパネルを介して、目的のサービスを目的のバージョンにロールバックします。







dev、stage、prodの3つの環境はすべて、異なるVPCで分離されています。 Consulは環境ごとに個別のデータセンターを持っているため、サービスが誤って異なる環境間を移動することさえありません。 そして、そのような状況で大きな欲求があったとしても、処女を破るなど、乙女に対するいかなる行動によっても非常に困難です。



また、プロジェクトの容量を簡単に増やすことができます。 新しいコンピューティングパワーが必要な場合、約10分で新しいインスタンスを起動して作業の準備をすることができます。

遭遇した問題

全体として、活動の分野自体は多くの人にとってかなり複雑に見えるかもしれないという事実にもかかわらず、多くの問題が私たちを待っていて、ほとんどすべてがすぐにうまくいきました。 一般的に、これは継続的インテグレーションとは関係ありません。



問題は、このプロジェクトがホストされているAmazon Web Servicesによってスローされました。



Consulをセットアップするときに、彼らは興味深いプラグに出会いました。 エージェントとそれらへのアクセスは、システムリゾルバーを介してコンテナに登録されます。 ただし、Amazonがデフォルトで使用するAMI LinuxはデフォルトのCentOSとは多少異なり、リゾルバーとの連携はVirtual Private Cloud（VPC）ネットワークの設定で行われます。 サーバーが再起動すると、Amazonはリゾルバーを強制します。 残念ながら、これまで失敗した執政官の解像度設定を壊さないように彼に強制しました。 しかし、chatrtr + iは全員を救ったので、今は生きています。



一般に、VPCとそのネットワークの構造は非常に興味深いものであり、非常に予期しない場所での制限につまずく可能性があります。 たとえば、アプリケーションバランサーはアクセシビリティマルチゾーンでのみ作成できます。つまり、バックエンドは一度に複数の異なる可用性ゾーンに配置する必要があります。 このため、プライベート/パブリックおよび1つのゾーンと別のゾーンにアドレスがあるように、VPCネットワークにブレークダウンが必要です。 また、作成時にのみVPCネットワークの内訳を変更できます。 また、インスタンスでVPCを変更することも、作成時にのみ可能です。



そして、同じアクセシビリティゾーン内に本番サーバーを備えた既製のインフラストラクチャが既にある場合、別のゾーンにサーバーを追加してバランサーを前に吊るすだけでそれを変更する方法はありません。 残念ながら、構造全体を最初から完全にやり直す必要があります。

結論と計画

プロジェクトの現在の開発レベルである状況の要件を満たせなくなった場合、通常のワークフローを拡大したり変更したりすることを恐れないでください。 プロジェクト開発の次の段階への移行は確かにあなたにとって負担が大きすぎることを恐れないでください。 自分のニーズに適切にアプローチし、最初に耳にする決定について考えずに把握しなければ、この道は一人でも簡単に習得できます。



もちろん、多くの人が言うことができます：「ええ、そうです、彼らはHabrahabrやOur Ra​​dioのようなプロジェクトを10年間サポートしており、ここではシンプルさについて話しているのです！」 はい、確かに、私たちは一生のうちに多くの異なるものを見てきました。 そして、おそらくこれは、単純なものと複雑なものを区別し、あまりにも多くの熊手を踏まないようにするのに役立つのです。 しかし、繰り返しになりますが、最初に「クールさ」を追求せずにタスクにアプローチして適切なツールを選択することが合理的であれば、人生を大幅に簡素化できます。



一方、説明されているスキーム（およびコンテナ化に基づく他のスキーム）は、プロジェクトが最初からこのような操作に対応する必要があることを意味していることを覚えておく価値があります。 プロジェクトは、モバイルで交換可能なように、状態を維持できない本格的なマイクロサービスで構成する必要があります。 モノリシックシステムのフレームワークでは、このような継続的インテグレーションアプローチの導入は、労働集約的であり、将来の使用での快適性が低いようです。



プロジェクトの今後の計画は？



基本的なインフラストラクチャが確立された後、Jiraベースのバグトラッカーをそれに接続して、Gitリポジトリからprodの新しいバージョンを展開するときに、バグのアプリケーションに関する情報を選択し、自動的に閉じてリリースノートに書き込むことができます。



また、メインの作業ノードで自動スケーリングを設定する必要があるときが来ているようです。 その合計数は常に増加しており、ピーク時にアクティブなサーバーの数を節約することでコストを削減できます。