一般的なコンテナイメージ構築ツールとソリューションの紹介

[[420216]]

Docker を使用する場合、通常は docker build を使用してイメージを直接ビルドします。 Containerd に切り替える場合、前のセクションで nerdctl + buildkit を使用してコンテナイメージをビルドできることも紹介しました。これらの方法に加えて、他の一般的なイメージ構築ツールはありますか?

次に、Containerd コンテナランタイムでイメージを構築するための主なツールとソリューションを紹介します。

イメージ構築サービスにDockerを使用する

Kubernetes クラスターでは、一部の CI/CD パイプラインサービスでイメージパッケージングサービスを提供するために Docker を使用する必要がある場合があります。これは、ホストマシンの Docker を通じて実現できます。 Docker UNIX ソケット (/var/run/docker.sock) は、hostPath を介して CI/CD ビジネス Pod にマウントされます。次に、コンテナ内の UNIX ソケットを介してホストマシン上の Docker が呼び出され、ビルドが行われます。これは、これまで頻繁に使用されてきた Docker 外部の Docker ソリューションです。この方法は操作が簡単で、Docker 内の実際の Docker よりも多くのリソースを節約できますが、次の問題が発生する可能性があります。

ランタイムが containerd であるクラスターでは実行できません。
制御されない場合、ノード上の既存のイメージが上書きされる可能性があります。
Docker デーモン構成ファイルを変更する必要がある場合、他のサービスに影響が及ぶ可能性があります。
マルチテナントのシナリオでは安全ではありません。特権 Pod が Docker の UNIX ソケットを取得すると、Pod 内のコンテナはホストの Docker を呼び出してイメージを構築したり、既存のイメージやコンテナを削除したりできるだけでなく、docker exec インターフェースを介して他のコンテナを操作することもできます。

コンテナクラスターが必要であるものの、CI/CD ビジネスプロセスを変更せずに Docker を使用してイメージの一部をビルドするシナリオでは、DinD コンテナをサイドカーとして元の Pod に追加したり、DaemonSet を使用してノード上にイメージをビルドするための Docker サービスをデプロイしたりできます。

DinD をポッドサイドカーとして使用する

以下に示すように、 clean-ci という名前のコンテナがあります。コンテナに Sidecar コンテナを追加し、emptyDir を使用して clean-ci コンテナが UNIX ソケット経由で DinD コンテナにアクセスできるようにします。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: clean-ci
仕様:
  コンテナ:
  -名前: ディンド
    イメージ: 'docker:stable-dind'  
    指示：
    -ドッカー
    - --host=unix:///var/run/docker.sock  
    - --host=tcp://0.0.0.0:8000  
    セキュリティコンテキスト:
      特権: true  
    ボリュームマウント:
    - マウントパス: /var/run
名前: キャッシュディレクトリ
  -名前: clean-ci
    イメージ: 'docker:stable'  
    コマンド: [ "/bin/sh" ]
    引数: [ "-c" , "docker info >/dev/null 2>&1; while [ $? -ne 0 ] ; do sleep 3; docker info >/dev/null 2>&1; done; docker pull library/busybox:latest; docker save -o busybox-latest.tar library/busybox:latest; docker rmi library/busybox:latest; while true; do sleep 86400; done" ]
    ボリュームマウント:
    - マウントパス: /var/run
名前: キャッシュディレクトリ
  ボリューム:
  -名前: キャッシュディレクトリ
    空ディレクトリ: {}

上記で追加したdindコンテナを通じてdockerdを提供する

サービス、そして業務構築コンテナ内のemptyDir{}を介して/var/runディレクトリを共有します。ビジネスコンテナー内の docker クライアントは、unix:///var/run/docker.sock を介して dockerd と通信できます。

DaemonSet を使用して、各 containerd ノードに Docker をデプロイします。上記のサイドカーモードに加えて、DaemonSet を介して Docker を containerd クラスターに直接デプロイすることもできます。すると、ビジネスによって構築されたコンテナは以前のモードと同じになります。ホストの unix:///var/run/docker.sock ファイルを hostPath 経由で直接マウントするだけです。

DaemonSet をデプロイするには、次の YAML を使用します。次に例を示します。

 APIバージョン: アプリ/v1
種類: DaemonSet
メタデータ:
名前: docker-ci
仕様:
  セレクタ：
    一致ラベル:
      アプリ: docker-ci
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: docker-ci
    仕様:
      コンテナ:
      -名前: docker-ci
        イメージ: 'docker:stable-dind'  
        指示：
        -ドッカー
        - --host=unix:///var/run/docker.sock  
        - --host=tcp://0.0.0.0:8000  
        セキュリティコンテキスト:
          特権: true  
        ボリュームマウント:
        -マウントパス: /var/run
