Compute Engine での Spinnaker の実行

このソリューションでは、Spinnaker デプロイの実施、保護、維持など、Google Compute Engine で Spinnaker を実行する場合のおすすめの方法について説明します。

継続的配信パイプラインを設定する必要がある場合、Spinnaker によって次のようなメリットがもたらされます。

  • Spinnaker は、「不変のインフラ」の原則に基づいて構築されており、クラウド ネイティブ アプリの高速かつ信頼性の高いデプロイのための基盤を提供します。

  • デプロイは、予測可能で安全であり、必要なときに簡単にロールバックすることができます。

  • テスト、QA、本番など、複数の開発環境にまたがる複雑なデプロイ パイプラインを作成することができます。

Spinnaker について

Spinnaker は、クラウド リソースにソフトウェアをデプロイする継続的配信パイプラインを編成するためのオープンソース ツールです。コードベースは、Java および Groovy で作成され、Spring Boot フレームワークを活用します。Spinnaker は、直感的なユーザー インターフェースと、各パイプライン ステージのタスクおよびステージ間の依存関係をきめ細かく制御するための柔軟な REST API を提供します。Spinnaker を使用すれば、ソフトウェア リリース プロセスを個別のステップのセットに簡単にマップし、ソフトウェアを確実にエンドユーザーに配信することができます。

次の画像は、Spinnaker のリリース プロセスについて説明したものです。

Spinnaker リリース プロセス

ソフトウェアは構築されてから、テストされます。すべてのテストに合格すると、不変のイメージが「作成」され、クラウドで利用可能になります。イメージが利用可能になったら、それをインスタンスのセットにデプロイし、実行中のソフトウェアを更新することができます。

Spinnaker は、マイクロサービス コンポーネントが含まれるアプリケーション スタックであり、それぞれが機能の個別の部分を処理します。各コンポーネントは、トップレベルの /var/log/spinnaker ディレクトリで個別のディレクトリにログを生成します。 Spinnaker のコンポーネント構成ファイルは、/opt/spinnaker/config/ ディレクトリにあります。

次のコンポーネントは、Google Cloud Platform(GCP)と直接対話します。

  • Clouddriver コンポーネントは Compute Engine API と対話してアプリケーションをデプロイし、そのロードバランサを更新します。

  • Front50 コンポーネントは、パイプライン定義といった、Spinnaker 固有の構成とメタデータ用の永続ストレージを処理します。構成データは、Google Cloud Storage に保存されます。

  • Rosco コンポーネントは、パイプラインの作成段階で Packer を使用して Compute Engine イメージを構築します。

Spinnaker コンポーネントの全リストについては、Spinnaker ドキュメントを参照してください。

デプロイ アーキテクチャ

Spinnaker Deployment Manager テンプレートを使用して、次のアーキテクチャをデプロイできます。

Spinnaker デプロイ アーキテクチャ

Spinnaker、Jenkins、および Redis などの主要コンポーネントはそれぞれ、独立したスケーリングを実施するために独自の仮想マシン上で実行されます。各仮想マシンは、少なくとも 1 つのインスタンスが常に実行されるように独自のインスタンス グループで実行されます。この設定を使用すると、マシンに障害が発生したり、異常終了した場合、Compute Engine インスタンス グループ マネージャが代わりに別のインスタンスを起動します。

各デプロイ ネットワークおよびサブネットワークは、Spinnaker をプロジェクトの残りのインフラストラクチャから分離します。静的 IP アドレスは、各コンポーネントをよく知られているネットワーク位置に配置し、他のコンポーネントが確実にアクセスできるようにします。ネットワーク ファイアウォールは、Spinnaker の動作に必要なトラフィックや、管理者が Spinnaker を管理するトラフィック以外のアクセスを制限します。Spinnaker のネットワーク内部では、Spinnaker インスタンスのみが Jenkins と Redis にアクセスできます。

Cloud Storage は可用性が高く、データ レプリケーションを提供するため、アーキテクチャは Cloud Storage を使用して Spinnaker の構成設定を保存します。

Spinnaker の設定

設定ファイル

各 Spinnaker コンポーネントには、その機能をカスタマイズするための、対応する設定ファイルが含まれています。たとえば、編成コンポーネント Orca を設定して、Jenkins で汎用スクリプト ステージを実行できます。これにより、ソースコード リポジトリ内の Bash スクリプトによって定義されたパイプラインにデータベース移行ステージを設定できます。Spinnaker をインストールすると、これらの設定ファイルは /opt/spinnaker/config ディレクトリに配置されます。

spinnaker-local.yml ファイルは、共通の値をさまざまなコンポーネントで再利用できるように、コンポーネント間で共通パラメータを統合します。

次の図は、Spinnaker の設定ファイルの階層を示しています。

Spinnaker 設定ファイル

