スクリプトから独自のプラットフォームまで: CIAN で開発を自動化する方法

RIT 2019 で、私たちの同僚アレクサンダー・コロトコフは次のように述べました。 報告 CIAN での開発の自動化について: 生活と仕事を簡素化するために、私たちは独自の Integro プラットフォームを使用しています。 タスクのライフサイクルを追跡し、開発者を日常的な操作から解放し、運用環境でのバグの数を大幅に削減します。 この投稿では、Alexander のレポートを補足し、単純なスクリプトから独自のプラットフォームを介してオープンソース製品を組み合わせるまでの過程と、別個の自動化チームの活動について説明します。
 

ゼロレベル

「ゼロレベルなんてない、そんなことは知らない」
映画「カンフー・パンダ」のマスター・シフ

CIAN における自動化は、会社設立から 14 年後に始まりました。 当時の開発チームは35名でした。 信じられないでしょう？ もちろん、自動化は何らかの形で存在していましたが、継続的インテグレーションとコード配信という別の方向性が 2015 年に具体化し始めました。 

当時、Python、C#、PHP の巨大なモノリスが Linux/Windows サーバーにデプロイされていました。 このモンスターを展開するには、手動で実行する一連のスクリプトが必要でした。 また、モノリスの組み立ても行われ、ブランチのマージ、欠陥の修正、「ビルド内の異なる一連のタスクによる」再構築の際に競合が発生し、痛みと苦しみがもたらされました。 簡略化したプロセスは次のようになります。

私たちはこれに満足できず、繰り返し可能で自動化され、管理しやすいビルドとデプロイメントのプロセスを構築したいと考えていました。 このためには CI/CD システムが必要でした。Teamcity の無料バージョンと Jenkins の無料バージョンのどちらかを選択しました。なぜなら、私たちは彼らと協力しており、機能セットの点でどちらも私たちに適していたからです。 より新しい製品として Teamcity を選択しました。 当時、私たちはまだマイクロサービス アーキテクチャを使用しておらず、大量のタスクやプロジェクトが発生するとは予想していませんでした。

独自のシステムのアイデアにたどり着く

Teamcity の実装により削除されたのは手動作業の一部だけです。残っているのは、プル リクエストの作成、Jira でのステータスごとの課題の昇格、およびリリースする課題の選択です。 Teamcity システムはこれに対応できなくなりました。 さらなる自動化の道を選択する必要がありました。 Teamcity でスクリプトを使用するか、サードパーティの自動化システムに切り替えるオプションを検討しました。 しかし最終的には、当社独自のソリューションのみが提供できる最大限の柔軟性が必要であると判断しました。 これが、Integro と呼ばれる内部自動化システムの最初のバージョンが登場した方法です。

Teamcity はビルドおよび展開プロセスの開始レベルでの自動化に取り組んでいますが、Integro は開発プロセスのトップレベルの自動化に焦点を当てていました。 Jira での課題に関する作業と、Bitbucket での関連ソース コードの処理を組み合わせる必要がありました。 この段階で、Integro はさまざまな種類のタスクを処理するための独自のワークフローを持ち始めました。 

ビジネス プロセスの自動化の増加により、Teamcity でのプロジェクトと実行の数が増加しました。 そこで、新たな問題が発生しました。無料の Teamcity インスタンス 3 つでは不十分 (エージェント 100 つとプロジェクト 3) だったので、別のインスタンス (エージェント 100 つとプロジェクト XNUMX) を追加し、さらにインスタンスを追加しました。 その結果、管理が難しい複数のクラスターからなるシステムになりました。

4 番目のインスタンスの問題が生じたとき、4 つのインスタンスをサポートするための総コストがもはや制限内ではなくなったため、私たちはこのままではいけないことに気づきました。 有料の Teamcity を購入するか、無料の Jenkins を選択するかという疑問が生じました。 私たちはインスタンスと自動化計画を計算し、Jenkins を使用することに決めました。 数週間後、私たちは Jenkins に切り替え、複数の Teamcity インスタンスの維持に伴う頭痛の種をいくつか解消しました。 そのため、私たちは Integro の開発と Jenkins のカスタマイズに集中することができました。

