DigitalOcean KubernetesでSpinnakerを使用してCDパイプラインをセットアップする方法

Spinnakerは、強力でカスタマイズ可能なパイプラインシステムを使用して、高速で安全かつ反復可能な展開を実現するオープンソースのリソース管理および継続的デリバリーアプリケーションです。 Spinnakerを使用すると、DigitalOcean Kubernetesを含む多くのプラットフォームへのアプリケーションの自動展開が可能になります。 デプロイするとき、独自のデプロイメント戦略を作成するオプションを使用して、HighlanderやRed / blackなどの組み込みのdeployment strategiesを使用するようにSpinnakerを構成できます。 JenkinsやTravisCIなどの他のDevOpsツールと統合でき、GitHubリポジトリとDockerレジストリを監視するように構成できます。

Spinnakerは、さまざまなプラットフォームにSpinnakerを構成および展開するために特別に構築されたツールであるHalyardによって管理されます。 Spinnakerでは、アプリケーションの設定とパイプラインを永続化するためにexternal storageが必要です。 DigitalOcean Spacesなど、このタスクのさまざまなプラットフォームをサポートします。

このチュートリアルでは、Halyardを使用して、DigitalOcean Spacesをバックエンドストレージとして、SpinnakerをDigitalOcean Kubernetesにデプロイします。 また、Spinnakerを目的のドメインで使用できるように設定し、Let's Encrypt TLS証明書を使用して保護します。 次に、Spinnakerでサンプルアプリケーションを作成し、パイプラインを作成して、Hello WorldアプリをKubernetesクラスターにデプロイします。 テスト後、GitHub Organizationsを介して認証と承認を導入します。 最終的に、Kubernetesクラスターに安全で動作するSpinnaker展開ができます。

[.note]＃Note:このチュートリアルは、Spinnaker1.13.5。
で特別にテストされています＃

[[step-1 -—- adding-a-kubernetes-account-with-halyard]] ==ステップ1—HalyardでKubernetesアカウントを追加する

このセクションでは、Halyardを介してKubernetesアカウントをSpinnakerに追加します。 アカウントは、Spinnakerの用語では、クラウドプロバイダーへのアクセスに使用する名前付きの資格情報です。

前提条件の一部として、テスト目的でecho1およびecho2サービスとecho_ingress入力を作成しました。このチュートリアルではこれらは必要ないため、削除できます。

次のコマンドを実行して、イングレスを削除することから始めます。

次に、2つのテストサービスを削除します。

kubectl deleteコマンドは、-fパラメーターが渡されると、削除するファイルを受け入れます。

次に、ローカルマシンから、ワークスペースとして機能するフォルダーを作成します。

次のコマンドを実行して、ワークスペースに移動します。

HalyardはSpinnakerの展開先をまだ知りません。 次のコマンドでKubernetesプロバイダーを有効にします。

次の出力が表示されます。

HalyardはKubernetesプロバイダーを有効にするために行ったすべての手順を記録し、アカウントがまだ定義されていないことを警告しました。

次に、RBACとともにSpinnakerのKubernetesservice accountを作成します。 サービスアカウントは、単一の名前空間にスコープされるアカウントの一種です。 これはソフトウェアによって使用され、クラスター内のさまざまなタスクを実行できます。 RBAC（Role Based Access Control）は、Kubernetesクラスター内のリソースへのアクセスを規制する方法です。 重要な構成がクラスターで不注意に変更されないように、アカウントのアクションの範囲を制限します。

ここでは、Spinnakerにcluster-admin権限を付与して、クラスター全体を制御できるようにします。 より制限の厳しい環境を作成したい場合は、official Kubernetes documentation on RBACを参照してください。

まず、次のコマンドを実行して、spinnaker名前空間を作成します。

出力は以下のようになります。

次のコマンドを実行して、spinnaker-service-accountという名前のサービスアカウントを作成します。

-nフラグを使用して、kubectlがspinnaker名前空間にサービスアカウントを作成するように指定しました。 出力は次のようになります。

次に、それをcluster-adminロールにバインドします。

次の出力が表示されます。

