通常の Dockerfile を使用して、werf で Docker イメージを構築できるようになりました

遅刻しないよりはマシです。 あるいは、アプリケーション イメージを構築するための通常の Dockerfile をサポートしていないという重大な間違いを犯すところでした。

について話しましょう ワーフ — あらゆる CI/CD システムと統合し、アプリケーションのライフサイクル全体の管理を提供する GitOps ユーティリティにより、次のことが可能になります。

• 画像を収集して公開し、
• Kubernetes にアプリケーションをデプロイし、
• 特別なポリシーを使用して未使用のイメージを削除します。

このプロジェクトの理念は、低レベルのツールを XNUMX つの統合システムに集め、DevOps エンジニアがアプリケーションを制御できるようにすることです。 可能であれば、既存のユーティリティ (Helm や Docker など) を使用する必要があります。 問題に対する解決策がない場合は、そのために必要なものをすべて作成してサポートします。

背景: 独自の画像コレクター

これが werf のイメージ コレクターで起こったことです。通常の Dockerfile では十分ではありませんでした。 プロジェクトの歴史をざっと見てみると、この問題は werf の最初のバージョンですでに発生していました (その後も ダップとして知られています).

アプリケーションを Docker イメージに構築するツールを作成しているときに、Dockerfile がいくつかの非常に特殊なタスクには適していないことにすぐに気づきました。

1. 次の標準スキームに従って、典型的な小規模な Web アプリケーションを構築する必要があります。
   • システム全体のアプリケーションの依存関係をインストールし、
   • アプリケーションの依存関係ライブラリのバンドルをインストールします。
   • 資産を集め、
   • そして最も重要なことは、イメージ内のコードを迅速かつ効率的に更新することです。
2. プロジェクト ファイルに変更が加えられた場合、ビルダーは変更されたファイルにパッチを適用して新しいレイヤーを迅速に作成する必要があります。
3. 特定のファイルが変更された場合は、対応する依存ステージを再構築する必要があります。

現在、私たちのコレクターには他にも多くの可能性がありますが、これらは当初の願望と衝動でした。

一般に、私たちはよく考えずに、使用したプログラミング言語で武装しました。 （下記参照） そして実装に向けて出発します 独自のDSL！ 目的に従って、アセンブリ プロセスを段階的に記述し、これらの段階のファイルへの依存関係を判断することを目的としていました。 そしてそれを補完した 自分のコレクター、DSL を最終目標、つまり組み立てられたイメージに変えました。 当初、DSL は Ruby で作られていましたが、 Golang への移行 — コレクターの構成が YAML ファイルで記述され始めました。

Ruby の dapp の古い構成

YAML 上の werf の現在の構成

コレクターのメカニズムも時代とともに変化しました。 最初は、構成から一時的な Dockerfile をオンザフライで生成するだけで、次に一時コンテナーでアセンブリ命令を実行してコミットを開始しました。

NB: 現時点では、(YAML での) 独自の構成で動作し、Stapel コレクターと呼ばれるコレクターは、すでにかなり強力なツールに開発されています。 詳細な説明は別の記事に値します。基本的な詳細については、以下を参照してください。 ドキュメンテーション.

問題意識

しかし、私たちはすぐには気づきませんでしたが、XNUMX つの間違いを犯したことに気づきました。それは、機能を追加しなかったことです。 標準の Dockerfile 経由でイメージをビルドする そしてそれらを同じエンドツーエンドのアプリケーション管理インフラストラクチャに統合します (つまり、イメージを収集し、展開し、クリーンアップします)。 Dockerfile サポートを実装せずに、Kubernetes でデプロイするためのツールを作成することがどのように可能でしょうか。 ほとんどのプロジェクトで画像を記述する標準的な方法?

この質問に答える代わりに、解決策を提供します。 すでに Dockerfile (または一連の Dockerfile) があり、werf を使用したい場合はどうすればよいでしょうか?

NB：ところで、なぜwerfを使いたいと思ったのですか？ 主な機能は次のとおりです。

• イメージのクリーニングを含む完全なアプリケーション管理サイクル。
• 単一の構成から複数のイメージのアセンブリを一度に管理する機能。
• Helm 互換チャートのデプロイメントプロセスが改善されました。

それらのより完全なリストは、次の場所にあります。 プロジェクトページ.

したがって、以前に構成内の Dockerfile を書き換えることを提案していたとしても、今では喜んで「werf に Dockerfile を構築させましょう!」と言うでしょう。

どのように使用する？

この機能の完全な実装はリリースに記載されています ワーフ v1.0.3-beta.1。 一般的な原則は単純です。ユーザーは werf config で既存の Dockerfile へのパスを指定し、コマンドを実行します。 werf build...それだけです - werf が画像を組み立てます。 抽象的な例を見てみましょう。

次回も発表しましょう Dockerfile プロジェクトルート内:

FROM ubuntu:18.04
RUN echo Building ...

そして発表します werf.yamlこれを使用するのは Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

全て！ 左 走る werf build:

さらに、次のように宣言することもできます werf.yaml 異なる Dockerfile から複数のイメージを一度に構築するには:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

最後に、次のような追加のビルド パラメーターの受け渡しもサポートします。 --build-arg и --add-host - werf config経由。 Dockerfile イメージ構成の完全な説明は、次の場所で参照できます。 ドキュメントページ.