/etc/default/spinnaker ディレクトリで環境変数を設定することによって、spinnaker-local.yml ファイル内の特定の構成オプションを使用できます。環境変数を使用して設定できるオプションを確認するには、以下の表記で表される変数を探します。

${VARIABLE:default-value}

これらの変数を上書きしなかった場合、default-value が使用されます。

次の例に示すように、等号で区切られたキーと値のペアで環境変数を作成します。

SPINNAKER_GOOGLE_ENABLED=true
SPINNAKER_GOOGLE_PROJECT_ID=myproject-name
SPINNAKER_DEFAULT_STORAGE_BUCKET=my-spinnaker-bucket
SPINNAKER_GOOGLE_DEFAULT_REGION=us-west1
SPINNAKER_GOOGLE_DEFAULT_ZONE=us-west1-a

イメージ作成の設定

Spinnaker の重要なユースケースの 1 つは、VM クラスタに不変のイメージをデプロイするパイプラインを編成することです。不変のイメージには、いくつかの利点があります。

  • イメージを特定の以前のリリースにロールバックできます。

  • 既存のバージョンをスケーリングすることで、アプリケーションの同一のコピーを生成します。

  • 最小限のスタートアップ ステップにより、アプリケーションを高速で起動できます。

Spinnaker は Packer を活用して、不変のイメージを作成します。Rosco コンポーネントは、イメージ構築プロセスを管理します。Rosco は、/opt/rosco/config/packer/gce.json ファイルにあるデフォルトの Packer 設定テンプレートで設定されます。明示的な設定ファイルを構成することにより、パイプラインを作成するときにこの設定を上書きできます。デフォルトのテンプレートを変更する場合は、gce.json ファイルを更新するか、設定ファイルを作成して、パイプラインの作成段階を設定する場合にそれを指定できます。

作成段階の設定

トリガーの設定

Spinnaker は、Igor コンポーネントを、Jenkins や Travis CI といった継続的統合(CI)システム、および Github や Stash といった Git リポジトリとのインターフェースとして使用します。コンポーネントは、パイプライン トリガーのポーリングや、パイプラインの一部としての外部ジョブのトリガを処理します。個別に構築と統合テストを行うために、複数の独立した CI システムとインターフェースするように Igor を構成できます。パイプラインをリポジトリ push によってトリガするには、CI ジョブをポーリングし、これにより Git リポジトリがポーリングされるように、または Github または Stash を直接ポーリングするように Igor を構成する必要があります。

通知の設定

Spinnaker は、トリガーまたはパイプライン ステージの結果に基づいて通知を送信できます。echo コンポーネントを設定して、通知を電子メールまたは SMS メッセージを介して、または Slack や Hipchat に送信することができます。

セキュリティと承認

このセクションでは、GCP での Spinnaker のセキュリティおよび承認のおすすめの設定について説明します。

GCP への Spinnaker のアクセスの承認

単一または複数のプロジェクトにデプロイするために、Spinnaker の GCP へのアクセスを承認することができます。

単一のプロジェクトへのデプロイ

単一のプロジェクトにデプロイする場合、Spinnaker はデフォルトのサービス アカウントを使用して Compute Engine のリクエストのための認証情報を取得できます。Spinnaker VM では、次の IAM 役割が必要です。

  • サービス アカウント アクター
  • Compute インスタンス管理者
  • Compute ネットワーク管理者
  • Compute ストレージ管理者
  • ストレージ管理者

複数のプロジェクトへのデプロイ

多くの顧客は、GCP プロジェクトごとに 1 つの Spinnaker のデプロイを実行しますが、このユースケースが当てはまらない場合は、複数のプロジェクトに対して Spinnaker サービス アカウントを認証することができます。Deployment Manager テンプレートを使用する場合、Spinnaker VM は、プロジェクトに属するデフォルトのサービス アカウントを使用して起動します。Spinnaker にアクセス権を付与し、複数のプロジェクトにデプロイするには、次のタスクを完了します。

  1. サービス アカウントを作成します

  2. Spinnaker Instance Group を更新して、サービス アカウントと同じメールアドレスを使用します。

  3. プロジェクトごとにデプロイし、単一のプロジェクトへのデプロイにリストされている役割でサービス アカウントを認証します。

  4. clouddriver.yml 設定ファイルを複数のアカウントに設定します。それぞれのアカウントは単一プロジェクトにマッピングされます。

サービス アカウントと GCP の詳細については、サービス アカウントについてをご覧ください。

UI 用のユーザーの認証と承認

Google OAuth を使用してユーザーを認証するように Spinnaker を構成できます。ユーザーは、初めて UI にアクセスしたときに、Google アカウントで認証するように求められ、その後 UI に転送されます。2 要素認証が有効になっているアカウントの場合、UI へのアクセス権が付与されるようにするには両方の認証フォームを使用する必要があります。

