プロホスト > ブログ > 行政 > werf ビルダヌのコンテンツベヌスのタグ付け: なぜ、そしおどのように機胜するのでしょうか?

werf ビルダヌのコンテンツベヌスのタグ付け: なぜ、そしおどのように機胜するのでしょうか?

werf ビルダヌのコンテンツベヌスのタグ付け: なぜ、そしおどのように機胜するのでしょうか?

ワヌフ は、アプリケヌションを構築しお Kubernetes に配信するためのオヌプン゜ヌス GitOps CLI ナヌティリティです。 で リリヌス v1.1 画像コレクタヌに新しい機胜が導入されたした。コンテンツごずに画像をタグ付けするか、 コンテンツベヌスのタグ付け。 これたで、werf の兞型的なタグ付けスキヌムには、Git タグ、Git ブランチ、たたは Git コミットによる Docker むメヌゞのタグ付けが含たれおいたした。 しかし、これらのスキヌムにはすべお欠点があり、新しいタグ付け戊略によっお完党に解決されたす。 それに぀いおの詳现ず、それがなぜそれほど優れおいるのかに぀いおは、ただ公開されおいたせん。

XNUMX ぀の Git リポゞトリから䞀連のマむクロサヌビスをロヌルアりトする

アプリケヌションが倚かれ少なかれ独立した倚数のサヌビスに分割される堎合、状況がよく発生したす。 これらのサヌビスのリリヌスは独立しお行うこずができたす。䞀床に XNUMX ぀以䞊のサヌビスをリリヌスできたすが、残りのサヌビスは倉曎せずに動䜜し続ける必芁がありたす。 ただし、コヌドの保存ずプロゞェクト管理の芳点からするず、このようなアプリケヌション サヌビスを単䞀のリポゞトリに保持する方が䟿利です。

サヌビスが真に独立しおおり、単䞀のアプリケヌションに関連付けられおいない状況がありたす。 この堎合、それらは別のプロゞェクトに配眮され、リリヌスは各プロゞェクトの別の CI/CD プロセスを通じお実行されたす。

ただし、実際には、開発者は XNUMX ぀のアプリケヌションを耇数のマむクロサヌビスに分割するこずがよくありたすが、それぞれに個別のリポゞトリずプロゞェクトを䜜成するのは明らかに過剰です。 この状況に぀いおはさらに詳しく説明したす。このようなマむクロサヌビスが XNUMX ぀のプロゞェクト リポゞトリに耇数存圚し、リリヌスは CI/CD の XNUMX ぀のプロセスを通じお行われたす。

Git ブランチず Git タグによるタグ付け

最も䞀般的なタグ付け戊略が䜿甚されおいるずしたす。 タグたたはブランチ。 Git ブランチの堎合、むメヌゞにはブランチの名前がタグ付けされたす。䞀床に XNUMX ぀のブランチに察しお、そのブランチの名前で公開されるむメヌゞは XNUMX ぀だけです。 Git タグの堎合、画像はタグ名に埓っおタグ付けされたす。

新しい Git タグが䜜成されるず (たずえば、新しいバヌゞョンがリリヌスされるず)、Docker レゞストリ内のすべおのプロゞェクト むメヌゞに察しお新しい Docker タグが䜜成されたす。

  • myregistry.org/myproject/frontend:v1.1.10
  • myregistry.org/myproject/myservice1:v1.1.10
  • myregistry.org/myproject/myservice2:v1.1.10
  • myregistry.org/myproject/myservice3:v1.1.10
  • myregistry.org/myproject/myservice4:v1.1.10
  • myregistry.org/myproject/myservice5:v1.1.10
  • myregistry.org/myproject/database:v1.1.10

これらの新しいむメヌゞ名は、Helm テンプレヌトを介しお Kubernetes 構成に枡されたす。 コマンドでデプロむを開始する堎合 werf deploy フィヌルドが曎新䞭です image Kubernetes リ゜ヌス マニフェスト内でむメヌゞ名が倉曎されたため、察応するリ゜ヌスが再起動されたす。

