Clever Geek Handbook

Octopodで（およびお客様の）CI / CDパイプライン用のパラレルユニバースを構築した方法

Octopodで（およびお客様の）CI / CDパイプライン用のパラレルユニバースを構築した方法





こんにちは、Habr！私の名前はデニスです。Typeableの開発プロセスとQAを最適化するための技術的なソリューションを作成することがどのように提案されたかを説明します。それは、私たちがすべてを正しく行っているという一般的な感覚から始まりましたが、それでも、より速く、より効率的に移動することは可能です-新しいタスクを受け入れ、テストし、同期を少なくします。これらすべてが私たちを議論と実験に導き、その結果、私たちのオープンソースソリューションが生まれました。これについては以下で説明し、現在利用可能です。



しかし、機関車の前を走るのではなく、最初から始めて、私が話していることを詳細に理解しましょう。かなり標準的な状況、つまり3層アーキテクチャ（ストレージ、バックエンド、フロントエンド）を備えたプロジェクトを想像してみましょう。テスト用のいくつかの環境（アウトラインと呼ばれることが多い）がある開発プロセスと品質保証プロセスがあります。



  • 本番環境は、システムユーザーがアクセスする主要な作業環境です。 
  • Pre-Production – - (, production, ; RC), production, production . Pre-production – , Production .
  • Staging – , , , Production, .




プリプロダクション、すべてが非常に明確である：リリース候補は一貫してリリース履歴はと同じで、そこに行く 制作。ステージングには微妙な違いがあり ます：



  1. 組織。重要なパーツのテストでは、新しい変更の公開を遅らせる必要がある場合があります。変更は予測できない方法で相互作用する可能性があります。サーバー上で大量のアクティビティが発生するため、エラーのトレースが困難になります。どのバージョンが実装されているかについて混乱が生じることがあります。蓄積された変更のどれが問題を引き起こしたのかが不明な場合があります。
  2. . : production , «». staging , . . : , . , QA production , .

  3. .



  4. . . -. , . , . , .
  5. . - , , , , . , , , . , . production , time-to-production time-to-market .


これらの各ポイントは何らかの方法で解決されますが、これらすべてが問題につながりました。1つのステージングスタンドの概念から動的な数に移行すると、私たちの生活を簡素化することが可能でしょうか。gitで各ブランチのCIチェックを行う方法と同様に、各ブランチのQAチェックアウトスタンドを取得できます。そのような動きから私たちを阻む唯一のことは、インフラストラクチャとツールの欠如です。大まかに言えば、機能を受け入れるために、専用のドメイン名を使用して別のステージングが作成され、QAがそれをテストし、受け入れ、または改訂のために返します。このようなもの： 





このアプローチでは、さまざまな環境の問題が自然な方法で解決されます。





話し合いの結果、チーム内の意見は「やってみよう、今より良くしたい」と「当たり前のようで、大きな問題は見られない」に分かれていましたが、後でまた話を戻します。



ソリューションへの道



最初に試したのは、DevOpsによって構築されたプロトタイプでした。docker-compose（オーケストレーション）、rundeck（管理）、portainer（イントロスペクション）の組み合わせで、思考とアプローチの全体的な方向性をテストできました。利便性に問題がありました：



  1. 変更を加えるには、開発者が持っていたが、たとえばQAエンジニアがいなかったコードとrundeckにアクセスする必要がありました。
  2. これは1台の大型マシンで発生しましたが、すぐに不十分になり、次のステップでは、Kubernetesなどがすでに必要でした。
  3. Portainerは、特定のステージングの状態についてではなく、コンテナのセットについての情報を提供しました。
  4. 私は常にファイルをステージの説明とマージする必要があり、古いスタンドを削除する必要がありました。


すべての欠点があり、操作に不便があったとしても、このアプローチが採用され、プロジェクトチームの時間と労力を節約し始めました。仮説が検証され、すべて同じことを行うことにしましたが、しっかりとノックされました。開発プロセスを最適化するという目標を追求するために、新しい要件を収集し、必要なものを理解しました。



  1. Kubernetesを使用して、任意の数のステージング環境にスケーリングし、最新のDevOps用の標準ツールセットを用意します。
  2. すでにKubernetesを使用しているインフラストラクチャに簡単に統合できるソリューション。
  3. , Product QA-. , . – .
  4. , CI/CD , . , Github Actions CI.
  5. , DevOps .
  6. , , / - .
  7. 完全な情報とアクションのリストは、DevOpsエンジニアとチームリーダーのスーパーユーザーが利用できるようにする必要があります。


