k8s クラスター用の CD ソリューションを探しています。dev-*
タグ付きのコミットをプッシュした後、dockerhub は としてタグ付けされた新しいイメージを作成しますdev-latest
。これが私のデプロイメント構成です:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-image-backend-local-deployment
labels:
app: my-image
type: web
spec:
replicas: 2
minReadySeconds: 15
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 1
selector:
matchLabels:
app: my-image
template:
metadata:
labels:
app: my-image
spec:
imagePullSecrets:
- name: regcred
containers:
- name: backend
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
envFrom:
- secretRef:
name: my-image-backend-local-secret
ports:
- containerPort: 8000
readinessProbe:
httpGet:
path: /flvby
port: 8000
initialDelaySeconds: 10
periodSeconds: 5
- name: celery
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
workingDir: /code
command: ["/code/run/celery.sh"]
envFrom:
- secretRef:
name: my-image-backend-local-secret
- name: redis
image: redis:latest
imagePullPolicy: IfNotPresent
新しいイメージをポッドに自動的にデプロイしたいのですが、適切な解決策が見つかりません。
上院
(* は数字) タグ付きの新しいイメージがレジストリにプッシュされた後、イメージが自動的にデプロイされるようにしたいですdev-0.1.*
。コードがプッシュされ、イメージに組み込まれた後は、何もしないようにしたいです。CD Foundation のプロジェクトをいくつか発見しました。Jenkins X、Spinnaker、Tekton などです。これらのいくつかは私のアイデアの実装に役立つと思いますが、動物園にペットが 1 匹増えることなく実装できれば最高です。
答え1
画像参照とマニフェスト
Kubernetes は、マニフェストが変更されるたびにローリング デプロイメント戦略を使用するなど、デプロイメントを管理しますkind: Deployment
。
dev-*タグ付きのコミットをプッシュすると、dockerhubはdev-latestタグ付きの新しいイメージを作成します。
これの主な問題は、同じ各イメージのタグ名。つまり、kind: Deployment
マニフェストはないイメージが更新されると更新されるため、マニフェストに変更がないため、Kubernetes は新しいローリング デプロイメントを開始しません。
良い方法としては、イメージをプッシュするたびに一意のイメージ タグを使用し、kind: Deployment
この新しいイメージ タグ名でマニフェストを更新して、Kubernetes が自動的に新しいローリング デプロイメントをトリガーするようにします。
一部のイメージレジストリは「不変のタグ名」を使用するように設定できます。これは、強制されたビルドされたイメージごとに常に一意のタグ名を使用するようにする。あるいは、フルイメージダイジェストマニフェストではkind: Deployment
、タグ名が同じであっても一意のイメージ参照を持つことができます (イメージ ダイジェストはコンテンツのハッシュです)。
要約すれば:
- ビルドごとに一意のイメージタグ名を使用する
kind: Deployment
新しいタグ名でマニフェストを更新するkind: Deployment
マニフェスト(およびその他の yaml マニフェスト)をバージョン管理(例:Git)に保存します。- イメージを参照する場合は、マニフェストで完全なイメージダイジェストを使用することを検討してください。
プロセスと自動化
マニフェストを更新してクラスターに適用するには、いくつかの方法がありますが、変更を行った後は必ず、クラスターに適用する前に、更新されたマニフェストを Git リポジトリに保存することをお勧めします。こうすることで、変更内容の追跡可能性が向上し、何か問題が発生した場合でも、作業バージョンに簡単に戻すことができます。
上記の手順に加えて、もう1つの重要な方法は、オートメーションそのために、Gitリポジトリに変更を加えるたびに、できれば手動の手順なしで作業を実行する自動プロセスをトリガーします。歴史的に、Jenkinsはこのための人気のツールでしたが、古く、コンテナ環境でうまく動作するようには設計されていません。現在、次のようなツールを使用することをお勧めします。GitHubアクション、Google クラウド ビルドまたはKubernetesクラスタ内の最新のシステム、例えばテクトンパイプライン
Tekton を使用したパイプラインの構築とデプロイ
Kubernetes クラスターで Tekton を使用することを選択した場合は、プロジェクトを次のように構成できます。
- コード変更をコードリポジトリに Git プッシュする
- あテクトントリガーGit システムからイベントを受信し、新しいを開始します
PipelineRun
。 - のテクトンパイプラインgit-clone、コードのビルド、テストの実行、イメージのビルドとプッシュの手順が含まれています。結果はイメージ ダイジェストまたはラベルです。その後、パイプラインの最後のタスクでは、以前のすべてのタスクが成功した場合、
kind: Deployment
新しいイメージ ダイジェストでマニフェストを更新し、マニフェストを含むリポジトリに git-push します。 - デプロイメント パイプラインがトリガーされ、マニフェストがクラスターに適用されます (選択したデプロイメント戦略、ローリング デプロイメント、段階的デプロイメント、カナリア デプロイメントなどを使用)。
本の推薦
Kubernetes の起動と実行第 2 版 (2019 年から) - 新しい章が含まれています:18. 申請書の整理マニフェストとバージョン管理を使用してデプロイメントを管理する方法について説明します。
継続的デリバリー- 使い方についての古典的な本パイプラインの構築と展開そして自動化。
代替案
私は CD Foundation のプロジェクトをいくつか発見しました: Jenkins X、Spinnaker、Tekton。これらのいくつかは私のアイデアの実装に役立つと思いますが、動物園にもう 1 匹ペットを追加せずに実装できれば最高です。
Kubernetes でのデプロイメントできる宣言的なマニフェストを使用せずに、代わりに命令形バージョン管理された変更はありませんが、これは本当にがっかりしたプロフェッショナルな環境向けです。自動化されたパイプラインのセットアップと構成には時間がかかりますが、宣言的かつ再現可能な方法でこれを行うことが重要です。
答え2
ついに、KubernetesのCDに期待していた通りの機能を果たす素晴らしいツール「keel.sh」を発見しました。