タコを展開します。 血なまぐさい企業の世界を改善する

今日は、 Octopus Deploy展開システムについてお話します。 現時点では、Habréのこのトピックに関する紹介記事は1つしかありません。したがって、私の資料では、システムの説明を拡張し、「ライフサイクル」や「チャネル」などの重要な概念について詳しく説明します。 Octopusをどのように実装して使用したか。

私たちは誰ですか

私たちは独自の開発部門Tinkoff.ruです。 私が取り組んでいるチームは、WebOfficeクラウド仮想デスクトッププラットフォームを開発しています。 現時点では、Asp.Net MVCアプリケーションと、バックエンドのServiceStackベースのREST API、およびフロントのAngularのSPAがあります。 これに加えて、他の銀行システムとの統合のためのSOAPサービス、定期的なタスクのためのジョブセキュリティ、および.Net Core 2.0上の多数のマイクロサービスがあります。

古い展開プロセスの問題

Tinkoffに来たとき、TeamCity：MSDeployを使用してシステムの展開が実行され、さまざまな複雑さのn番目のPowerShellスクリプトが使用されました。 プロジェクトの構築と展開を担当する構成ビルドは、その時点で利用可能な輪郭（QAとProd）に従ってグループ化されました。



各回路の古いアセンブリと展開プロセスは、次のように条件付きで表すことができます：特定の環境のプロジェクトを収集します（xml構成の適切な変換を適用します）→受信したアーティファクトをいくつかのzipファイルに収集します（個別に展開されたアプリケーション+データベース移行スクリプト+展開スクリプトごとに1つ） ）→指定されたサーバー環境に指定された場所にデプロイします。



作業ではフォールトトレランスと負荷分散に複数のサーバーを使用しているため、アプリケーションとサーバーを順番に処理するため、展開プロセスにかなりの時間がかかりました（PowerShell並列非同期タスクの作成はかなり苦痛です）。 追加のQA2ループとPreprodループの追加により、ビルド構成の数が増加し、異なるパラメーターによる展開設定の管理がより複雑になりました。

目的

展開プロセスをさまざまな回路に統合し、可能な場合は高速化し、バージョン管理システムのタイプに応じてリリース配信プロセスを標準化しました。メジャーリリースはQA→Pre→Prodを、マイナーリリースはQA2→Pre→Prodを実行する必要があります、ホットフィックス-Pre→Prod。



これらすべてのウィッシュリストで、Octopus Deployが役に立ちました。 リリース配信プロセスに実装することで得られた主な利点は次のとおりです。

• すべての回路のアプリケーション全体に対する単一の展開プロセス。
• アプリケーションのインフラストラクチャ設定の変数を保存する単一の場所。
• 複数のサーバーへの並列展開。
• TeamCityのさまざまなビルド構成を1つに減らします。
• 通常の（正しい）ビルドライフサイクル（同じバイナリが最初にQAに展開され、次にPreprodに展開され、次にProdに展開される場合。TeamCityバージョンでは、環境ごとに個別のビルド構成が構成されました）。
• リモーティングバインディングをスローすることによるカスタムPowerShellスクリプトの簡素化。
• 環境の可視性、展開プロセス、特定の展開を柔軟に構成する機能。
• リリース管理に対するアクセス権の柔軟な差別化。

インストールとセットアップ

システム自体のインストールは簡単で簡単です。外部の依存関係から、データベースの保存に必要なのはMS SQL Serverのみです。 さらに、展開を計画している各サーバーに、Octopus Tentacleエージェントをインストールする必要があります。



インストールは自動化されているため、不必要な手動作業がなくなり、新しいサーバーを展開する準備ができます。 これを行うには、Ansibleを使用し、アプリケーション自体をインストールした後、そのようなPowerShellスクリプトを使用して構成を実行します。





その結果、新しいサーバーを作成した後、自動的にタコに登録され、すぐに展開できます。 とても快適です。

ライフサイクル

Octopus Deployの重要なエンティティの1つはライフサイクルです。 これらは、環境間でリリースを自動的に促進するため、および適切なテストに合格する前にアプリケーションをデプロイできる環境を制限するために使用されます。



たとえば、メジャーバージョンの場合、システムのライフサイクルはQA→Pre→Prodとして定義されます。 これは、テストおよびpreprod回路に進む前に、本番環境にバージョンを展開できないことを意味します。 一方、パッチバージョンのライフサイクルは短くなります。Pre→Prod。 それらはプリプロードですぐにテストされます。

チャンネル

Octopusのチャネルを使用すると、単一プロジェクトの複数のバージョンを個別に展開できます。 パッケージのバージョンを制限するルールに加えて、各チャネルについて、リリースを促進するために使用されるライフサイクルを指定し、展開プロセスを構成します（各ステップには実行するチャネルの設定があるため）。また、変数の値を決定できます。 Octopus Deployで作成された各リリースは、必ずチャネルを参照します。



このプロジェクトには、メジャー、マイナー、パッチバージョンのチャネルと、修正プログラムの直接起動および統合テスト用のシステムインスタンスの展開のための専用チャネルがあります。



主な魅力は、適切なチャネルでリリースを自動的に作成できることです。 これを行うには、チャネルプロパティでパッケージバージョンの範囲を指定し（SemVerタグも使用できます）、このチャネルでリリースを作成するために使用する必要があります。 Octopusは、最新バージョンのパッケージを自動的に選択します。