基本的な自動化 (プル リクエストの自動作成、コード カバレッジやその他のチェックの収集と公開という形で) の成長に伴い、手動リリースを可能な限り放棄し、この作業をロボットに任せたいという強い要望が高まっています。 さらに、同社は社内でマイクロサービスへの移行を開始しましたが、これには頻繁なリリースが必要であり、相互に個別にリリースする必要がありました。 このようにして、徐々にマイクロサービスの自動リリースに到達しました (プロセスの複雑さのため、現在はモノリスを手動でリリースしています)。 しかし、いつものように、新たな複雑さが生じました。 

テストを自動化します

リリースの自動化により、一部のテスト段階が省略されたこともあり、開発プロセスが加速されました。 そしてこれにより、一時的な品質の低下が発生しました。 些細なことのように聞こえますが、リリースの加速に伴い、製品開発手法の変更が必要になりました。 テストの自動化、リリースされたコードとその中のバグに対する開発者の個人責任 (ここでは金銭的な罰金ではなく、「頭の中でアイデアを受け入れる」ことについて話しています) を課すこと、および次の決定について考える必要がありました。自動デプロイメントを通じてタスクをリリースするかどうか。 

品質上の問題を解決するために、私たちは XNUMX つの重要な決定に至りました。カナリア テストの実施を開始し、過剰なエラーに自動的に対応するエラー バックグラウンドの自動監視を導入しました。 XNUMX つ目のソリューションでは、コードが本番環境に完全にリリースされる前に明らかなエラーを発見することができ、XNUMX つ目のソリューションでは、本番環境での問題に対する応答時間が短縮されました。 もちろん間違いは起こりますが、私たちは間違いを修正することではなく、間違いを最小限に抑えることに時間と労力のほとんどを費やします。 

自動化チーム

現在、当社には 130 名の開発者スタッフがおり、今後も継続的に開発を続けていきます。 成長する。 継続的インテグレーションとコードデリバリーのチーム (以下、Deploy and Integration または DI チームと呼びます) は 7 人で構成され、Integro 自動化プラットフォームの開発と DevOps の 2 つの方向で活動します。 

DevOps は、CIAN サイトの開発/ベータ環境である Integro 環境を担当し、開発者が問題を解決し、環境をスケーリングするための新しいアプローチを開発するのを支援します。 Integro の開発方向では、Integro 自体と関連サービス (Jenkins、Jira、Confluence 用のプラグインなど) の両方を扱い、開発チーム向けの補助ユーティリティやアプリケーションも開発します。 

DI チームは、アーキテクチャ、ライブラリ、開発アプローチを社内で開発するプラットフォーム チームと協力して作業します。 同時に、CIAN 内の開発者は全員、チームのニーズに合わせてマイクロオートメーションを作成したり、自動化をさらに改善する方法に関するクールなアイデアを共有したりするなど、自動化に貢献できます。

CIAN の自動化のレイヤーケーキ

自動化に関与するすべてのシステムは、いくつかの層に分割できます。

1. 外部システム (Jira、Bitbucket など)。 開発チームは彼らと協力して作業します。
2. インテグロプラットフォーム。 ほとんどの場合、開発者はこれを直接操作しませんが、すべての自動化を実行し続けるのはこれです。
3. 配信、オーケストレーション、および検出サービス (Jeknins、Consul、Nomad など)。 彼らの助けを借りて、コードをサーバーにデプロイし、サービスが相互に動作することを確認します。
4. 物理層（サーバー、OS、関連ソフトウェア）。 私たちのコードはこのレベルで動作します。 これは、物理サーバーまたは仮想サーバー (LXC、KVM、Docker) のいずれかになります。

この考え方に基づき、DIチーム内で担当領域を分担しています。 最初の XNUMX つのレベルは Integro 開発方向の責任の領域にあり、最後の XNUMX つのレベルはすでに DevOps の責任の領域にあります。 この分離により、私たちはお互いに近くにいて常に知識や経験を交換できるため、仕事に集中することができ、相互作用を妨げることはありません。

インテグロ

Integro に焦点を当て、テクノロジー スタックから始めましょう。

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (古い Integro モノリスは Java 8 に残ります)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSQL 11
• RabbitMQの 
• アパッチ・イグナイト
• カムンダ (埋め込み)
• グラファナ + グラファイト + プロメテウス + イェーガー + ELK
• Web UI: React (CSR) + MobX
• SSO: キークローク

