1. 概要

このチュートリアルでは、Netflixによって構築されたオープンソースの継続的デリバリープラットフォームであるSpinnakerを見ていきます。 これを使用して、複数のクラウドプロバイダーにアプリケーションをデプロイできます。

このシステムはSpringBoot の上に構築されており、多くのクラウドプロバイダーをサポートしています。

それがどのように機能し、どのような場合に使用できるかを見ていきます。

2. バックグラウンド

ソフトウェア開発の歴史を見てみましょう。 まず、リリース頻度の低いウォーターフォールがありました。

その後、アジャイルの作業を開始し、スプリントごとに機能を提供しました。 ただし、すべてのスプリントを本番環境にデプロイすることはできませんでした。残念ながら、ユーザーは棚に置かれていた新機能を使用できませんでした。

定期的に展開しない理由はいくつかあります。 それらの1つは、展開手順が手動で実行されることが多く、人的エラーが発生しやすいという事実でした。

さらに、一部の人々は、より頻繁に展開することは潜在的な問題のより多くのリスクを意味すると考えました。 現在、小さな変更を導入することで大きな間違いのリスクが少なくなることにほぼ同意しています。それでも、間違いがあった場合は、小さな変更ですぐに見つけて、問題を解決する新しいバージョンをリリースできます。

3. Spinnaker

Spinnakerを使用すると、継続的デリバリーまたは継続的デプロイを使用して、アプリケーションを本番環境で自動的にリリースできます。継続的デリバリーとは、すべてが本番リリースに向けて準備されることを意味します。

ただし、リリースは、アプリケーションが本番環境にデプロイされる前に手動で承認されます。 継続的展開とは、手動による介入がないことを意味します。 本番環境へのデプロイを含むすべてのステップが実行されます。アプリケーションコードをバージョン管理システムにプッシュするだけで、それだけです。

コードをバージョン管理にプッシュしてから本番環境にデプロイするまで、多くのステップを実行できます。 コードをビルドし、コードを単体テストし、テスト環境にデプロイして、機能テストを実行できます。 いわゆるパイプラインを使用して、これらすべてのステップを構成します。

Spinnakerを使用すると、このようなパイプラインを作成して、ほとんどのクラウドプロバイダーにアプリケーションをデプロイできます。

4. コンポーネント

Spinnakerは、基本的に2つの部分で構成されています。さまざまなクラウドプロバイダーの上にある抽象化レイヤーと、継続的デリバリーのためのツールです。

4.1. 従来のクラウド展開

クラウドプロバイダーを見ると、それらはすべてほぼ同じサービスを提供しています。 これらのサービスには、インスタンス、サーバーレス、コンテナサポートなどが含まれます。

ただし、これらのサービスの構成はプロバイダーによって大きく異なります。 そのため、プロバイダーを切り替えるのが難しくなります。 別のクラウドプロバイダーに移動してすべての詳細を学習するには時間がかかります。つまり、基本的にベンダーロックインがクラウドプロバイダーにあります。

Netflixは、1つだけに依存するのではなく、クラウドプロバイダーを簡単に切り替える可能性を望んでいました。 そのため、彼らはクラウドプロバイダーの上に抽象化レイヤーを構築しました。

4.2. 抽象化レイヤー

Spinnakerを使用する場合、すべてのクラウドプロバイダーで同じです。 Amazon Web Services、Microsoft Azure、Google Cloud Platform、OpenStack、Google App Engine、またはKubernetesで使用できます。 これにより、価格競争力が高い場合は、別のクラウドプロバイダーに移行できます。

さらに、同時に複数のプロバイダーにデプロイすることを選択できます。このようにして、冗長性を高めるために2つ以上のプロバイダーでアプリケーションを実行できます。

抽象化レイヤーのもう1つの利点は、リソースではなくアプリケーションに焦点を当てることです。通常、クラウドプロバイダーは、現在使用しているリソースを表示します。 ただし、どのアプリケーションがどのリソースを使用しているかを把握する必要があります。