現在、バージョンV10.1およびV11.0をテストしているとします。 V10.1ブランチからプロジェクトをビルドした後、TeamCityは収集されたパッケージ（パッケージのバージョンは10.1.0.xxxxになります）をOctopusでフラッディングし、「マイナー」リリースのチャネルでリリースを作成します。 同時に、バージョン10.1.0.xxxxのパッケージは、Octopusがバージョン11.0.0.yyyyの新しいパッケージを既に持っているという事実にもかかわらず、リリースに入ります。 バージョン範囲では、「マイナー」リリースのチャネルの範囲は[10.1.0.00000、10.1.0.99999）です。







したがって、アプリケーションの異なるバージョンはチャネル内で完全に共存し、異なる環境への独自の展開プロセスに従います。

プロジェクトコントロールパネルでの表示例を次に示します。

重要！ 展開プロセスに新しい手順を追加する場合、チャネルルールに新しいパッケージを追加します。 チャンネル内のパッケージにバージョン制限が設定されていない場合、Octopusはパッケージの最新バージョンを使用します。 アプリケーションバージョン10.1をデプロイする場合がありますが、たとえばOctopusに既にある場合、1つのパッケージはバージョン11.0になります。

NuGetパッケージの作成

Octopackツールを使用して、プロジェクトのビルド中に展開用のパッケージを作成できます。 これは、NuGetパッケージとして必要なプロジェクトにインストールされます。デフォルトの設定で問題なければ、他に何もする必要はありません。



Octopackは、プロジェクトの種類（コンソールアプリケーション、Webアプリケーション、Windowsサービス）に基づいて、展開中に必要なファイルを選択します。 パッケージに含めるファイルをさらに微調整する必要がある場合は、カスタム.nuspecファイルを作成できます。

TeamCity統合

しかし、最も興味深い部分は、TeamCityでプロジェクトをビルドした後にリリースを作成（および展開）するプロセスを自動化するときに始まります。 このプロセスは次のようになります。

• レビュー後、開発者は自分のタスクをバージョンブランチにマージします。
• TeamCityはプロジェクトを収集し、アセンブリを配置するチャネルを決定し、Octopus Deployの必要なチャネルでリリースを作成します。
• 準備ができたら、テスターはOctopusコントロールパネルの[展開]ボタンをクリックし、このチャネルに対応するテスト環境にアセンブリを展開します。

NuGetパッケージを準備し、Octopusにアップロードし、リリースを作成するタスクの一部は、TeamCity用のOctopus Deployプラグインをインストールすることにより、非常に簡単に実行できます。 他のいくつかの操作（たとえば、チャネルのバージョン範囲の自動更新）のために、小さなPowerShellスクリプトを作成しました。

ガイド付き障害

展開プロセス中にいずれかの手順でエラーが発生した場合、展開全体が停止し、落下としてマークされます。 この動作は常に関連しているわけではありません。展開のいくつかのステップで問題に対処する準備ができている場合があります。 これらの場合には、ガイド付き障害と呼ばれる体制があります。



オンになっていて、展開中にエラーが発生した場合、Octopusはすべての操作を一時停止し、特別なウィンドウを表示します。 調査の結果を示し、展開プロセスを続行するかどうかを決定できます。 展開履歴には、誰が、いつ、何を決定したかについてのメモがあります。

パッケージ内の展開スクリプト

アプリケーションとサービスをデプロイする前に、追加のアクションを実行したい場合があります。 たとえば、サービスアカウントに代わって、アプリケーションが起動時にポートにアクセスできることを確認します。 これは、追加のインストールスクリプトを使用して行うことができます。このスクリプトは、Octopus Webインターフェイスで記述でき、展開可能なアプリケーションパッケージの一部にすることができます。



スクリプトでは、PowerShellの変数の命名規則に従ってスローされるタコ変数を使用できます（ドットやその他の特殊文字は変数名から削除されるため、MyApp.ConnectionStringタコ変数は$ MyAppConnectionStringとしてスクリプトで使用できます）。





サービスのポート予約を削除および追加する展開前スクリプトの例

保持ポリシー

ある日、ハードドライブが完全にいっぱいになった状況にならないように、Octopusは、古いリリースで使用されて不要になったパッケージを削除するメカニズムを提供します。



パッケージストレージポリシーはライフサイクルレベルで記述されますが、個々のフェーズで再定義できます。 そのため、たとえば、テスト環境へのアプリケーションの展開のすべての段階で、パッケージの最新バージョンを1つだけ保存します。







戦闘環境では、この設定をオーバーライドし、最後の5つのリリースのパッケージを格納します（突然ロールバックする必要がある場合）。 マシン自体にパッケージを保存するリリースを指定することもできます。 ロールバックが発生した場合、Octopusサーバーからパッケージを再ダウンロードする時間を無駄にすることなく、より迅速に展開できます。

追加の肉焼き

このセクションでは、システムで使用するpowershellスクリプトを共有します。 それらをそのまま、または例として使用して、独自のアイデアを実装できます。

おわりに

1年前にOctopus Deployの使用を開始し、短時間のテスト操作の後、すべての環境にシステムをデプロイするために完全に切り替えたことを非常に嬉しく思います。



このプロジェクトは活発に開発されており、マイナーリリースはほぼ毎週公開されています。 最近のバージョンでは、Octopus Deployは.netコアおよびモノラルアプリケーションをLinuxマシンにデプロイし、Dockerコンテナをデプロイすることを学びました。最新リリース3.17では、Tomcat、RedHat JBOSS、WildflyアプリケーションサーバーへのJavaアプリケーションのデプロイに対する一流のサポートを追加しました。



次の記事では、ブランチの機能をローカルOpenStackクラウドで自動的に発生する個々の仮想マシンに展開するプロセスを整理して、個々のタスクの分離テストを実施するために使用するマルチテナント展開について説明します。