Halyardはローカルのkubectlを使用してクラスターにアクセスします。 Spinnakerを展開する前に、新しく作成したサービスアカウントを使用するように設定する必要があります。 Kubernetesアカウントは、ユーザー名とトークンを使用して認証します。 サービスアカウントが作成されると、Kubernetesは新しいシークレットを作成し、アカウントトークンを設定します。 spinnaker-service-accountのトークンを取得するには、最初にシークレットの名前を取得する必要があります。 次のコマンドを実行して、TOKEN_SECRETという名前のコンソール変数にフェッチできます。

これは、名前空間spinnakerからspinnaker-service-accountに関する情報を取得し、JSONパスを渡すことによって含まれる最初のシークレットの名前をフェッチします。

次のコマンドを実行して、シークレットの内容をTOKENという名前の変数にフェッチします。

これで、環境変数TOKENで使用できるトークンができました。 次に、kubectlでサービスアカウントの認証情報を設定する必要があります。

次の出力が表示されます。

次に、次のコマンドを実行して、現在のコンテキストのユーザーを新しく作成されたspinnaker-token-userに設定する必要があります。

現在のユーザーをspinnaker-token-userに設定することにより、kubectlはspinnaker-service-accountを使用するように構成されますが、Halyardはそれについて何も知りません。 次を実行して、Kubernetesプロバイダーにアカウントを追加します。

出力は次のようになります。

このコマンドは、spinnaker-accountという名前のKubernetesアカウントをHalyardに追加し、サービスアカウントとしてマークします。

一般に、Spinnakerは、分散インストールまたはローカルインストールの2つの方法で展開できます。 Distributedのインストールは、このチュートリアルで完了しているものです。つまり、クラウドにデプロイします。 一方、Localのインストールは、Halyardが実行されているマシンにSpinnakerがダウンロードされてインストールされることを意味します。 SpinnakerをKubernetesにデプロイするため、次のようにデプロイメントをdistributedとしてマークする必要があります。

Spinnakerデプロイメントはイメージを構築するため、Spinnakerでartifactsを有効にする必要があります。 次のコマンドを実行して、それらを有効にできます。

ここでは、artifactsを有効にして、Spinnakerが作成するオブジェクトに関するより多くのメタデータを保存できるようにしました。

Halyardを介してSpinnakerにKubernetesアカウントを追加しました。 Kubernetesプロバイダーを有効にし、RBACロールを構成し、現在のkubectl構成をSpinnakerに追加して、プロバイダーにアカウントを追加しました。 次に、バックエンドストレージをセットアップします。

[[step-2 -—- configuring-the-space-as-the-underlying-storage]] ==ステップ2—スペースを基礎となるストレージとして構成する

このセクションでは、スペースをSpinnakerデプロイメントの基礎となるストレージとして構成します。 SpinnakerはSpaceを使用して、その構成とパイプライン関連のデータを保存します。

HalyardでS3ストレージを構成するには、次のコマンドを実行します。

your_space_access_keyをスペースアクセスキーに置き換え、spaces_endpoint_with_region_prefixをスペースのエンドポイントに置き換えることを忘れないでください。 これは通常region-id.digitaloceanspaces.comであり、region-idはスペースの領域です。 space_nameをスペースの名前に置き換えることができます。 --no-validateフラグは、DigitalOcean Spaces検証がサポートされていないため、指定された設定をすぐに検証しないようにHalyardに指示します。

このコマンドを実行すると、Halyardはシークレットアクセスキーを要求します。 入力して続行すると、次の出力が表示されます。

s3ストレージを構成したので、次のコマンドを実行して、デプロイメントがこれをストレージとして使用することを確認します。

出力は次のようになります。

Spinnakerのインスタンスが使用する基礎となるストレージとしてSpaceを設定しました。 次に、SpinnakerをKubernetesクラスターにデプロイし、Nginx Ingress Controllerを使用してドメインで公開します。

[[step-3 -—- deploying-spinnaker-to-your-cluster]] ==ステップ3—Spinnakerをクラスターにデプロイする