G Suite の顧客は、ドメイン内のグループに基づいて承認ルールを実装することによって、Spinnaker を安全にインストールできます。Spinnaker を使用して、変更が受け入れられるためにユーザーが属する必要があるグループのリストを定義できます。デフォルトでは、すべてのユーザーが UI のすべてのリソースを表示できます。アカウントにグループ メンバーシップの要件が含まれている場合は、そのグループのメンバーだけがそのアカウント内のリソースに変更を加えることができます。たとえば、「spinnaker-admins」という名前のユーザーのグループを設定して、次のことを行えます。

  • パイプラインの作成と削除
  • パイプラインのキックオフ
  • クラスタの破壊

既存のアイデンティティ連携システムを持っているユーザーは、Spinnaker の SAML 統合を活用できます。

ネットワーク アクセスの設定

ユーザーは通常、オンプレミス ネットワークを介して Spinnaker にアクセスするため、Spinnaker をインターネットからアクセスできるようにする必要はありません。オンプレミス環境から Spinnaker にアクセスする 1 つの方法は、Spinnaker をデプロイしたネットワークで Google Cloud VPN インスタンスを設定することです。次の画像は、その設定について説明しています。

Spinnaker と Google Cloud VPN のセットアップ

Google Cloud VPN は、ご使用の環境と Compute Engine インスタンス間のトラフィックに対して暗号化トンネルを提供し、企業ネットワーク上のすべてのユーザーが、Spinnaker のプライベート IP アドレスにアクセスできるようにします。パブリック IP アドレスを使用せずに Spinnaker を起動する場合、リポジトリと依存関係をダウンロードするために、インターネットに到達するために使用可能な NAT ゲートウェイを作成する必要があります。

数人のユーザーだけが Spinnaker と直接対話する状況では、各ユーザーのワークステーションから Spinnaker インスタンスへの SSH ポート転送を設定することができます。Spinnaker をリモートマシンから使用する場合は、Deck(9000)、Gate(8084)、Rosco(8087)ポートを転送します。ポート転送を設定する方法の詳細については、SSH でのポート転送をご覧ください。

VM 間の不要なアクセスを防ぐファイアウォールのルールを作成することで、内部ネットワークのトラフィックをロックダウンすることができます。Spinnaker から Redis へのトラフィックおよび Spinnaker から Jenkins へのトラフィックのみを許可します。Spinnaker VM への SSH トラフィックを制限します。

Spinnaker のアップグレード

定期的に Spinnaker をアップグレードして、最新の機能拡張とバグ修正を受信します。Spinnaker のインストールを最新のリリースにアップグレードするには、パッケージのアップグレードを実行します。たとえば、次のコマンドを実行して Ubuntu 14.04 を更新することができます。

sudo apt-get update
sudo apt-get upgrade spinnaker-clouddriver \
                   spinnaker-deck spinnaker-echo spinnaker-front50 \
                   spinnaker-gate spinnaker-igor spinnaker-orca \
                   spinnaker-rosco spinnaker
sudo restart spinnaker

Spinnaker を再起動すると、現在実行中のパイプラインは終了し、Spinnaker が再度稼働したときにそれらのパイプラインが再起動する可能性があるので注意してください。

Spinnaker のバックアップと復元

Spinnaker は、パイプライン、アプリケーション、およびプロジェクト構成などの重要なデータを Cloud Storage に保存します。このデータは、耐久性に優れており、デフォルトで領域全体で複製され、保存時に暗号化されます。Spinnaker は Cloud Storage のバージョン管理機能を使用して、パイプラインの変更履歴を有効にします。Spinnaker のユーザー インターフェースは、パイプラインのバージョン間の違いを示し、以前の状態を復元できるようにします。

Spinnaker パイプラインの変更履歴

データをバックアップするには、gcloud sync コマンドを使用してデータを別のリージョンのバケットに複製します。データを復元するには、Spinnaker を再デプロイするリージョンのバケットにデータを同期します。

Spinnaker は、Redis を一時的なストレージとして使用し、継続的なパイプライン タスクを追跡します。状態が失われてもパイプラインは再起動できるため、このデータのバックアップはそれほど重要ではありません。Redis の状態が失われると、パイプラインが自動的に再トリガーされる場合があります。デプロイメント パイプラインには、手動判定ステージや Spinnaker の組み込み通知を使用して、重要なステージまたは破壊的なステージのためのゲートを含めるようにしてください。複数の Redis インスタンスを所有することによって、1 つのホストがダウンした場合でも高可用性を実現できます。このデータをバックアップすることを選択した場合は、定期的に状態のスナップショットを取り、ファイルを Cloud Storage にファイルを転送するように Redis を構成することができます。Redis の永続性と災害復旧の詳細については、Redis の永続性をご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...