DigitalOceanKubernetesでSpinnakerを使用してCDパイプラインを設定する方法
著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。
序章
Spinnaker は、強力でカスタマイズ可能なパイプラインシステムを使用して、高速で安全かつ反復可能な展開を実現するオープンソースのリソース管理および継続的デリバリーアプリケーションです。 Spinnakerを使用すると、 DigitalOceanKubernetesを含む多くのプラットフォームへのアプリケーションの自動展開が可能になります。 展開時に、独自の展開戦略を作成するオプションを使用して、HighlanderやRed/blackなどの組み込みの展開戦略を使用するようにSpinnakerを構成できます。 JenkinsやTravisCIなどの他のDevOpsツールと統合でき、GitHubリポジトリとDockerレジストリを監視するように構成できます。
Spinnakerは、 Halyard によって管理されます。これは、Spinnakerを構成してさまざまなプラットフォームにデプロイするために特別に構築されたツールです。 Spinnakerは、アプリケーションの設定とパイプラインを永続化するために外部ストレージを必要とします。 DigitalOcean Spaces など、このタスクのさまざまなプラットフォームをサポートします。
このチュートリアルでは、Halyardを使用してSpinnakerをDigitalOcean Kubernetesにデプロイし、基盤となるバックエンドストレージとしてDigitalOceanSpacesを使用します。 また、Let’s Encrypt TLS証明書を使用して保護された、目的のドメインで使用できるようにSpinnakerを構成します。 次に、Spinnakerでサンプルアプリケーションを作成し、パイプラインを作成して、Hello World
アプリをKubernetesクラスターにデプロイします。 テストした後、GitHub組織を介した認証と承認を紹介します。 最終的に、Kubernetesクラスターに安全で機能するSpinnakerデプロイメントができます。
注:このチュートリアルは、Spinnaker1.13.5
で特別にテストされています。
前提条件
-
公式の指示に従って、ローカルマシンにインストールされたハリヤード。 16.04以降のUbuntuバージョンでのHalyardの使用はサポートされていないことに注意してください。 このような場合は、Dockerを介してを使用できます。
-
接続が
kubectl
デフォルトとして構成されたDigitalOceanKubernetesクラスター。 クラスターには、Spinnakerで使用可能な少なくとも8GBのRAMと4つのCPUコアが必要です(より頻繁に使用する場合は、さらに多くのコアが必要になります)。kubectl
の構成方法については、クラスターの作成時に表示されるクラスターへの接続の手順を参照してください。 DigitalOceanでKubernetesクラスタを作成するには、Kubernetesクイックスタートをご覧ください。 -
クラスターにインストールされたNginxIngressControllerとcert-manager。 これを行う方法のガイドについては、 DigitalOceanKubernetesでCert-Managerを使用してNginxIngressを設定する方法を参照してください。
-
APIキー(アクセスとシークレット)を備えたDigitalOceanスペース。 DigitalOceanスペースとAPIキーを作成するには、DigitalOceanスペースとAPIキーを作成する方法を参照してください。
-
Ingressが使用するDigitalOceanロードバランサーを指す3つのDNSAレコードを持つドメイン名。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、DNSレコードの作成方法を参照してAレコードを作成してください。 このチュートリアルでは、Aレコードを
spinnaker.example.com
、spinnaker-api.example.com
、およびhello-world.example.com
と呼びます。 -
GitHub アカウント。管理者権限と公開情報を使用して、GitHub組織に追加されます。 アカウントは、組織内のチームのメンバーでもある必要があります。 これは、ステップ5を完了するために必要です。
ステップ1—HalyardでKubernetesアカウントを追加する
このセクションでは、KubernetesアカウントをHalyard経由でSpinnakerに追加します。 Spinnakerの用語では、アカウントはクラウドプロバイダーにアクセスするために使用する名前付きのクレデンシャルです。
前提条件の一部として、テスト目的でecho1
およびecho2
サービスとecho_ingress
入力を作成しました。 このチュートリアルではこれらは必要ないため、削除できます。
次のコマンドを実行して、入力を削除することから始めます。
- kubectl delete -f echo_ingress.yaml
次に、2つのテストサービスを削除します。
- kubectl delete -f echo1.yaml && kubectl delete -f echo2.yaml
kubectl delete
コマンドは、-f
パラメーターが渡されると、削除するファイルを受け入れます。
次に、ローカルマシンから、ワークスペースとして機能するフォルダーを作成します。
- mkdir ~/spinnaker-k8s
次のコマンドを実行して、ワークスペースに移動します。
- cd ~/spinnaker-k8s
Halyardは、Spinnakerをどこに展開すべきかをまだ知りません。 次のコマンドでKubernetesプロバイダーを有効にします。
- hal config provider kubernetes enable
次の出力が表示されます。
Output+ Get current deployment
Success
+ Edit the kubernetes provider
Success
Problems in default.provider.kubernetes:
- WARNING Provider kubernetes is enabled, but no accounts have been
configured.
+ Successfully enabled kubernetes
Halyardは、Kubernetesプロバイダーを有効にするために行ったすべての手順をログに記録し、アカウントがまだ定義されていないことを警告しました。
次に、 RBAC とともに、SpinnakerのKubernetesサービスアカウントを作成します。 サービスアカウントは、単一の名前空間にスコープされるアカウントの一種です。 これは、クラスター内でさまざまなタスクを実行する可能性のあるソフトウェアによって使用されます。 RBAC(ロールベースのアクセス制御)は、Kubernetesクラスター内のリソースへのアクセスを規制する方法です。 アカウントのアクションの範囲を制限して、クラスターで重要な構成が誤って変更されないようにします。
ここでは、Spinnaker cluster-admin
に、クラスター全体を制御できるようにする権限を付与します。 より制限の厳しい環境を作成したい場合は、RBACに関する公式Kubernetesドキュメントを参照してください。
まず、次のコマンドを実行して、spinnaker
名前空間を作成します。
- kubectl create ns spinnaker
出力は次のようになります。
Outputnamespace/spinnaker created
次のコマンドを実行して、spinnaker-service-account
という名前のサービスアカウントを作成します。
- kubectl create serviceaccount spinnaker-service-account -n spinnaker
-n
フラグを使用して、kubectl
がspinnaker
名前空間にサービスアカウントを作成することを指定しました。 出力は次のようになります。
Outputserviceaccount/spinnaker-service-account created
次に、それをcluster-admin
ロールにバインドします。
- kubectl create clusterrolebinding spinnaker-service-account --clusterrole cluster-admin --serviceaccount=spinnaker:spinnaker-service-account
次の出力が表示されます。
Outputclusterrolebinding.rbac.authorization.k8s.io/spinnaker-service-account created
Halyardは、ローカルkubectlを使用してクラスターにアクセスします。 Spinnakerをデプロイする前に、新しく作成されたサービスアカウントを使用するように構成する必要があります。 Kubernetesアカウントは、ユーザー名とトークンを使用して認証します。 サービスアカウントが作成されると、Kubernetesは新しいシークレットを作成し、アカウントトークンを設定します。 spinnaker-service-account
のトークンを取得するには、最初にシークレットの名前を取得する必要があります。 次のコマンドを実行して、TOKEN_SECRET
という名前のコンソール変数にフェッチできます。
- TOKEN_SECRET=$(kubectl get serviceaccount -n spinnaker spinnaker-service-account -o jsonpath='{.secrets[0].name}')
これは、名前空間spinnaker
からspinnaker-service-account
に関する情報を取得し、JSONパスを渡すことによって含まれる最初のシークレットの名前をフェッチします。
次のコマンドを実行して、シークレットの内容をTOKEN
という名前の変数にフェッチします。
- TOKEN=$(kubectl get secret -n spinnaker $TOKEN_SECRET -o jsonpath='{.data.token}' | base64 --decode)
これで、環境変数TOKEN
でトークンを使用できるようになりました。 次に、kubectlでサービスアカウントのクレデンシャルを設定する必要があります。
- kubectl config set-credentials spinnaker-token-user --token $TOKEN
次の出力が表示されます。
OutputUser "spinnaker-token-user" set.
次に、次のコマンドを実行して、現在のコンテキストのユーザーを新しく作成されたspinnaker-token-user
に設定する必要があります。
- kubectl config set-context --current --user spinnaker-token-user
現在のユーザーをspinnaker-token-user
に設定することにより、kubectlはspinnaker-service-account
を使用するように構成されますが、Halyardはそれについて何も知りません。 次のコマンドを実行して、Kubernetesプロバイダーにアカウントを追加します。
- hal config provider kubernetes account add spinnaker-account --provider-version v2
出力は次のようになります。
Output+ Get current deployment
Success
+ Add the spinnaker-account account
Success
+ Successfully added account spinnaker-account for provider
kubernetes.
このコマンドは、spinnaker-account
という名前のKubernetesアカウントをHalyardに追加し、サービスアカウントとしてマークします。
一般に、Spinnakerは、分散インストールまたはローカルインストールの2つの方法で展開できます。 分散インストールは、このチュートリアルで完了しているものです。つまり、クラウドにデプロイします。 一方、 Local インストールは、Halyardが実行されているマシンにSpinnakerがダウンロードされてインストールされることを意味します。 SpinnakerをKubernetesにデプロイするため、次のようにデプロイメントをdistributed
としてマークする必要があります。
- hal config deploy edit --type distributed --account-name spinnaker-account
Spinnakerデプロイメントはイメージを構築するため、Spinnakerでartifacts
を有効にする必要があります。 次のコマンドを実行して、これらを有効にできます。
- hal config features edit --artifacts true
ここでは、artifacts
を有効にして、Spinnakerが作成するオブジェクトに関するより多くのメタデータを保存できるようにしました。
Halyardを介してKubernetesアカウントをSpinnakerに追加しました。 Kubernetesプロバイダーを有効にし、RBACロールを構成し、現在のkubectl構成をSpinnakerに追加して、プロバイダーにアカウントを追加しました。 次に、バックエンドストレージを設定します。
ステップ2—スペースを基盤となるストレージとして構成する
このセクションでは、Spinnakerデプロイメントの基盤となるストレージとしてSpaceを構成します。 Spinnakerは、Spaceを使用して構成とパイプライン関連のデータを保存します。
HalyardでS3ストレージを設定するには、次のコマンドを実行します。
- hal config storage s3 edit --access-key-id your_space_access_key --secret-access-key --endpoint spaces_endpoint_with_region_prefix --bucket space_name --no-validate
your_space_access_key
をスペースアクセスキーに置き換え、spaces_endpoint_with_region_prefix
をスペースのエンドポイントに置き換えることを忘れないでください。 これは通常region-id.digitaloceanspaces.com
であり、region-id
はスペースの領域です。 space_name
をスペースの名前に置き換えることができます。 --no-validate
フラグは、DigitalOcean Spacesの検証がサポートされていないため、指定された設定をすぐに検証しないようにHalyardに指示します。
このコマンドを実行すると、Halyardは秘密のアクセスキーを要求します。 入力して続行すると、次の出力が表示されます。
Output+ Get current deployment
Success
+ Get persistent store
Success
+ Edit persistent store
Success
+ Successfully edited persistent store "s3".
s3
ストレージを構成したので、次のコマンドを実行して、デプロイメントがこれをストレージとして使用することを確認します。
- hal config storage edit --type s3
出力は次のようになります。
Output+ Get current deployment
Success
+ Get persistent storage settings
Success
+ Edit persistent storage settings
Success
+ Successfully edited persistent storage.
Spinnakerのインスタンスが使用する基盤となるストレージとしてSpaceを設定しました。 次に、SpinnakerをKubernetesクラスターにデプロイし、NginxIngressControllerを使用してドメインで公開します。
ステップ3—Spinnakerをクラスターにデプロイする
このセクションでは、Halyardを使用してSpinnakerをクラスターにデプロイし、NginxIngressを使用してドメインでそのUIおよびAPIコンポーネントを公開します。 まず、ドメインURLを構成します。1つはSpinnakerのユーザーインターフェイス用で、もう1つはAPIコンポーネント用です。 次に、希望するバージョンのSpinnakerを選択し、Halyardを使用してデプロイします。 最後に、入力を作成し、Nginxコントローラーとして構成します。
まず、HalyardでSpinnakerのUIおよびAPI URL構成値を編集し、それらを目的のドメインに設定する必要があります。 APIエンドポイントを目的のドメインに設定するには、次のコマンドを実行します。
- hal config security api edit --override-base-url https://spinnaker-api.example.com
出力は次のようになります。
Output+ Get current deployment
Success
+ Get API security settings
Success
+ Edit API security settings
Success
...
SpinnakerにアクセスするドメインにUIエンドポイントを設定するには、次のコマンドを実行します。
- hal config security ui edit --override-base-url https://spinnaker.example.com
出力は次のようになります。
Output+ Get current deployment
Success
+ Get UI security settings
Success
+ Edit UI security settings
Success
+ Successfully updated UI security settings.
spinnaker-api.example.com
とspinnaker.example.com
をドメインに置き換えることを忘れないでください。 これらは、NginxIngressControllerの前提条件で作成したロードバランサーをポイントしたドメインです。
SpinnakerのKubernetesアカウントを作成して保護し、Spaceを基盤となるストレージとして構成し、UIとAPIエンドポイントをドメインに設定しました。 これで、利用可能なSpinnakerバージョンを一覧表示できます。
- hal version list
出力には、使用可能なバージョンのリストが表示されます。 この記事を書いている時点では、1.13.5
が最新バージョンでした。
Output+ Get current deployment
Success
+ Get Spinnaker version
Success
+ Get released versions
Success
+ You are on version "", and the following are available:
- 1.11.12 (Cobra Kai):
Changelog: https://gist.GitHub.com/spinnaker-release/29a01fa17afe7c603e510e202a914161
Published: Fri Apr 05 14:55:40 UTC 2019
(Requires Halyard >= 1.11)
- 1.12.9 (Unbreakable):
Changelog: https://gist.GitHub.com/spinnaker-release/7fa9145349d6beb2f22163977a94629e
Published: Fri Apr 05 14:11:44 UTC 2019
(Requires Halyard >= 1.11)
- 1.13.5 (BirdBox):
Changelog: https://gist.GitHub.com/spinnaker-release/23af06bc73aa942c90f89b8e8c8bed3e
Published: Mon Apr 22 14:32:29 UTC 2019
(Requires Halyard >= 1.17)
インストールするバージョンを選択するには、次のコマンドを実行します。
- hal config version edit --version 1.13.5
なんらかのリグレッションが発生しない限り、常に最新バージョンを選択することをお勧めします。
次の出力が表示されます。
Output+ Get current deployment
Success
+ Edit Spinnaker version
Success
+ Spinnaker has been configured to update/install version "version".
Deploy this version of Spinnaker with `hal deploy apply`.
これで、Spinnakerのデプロイメントが完全に構成されました。 次のコマンドを使用してデプロイします。
- hal deploy apply
このコマンドは、完了するまでに数分かかる場合があります。
最終的な出力は次のようになります。
Output+ Get current deployment
Success
+ Prep deployment
Success
+ Preparation complete... deploying Spinnaker
+ Get current deployment
Success
+ Apply deployment
Success
+ Deploy spin-redis
Success
+ Deploy spin-clouddriver
Success
+ Deploy spin-front50
Success
+ Deploy spin-orca
Success
+ Deploy spin-deck
Success
+ Deploy spin-echo
Success
+ Deploy spin-gate
Success
+ Deploy spin-rosco
Success
...
Halyardは、Spinnakerの各マイクロサービスのデプロイステータスを表示しています。 舞台裏では、kubectlを呼び出してインストールします。
Kubernetesは、特に初めて、すべてのコンテナを起動するのに時間がかかります(平均で10分)。 次のコマンドを実行すると、進行状況を確認できます。
- kubectl get pods -n spinnaker -w
SpinnakerをKubernetesクラスターにデプロイしましたが、クラスターを超えてアクセスすることはできません。
入力設定をspinnaker-ingress.yaml
という名前のファイルに保存します。 テキストエディタを使用して作成します。
- nano spinnaker-ingress.yaml
次の行を追加します。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: spinnaker-ingress
namespace: spinnaker
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- spinnaker-api.example.com
- spinnaker.example.com
secretName: spinnaker
rules:
- host: spinnaker-api.example.com
http:
paths:
- backend:
serviceName: spin-gate
servicePort: 8084
- host: spinnaker.example.com
http:
paths:
- backend:
serviceName: spin-deck
servicePort: 9000
spinnaker-api.example.com
をAPIドメインに、spinnaker.example.com
をUIドメインに置き換えることを忘れないでください。
構成ファイルは、spinnaker-ingress
と呼ばれる入力を定義します。 アノテーションは、この入力のコントローラーがNginxコントローラーになること、およびletsencrypt-prod
クラスター発行者が前提条件のチュートリアルで定義されたTLS証明書を生成することを指定します。
次に、TLSがUIドメインとAPIドメインを保護することを指定します。 APIドメインをspin-gate
サービス(SpinnakerのAPIコンテナー)に送信し、UIドメインをspin-deck
サービス(SpinnakerのUIコンテナー)に適切なポート9000
。
ファイルを保存して閉じます。
次のコマンドを実行して、Kubernetesにイングレスを作成します。
- kubectl create -f spinnaker-ingress.yaml
次の出力が表示されます。
Outputingress.extensions/spinnaker-ingress created
Let’s EncryptがTLS証明書をプロビジョニングするまで数分待ってから、ブラウザーでUIドメインspinnaker.example.com
に移動します。 Spinnakerのユーザーインターフェイスが表示されます。
Spinnakerをクラスターにデプロイし、ドメインでUIおよびAPIコンポーネントを公開し、それが機能するかどうかをテストしました。 次に、Spinnakerでアプリケーションを作成し、パイプラインを実行してHello World
アプリをデプロイします。
ステップ4—アプリケーションの作成とパイプラインの実行
このセクションでは、ドメインのSpinnakerへのアクセスを使用して、Spinnakerを使用してアプリケーションを作成します。 次に、パイプラインを作成して実行し、Hello World
アプリをデプロイします。このアプリはpaulbouwer /hello-kubernetesにあります。 後でアプリにアクセスします。
SpinnakerのUIを公開したドメインに移動します。 右上隅にあるアクションを押してから、アプリケーションの作成を選択します。 新しいアプリケーションフォームが表示されます。
名前としてhello-world
と入力し、メールアドレスを入力して、Createを押します。
ページが読み込まれたら、トップメニューの最初のタブをクリックしてパイプラインに移動します。 パイプラインがまだ定義されていないことがわかります。
新しいパイプラインの構成を押すと、新しいフォームが開きます。
パイプラインの名前としてDeploy Hello World Application
を入力し、Createを押します。
次のページで、ステージの追加ボタンをクリックします。 Type として、 Deploy(Manifest)を選択します。これは、指定したKubernetesマニフェストのデプロイに使用されます。 ステージ名には、Deploy Hello World
と入力します。 下にスクロールして、マニフェスト構成の下のテキストボックスに次の行を入力します。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-world-ingress
namespace: spinnaker
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- hello-world.example.com
secretName: hello-world
rules:
- host: hello-world.example.com
http:
paths:
- backend:
serviceName: hello-kubernetes
servicePort: 80
---
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes
namespace: spinnaker
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes
namespace: spinnaker
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes
template:
metadata:
labels:
app: hello-kubernetes
spec:
containers:
- name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.5
ports:
- containerPort: 8080
hello-world.example.com
をドメインに置き換えることを忘れないでください。ドメインは、ロードバランサーでも指定されています。
この構成では、paulbouwer/hello-kubernetes:1.5
イメージの3つのレプリカで構成されるDeployment
を定義します。 また、Service
にアクセスできるように定義し、Ingressを定義してドメインでService
を公開します。
画面右下の[変更を保存]を押します。 終了したら、パイプラインに戻ります。 右側で、作成したパイプラインを選択し、手動実行の開始リンクを押します。 確認を求められたら、実行を押します。
このパイプラインは、完了するまでに少し時間がかかります。 正常に終了すると、進行状況バーが完了します。
これで、構成で定義したドメインに移動できます。 SpinnakerがデプロイしたばかりのHello World
アプリが表示されます。
Spinnakerでアプリケーションを作成し、パイプラインを実行してHello World
アプリをデプロイし、それにアクセスしました。 次のステップでは、GitHub組織の認証を有効にして、Spinnakerを保護します。
ステップ5—GitHub組織でロールベースのアクセスを有効にする
このセクションでは、GitHubOAuth認証とGitHub組織の承認を有効にします。 GitHub OAuth認証を有効にすると、SpinnakerユーザーはGitHub経由でログインするように強制されるため、匿名アクセスが防止されます。 GitHub組織を介した承認では、アクセスは組織内の組織のみに制限されます。 GitHub組織には、チーム(メンバーの名前付きグループ)を含めることができます。これを使用して、Spinnakerのリソースへのアクセスをさらに制限できます。
OAuth認証を機能させるには、最初に承認コールバックURLを設定する必要があります。これは、承認後にユーザーがリダイレクトされる場所です。 これは、/login
で終わるAPIドメインです。 Spinnakerやその他のサービスが推測しないように、これを手動で指定する必要があります。 これを構成するには、次のコマンドを実行します。
- hal config security authn oauth2 edit --pre-established-redirect-uri https://spinnaker-api.example.com/login
次の出力が表示されます。
Output+ Get current deployment
Success
+ Get authentication settings
Success
+ Edit oauth2 authentication settings
Success
+ Successfully edited oauth2 method.
GitHubでOAuth認証を設定するには、組織のOAuthアプリケーションを作成する必要があります。 これを行うには、GitHubで組織に移動し、設定に移動し、開発者設定をクリックして、左側のメニューからOAuthアプリを選択します。 その後、右側の新しいOAuthアプリボタンをクリックします。 新しいOAuthアプリケーションの登録フォームが表示されます。
名前としてspinnaker-auth
を入力します。 ホームページURLにはhttps://spinnaker.example.com
と入力し、認証コールバックURLにはhttps://spinnaker-api.example.com/login
と入力します。 次に、アプリケーションの登録を押します。
新しいOAuthアプリの設定ページにリダイレクトされます。 クライアントIDとクライアントシークレットの値に注意してください。次のコマンドで必要になります。
OAuthアプリを作成したら、次のコマンドを実行して、OAuthアプリを使用するようにSpinnakerを構成できます。
- hal config security authn oauth2 edit --client-id client_id --client-secret client_secret --provider GitHub
client_id
とclient_secret
をGitHub設定ページに表示されている値に置き換えることを忘れないでください。
出力は次のようになります。
Output+ Get current deployment
Success
+ Get authentication settings
Success
+ Edit oauth2 authentication settings
Success
Problems in default.security.authn:
- WARNING An authentication method is fully or partially
configured, but not enabled. It must be enabled to take effect.
+ Successfully edited oauth2 method.
OAuthアプリを使用するようにSpinnakerを構成しました。 ここで、それを有効にするには、次を実行します。
- hal config security authn oauth2 enable
出力は次のようになります。
Output+ Get current deployment
Success
+ Edit oauth2 authentication settings
Success
+ Successfully enabled oauth2
GitHubOAuth認証を構成して有効にしました。 これで、ユーザーはSpinnakerにアクセスするためにGitHub経由でログインする必要があります。 ただし、現時点では、GitHubアカウントを持っている人なら誰でもログインできますが、これはあなたが望んでいることではありません。 これを克服するには、目的の組織のメンバーへのアクセスを制限するようにSpinnakerを構成します。
Halyardにはまだこれを設定するコマンドがないため、ローカル構成ファイルを介してこれを半手動で設定する必要があります。 展開中、Halyardはローカル構成ファイルを使用して生成された構成をオーバーライドします。
Halyardは、~/.hal/default/profiles/
でカスタム構成を探します。 service-name-*.yml
という名前のファイルは、Halyardによって取得され、特定のサービスの設定を上書きするために使用されます。 オーバーライドするサービスはgate
と呼ばれ、Spinnaker全体のAPIゲートウェイとして機能します。
~/.hal/default/profiles/
の下にgate-local.yml
という名前のファイルを作成します。
- nano ~/.hal/default/profiles/gate-local.yml
次の行を追加します。
security:
oauth2:
providerRequirements:
type: GitHub
organization: your_organization_name
your_organization_name
をGitHub組織の名前に置き換えます。 ファイルを保存して閉じます。
この設定により、GitHub組織のメンバーのみがSpinnakerにアクセスできるようになります。
注:メンバーシップがPublicに設定されているGitHub組織のメンバーのみがSpinnakerにログインできます。 この設定は、組織のメンバーリストページで変更できます。
ここで、Spinnakerをさらに具体的なアクセスルールソリューションであるGitHubTeamsと統合します。 これにより、アプリケーションなど、Spinnakerで作成されたリソースにアクセスできるチームを指定できます。
これを実現するには、組織の管理者アカウント用のGitHubパーソナルアクセストークンが必要です。 作成するには、パーソナルアクセストークンにアクセスし、新しいトークンの生成ボタンを押します。 次のページで、選択した説明を入力し、 admin:orgの下にあるread:orgスコープを確認してください。 完了したら、トークンの生成を押して、表示されたらメモします。これ以上表示することはできません。
SpinnakerでGitHubチームの役割の承認を構成するには、次のコマンドを実行します。
- hal config security authz github edit --accessToken access_token --organization organization_name --baseUrl https://api.github.com
必ずaccess_token
を生成した個人用アクセストークンに置き換え、organization_name
を組織の名前に置き換えてください。
出力は次のようになります。
Output+ Get current deployment
Success
+ Get GitHub group membership settings
Success
+ Edit GitHub group membership settings
Success
+ Successfully edited GitHub method.
GitHubグループの設定を更新しました。 次に、次のコマンドを実行して、承認プロバイダーをGitHubに設定します。
- hal config security authz edit --type github
出力は次のようになります。
Output+ Get current deployment
Success
+ Get group membership settings
Success
+ Edit group membership settings
Success
+ Successfully updated roles.
これらの設定を更新した後、以下を実行して有効にします。
- hal config security authz enable
次の出力が表示されます。
Output+ Get current deployment
Success
+ Edit authorization settings
Success
+ Successfully enabled authorization
すべての変更が完了したら、実行中のSpinnakerデプロイメントに変更を適用できます。 これを行うには、次のコマンドを実行します。
- hal deploy apply
終了したら、Kubernetesが変更を伝播するのを待ちます。 これにはかなりの時間がかかる場合があります。次を実行することで進行状況を確認できます。
- kubectl get pods -n spinnaker -w
すべてのポッドの状態がRunning
および可用性1/1
になったら、SpinnakerUIドメインに移動します。 まだログインしていない場合は、GitHubにリダイレクトされ、ログインするように求められます。 ログインしたアカウントが組織のメンバーである場合は、Spinnakerにリダイレクトされ、ログインします。 そうしないと、次のようなメッセージでアクセスが拒否されます。
{"error":"Unauthorized", "message":"Authentication Failed: User's provider info does not have all required fields.", "status":401, "timestamp":...}
GitHub Teams統合の効果は、Spinnakerがそれらをrolesに変換することです。 Spinnakerでこれらのロールを使用して、特定のチームのメンバーがアクセスするための追加の制限を組み込むことができます。 別のアプリケーションを追加しようとすると、そのアプリケーションのアクセスレベル(読み取り専用または読み取りと書き込み)と役割を組み合わせたアクセス許可も指定できるようになりました。
GitHubの認証と承認を設定しました。 また、組織のメンバーへのアクセスを制限するようにSpinnakerを構成し、役割と権限について学習し、Spinnakerと統合した場合のGitHubチームの場所を検討しました。
結論
これで、Spinnakerが正常に構成され、DigitalOceanKubernetesクラスターにデプロイされました。 中央の場所から、クラウドリソースをより簡単に管理および使用できるようになりました。 トリガーを使用して、パイプラインを自動的に開始できます。 たとえば、新しいDockerイメージがレジストリに追加された場合です。 Spinnakerの用語とアーキテクチャの詳細については、公式ドキュメントにアクセスしてください。 イメージを保持するためにプライベートDockerレジストリをクラスタにデプロイする場合は、DigitalOceanSpaces上にプライベートDockerレジストリを設定してDOKubernetesで使用する方法にアクセスしてください。