名前: ホスト
      ボリューム:
      -名前: ホスト
        ホストパス:
          パス: /var/run

上記の DaemonSet は各ノードで dockerd サービスを実行します。これは、以前の docker サービスを Kubernetes クラスターに管理用に配置するのと似ています。残りは以前と変わらず、以前の方法で何かを変更する必要さえありません。以下に示すように、ビジネスビルディング Pod と DaemonSet は同じ hostPath を共有します。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: clean-ci
仕様:
  コンテナ:
  -名前: clean-ci
    イメージ: 'docker:stable'  
    コマンド: [ "/bin/sh" ]
    引数: [ "-c" , "docker info >/dev/null 2>&1; while [ $? -ne 0 ] ; do sleep 3; docker info >/dev/null 2>&1; done; docker pull library/busybox:latest; docker save -o busybox-latest.tar library/busybox:latest; docker rmi library/busybox:latest; while true; do sleep 86400; done" ]
    ボリュームマウント:
    -マウントパス: /var/run
名前: ホスト
  ボリューム:
  -名前: ホスト
    ホストパス:
      パス: /var/run

カニコ

Kaniko は、コンテナまたは Kubernetes クラスター内の Dockerfile からコンテナイメージを構築できる、Google のオープンソースコンテナイメージ構築ツールです。 Kaniko は、コンテナイメージを構築するときに Docker デーモンに依存せず、特権モードも必要ありません。代わりに、Dockerfile 内の各コマンドを完全にユーザー空間で実行することで、Docker デーモンを簡単または安全に実行できない環境でもコンテナイメージを構築できるようになります。

カニコ

Kaniko がコンテナイメージをビルドするときは、Dockerfile、ビルドコンテキスト、およびビルドが成功した後のウェアハウス内のイメージのストレージアドレスを使用する必要があります。さらに、Kaniko は、ローカルフォルダー、GCS バケット、S3 バケットなどを使用するなど、ビルドコンテキストをコンテナにマウントする複数の方法をサポートしています。GCS または S3 を使用する場合、コンテキストを tar.gz に圧縮する必要があり、Kaniko はビルド中にコンテキストを自動的に解凍します。

Dockerfile を読み取った後、Kaniko Executor は Dockerfile の内容を 1 つずつ解析し、コマンドを 1 つずつ実行します。各コマンドが実行されると、ユーザースペースの下にスナップショットが作成され、ストレージとメモリ内の以前の状態と比較されます。変更があった場合、新しい変更がイメージレイヤーとして生成され、ベースイメージに追加され、関連する変更情報がイメージメタデータに書き込まれます。すべてのコマンドが実行されると、Kaniko は最終イメージを指定されたリモートイメージリポジトリにプッシュします。。プロセス全体は Docker デーモンから完全に独立しています。

以下に簡単な Dockerfile の例を示します。

アルパイン:最新より
apk add busybox-extras curlを実行します
CMD [ "エコー" , "こんにちはカニコ" ]

次に、kaniko コンテナを起動して、上記のイメージの構築を完了します。もちろん、Kubernetes クラスター内で直接実行することもできます。以下に示すように、上記のイメージを構築するための新しい kaniko Pod を作成します。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: かにこ
仕様:
  コンテナ:
  -名前：かにこ
    画像: gcr.io/kaniko-project/executor:latest
    引数: [ "--dockerfile=/workspace/Dockerfile" ,
 "--context=/ワークスペース/" 、
 "--destination=cnych/kaniko-test:v0.0.1" ]
    ボリュームマウント:
      -名前：カニコシークレット
        マウントパス: /kaniko/.docker
      -名前: dockerfile
        マウントパス: /workspace/Dockerfile
        サブパス: Dockerfile
  ボリューム:
    -名前: dockerfile
      構成マップ:
名前: dockerfile
    -名前：カニコシークレット
        予測:
         出典:
         - 秘密：
名前: regcred
            アイテム:
            -キー: .dockerconfigjson
              パス: config.json

上記の Pod 実行の args パラメータは、主に kaniko の実行に必要な 3 つのパラメータ (Dockerfile、ビルドコンテキスト、リモートイメージリポジトリ) を指定します。

指定されたリモートイメージリポジトリにプッシュするには資格情報のサポートが必要なので、資格情報をシークレットとして /kaniko/.docker/ ディレクトリにマウントする必要があります。ファイル名はconfig.jsonで、内容は次のとおりです。

 {
 「認証」 : {
 "https://index.docker.io/v1/" : {
 「認証」 : 「AbcdEdfgEdggds="  
       }
    } 
 
 }