このセクションでは、Halyardを使用してSpinnakerをクラスターにデプロイし、Nginx Ingressを使用してドメインのUIおよびAPIコンポーネントを公開します。 まず、ドメインURLを構成します。1つはSpinnakerのユーザーインターフェイス用で、もう1つはAPIコンポーネント用です。 次に、目的のバージョンのSpinnakerを選択し、Halyardを使用して展開します。 最後に、イングレスを作成し、Nginxコントローラーとして構成します。

最初に、HalyardでSpinnakerのUIとAPI URLの構成値を編集し、目的のドメインに設定する必要があります。 APIエンドポイントを目的のドメインに設定するには、次のコマンドを実行します。

出力は以下のようになります。

SpinnakerにアクセスするドメインにUIエンドポイントを設定するには、次を実行します。

出力は以下のようになります。

spinnaker-api.example.comとspinnaker.example.comをドメインに置き換えることを忘れないでください。 これらは、Nginx Ingress Controllerの前提条件で作成したロードバランサーをポイントしたドメインです。

SpinnakerのKubernetesアカウントを作成して保護し、Spaceを基盤となるストレージとして設定し、UIとAPIエンドポイントをドメインに設定しました。 これで、使用可能なSpinnakerバージョンをリストできます。

出力には、使用可能なバージョンのリストが表示されます。 この記事を書いている時点では、1.13.5が最新バージョンでした。

インストールするバージョンを選択するには、次のコマンドを実行します。

何らかのリグレッションが発生しない限り、常に最新バージョンを選択することをお勧めします。

次の出力が表示されます。

これで、Spinnakerの展開を完全に構成できました。 次のコマンドでデプロイします：

このコマンドが完了するまでに数分かかる場合があります。

最終的な出力は次のようになります。

Halyardは、Spinnakerの各マイクロサービスの展開ステータスを表示しています。 舞台裏では、kubectlを呼び出してインストールします。

Kubernetesは、すべてのコンテナを起動するのに、特に初めての場合、平均して10分かかります。 次のコマンドを実行して、進行状況を監視できます。

SpinnakerをKubernetesクラスターにデプロイしましたが、クラスターを超えてアクセスすることはできません。

入力構成をspinnaker-ingress.yamlという名前のファイルに保存します。 テキストエディターを使用して作成します。

次の行を追加します。

spinnaker-ingress.yaml

spinnaker-api.example.comをAPIドメインに、spinnaker.example.comをUIドメインに置き換えることを忘れないでください。

構成ファイルは、spinnaker-ingressと呼ばれる入力を定義します。 注釈は、この入力のコントローラーがNginxコントローラーになること、およびletsencrypt-prodクラスター発行者が前提条件のチュートリアルで定義されているTLS証明書を生成することを指定します。

次に、TLSがUIおよびAPIドメインを保護することを指定します。 APIドメインをspin-gateサービス（SpinnakerのAPIコンテナー）に転送し、UIドメインを適切なポート8084でspin-deckサービス（SpinnakerのUIコンテナー）に転送することでルーティングを設定します。 9000。

ファイルを保存して閉じます。

次を実行して、KubernetesにIngressを作成します。

次の出力が表示されます。

Let’s EncryptがTLS証明書をプロビジョニングするまで数分待ってから、ブラウザでUIドメインspinnaker.example.comに移動します。 Spinnakerのユーザーインターフェースが表示されます。

Spinnakerをクラスターに展開し、ドメインでUIおよびAPIコンポーネントを公開し、動作するかどうかをテストしました。 次に、Spinnakerでアプリケーションを作成し、パイプラインを実行してHello Worldアプリをデプロイします。

[[ステップ-4 -—-アプリケーションの作成とパイプラインの実行]] ==ステップ4—アプリケーションの作成とパイプラインの実行

このセクションでは、ドメインのSpinnakerへのアクセスを使用して、アプリケーションを作成します。 次に、パイプラインを作成して実行し、paulbouwer/hello-kubernetesにあるHello Worldアプリをデプロイします。 後でアプリにアクセスします。

SpinnakerのUIを公開したドメインに移動します。 右上隅で、Actionsを押してから、Create Applicationを選択します。 New Applicationフォームが表示されます。

名前としてhello-worldを入力し、メールアドレスを入力して、Createを押します。

