問題タブ [kaniko]

私は Kubernetes や自分の登録済みランナーを使用していないため、この同様の質問は当てはまりません。

後続のパイプライン ステージで使用できるように gem を事前にインストールするために、GitLabCI パイプラインで Ruby ベースのイメージを構築しようとしています。このイメージを構築するために、.pre ステージで実行されるジョブで Kaniko を使用しようとしています。

もちろん、これはGitLabCI Kaniko の公式ドキュメント に基づいています。

ただし、パイプラインを実行すると、このジョブは次のメッセージでエラーを返します。

error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: getting tag for destination: registries must be valid RFC 3986 URI authorities: registry.gitlab.com

Dockerfile パスは正しく、 --dockerfile 引数への無効な Dockerfile パスを使用してテストした結果、これが問題の原因ではないことは明らかです。

私が知る限り、認証には正しいパイプライン環境変数を使用しており、Kaniko をそのまま使用するためのドキュメントに従っています。GitLab の共有ランナーを使用してパイプライン ジョブを実行しています。

5 月のこの問題のコメントによると、他のユーザーも同様の問題を経験しており、その後debug-v0.16.0Kaniko イメージに戻すと解決されました。同様に、イメージ名の行を に変更しましたname: gcr.io/kaniko-project/executor:debug-v0.16.0が、これにより同じエラー メッセージが表示されました。

最後に、ここに示されているように展開キーを使用して、レジストリにアクセスするための汎用ユーザーを作成してみました。GitLabCI 環境変数プロジェクト設定インターフェイスを介して、ユーザー名とキーに対応する 2 つの変数を追加し、パイプライン スクリプトでこれらの変数を置き換えました。これにより、同じエラー メッセージが表示されました。

これらのカスタム変数の名前を「CI_REGISTRY_USER」および「CI_REGISTRY_PASSWORD」（事前定義された変数）に変更するなど、このアプローチでいくつかのバリエーションを試しました。また、これらの変数のどちらも「保護」としてマークされていないことも確認しました。これで問題は解決しませんでした。

また、チュートリアル スクリプトを逐語的に (カスタム イメージ タグなしで) 実行しようとしましたが、これも同じエラー メッセージが表示されます。

Kaniko を使用して GitLabCI パイプラインで Docker イメージを構築することに最近成功した人はいますか? 他の人も同様の問題を経験しているようですが、私が知る限り、解決策は提示されておらず、問題が私の側にあるのかどうかはわかりません. 潜在的な問題の原因を診断するのに役立つ追加情報があれば教えてください。皆さんありがとう！

GitLab CI/CD パイプラインで kaniko を使用してビルドできる Dockerfile があります。現在、buildステージはコンテナーを構築し、それをリモートの Docker リポジトリーにプッシュします。

CI/CD パイプラインのステージの概念を利用してイメージを構築し、自動テストを実行してコンテナー セキュリティ分析ツール ( Trivy ) を実行し、最後のステップとして、すべての前のステップが成功した場合は、レジストリにプッシュします。

1. ビルドイメージ
2. 自動テストの実行 (作成されたイメージに基づく)
3. 作成したイメージのセキュリティを分析する (Trivy を使用)
4. 前の手順が成功した場合にのみイメージをレジストリにプッシュし、イメージを再構築しない

イメージをビルドしてプッシュするコマンドは次のとおりです。

プッシュを実行しないオプション/コマンド ライン フラグと、イメージの tarball のみを生成する--no-pushフラグがあります。--tar-path

これらのフラグとコマンドを組み合わせて、レジストリにプッシュせずにイメージのみを作成するにはどうすればよいでしょうか。セキュリティ チェックが実行されている場合にのみイメージをプッシュする必要があるからです。そして、プッシュ ステージ (GitLab CI ジョブ) はどのように見えますか。特に正確な kaniko コマンド ラインです。

最後のプッシュ ステージ/ジョブが、以前にビルドされたイメージまたはキャッシュを再利用し、再構築しないようにできれば素晴らしいことです。 tarball は何とか使えると思いますが、kaniko がそれを使用するためのフラグは何でしょうか? それとも、その tarball を使用し、docker コマンドを使用して tarball をレジストリにプッシュするだけですか?

gitlab のドキュメントから、kaniko を使用して Docker イメージを作成する方法は次のとおりです。

しかし、コンテナー レジストリにプッシュする前に、最初にテスト (pytest) を実行したいと考えています。どんな助けでも大歓迎です。ありがとう！

React アプリケーション ( github repo )の Google Cloud Build を高速化しようとしています。そのため、Cloud Build の公式ドキュメントで提案されているように、Kaniko Cache の使用を開始しました。

私のビルドプロセスのnpm install一部が実際にキャッシュされているようです。npm run buildただし、ソース ファイルが変更されていない場合もキャッシュされると予想していました。

私の Dockerfile:

ビルド出力:

現在、キャッシュ システムのオーバーヘッドがあるため、速度の利点はないようです。

私は Dockerfiles に比較的慣れていないので、単純な行が欠けていることを願っています。