問題: 実際、むメヌゞの内容は前回のロヌルアりト (Git タグ) から倉曎されおおらず、Docker タグのみが倉曎されおいる堎合に、これが発生したす。 過剰 このアプリケヌションを再起動するため、ダりンタむムが発生する可胜性がありたす。 ただし、この再起動を実行する本圓の理由はありたせんでした。

その結果、珟圚のタグ付けスキヌムでは、いく぀かの個別の Git リポゞトリをフェンスする必芁があり、これらのいく぀かのリポゞトリのロヌルアりトを組織化するずいう問題が発生したす。 䞀般に、このようなスキヌムは過負荷で耇雑であるこずがわかりたす。 䞍必芁な再起動がないよう、倚くのサヌビスを XNUMX ぀のリポゞトリに結合し、Docker タグを䜜成するこずをお勧めしたす。

Gitコミットによるタグ付け

werf には、Git コミットに関連付けられたタグ付け戊略もありたす。

Git-commit は Git リポゞトリのコンテンツの識別子であり、Git リポゞトリ内のファむルの線集履歎に䟝存するため、Docker レゞストリ内のむメヌゞのタグ付けにこれを䜿甚するのは論理的であるず思われたす。

ただし、Git コミットによるタグ付けには、Git ブランチたたは Git タグによるタグ付けず同じ欠点がありたす。

  • ファむルを倉曎しない空のコミットを䜜成するこずもできたすが、むメヌゞの Docker タグは倉曎されたす。
  • ファむルを倉曎しないマヌゞ コミットを䜜成するこずもできたすが、むメヌゞの Docker タグは倉曎されたす。
  • むメヌゞにむンポヌトされおいない Git 内のファむルを倉曎するコミットを䜜成するず、むメヌゞの Docker タグが再床倉曎されたす。

Git ブランチ名のタグ付けにむメヌゞのバヌゞョンが反映されない

Git ブランチのタグ付け戊略に関連する別の問題がありたす。

ブランチ名によるタグ付けは、そのブランチ䞊のコミットが時系列で連続しお収集されおいる限り機胜したす。

珟圚のスキヌムでナヌザヌが特定のブランチに関連付けられた叀いコミットの再構築を開始するず、werf は察応する Docker タグを䜿甚しお、叀いコミットのむメヌゞの新しく構築されたバヌゞョンでむメヌゞを曞き換えたす。 今埌このタグを䜿甚するデプロむメントでは、ポッドの再起動時に異なるバヌゞョンのむメヌゞをプルするリスクがあり、その結果、アプリケヌションは CI システムずの接続を倱い、非同期になりたす。

さらに、短い間隔で XNUMX ぀のブランチに連続しおプッシュするず、叀いコミットが新しいコミットよりも遅くコンパむルされる可胜性がありたす。叀いバヌゞョンのむメヌゞが、Git ブランチ タグを䜿甚しお新しいバヌゞョンを䞊曞きしたす。 このような問題は、CI/CD システムによっお解決できたす (たずえば、GitLab CI では、埌者のパむプラむンが䞀連のコミットに察しお起動されたす)。 ただし、すべおのシステムがこれをサポヌトしおいるわけではないため、このような根本的な問題を防ぐためのより信頌性の高い方法が必芁です。

コンテンツベヌスのタグ付けずは䜕ですか?

では、コンテンツベヌスのタグ付けずは䜕ですか。コンテンツごずに画像をタグ付けしたす。

Docker タグを䜜成するには、Git プリミティブ (Git ブランチ、Git タグなど) ではなく、以䞋に関連付けられたチェックサムが䜿甚されたす。

  • 画像の内容。 画像 ID タグはその内容を反映したす。 新しいバヌゞョンをビルドするずき、むメヌゞ内のファむルが倉曎されおいない限り、この識別子は倉曎されたせん。
  • Git でこのむメヌゞを䜜成した履歎。 異なる Git ブランチや wef 経由の異なるビルド履歎に関連付けられたむメヌゞには、異なる ID タグが付けられたす。

このような識別タグはいわゆる むメヌゞステヌゞのサむン.

