Tanzu Kubernetes Cluster(TKC) に Contour, Harbor, TBS, Concourse をデプロイした際の手順
Tanzu Kubernetes Cluster(TKC) にてんこ盛りでデプロイしたので、その際に実施した手順です。Contour をIngress として利用し、そのバックエンドで Harbor, Concourse にアクセス出来るようにしています。このHarbor を利用する形でTBS もデプロイしています。
環境
- vSphere with Tanzu 7u2 + NSX ALB
- Tanzu Kubernetes Cluster v1.19.7
手順
TKC のデプロイ
以下のTKC マニフェストを利用し、TKC をデプロイします。Tanzu Build Service(TBS) が Worker Node の
/var/lib の領域を利用するため、50GB 以上を指定し作成しておきます。この環境は検証用環境でThin Provisioning で仮想ディスクが切り出されるため、256GB を指定しています。$ cat tkc-fender.yaml
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: fender
namespace: tadashi
spec:
distribution:
version: 1.19.7
topology:
controlPlane:
count: 1
class: best-effort-medium
storageClass: default
volumes:
- name: etcd
mountPath: /var/lib/etcd
capacity:
storage: 64Gi
workers:
count: 1
class: best-effort-large
storageClass: default
volumes:
- name: containerd
mountPath: /var/lib/containerd
capacity:
storage: 256Gi
settings:
network:
cni:
name: antrea
storage:
defaultClass: default # default storage class setting
$ kubectl apply -f tkc-fender.yaml
こちらの「Connect to the Tanzu Kubernetes Cluster Control Plane as the Administrator」に従って、デプロイしたTKC にアクセスするための
kubeconfig ファイルを取得しておきます。$ kubectl -n tadashi get secrets fender-kubeconfig -o jsonpath='{.data.value}' | base64 -d > fender-kubeconfig
$ export KUBECONFIG=~/fender-kubeconfig
これからContour, Harbor, TBS, Concourse をデプロイするための準備が出来ました。
Contour のデプロイ
こちらの「Deploy the Contour Extension」に従ってデプロイしていきます。
tanzu-extentions は事前にダウンロードして、展開しておきます。※TKG Extension v1.3.1 以降では、tmc-extension-manager.yaml のデプロイは不要です。まず、
tmc-extension-manager.yaml を apply します。$ kubectl apply -f tmc-extension-manager.yaml
tkg-extensions-v1.3.0+vmware.1 ディレクトリ直下に移動し、cert-manager をインストールします。$ kubectl apply -f cert-manager
ディレクトリを
tkg-extensions-v1.3.0+vmware.1/extensions に移動し、以下のマニフェストを apply します。$ kubectl apply -f ingress/contour/namespace-role.yaml
contour の
values.yaml をコピーし、envoy.service.type を NodePort から LoadBalancer に変更します。変更したvalues.yaml を元にSecret を作成します。$ cp ingress/contour/vsphere/contour-data-values.yaml.example \
ingress/contour/vsphere/contour-data-values.yaml
$ cat ingress/contour/vsphere/contour-data-values.yaml
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
infrastructure_provider: "vsphere"
contour:
image:
repository: projects.registry.vmware.com/tkg
envoy:
image:
repository: projects.registry.vmware.com/tkg
service:
type: "NodePort"%
$ vim ingress/contour/vsphere/contour-data-values.yaml
$ kubectl -n tanzu-system-ingress create secret generic contour-data-values \
--from-file=values.yaml=ingress/contour/vsphere/contour-data-values.yaml
contour をデプロイします。
$ kubectl apply -f ingress/contour/contour-extension.yaml
しばらくすると、サービスが起動してきます。
$ kubectl -n tanzu-system-ingress get app contour
NAME DESCRIPTION SINCE-DEPLOY AGE
contour Reconcile succeeded 11s 114s
後ほど必要になるので、envoy の
EXTERNAL-IP をメモしておきます。$ kubectl -n tanzu-system-ingress get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
contour ClusterIP 10.100.210.152 <none> 8001/TCP 73s
envoy LoadBalancer 10.107.194.106 xx.xxx.xxx.xxx 80:32060/TCP,443:32072/TCP 72s
Contour をデプロイした後は、こちら「Access the Envoy Administration Interface Remotely」にある手順に従うと、Envoy の管理者インターフェースにアクセスする事が出来ます。
$ export KUBECONFIG=~/fender-kubeconfig
$ ENVOY_POD=$(kubectl -n tanzu-system-ingress get pod -l app=envoy -o name | head -1)
$ kubectl -n tanzu-system-ingress port-forward $ENVOY_POD 9001
続いて、Let's Encrypt を利用し、Contour で利用する証明書を取得します。
Let's Encrypt で証明書の取得
以下のコマンドで証明書を発行します。
この環境ではGoogle DNS を使っています。envoy にアサインされていた
EXTERNAL-IP を *.<MYDOMAIN> のAレコードとして登録しています。$ certbot --server https://acme-v02.api.letsencrypt.org/directory \
-d "*.<MYDOMAIN>" --manual --preferred-challenges dns-01 certonly \
--work-dir ./<cluster-name>/wd \
--config-dir ./<cluster-name>/cfg \
--logs-dir ./<cluster-name>/logs
案内に従ってステップを進めていくと、DNS TXT レコード とそれに対応する Values が表示されるので、その組合せをGoogle DNS に登録します。
名前解決出来るまでしばらく時間が掛かりますが、以下のコマンドで登録したDNS TXT レコードの Values 値が返ってくればOKです。
$ nslookup -q=txt _acme-challenge.<MYDOMAIN>
クエリが通ったら、プロンプトでEnter を入力し、処理を終えます。
Congratulations! Your certificate and chain have been saved at: と出力されていれば、無事処理が終わっています。Harbor のデプロイ
続いてHarbor をデプロイしていきます。この手順ではBitnami が提供しているHelm Chart を利用してデプロイしています。こちらにある手順に従って、事前にBitnami のHelm Chart を追加しておきます。
Harbor をデプロイするNamespace とRoleBinding 設定をしていきます。
$ kubectl create ns harbor
$ kubectl -n harbor create rolebinding harbor-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
Harbor が利用するTLS の
Secret を作成していきます。--cert と --key で指定しているファイルは上の手順で作成したfullchain.pem とprivkey.pem になります。$ kubectl -n harbor create secret tls harbor-tls-secret \
--cert=./<cluster-name>/certbot/cfg/live/<MYDOMAIN>/fullchain.pem \
--key=./<cluster-name>/certbot/cfg/live/<MYDOMAIN>/privkey.pem
Helm のリポジトリをアップデートしておきます。
$ helm repo update
$ helm search repo bitnami |grep harbor
bitnami/harbor 9.8.3 2.2.1 Harbor is an an open source trusted cloud nativ...
Harbor をインストールする際の
values.yaml を作成します。この環境ではIngress として、Contour を利用しているので、ingress.annotations.kubernetes.io/ingress.class にContour を指定しています。$ cat harbor-values.yaml
harborAdminPassword: xxxxx
service:
type: ClusterIP
tls:
enabled: true
existingSecret: harbor-tls-secret
notaryExistingSecret: harbor-tls-secret
externalURL: registry.<MYDOMAIN>
ingress:
enabled: true
hosts:
core: registry.<MYDOMAIN>
notary: notary.<MYDOMAIN>
annotations:
ingress.kubernetes.io/force-ssl-redirect: "true" # force https, even if http is requested
kubernetes.io/ingress.class: contour # using Contour for ingress
kubernetes.io/tls-acme: "true" # using ACME certificates for TLS
portal:
tls:
existingSecret: harbor-tls-secret
persistence:
persistentVolumeClaim:
registry:
size: 100Gi
jobservice:
size: 10Gi
chartmuseum:
size: 10Gi
trivy:
size: 100Gi
※Docker Hub のRate Limit に当たってしまたっため、GCR レジストリにあると
gcr.io/bitnami-containers リポジトリを利用する場合は、以下の様な形のvalues.yaml を利用しました。# values.yaml
global:
imageRegistry: gcr.io
coreImage:
registry: gcr.io
repository: bitnami-containers/harbor-core
portalImage:
registry: gcr.io
repository: bitnami-containers/harbor-portal
jobserviceImage:
registry: gcr.io
repository: bitnami-containers/harbor-jobservice
chartMuseumImage:
registry: gcr.io
repository: bitnami-containers/chartmuseum
registryImage:
registry: gcr.io
repository: bitnami-containers/harbor-registry
registryctlImage:
registry: gcr.io
repository: bitnami-containers/harbor-registryctl
trivyImage:
registry: gcr.io
repository: bitnami-containers/harbor-adapter-trivy
clairImage:
registry: gcr.io
repository: bitnami-containers/harbor-clair
clairAdapterImage:
registry: gcr.io
repository: bitnami-containers/harbor-adapter-clair
notaryServerImage:
registry: gcr.io
repository: bitnami-containers/harbor-notary-server
notarySignerImage:
registry: gcr.io
repository: bitnami-containers/harbor-notary-signer
nginxImage:
registry: gcr.io
repository: bitnami-containers/nginx
volumePermissions:
image:
registry: gcr.io
repository: bitnami-containers/bitnami-shell
...(SNIP)...
redis:
image:
registry: gcr.io
repository: bitnami-containers/redis
postgresql:
image:
registry: gcr.io
repository: bitnami-containers/postgresql
helm でHarbor をデプロイします。
$ helm upgrade --install harbor bitnami/harbor -f harbor-values.yaml --namespace harbor
Chart のバージョンを指定する場合は、以下のように実行。
$ helm upgrade --install harbor bitnami/harbor -f harbor-values.yaml --namespace harbor --version 9.8.3
無事にHarbor が立ち上がっている様です。
$ kubectl -n harbor get pods
NAME READY STATUS RESTARTS AGE
harbor-chartmuseum-69965dcd88-w7st4 1/1 Running 0 3m9s
harbor-core-54f5cf46bc-frvjk 1/1 Running 0 3m9s
harbor-jobservice-76bdd989bf-4vzg6 1/1 Running 0 3m9s
harbor-notary-server-cc445d54d-dsw2v 1/1 Running 0 3m9s
harbor-notary-signer-798bbddc89-knrg8 1/1 Running 1 3m9s
harbor-portal-5f69977cbf-d46wk 1/1 Running 0 3m9s
harbor-postgresql-0 1/1 Running 0 3m9s
harbor-redis-master-0 1/1 Running 0 3m9s
harbor-registry-9f55dc7ff-5p9dd 2/2 Running 0 3m9s
harbor-trivy-0 1/1 Running 0 3m9s
試しに、コンテナイメージをHarbor にアップロード出来るか確認してみます。Harbor UI から事前にdevops ユーザーを作成し、コンテナをアップロードする権限を追加しています。
$ docker login registry.<MYDOMAIN> -u devops -p xxxx
$ docker tag nginx:1.17.10 registry.<MYDOMAIN>/library/nginx:1.17.10
$ docker push registry.<MYDOMAIN>/library/nginx:1.17.10
The push refers to repository [registry.<MYDOMAIN>/library/nginx]
6c7de695ede3: Pushed
2f4accd375d9: Pushed
ffc9b21953f4: Pushed
1.17.10: digest: sha256:8269a7352a7dad1f8b3dc83284f195bac72027dd50279422d363d49311ab7d9b size: 948
無事にインストール出来たことが確認出来ました。このHarbor を利用して、TBS をデプロイしていきます。
TBS のデプロイ
こちら「Tanzu Kubernetes Grid 上に Tanzu Build Service をインストールする」の記事を参考に事前に必要なパッケージやコマンドをインストールしておきます。
上で作成したHarbor と
registry.pivotal.io にログインしておきます。registry.pivotal.io のログインにはVMware Tanzu Network のアカウントが必要になります。$ docker login registry.<MYDOMAIN> -u devops -p xxxx
$ docker login registry.pivotal.io
TBS のインストールに必要なコンテナイメージをHarbor 上に展開します。Harbor 上にプロジェクトは事前に作成しておき、メンバーとしてdevops ユーザーを加えています。
$ kbld relocate -f images.lock --lock-output images-relocated.lock --repository registry.<MYDOMAIN>/tanzu/build-service
...(SNIP)...
relocate | imported 15 images
Succeeded
TBS をデプロイします。
$ ytt -f values.yaml -f manifests/ -v docker_repository="registry.<MYDOMAIN>/tanzu/build-service" -v docker_username=devops -v docker_password=xxxx | kbld -f images-relocated.lock -f- | kapp deploy -a tanzu-build-service -f- -y
...(SNIP)...
Changes
Namespace Name Kind Conds. Age Op Op st. Wait to Rs Ri
(cluster) build-service Namespace - - create - reconcile - -
^ build-service-admin-role ClusterRole - - create - reconcile - -
^ build-service-admin-role-binding ClusterRoleBinding - - create - reconcile - -
^ build-service-authenticated-role ClusterRole - - create - reconcile - -
^ build-service-authenticated-role-binding ClusterRoleBinding - - create - reconcile - -
^ build-service-secret-syncer-role ClusterRole - - create - reconcile - -
^ build-service-secret-syncer-role-binding ClusterRoleBinding - - create - reconcile - -
^ build-service-user-role ClusterRole - - create - reconcile - -
^ build-service-warmer-role ClusterRole - - create - reconcile - -
^ build-service-warmer-role-binding ClusterRoleBinding - - create - reconcile - -
^ builders.kpack.io CustomResourceDefinition - - create - reconcile - -
^ builds.kpack.io CustomResourceDefinition - - create - reconcile - -
^ cert-injection-webhook-cluster-role ClusterRole - - create - reconcile - -
^ cert-injection-webhook-cluster-role-binding ClusterRoleBinding - - create - reconcile - -
^ clusterbuilders.kpack.io CustomResourceDefinition - - create - reconcile - -
^ clusterstacks.kpack.io CustomResourceDefinition - - create - reconcile - -
^ clusterstores.kpack.io CustomResourceDefinition - - create - reconcile - -
^ custom-stack-editor-role ClusterRole - - create - reconcile - -
^ custom-stack-viewer-role ClusterRole - - create - reconcile - -
^ customstacks.stacks.stacks-operator.tanzu.vmware.com CustomResourceDefinition - - create - reconcile - -
^ defaults.webhook.cert-injection.tanzu.vmware.com MutatingWebhookConfiguration - - create - reconcile - -
^ defaults.webhook.kpack.io MutatingWebhookConfiguration - - create - reconcile - -
^ images.kpack.io CustomResourceDefinition - - create - reconcile - -
^ kpack Namespace - - create - reconcile - -
^ kpack-controller-admin ClusterRole - - create - reconcile - -
^ kpack-controller-admin-binding ClusterRoleBinding - - create - reconcile - -
^ kpack-webhook-certs-mutatingwebhookconfiguration-admin-binding ClusterRoleBinding - - create - reconcile - -
^ kpack-webhook-mutatingwebhookconfiguration-admin ClusterRole - - create - reconcile - -
^ metrics-reader ClusterRole - - create - reconcile - -
^ proxy-role ClusterRole - - create - reconcile - -
^ proxy-rolebinding ClusterRoleBinding - - create - reconcile - -
^ sourceresolvers.kpack.io CustomResourceDefinition - - create - reconcile - -
^ stacks-operator-manager-role ClusterRole - - create - reconcile - -
^ stacks-operator-manager-rolebinding ClusterRoleBinding - - create - reconcile - -
^ stacks-operator-system Namespace - - create - reconcile - -
^ validation.webhook.kpack.io ValidatingWebhookConfiguration - - create - reconcile - -
build-service build-pod-image-fetcher DaemonSet - - create - reconcile - -
^ build-service-warmer-namespace-role Role - - create - reconcile - -
^ build-service-warmer-namespace-role-binding RoleBinding - - create - reconcile - -
^ ca-cert ConfigMap - - create - reconcile - -
^ canonical-registry-secret Secret - - create - reconcile - -
^ cb-service-account ServiceAccount - - create - reconcile - -
^ cert-injection-webhook Deployment - - create - reconcile - -
^ cert-injection-webhook Service - - create - reconcile - -
^ cert-injection-webhook-role Role - - create - reconcile - -
^ cert-injection-webhook-role-binding RoleBinding - - create - reconcile - -
^ cert-injection-webhook-sa ServiceAccount - - create - reconcile - -
^ cert-injection-webhook-tls Secret - - create - reconcile - -
^ http-proxy ConfigMap - - create - reconcile - -
^ https-proxy ConfigMap - - create - reconcile - -
^ no-proxy ConfigMap - - create - reconcile - -
^ secret-syncer-controller Deployment - - create - reconcile - -
^ secret-syncer-service-account ServiceAccount - - create - reconcile - -
^ setup-ca-certs-image ConfigMap - - create - reconcile - -
^ sleeper-image ConfigMap - - create - reconcile - -
^ warmer-controller Deployment - - create - reconcile - -
^ warmer-service-account ServiceAccount - - create - reconcile - -
kpack build-init-image ConfigMap - - create - reconcile - -
^ build-init-windows-image ConfigMap - - create - reconcile - -
^ canonical-registry-secret Secret - - create - reconcile - -
^ canonical-registry-serviceaccount ServiceAccount - - create - reconcile - -
^ completion-image ConfigMap - - create - reconcile - -
^ completion-windows-image ConfigMap - - create - reconcile - -
^ controller ServiceAccount - - create - reconcile - -
^ kp-config ConfigMap - - create - reconcile - -
^ kpack-controller Deployment - - create - reconcile - -
^ kpack-controller-local-config Role - - create - reconcile - -
^ kpack-controller-local-config-binding RoleBinding - - create - reconcile - -
^ kpack-webhook Deployment - - create - reconcile - -
^ kpack-webhook Service - - create - reconcile - -
^ kpack-webhook-certs-admin Role - - create - reconcile - -
^ kpack-webhook-certs-admin-binding RoleBinding - - create - reconcile - -
^ lifecycle-image ConfigMap - - create - reconcile - -
^ rebase-image ConfigMap - - create - reconcile - -
^ webhook ServiceAccount - - create - reconcile - -
^ webhook-certs Secret - - create - reconcile - -
stacks-operator-system canonical-registry-secret Secret - - create - reconcile - -
^ controller-manager Deployment - - create - reconcile - -
^ controller-manager-metrics-service Service - - create - reconcile - -
^ leader-election-role Role - - create - reconcile - -
^ leader-election-rolebinding RoleBinding - - create - reconcile - -
^ stackify-image ConfigMap - - create - reconcile - -
Op: 82 create, 0 delete, 0 update, 0 noop
Wait to: 82 reconcile, 0 delete, 0 noop
...(SNIP)...
Succeeded
RoleBinding の設定が無いとPod が立ち上がらないので、上のコマンドを実行しているターミナルとは別のターミナルを開いて、TBS デプロイ時に作成される以下3つのNamespace に対してRoleBinding 設定をしておきます。
$ kubectl -n build-service create rolebinding tbs-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
$ kubectl -n kpack create rolebinding tbs-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
$ kubectl -n stacks-operator-system create rolebinding tbs-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
ClusterBuilder をインストールします。
$ kp import -f descriptor-100.0.80.yaml
$ kp clusterbuilder list
NAME READY STACK IMAGE
base true io.buildpacks.stacks.bionic registry.<MYDOMAIN>/tanzu/build-service/base@sha256:e49bfb99292dd424d41debba05b21a1abed5b806ded08a8fedfab5c5491f3434
default true io.buildpacks.stacks.bionic registry.<MYDOMAIN>/tanzu/build-service/default@sha256:e49bfb99292dd424d41debba05b21a1abed5b806ded08a8fedfab5c5491f3434
full true io.buildpacks.stacks.bionic registry.<MYDOMAIN>/tanzu/build-service/full@sha256:38841a236b15059a390975ea6f492d7bda0d294287d267fe95ff731993363946
tiny true io.paketo.stacks.tiny registry.<MYDOMAIN>/tanzu/build-service/tiny@sha256:97b734efc85782bebdbe090c3bed0fd281ed0c0eec2dffb12d04825468f5091d
TBS を利用してコンテナイメージが作成出来るかどうか確認してみます。Harbor 上にプロジェクトは事前に作成しておき、メンバーとしてdevops ユーザーを加えています。
$ kubectl create ns tbs-apps
$ kubectl -n tbs-apps create rolebinding tbs-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
$ kp secret create harbor-pezfender --registry registry.<MYDOMAIN> \
--registry-user devops --namespace tbs-apps
$ kp image create go-hello-world --tag registry.<MYDOMAIN>/apps/go-hello-world --local-path ./go/hello-world/ --cluster-builder tiny --namespace tbs-apps --wait
Creating Image...
Uploading to 'registry.<MYDOMAIN>/apps/go-hello-world-source'...
Uploading 'registry.<MYDOMAIN>/apps/go-hello-world-source@sha256:66b5b9b5e2784486f0b04474526fc9789e1c1656e968fb7c8a0dbeddf0bf7771'
Image "go-hello-world" created
===> PREPARE
Build reason(s): CONFIG
CONFIG:
resources: {}
- source: {}
+ source:
+ registry:
+ image: registry.<MYDOMAIN>/apps/go-hello-world-source@sha256:66b5b9b5e2784486f0b04474526fc9789e1c1656e968fb7c8a0dbeddf0bf7771
Loading secret for "registry.<MYDOMAIN>" from secret "harbor-pezfender" at location "/var/build-secrets/harbor-pezfender"
Pulling registry.<MYDOMAIN>/apps/go-hello-world-source@sha256:66b5b9b5e2784486f0b04474526fc9789e1c1656e968fb7c8a0dbeddf0bf7771...
Successfully pulled registry.<MYDOMAIN>/apps/go-hello-world-source@sha256:66b5b9b5e2784486f0b04474526fc9789e1c1656e968fb7c8a0dbeddf0bf7771 in path "/workspace"
===> DETECT
tanzu-buildpacks/go-dist 0.1.3
tanzu-buildpacks/go-build 0.0.23
===> ANALYZE
Previous image with name "registry.<MYDOMAIN>/apps/go-hello-world" not found
===> RESTORE
===> BUILD
Tanzu Go Distribution Buildpack 0.1.3
Resolving Go version
Candidate version sources (in priority order):
<unknown> -> ""
Selected Go version (using <unknown>): 1.15.5
Executing build process
Installing Go 1.15.5
Completed in 35.264s
Tanzu Go Build Buildpack 0.0.23
Executing build process
Running 'go build -o /layers/tanzu-buildpacks_go-build/targets/bin -buildmode pie .'
Completed in 1m14.441s
Assigning launch processes
web: /layers/tanzu-buildpacks_go-build/targets/bin/workspace
===> EXPORT
Adding layer 'tanzu-buildpacks/go-build:targets'
Adding 1/1 app layer(s)
Adding layer 'launcher'
Adding layer 'config'
Adding layer 'process-types'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Setting default process type 'web'
*** Images (sha256:7fb06b63c1df7c2eeba471da84b1913d5bd6963b64722af74dc17c52f1f35e45):
registry.<MYDOMAIN>/apps/go-hello-world
registry.<MYDOMAIN>/apps/go-hello-world:b1.20210401.122003
Adding cache layer 'tanzu-buildpacks/go-dist:go'
Adding cache layer 'tanzu-buildpacks/go-build:gocache'
===> COMPLETION
Build successful
問題なく使える様です。最後にこのTKC にConcourse をデプロイします。
Concourse のデプロイ
Helm Chart を利用してデプロイします。こちらの手順を参考に事前にレポジトリを追加しておきます。
Concourse というNamespace にデプロイしていきます。
$ kubectl create ns concourse
$ kubectl -n concourse create rolebinding concourse-role-binding \
--clusterrole=psp:vmware-system-privileged --group=system:authenticated
Ingress 経由でTLS 通信させる設定にするために、Secret を作成しておきます。
$ kubectl -n concourse create secret tls concourse-tls-secret \
--cert=./<cluster-name>/certbot/cfg/live/<MYDOMAIN>/fullchain.pem \
--key=./<cluster-name>/certbot/cfg/live/<MYDOMAIN>/privkey.pem
Concourse の
values.yaml を作成します。$ cat concourse-values.yaml
concourse:
web:
externalUrl: https://concourse.<MYDOMAIN>
kubernetes:
keepNamespaces: false
web:
service:
api:
type: ClusterIP
ingress:
annotations:
ingress.kubernetes.io/force-ssl-redirect: "true" # force https, even if http is requested
kubernetes.io/ingress.class: contour # using Contour for ingress
kubernetes.io/tls-acme: "true" # using ACME certificates for TLS
enabled: true
hosts:
- concourse.<MYDOMAIN>
tls:
- secretName: concourse-tls-secret
hosts:
- concourse.<MYDOMAIN>
persistence:
worker:
size: 40Gi
デプロイします。
$ helm upgrade --install concourse concourse/concourse -f concourse-values.yaml --namespace concourse
Pod は問題なく起動している様です。
$ kubectl get pods -n concourse
NAME READY STATUS RESTARTS AGE
concourse-postgresql-0 1/1 Running 0 73m
concourse-web-97f647746-2xb4s 1/1 Running 0 70m
concourse-worker-0 1/1 Running 0 73m
concourse-worker-1 1/1 Running 0 73m
fly CLI でインストールしたConcourse をターゲット登録し、サンプルPipeline を流してみます。
$ fly -t pezfender login --concourse-url https://concourse.<MYDOMAIN> -u test -p test
$ fly -t pezfender set-pipeline -c pipeline.yml -p hello-world
jobs:
job job-hello-world has been added:
+ name: job-hello-world
+ plan:
+ - config:
+ image_resource:
+ name: ""
+ source:
+ repository: busybox
+ type: docker-image
+ platform: linux
+ run:
+ args:
+ - hello world
+ path: echo
+ task: hello-world
+ public: true
pipeline name: hello-world
apply configuration? [yN]: y
pipeline created!
you can view your pipeline here: https://concourse.<MYDOMAIN>/teams/main/pipelines/hello-world
the pipeline is currently paused. to unpause, either:
- run the unpause-pipeline command:
fly -t pezfender unpause-pipeline -p hello-world
- click play next to the pipeline in the web ui
無事にアクセス出来ました。
TKC のデプロイから始まり、Contour、Harbor、TBS、Concourse とデプロイし終わりました。