ページが読み込まれたら、トップメニューの最初のタブをクリックしてPipelinesに移動します。 パイプラインがまだ定義されていないことがわかります。

Configure a new pipelineを押すと、新しいフォームが開きます。

パイプラインの名前としてDeploy Hello World Applicationを入力し、Createを押します。

次のページで、Add Stageボタンをクリックします。 Typeとして、指定したKubernetesマニフェストのデプロイに使用されるDeploy (Manifest)を選択します。 Stage Nameには、Deploy Hello Worldと入力します。 下にスクロールし、Manifest Configurationの下のテキストボックスに次の行を入力します。

マニフェストの構成

hello-world.example.comをドメインに置き換えることを忘れないでください。ドメインもロードバランサーを指しています。

この構成では、paulbouwer/hello-kubernetes:1.5イメージの3つのレプリカで構成されるDeploymentを定義します。 また、アクセスできるようにServiceを定義し、ドメインでServiceを公開するためにIngressを定義します。

画面の右下隅にあるSave Changesを押します。 終了したら、Pipelinesに戻ります。 右側で、作成したパイプラインを選択し、Start Manual Executionリンクを押します。 確認を求められたら、Runを押します。

このパイプラインは完了するまでに少し時間がかかります。 正常に終了すると、進行状況バーが完了します。

これで、構成で定義したドメインに移動できます。 SpinnakerがデプロイしたばかりのHello Worldアプリが表示されます。

Spinnakerでアプリケーションを作成し、パイプラインを実行してHello Worldアプリをデプロイし、それにアクセスしました。 次のステップでは、GitHub Organizations認証を有効にしてSpinnakerを保護します。

[[step-5 -—- enableing-role-based-access-with-github-organizations]] ==ステップ5—GitHub組織での役割ベースのアクセスの有効化

このセクションでは、GitHub OAuth認証とGitHub Organizations認証を有効にします。 GitHub OAuth認証を有効にすると、SpinnakerユーザーはGitHub経由でログインするように強制されるため、匿名アクセスが防止されます。 GitHub Organizationsを介した承認は、組織内のユーザーのみにアクセスを制限します。 GitHub組織にはTeams（メンバーの名前付きグループ）を含めることができます。これを使用して、Spinnakerのリソースへのアクセスをさらに制限できます。

OAuth認証を機能させるには、最初に承認コールバックURLを設定する必要があります。これは、承認後にユーザーがリダイレクトされる場所です。 これは、/loginで終わるAPIドメインです。 Spinnakerや他のサービスが推測するのを防ぐために、これを手動で指定する必要があります。 これを構成するには、次のコマンドを実行します。

次の出力が表示されます。

GitHubでOAuth認証を設定するには、組織のOAuthアプリケーションを作成する必要があります。 これを行うには、GitHubで組織に移動し、Settingsに移動し、Developer Settingsをクリックして、左側のメニューからOAuth Appsを選択します。 その後、右側のNew OAuth Appボタンをクリックします。 Register a new OAuth applicationフォームが表示されます。

名前としてspinnaker-authを入力します。 Homepage URLにはhttps://spinnaker.example.comと入力し、Authorization callback URLにはhttps://spinnaker-api.example.com/loginと入力します。 次に、Register Applicationを押します。

新しいOAuthアプリの設定ページにリダイレクトされます。 Client IDとClient Secretの値に注意してください。次のコマンドで必要になります。

OAuthアプリを作成したら、次のコマンドを実行して、OAuthアプリを使用するようSpinnakerを構成できます。

client_idとclient_secretをGitHub設定ページに表示されている値に置き換えることを忘れないでください。

出力は次のようになります。

OAuthアプリを使用するようにSpinnakerを構成しました。 今、それを有効にするには、次を実行します：

出力は以下のようになります。

GitHub OAuth認証を構成して有効にしました。 これで、ユーザーはSpinnakerにアクセスするためにGitHub経由でのログインを強制されます。 ただし、現時点では、GitHubアカウントを持っているすべてのユーザーがログインできますが、これは望みのものではありません。 これを克服するには、目的の組織のメンバーへのアクセスを制限するようにSpinnakerを構成します。