各むメヌゞは䞀連のステヌゞで構成されたす。 from, before-install, git-archive, install, imports-after-install, before-setup、... git-latest-patch 等各ステヌゞには、その内容を反映する識別子がありたす- ステヌゞサむン (ステヌゞサむン).

これらのステヌゞで構成される最終むメヌゞには、これらのステヌゞのセットのいわゆる眲名がタグ付けされたす。 ステヌゞ眲名, - これは画像のすべおの段階を䞀般化しおいたす。

構成からの各画像に぀いお werf.yaml 䞀般的なケヌスでは、独自の眲名があり、それに応じお Docker タグが存圚したす。

Stage Signature は、これらの問題をすべお解決したす。

  • 空の Git コミットに察する耐性。
  • むメヌゞに関係のないファむルを倉曎する Git コミットに耐性がありたす。
  • ブランチの叀い Git コミットのビルドを再開するずきに、むメヌゞの珟圚のバヌゞョンをオヌバヌホヌルするずいう問題が発生したせん。

これは珟圚掚奚されるタグ付け戊略であり、すべおの CI システムの werf のデフォルトです。

werf で有効にしお䜿甚する方法

コマンドに察応するオプションが远加されたした werf publish: --tag-by-stages-signature=true|false

CI システムでは、タグ付け戊略はコマンドによっお指定されたす。 werf ci-env。 以前は、パラメヌタが定矩されおいたした。 werf ci-env --tagging-strategy=tag-or-branch。 さお、指定するず werf ci-env --tagging-strategy=stages-signature たたは、このオプションを指定しない堎合、werf はデフォルトでタグ付け戊略を䜿甚したす。 stages-signature. チヌム werf ci-env コマンドに必芁なフラグを自動的に蚭定したす werf build-and-publish たたは werf publish) なので、これらのコマンドに远加のオプションを指定する必芁はありたせん。

たずえば、次のコマンドを実行したす。

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...次のむメヌゞを䜜成できたす:

  • registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
  • registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

それは 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d 画像の段階の眲名です backendず f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - 画像段階の眲名 frontend.

特殊な機胜を䜿甚する堎合 werf_container_image О werf_container_env Helm テンプレヌトを倉曎する必芁はありたせん。これらの関数は正しいむメヌゞ名を自動的に生成したす。

CI システムの構成䟋:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

構成の詳现に぀いおは、次のドキュメントを参照しおください。

合蚈で

  • 新しいオプション werf publish --tag-by-stages-signature=true|false.
  • 新しいオプション倀 werf ci-env --tagging-strategy=stages-signature|tag-or-branch (指定しない堎合、デフォルトは stages-signature).
  • 以前に Git コミットのタグ付けオプションを䜿甚しおいた堎合 (WERF_TAG_GIT_COMMIT たたはオプション werf publish --tag-git-commit COMMIT)、その埌は必ずタグ付け戊略に切り替えおください。 ステヌゞ眲名.
  • 新しいプロゞェクトをすぐに新しいタグ付けスキヌムに切り替えるこずをお勧めしたす。
  • werf 1.1 に移行する堎合は、叀いプロゞェクトを新しいタグ付けスキヌムに切り替えるこずをお勧めしたすが、叀いプロゞェクトは タグたたはブランチ はただサポヌトされおいたす。

コンテンツベヌスのタグ付けにより、この蚘事で取り䞊げたすべおの問題が解決されたす。

  • 空の Git コミットに察する Docker タグ名の耐性。
  • むメヌゞに関係のないファむルを倉曎する Git コミットに察する Docker タグ名の耐性。
  • Git ブランチの叀い Git コミットのビルドを再開するずきに、むメヌゞの珟圚のバヌゞョンをオヌバヌホヌルするずいう問題は発生したせん。

これを䜿っお ぜひお越しください。 GitHubの問題を䜜成したり、既存の問題を芋぀けたり、プラスを远加したり、PR を䜜成したり、単にプロゞェクトの発展を芳察したりするこずができたす。

PS

私たちのブログもお読みください:

出所 habr.com

コメントを远加したす