そして、Octopodの開発を開始し ました。この名前は、プロジェクトのすべてを調整するために使用したK8Sに関するいくつかの考えの混乱でした。このエコシステムの多くのプロジェクトは、海洋の美学とテーマを反映しており、触手で多くの水中コンテナを調整する一種のタコを想像しました。さらに、ポッドはKubernetesの創設エンティティの1つです。



テクニカルスタックでは、OctopodはHaskell、Rust、FRP、JS、Nixへのコンパイルです。しかし、一般的にはこれについての話ではないので、これについてはこれ以上詳しく説明しません。



新しいモデルは、社内でマルチステージングとして知られるようになりました。複数のステージング環境を同時に操作することは、サイエンスフィクションのパラレルユニバースとディメンションを移動することに似ています（それほど多くはありません）。その中で、宇宙は1つの小さな詳細を除いて互いに似ています。どこかで異なる側が戦争に勝ち、どこかで文化大革命が起こり、どこかで技術的な進歩がありました。前提は小さいかもしれませんが、それがどのような変化につながる可能性があります！私たちのプロセスでは、この前提条件は、それぞれの個別の機能ブランチのコンテンツです。





私たちの実装はいくつかの段階で行われ、1つのプロジェクトから始まりました。これには、DevOps側からのプロジェクトオーケストレーションの調整、およびプロジェクトマネージャーからのテストとコミュニケーションプロセスの再編成が含まれます。



何度も繰り返した結果、Octopod自体の一部の機能が削除されたか、認識できないほど変更されました。たとえば、最初のバージョンでは、各回路の展開ログを含むページがありましたが、これは不運です。すべてのチームが、開発に関与するすべての従業員に資格情報がこれらのログを介して流れることを受け入れるわけではありません。その結果、この機能を削除し、別の形式で返すことにしました。現在はカスタマイズ可能（したがってオプション）であり、kubernetesダッシュボードとの統合を通じて実装されてい ます。



他にもポイントがあります。新しいアプローチでは、インフラストラクチャをサポートするためにより多くのコンピューティングリソース、ディスク、ドメイン名を使用するため、コストの最適化の問題が発生します。これをDevOpsの微妙な点と組み合わせると、資料は別の投稿、または2つでも入力されるため、ここではこれについて説明しません。



あるプロジェクトで新たに発生した問題を解決するのと並行して、別のチームからの関心を見て、このソリューションを別のプロジェクトに統合し始めました。これにより、さまざまなプロジェクトのニーズに対応できるように、ソリューションがカスタマイズ可能で柔軟性があることを確認できました。現在、Octopodは我が国で3ヶ月間広く使用されています。



結果として



その結果、システムとプロセスはいくつかのプロジェクトに実装されており、もう1つのプロジェクトから関心が寄せられています。興味深いことに、古いスキームに問題が見られなかった同僚でさえ、今はそれに切り替えたくないでしょう。一部の人にとっては、彼らが知らなかった問題を解決したことが判明しました！



いつものように、最も困難だったのは最初の実装でした。技術的な問題や問題のほとんどがそれに捕らえられました。ユーザーからのフィードバックにより、そもそも何を改善する必要があるのか​​をよりよく理解することができました。最新バージョンでは、Octopodのインターフェースと動作は次のようになります。





私たちにとって、Octopodは手続き上の質問に対する答えになりました。現在の状態は明白な成功であり、柔軟性と利便性が明らかに向上しています。まだ完全には解決されていない問題があります。クラスター内のOctopod自体の承認をいくつかのプロジェクトのAtlassianoauthにドラッグし、このプロセスが遅れています。ただし、これは時間の問題にすぎません。技術的には、最初の近似で問題はすでに解決されています。



オープンソース



Octopodが私たちだけでなく役立つことを願っています。同様のプロセスを最適化する方法に関する提案、プルリクエスト、および情報を喜んで受け取ります。プロジェクトに関心がある場合は、オーケストレーションと操作の機能について説明します。



構成例とドキュメントを含むすべてのソースコードは、Githubのリポジトリで入手できます 。


More articles:


All Articles