Halyardにはこれを設定するコマンドがまだないため、ローカルの設定ファイルを使用してこれを半手動で設定する必要があります。 デプロイ中、Halyardはローカル構成ファイルを使用して、生成された構成をオーバーライドします。

Halyardは、~/.hal/default/profiles/の下でカスタム構成を探します。 service-name-*.ymlという名前のファイルは、Halyardによって取得され、特定のサービスの設定を上書きするために使用されます。 オーバーライドするサービスはgateと呼ばれ、Spinnaker全体のAPIゲートウェイとして機能します。

gate-local.ymlという名前の~/.hal/default/profiles/の下にファイルを作成します。

次の行を追加します。

gate-local.yml

your_organization_nameをGitHub組織の名前に置き換えます。 ファイルを保存して閉じます。

この少しの構成では、GitHub組織のメンバーのみがSpinnakerにアクセスできます。

[.note]＃Note:メンバーシップがPublicに設定されているGitHub組織のメンバーのみが、Spinnakerにログインできます。 この設定は、組織のメンバーリストページで変更できます。
＃

次に、Spinnakerをさらに特定のアクセスルールソリューションであるGitHub Teamsと統合します。 これにより、アプリケーションなど、Spinnakerで作成されたリソースにアクセスするチームを指定できます。

これを実現するには、組織の管理者アカウント用のGitHubパーソナルアクセストークンが必要です。 作成するには、Personal Access Tokensにアクセスし、Generate New Tokenボタンを押します。 次のページで、選択した内容を説明し、admin:orgの下にあるread:orgスコープを必ず確認してください。 完了したら、Generate tokenを押して、表示されたらメモします。再び表示することはできません。

SpinnakerでGitHub Teamsの役割の承認を構成するには、次のコマンドを実行します。

必ずaccess_tokenを生成した個人用アクセストークンに置き換え、organization_nameを組織の名前に置き換えてください。

出力は次のようになります。

GitHubグループの設定を更新しました。 次のコマンドを実行して、認証プロバイダーをGitHubに設定します。

出力は以下のようになります。

これらの設定を更新したら、次を実行して有効にします。

次の出力が表示されます。

すべての変更が完了したら、実行中のSpinnakerデプロイメントに変更を適用できます。 これを行うには、次のコマンドを実行します。

終了したら、Kubernetesが変更を伝播するのを待ちます。 これにはかなり時間がかかる場合があります。次のコマンドを実行して、進行状況を確認できます。

すべてのポッドの状態がRunningおよび可用性1/1になったら、SpinnakerUIドメインに移動します。 GitHubにリダイレクトされ、まだログインしていない場合はログインするよう求められます。 ログインしたアカウントが組織のメンバーである場合、Spinnakerにリダイレクトされてログインし直します。 そうしないと、次のようなメッセージでアクセスが拒否されます。

GitHub Teams統合の効果は、Spinnakerがそれらをrolesに変換することです。 Spinnakerでこれらのrolesを使用して、特定のチームのメンバーのアクセスに対する追加の制限を組み込むことができます。 別のアプリケーションを追加しようとすると、そのアプリケーションのアクセスレベル（読み取り専用または読み取りと書き込み）とロールを組み合わせたアクセス許可も指定できるようになります。

GitHubの認証と承認を設定しました。 また、組織のメンバーへのアクセスを制限するようにSpinnakerを構成し、役割と権限について学習し、Spinnakerと統合する際のGitHubチームの場所を検討しました。

SpinnakerをDigitalOcean Kubernetesクラスターに正常に構成およびデプロイしました。 クラウドリソースを中央の場所からより簡単に管理および使用できるようになりました。 トリガーを使用して、パイプラインを自動的に開始できます。たとえば、新しいDockerイメージがレジストリに追加されたとき。 Spinnakerの用語とアーキテクチャの詳細については、official documentationにアクセスしてください。 イメージを保持するためにプライベートDockerレジストリをクラスターにデプロイする場合は、How To Set Up a Private Docker Registry on Top of DigitalOcean Spaces and Use It with DO Kubernetesにアクセスします。