auth の値は、docker_registry_username:docker_registry_password で、base64 でエンコードされた値です。その後、Dockerfile は Configmap としてマウントされます。ビルドコンテキストに他の何かがある場合は、それもマウントする必要があります。

kaniko の使用方法の詳細については、公式リポジトリ (https://github.com/GoogleContainerTools/kaniko) を参照してください。

ジブ

Java 環境の場合は、Jib を使用してイメージを構築することもできます。 Jib も Google のオープンソースですが、Java コンテナイメージを構築するためのツールです。

ジブ

Jib を使用すると、Java 開発者は使い慣れた Java ツールを使用してイメージを構築できます。 Jib は、アプリケーションをコンテナイメージにパッケージ化するために必要なすべての手順を処理する、高速でシンプルなコンテナイメージ構築ツールです。 Dockerfile を記述したり Docker をインストールしたりする必要がなく、Maven および Gradle に直接統合できます。 Java アプリケーションをすぐにコンテナ化するには、ビルドにプラグインを追加するだけです。

Jib は Docker イメージの階層化メカニズムを活用し、それをビルドシステムと統合し、次の方法で Java コンテナイメージのビルドを最適化します。

シンプル: Jib は Java で開発され、Maven または Gradle の一部として実行されます。 Dockerfile を記述したり、Docker デーモンを実行したり、すべての依存関係を含む大きな JAR パッケージを作成したりする必要はありません。 Jib は Java ビルドプロセスと緊密に統合されているため、アプリケーションをパッケージ化するために必要なすべての情報にアクセスできます。
高速: Jib はイメージのレイヤー化とキャッシュを活用して、高速な増分ビルドを可能にします。ビルド構成を読み取り、アプリケーションをさまざまなレイヤー (依存関係、リソース、クラス) に整理し、変更されたレイヤーのみを再構築してプッシュします。プロジェクトが迅速に反復される場合、Jib は変更されたレイヤーのみ (アプリケーション全体ではなく) をイメージリポジトリにプッシュして、貴重なビルド時間を節約します。
再現可能: Jib は、Maven および Gradle ビルドメタデータに基づく宣言的なコンテナイメージの構築をサポートしているため、入力が変更されない限り、構成を通じて同じイメージを繰り返し作成できます。

次の例では、Jib が提供する Gradle プラグインを使用して Spring Boot プロジェクトのビルドに統合し、Jib がイメージを簡単かつ迅速にビルドする方法を示します。

まず、プロジェクトの build.gradle ビルドファイルに jib プラグインを導入します。

ビルドスクリプト{
    ...
    依存関係 {
        ...
        クラスパス"gradle.plugin.com.google.cloud.tools:jib-gradle-plugin:1.1.2"  
    }
 } 
 
プラグインを適用: 'com.google.cloud.tools.jib'

関連するパラメータを設定する必要がある場合は、次の Gradle 設定を使用できます。

ジブ {
から{
        イメージ = 'harbor.k8s.local/library/base:1.0'  
        認証{
            ユーザー名 = '********'  
パスワード= '********'  
        }
    }
に{
        イメージ = 'harbor.k8s.local/library/xxapp:1.0'  
        認証{
            ユーザー名 = '********'  
パスワード= '********'  
        }
    }
    容器 {
        jvmFlags = [ '-Djava.security.egd=file:/dev/./urandom' ]
        ポート = [ '8080' ]
        useCurrentTimestamp = false  
        作業ディレクトリ = "/app"  
    }
 }

次に、次のコマンドを実行してビルドを直接トリガーし、コンテナイメージを生成します。

 # jib で指定されたイメージをビルドします。 .imageに変更し、イメージリポジトリにプッシュします。
 $ gradle ジブ

ビルドしたイメージをローカルの dockerd に保存したい場合は、次のコマンドを使用してビルドできます。

 gradle jibDockerBuild

もちろん、前回の記事で紹介したイメージビルドに使用できるビルドキットもあります。 Podman と一緒によく使用される Buildah もあります。これは、OCI 標準に準拠したコンテナイメージを構築するために使用できるコマンドラインツールです。これらのツールを使用すると、コンテナイメージを構築するときに docker デーモンを完全に排除できます。さらに、これらのツールは Kubernetes と適切に統合され、コンテナ環境での構築をサポートします。

<<: Longhorn クラウドネイティブコンテナ分散ストレージ - エアギャップインストール

>>: Docker イメージの削減: 1.43G から 22.4MB へ