しかし、リソースは私たちにとって興味深いものではありません。 リソースの追跡に時間を費やすことなく、アプリケーションを実行したいと考えています。 Spinnakerにはアプリケーション中心のビューがあります。 したがって、これを見ると、最初にアプリケーションが表示され、次にアプリケーションで使用されているリソースが表示されます。

4.3. 継続的デリバリー

抽象化レイヤーの上に、Netflixは継続的デリバリープラットフォームを構築しました。このプラットフォームにより、アプリケーションを1つ以上のクラウドプロバイダーにデプロイできます。 Jenkinsに少し似ていますが、クラウドプロバイダーとの統合が優れており、必要な構成が少なくて済みます。

たとえば、Jenkins、アップロードされたDockerイメージ、またはgitpushから継続的デリバリーパイプラインをトリガーできます。 その後、アプリケーションを使用してイメージまたはコンテナを作成し、本番環境で開始するだけです。

ただし、本番環境に展開する前の自動テストや手動承認など、利用できるオプションは他にもたくさんあります。

既存のアプリケーションの新しいバージョンを展開するときに、どの戦略に従うかを決定することもできます。 そのため、古いバージョンを新しいバージョンに簡単に置き換えることができます。 ただし、より良い戦略は、最初にそれらを並べて実行することです。 そうすれば、新しいバージョンが機能するかどうかを自動または手動で確認し、機能する場合は古いバージョンを削除できます。

5. Netflixクラウドモデル

すべてのアプリケーションは1つ以上のサーバーグループで構成されています。同じバージョンのアプリケーションがサーバーグループ内のすべてのインスタンスで実行されます。 次の命名規則が使用されます。 -<(オプション)スタック>-<(オプションの詳細)>- 。 (オプションの)スタックフィールドは、サーバーグループがテスト、本番、またはその他の目的であるかどうかを指定するために使用されます。 オプションの詳細フィールドは、追加情報に使用されます。

最後に、同じ名前、スタック、および詳細を持つ1つ以上のサーバーグループを含むクラスターの概念があります。ただし、ほとんどの場合、クラスター内の各サーバーグループは異なるバージョンの応用。 失敗したインスタンスは、新しいインスタンスに置き換えられます。

増加した負荷に対応するために、サーバーグループにインスタンスを自動的に追加することもできます。

6. 展開戦略

新しいバージョンのアプリケーションを展開する場合、通常は「赤/黒」戦略が選択されます。最初に、新しいバージョンのアプリケーションを含む新しいサーバーグループがクラスターに展開されます。 アプリケーションの展開後、新しいサーバーグループが正常であるかどうかを確認するためのチェックが実行されます。

これで、サーバーグループが有効になり、お客様が利用できるようになりました。 最後に、古いサーバーグループが無効になります。

このシナリオでは、新しいアプリケーションサーバーで問題が発生した場合に、簡単にロールバックできます。古いバージョンのサーバーグループを再度有効にして、お客様が利用できるようにするだけです。

7. Spinnakerが選ばれる理由

Spinnakerを使用すると、使用するクラウドリソースではなく、アプリケーションに集中できます。これにより、アプリケーションのデプロイと保守が容易になります。

さらに、Spinnakerを使用すると、複数のクラウドプロバイダーで同時に実行できます。 さらに、価格戦略と利用可能な機能に応じて、他のクラウドプロバイダーに簡単に切り替えることができます。

8. 結論

Spinnakerは、Netflixの経験に基づいています。最小限の労力で、彼らの知識を活用し、同じように作業できます。 これらのツールに基づいて、アプリケーションを本番環境にデプロイするためのデプロイメントパイプラインを簡単に実装できます。

Spinnakerの詳細については、無料の Continuous Delivery withSpinnaker電子ブックをダウンロードしてください。