それはどのように動作しますか？

ビルド プロセス中、Docker のローカル レイヤーの標準キャッシュが機能します。 しかし、重要なことは、ヴェルフもまた、 Dockerfile 構成をインフラストラクチャに統合します. これは何を意味するのでしょうか？

1. Dockerfile から構築された各イメージは、と呼ばれる XNUMX つのステージで構成されます。 dockerfile (werf にどのようなステージがあるかについて詳しく読むことができます) ここで).
2. ステージ用 dockerfile werf は、Dockerfile 構成の内容に応じて署名を計算します。 Dockerfile 構成が変更されると、ステージ署名が変更されます dockerfile そして、werf は新しい Dockerfile 構成を使用してこのステージの再構築を開始します。 署名が変更されない場合、werf はキャッシュから画像を取得します。 (werf での署名の使用についての詳細は、次のセクションで説明されています) このレポート).
3. 次に、収集した画像をコマンドで公開できます。 werf publish （または werf build-and-publish) を作成し、Kubernetes へのデプロイメントに使用します。 Docker レジストリに公開されたイメージは、標準の werf クリーンアップ ツールを使用してクリーンアップされます。 古いイメージ (N 日より古い)、存在しない Git ブランチに関連付けられたイメージ、およびその他のポリシーは自動的にクリーンアップされます。

ここで説明する点の詳細については、次のドキュメントを参照してください。

• 出版プロセス;
• Kubernetes デプロイメントプロセスとの統合;
• 洗浄工程.

注意事項と注意事項

1. 外部 URL は ADD ではサポートされていません

現在、ディレクティブでの外部 URL の使用はサポートされていません。 ADD。 Werf は、指定された URL のリソースが変更されたときに再構築を開始しません。 この機能は近々追加する予定です。

2. .git をイメージに追加することはできません

一般的に、ディレクトリを追加すると、 .git 画像は悪質な悪い習慣であり、その理由は次のとおりです。

1. もし .git 最終画像に残ります。これは原則に違反します。 12要素アプリ: 最終イメージは単一のコミットにリンクする必要があるため、次のことはできないはずです。 git checkout 任意のコミット。
2. .git イメージのサイズが増加します (大きなファイルが一度リポジトリに追加され、その後削除されるため、リポジトリが大きくなる可能性があります)。 特定のコミットのみに関連付けられたワークツリーのサイズは、Git での操作の履歴には依存しません。 この場合、追加とその後の削除は .git 最終イメージからの変換は機能しません。イメージは引き続き追加のレイヤーを取得します。これが Docker の仕組みです。
3. Docker は、同じコミットが異なるワークツリーから構築されている場合でも、不要な再構築を開始する可能性があります。 たとえば、GitLab は、次の場所に別のクローン ディレクトリを作成します。 /home/gitlab-runner/builds/HASH/[0-N]/yourproject 並列アセンブリが有効な場合。 追加の再アセンブリは、ディレクトリが .git 同じコミットがビルドされた場合でも、同じリポジトリの異なるクローン バージョンでは異なります。

最後の点は、werf を使用する場合にも影響します。 Werf では、いくつかのコマンド (例: werf deploy）。 これらのコマンドを実行すると、werf は指定されたイメージのステージ シグネチャを計算します。 werf.yamlそれらはアセンブリ キャッシュ内に存在する必要があります。そうでない場合、コマンドは動作を続行できません。 ステージ署名がコンテンツに依存する場合 .gitそうすると、無関係なファイルの変更に対して不安定なキャッシュが取得され、werf はそのような見落としを許すことができなくなります (詳細については、を参照してください)。 ドキュメンテーション).

一般的に、 特定の必要なファイルのみを追加する 指示を通して ADD いずれの場合でも、文書の効率と信頼性が向上します。 Dockerfile、また、このために収集されたキャッシュの安定性も向上します。 Dockerfile、Git の無関係な変更。

合計

特定のニーズに合わせて独自のビルダーを作成するための最初の道のりは、困難で正直かつ単純なものでした。標準の Dockerfile の上に松葉杖を使用する代わりに、カスタム構文を使用してソリューションを作成しました。 そしてこれには利点もありました。Stapel コレクターはそのタスクに完璧に対処します。

しかし、独自のビルダーを作成する過程で、既存の Dockerfile のサポートを見失いました。 この欠陥は現在修正されており、将来的には、分散アセンブリおよび Kubernetes を使用したアセンブリ (つまり、kaniko で行われるように、Kubernetes 内のランナーでのアセンブリ) 用のカスタム Stapel ビルダーとともに Dockerfile サポートを開発する予定です。

したがって、突然、いくつかの Dockerfile が存在した場合... 試してみる ワーフ!

PS トピックに関するドキュメントのリスト

• クイックスタートのためのガイド;
• dockerfile ビルダー構成;
• ヴェルフのステージ装置;
• 画像公開プロセス;
• Kubernetes デプロイメントプロセスとの統合;
• 洗浄工程;
• Dockerfile の代替としての Stapel ビルダー.

私たちのブログもお読みください:werf - Kubernetes の CI / CD 用ツール (概要とビデオレポート)'。

出所： habr.com