私たちは、Integro の初期バージョンのモノリスの形でレガシーを持っていますが、マイクロサービス開発の原則を遵守しています。 各マイクロサービスは独自の Docker コンテナーで実行され、サービスは HTTP リクエストと RabbitMQ メッセージを介して相互に通信します。 マイクロサービスは Consul を通じてお互いを見つけてリクエストを行い、SSO (Keycloak、OAuth 2/OpenID Connect) を通じて認可を渡します。

実際の例として、次の手順で構成される Jenkins との対話を考えてみましょう。

1. ワークフロー管理マイクロサービス (以下、フロー マイクロサービスと呼びます) は、Jenkins でビルドを実行したいと考えています。 これを行うために、彼は Consul を使用して Jenkins と統合するためのマイクロサービス (以下、Jenkins マイクロサービスと呼びます) の IP:PORT を見つけ、それに非同期リクエストを送信して、Jenkins でのビルドを開始します。
2. リクエストを受信すると、Jenkins マイクロサービスはジョブ ID を生成して応答します。ジョブ ID は、作業の結果を識別するために使用できます。 同時に、REST API 呼び出しを介して Jenkins でのビルドをトリガーします。
3. Jenkins はビルドを実行し、完了後、実行結果を含む Webhook を Jenkins マイクロサービスに送信します。
4. Webhook を受信した Jenkins マイクロサービスは、リクエスト処理の完了に関するメッセージを生成し、実行結果をそれに添付します。 生成されたメッセージは RabbitMQ キューに送信されます。
5. RabbitMQ を通じて、パブリッシュされたメッセージは Flow マイクロサービスに到達し、リクエストと受信したメッセージのジョブ ID を照合することで、タスクの処理結果を学習します。

現在、約 30 個のマイクロサービスがあり、いくつかのグループに分類できます。

1. 構成管理。
2. ユーザーとの情報および対話 (メッセンジャー、メール)。
3. ソースコードの操作。
4. デプロイメントツール (jenkins、nomad、consul など) との統合。
5. モニタリング (リリース、エラーなど)。
6. Web ユーティリティ (テスト環境の管理、統計の収集などのための UI)。
7. タスクトラッカーや同様のシステムとの統合。
8. さまざまなタスクのワークフロー管理。

ワークフロータスク

Integro は、タスクのライフサイクルに関連するアクティビティを自動化します。 簡略化すると、タスクのライフ サイクルは、Jira のタスクのワークフローとして理解されます。 当社の開発プロセスには、プロジェクト、タスクの種類、特定のタスクで選択されたオプションに応じて、いくつかのワークフローのバリエーションがあります。 

最も頻繁に使用するワークフローを見てみましょう。

図では、歯車は遷移が Integro によって自動的に呼び出されることを示し、人物の図は遷移が人によって手動で呼び出されることを示します。 このワークフローでタスクがたどることのできるいくつかのパスを見てみましょう。

カナリア テストを行わない DEV+BETA での完全な手動テスト (通常、これがモノリスをリリースする方法です):

他の遷移の組み合わせも存在する可能性があります。 課題が通過するパスは、Jira のオプションを通じて選択できる場合があります。

タスクの移動

タスクが「DEV テスト + カナリア テスト」ワークフローを通過するときに実行される主な手順を見てみましょう。

1. 開発者または PM がタスクを作成します。

2. 開発者はタスクを実行します。 完了後は「IN REVIEW」状態に切り替わります。

3. Jira は、Jira マイクロサービス (Jira との統合を担当) に Webhook を送信します。

4. Jira マイクロサービスは、ワークフローを開始するために、フロー サービス (作業が実行される内部ワークフローを担当) にリクエストを送信します。

5. フロー サービス内:

• レビュー担当者はタスク (ユーザーについてすべてを知っているユーザー マイクロサービス + Jira マイクロサービス) に割り当てられます。
• Source マイクロサービス (リポジトリとブランチについては認識していますが、コード自体は機能しません) を通じて、問題のブランチを含むリポジトリの検索が行われます (検索を簡略化するために、ブランチの名前は問題と一致します) Jira の番号)。 ほとんどの場合、タスクには XNUMX つのリポジトリにブランチが XNUMX つだけあります。これにより、デプロイメント キューの管理が簡素化され、リポジトリ間の接続が減少します。
• 見つかったブランチごとに、次の一連のアクションが実行されます。

  i) master ブランチ (コードを操作するための Git マイクロサービス) を更新します。
  ii) ブランチは開発者 (Bitbucket マイクロサービス) による変更からブロックされています。
  iii) このブランチ (Bitbucket マイクロサービス) に対してプル リクエストが作成されます。
  iv) 新しいプル リクエストに関するメッセージが開発者チャットに送信されます (通知を操作するための通知マイクロサービス)。
  v) ビルド、テスト、およびデプロイのタスクは DEV (Jenkins と連携するための Jenkins マイクロサービス) 上で開始されます。
  vi) 前の手順がすべて正常に完了すると、Integro はプル リクエスト (Bitbucket マイクロサービス) に承認を入れます。

• Integro は、指定されたレビュー担当者からのプル リクエストの承認を待ちます。
• 必要な承認がすべて受信されると (自動テストの合格を含む)、Integro はタスクを Test on Dev (Jira マイクロサービス) ステータスに移行します。

6. テスターがタスクをテストします。 問題がない場合、タスクは [Ready For Build] ステータスに転送されます。

7. Integro は、タスクがリリースの準備ができていることを「認識」し、カナリア モード (Jenkins マイクロサービス) でそのデプロイメントを開始します。 リリースの準備ができているかどうかは、一連のルールによって決まります。 たとえば、タスクが必要なステータスにある、他のタスクにロックがない、現在このマイクロサービスのアクティブなアップロードがない、などです。

8. タスクは Canary ステータス (Jira マイクロサービス) に転送されます。

9. Jenkins は、Nomad を介してカナリア モードでデプロイメント タスクを起動し (通常は 1 ～ 3 個のインスタンス)、デプロイメントについてリリース監視サービス (DeployWatch マイクロサービス) に通知します。

10. DeployWatch マイクロサービスはエラーの背景を収集し、必要に応じてそれに対応します。 エラー バックグラウンドを超えると (バックグラウンド基準は自動的に計算されます)、Notify マイクロサービスを介して開発者に通知されます。 5 分経過しても開発者が応答しない ([元に戻す] または [停止] をクリックした) 場合、カナリア インスタンスの自動ロールバックが開始されます。 バックグラウンドを超えていない場合、開発者は、(UI のボタンをクリックして) 運用環境へのタスクのデプロイメントを手動で開始する必要があります。 60 分以内に開発者が運用環境へのデプロイメントを開始しなかった場合、セキュリティ上の理由からカナリア インスタンスもロールバックされます。

11. 運用環境への展開を開始した後、次の手順を実行します。

• タスクは運用ステータス (Jira マイクロサービス) に転送されます。
• Jenkins マイクロサービスはデプロイメント プロセスを開始し、デプロイメントについて DeployWatch マイクロサービスに通知します。
• DeployWatch マイクロサービスは、運用環境上のすべてのコンテナが更新されたことを確認します (すべてが更新されていない場合もありました)。
• Notify マイクロサービスを通じて、デプロイメントの結果に関する通知が運用環境に送信されます。

12. マイクロサービスの不正な動作が検出された場合、開発者は 30 分間以内に本番環境からタスクのロールバックを開始する必要があります。 この時間が経過すると、タスクは自動的にマスター (Git マイクロサービス) にマージされます。

13. マスターへのマージが成功すると、タスクのステータスがクローズド (Jira マイクロサービス) に変更されます。

この図は完全に詳細であるようには見えませんが (実際にはさらに多くのステップがあります)、プロセスへの統合の程度を評価することができます。 私たちはこのスキームが理想的であるとは考えておらず、自動リリースと展開サポートのプロセスを改善しています。

次のステップ

私たちは自動化の開発に関する大きな計画を立てています。たとえば、モノリスリリース中の手動操作の排除、自動展開中のモニタリングの改善、開発者との対話の改善などです。

しかし、今はここでやめましょう。 自動化レビューでは多くのトピックを表面的に取り上げましたが、まったく触れられていないトピックもありましたので、ご質問に喜んでお答えいたします。 何を詳しく取り上げるべきかについての提案をコメントに書き込んでお待ちしています。

出所： habr.com