ラベル kaniko の投稿を表示しています。 すべての投稿を表示
ラベル kaniko の投稿を表示しています。 すべての投稿を表示

2025年10月20日月曜日

GitlabCI で buildkit を使って docker イメージをビルドする

GitlabCI で buildkit を使って docker イメージをビルドする

概要

buildkit 単体で動かそうとするとデーモンが必要だったり runc が必要だったりするのですが GitlabCI で公式のイメージを使用すると簡単に使えたのでメモしておきます

環境

  • buildkit
  • Gitlab 18.2.6
  • Gitlab Runner 18.2.2

.gitlab-ci.yml

.gitlab-ci.yml と同じディレクトリに Dockerfile があれば以下でそのまま使えます
他に環境変数などの設定が必要な場合は variables などで設定してください

stages:
  - test

build:
  stage: test
  image:
    name: moby/buildkit:rootless
    entrypoint: [""]
  variables:
    BUILDKITD_FLAGS: --oci-worker-no-process-sandbox
  before_script:
    - mkdir -p ~/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > ~/.docker/config.json
  script:
    - |
      buildctl-daemonless.sh build \
        --frontend dockerfile.v0 \
        --local context=. \
        --local dockerfile=. \
        --output type=image,name=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA,push=true

最後に

kaniko からの代替としては一番近い感じはします
以下にもありますが公式にも kaniko からの移行ドキュメントがあります

参考サイト

時刻: 0 件のコメント:
ラベル: , , ,

2025年10月18日土曜日

GitlabCI と werf を組み合わせてイメージのビルドとプッシュをしてみる

GitlabCI と werf を組み合わせてイメージのビルドとプッシュをしてみる

概要

前回 werf に入門してみました
今回は GitlabCI と連携して werf を使ってみます
なお Gitlab Runner は docker executor なので werf の公式イメージを使ってビルドアンドプッシュを行います

環境

  • werf 2-stable
  • Gitlab 18.2.6
  • Gitlab Runner 18.2.2

Gitlab Runner 側設定

以下どちらかを有効にする必要があります

  • 特権モード有効にする
  • seccompとapparmorを無効にする

前者であれば以下のように設定します

[[runners]]
  name = "<name of the Runner you registered>"
  [runners.docker]
    privileged = true
    volumes = [
      "werf-cache:/home/build/.werf",
      "buildah-cache:/home/build/.local/share/containers"
    ]

後者であれば以下のように設定します

[[runners]]
  name = "<name of the Runner you registered>"
  [runners.docker]
    security_opt = ["seccomp:unconfined", "apparmor:unconfined"]
    volumes = [
      "werf-cache:/home/build/.werf",
      "buildah-cache:/home/build/.local/share/containers"
    ]

.gitlab-ci.yml

Gitlab のコンテナレジストリはオンにしておきましょう
以下は werf を使って build and push する最低限の設定になります

  • vim .gitlab-ci.yml
stages:
  - test

werf_build_and_push:
  stage: test
  image:
    name: "registry.werf.io/werf/werf:2-stable"
    pull_policy: always
  before_script:
    - cat $(werf ci-env gitlab --as-file)
    - source $(werf ci-env gitlab --as-file)
  script:
    - werf build --repo ${CI_REGISTRY_IMAGE} --add-custom-tag latest

実際にパイプラインを走らせるとコンテナレジストリにイメージがあることが確認できます
どうやら werf は指定のイメージだけではなくメタデータなどを管理するイメージもコンテナレジストリ上で管理するようです

ポイント

werf を Gitlab で使って便利な点は source $(werf ci-env gitlab --as-file) の部分です
レジストリの認証情報やリポジトリの基本設定を自動で読み込んでくれます
例えば CI_REGISTRY_IMAGE は werf 用の変数 WERF_REPO を使っても OK です

その他コマンド

  • werf converge
    • ビルドアンドプッシュと k8s 環境へのデプロイもしてくれます
  • werf cleanup --repo container-registry/username/reponame --without-kube
    • 使用されていないイメージを自動で削除してくれます
    • 基本は --without-kube なしで使用し k8s 環境で使用されていないイメージを自動で削除しコンテナレジストリのディスク容量を解放するのが目的です
  • werf purge --repo container-registry/username/reponame
    • cleanup に似ていますがこれはイメージが使用されていようがいまいが強制的にコンテナレジストリ上のイメージを削除します

その他各種コマンドは https://werf.io/docs/v2/reference/cli/overview.html を参照してください

最後に

GitlabCI と werf を組み合わせてイメージのビルドアンドプッシュをしてみました
kaniko 代替としてはこれで十分な気もします
そもそも werf は k8s 環境に特化したツールなのでデプロイまで含めてやりたい場合などは werf 一択かなと思います

参考サイト

時刻: 0 件のコメント:
ラベル: , , ,

2025年10月17日金曜日

werf 超入門

werf 超入門

概要

kaniko がメンテされなくなり代わりのイメージビルドツールに werf というツールがあったので試してみました

環境

  • Ubuntu 24.04
  • werf 2.45.1

インストール

  • curl -sSL https://werf.io/install.sh | bash -s -- --version 2 --channel stable

.bashrc などに設定が記載されるのでターミナルを開きなおせば werf コマンドが使えるようになります

$ werf version
v2.45.1

werf.yaml の作成

  • vim werf.yaml
project: lab
configVersion: 1
---
image: test
context: .
dockerfile: Dockerfile

Dockerfile はプロジェクトの直下にあるものとします

werf.yaml の追加

werf.yaml はコミットされていないと認識されないので先にコミットします
リモート側に push まではしなくて OK です

  • git add .
  • git commit -m “Add werf.yaml”

ビルド

  • werf build

以下のように実行されます

Version: v2.45.1
WARNING: unable to parse ssh key /home/devops/.ssh/id_dsa: error parsing private key /home/devops/.ssh/id_dsa: ssh: unhandled key type
Using werf config render file: /tmp/werf-config-render-2657037271

┌ ???   (1/1) image test
│ ┌ Building stage test/dockerfile
│ │ test/dockerfile  #0 building with "default" instance using docker driver
│ │ test/dockerfile
│ │ test/dockerfile  #1 [internal] load remote build context
│ │ test/dockerfile  #1 DONE 0.1s
│ │ test/dockerfile
│ │ test/dockerfile  #2 copy /context /
│ │ test/dockerfile  #2 DONE 0.0s
│ │ test/dockerfile
│ │ test/dockerfile  #3 [internal] load metadata for docker.io/library/python:3.12.11-slim-bookworm
│ │ test/dockerfile  #3 ...
│ │ test/dockerfile
│ │ test/dockerfile  #4 [auth] library/python:pull token for registry-1.docker.io
│ │ test/dockerfile  #4 DONE 0.0s
│ │ test/dockerfile
│ │ test/dockerfile  #3 [internal] load metadata for docker.io/library/python:3.12.11-slim-bookworm
│ │ test/dockerfile  #3 DONE 2.7s
│ │ test/dockerfile
│ │ test/dockerfile  #5 [1/2] FROM docker.io/library/python:3.12.11-slim-bookworm@sha256:519591d6871b7bc437060736b9f7456b8731f1499a57e22e6c285135ae657bf7
│ │ test/dockerfile  #5 resolve docker.io/library/python:3.12.11-slim-bookworm@sha256:519591d6871b7bc437060736b9f7456b8731f1499a57e22e6c285135ae657bf7 done
│ │ test/dockerfile  #5 sha256:519591d6871b7bc437060736b9f7456b8731f1499a57e22e6c285135ae657bf7 9.13kB / 9.13kB done
│ │ test/dockerfile  #5 sha256:c00fc7b44d844b6da22861ec24af43968a5200eac4ec607b4725d585165d6b49 1.75kB / 1.75kB done
│ │ test/dockerfile  #5 sha256:688a685f6a1fa9250d7c6cee916889cbca364e4b027520110e0fce80c64a13e0 5.60kB / 5.60kB done
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 0B / 28.23MB 0.1s
│ │ test/dockerfile  #5 sha256:229c2e83adbca32a7582f378ce5a103e5c327ffd945d3f451fe66d1886693f34 0B / 3.52MB 0.1s
│ │ test/dockerfile  #5 sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e 0B / 13.66MB 0.1s
│ │ test/dockerfile  #5 sha256:229c2e83adbca32a7582f378ce5a103e5c327ffd945d3f451fe66d1886693f34 3.52MB / 3.52MB 0.6s done
│ │ test/dockerfile  #5 sha256:5ac70eb707d38d47fc69ca91acd4de7256ef894f5f446a9c344a1f4ad7628114 0B / 250B 0.6s
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 2.10MB / 28.23MB 0.9s
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 11.53MB / 28.23MB 1.1s
│ │ test/dockerfile  #5 sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e 4.19MB / 13.66MB 1.1s
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 14.68MB / 28.23MB 1.2s
│ │ test/dockerfile  #5 sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e 7.50MB / 13.66MB 1.2s
│ │ test/dockerfile  #5 sha256:5ac70eb707d38d47fc69ca91acd4de7256ef894f5f446a9c344a1f4ad7628114 250B / 250B 1.1s done
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 16.78MB / 28.23MB 1.4s
│ │ test/dockerfile  #5 sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e 13.66MB / 13.66MB 1.3s done
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 23.07MB / 28.23MB 1.5s
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 28.23MB / 28.23MB 1.6s
│ │ test/dockerfile  #5 extracting sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375
│ │ test/dockerfile  #5 sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 28.23MB / 28.23MB 1.6s done
│ │ test/dockerfile  #5 extracting sha256:5c32499ab806884c5725c705c2bf528662d034ed99de13d3205309e0d9ef0375 1.6s done
│ │ test/dockerfile  #5 extracting sha256:229c2e83adbca32a7582f378ce5a103e5c327ffd945d3f451fe66d1886693f34
│ │ test/dockerfile  #5 extracting sha256:229c2e83adbca32a7582f378ce5a103e5c327ffd945d3f451fe66d1886693f34 0.2s done
│ │ test/dockerfile  #5 extracting sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e
│ │ test/dockerfile  #5 extracting sha256:d296ae3a1b166ec8b25480749804c463ffde8dd56bd4a0d938c764b93565254e 0.8s done
│ │ test/dockerfile  #5 extracting sha256:5ac70eb707d38d47fc69ca91acd4de7256ef894f5f446a9c344a1f4ad7628114 done
│ │ test/dockerfile  #5 DONE 4.6s
│ │ test/dockerfile
│ │ test/dockerfile  #6 [2/2] RUN python -V
│ │ test/dockerfile  #6 0.496 Python 3.12.11
│ │ test/dockerfile  #6 DONE 0.8s
│ │ test/dockerfile
│ │ test/dockerfile  #7 exporting to image
│ │ test/dockerfile  #7 exporting layers 0.0s done
│ │ test/dockerfile  #7 writing image sha256:9b378fddd07c7546217a3ec2dba912453034e050f7a642d2052aa472fe085408 done
│ │ test/dockerfile  #7 naming to docker.io/library/9107100b-cef7-4f0a-9a66-49d3dbfe2bed done
│ │ test/dockerfile  #7 DONE 0.1s
│ │ ┌ Store stage into :local
│ │ └ Store stage into :local (0.01 seconds)
│ ├ Info
│ │      name: lab:594be819ed90f0081179a4a268c6045413df7b83b21e1a225badccdd-1760658483401
│ │        id: 9b378fddd07c
│ │   created: 2025-10-17 08:48:03.293806991 +0900 JST
│ │      size: 118.5 MiB
│ └ Building stage test/dockerfile (8.66 seconds)
└ ???   (1/1) image test (9.05 seconds)

Running time 9.30 seconds

以下のようなイメージができれば OK です

docker images
REPOSITORY            TAG                                                                      IMAGE ID       CREATED              SIZE
lab                   594be819ed90f0081179a4a268c6045413df7b83b21e1a225badccdd-1760658483401   9b378fddd07c   About a minute ago   124MB

プッシュする

ビルドしたイメージをプッシュするには --repo オプションを使います
例えば gitlab であれば以下のようにします

  • werf build --repo container-registry.your-gitlab-address/username-or-groupname/repo-name

コンテナレジストリのアドレス/ユーザ名orグループ名/gitlabのリポジトリ名 で指定します
実行すると以下のように gitlab に push されていることが確認できます

Version: v2.45.1
WARNING: unable to parse ssh key /home/devops/.ssh/id_dsa: error parsing private key /home/devops/.ssh/id_dsa: ssh: unhandled key type
Using werf config render file: /tmp/werf-config-render-2317128975

┌ ???   (1/1) image test
│ ┌ Copy suitable stage from secondary :local
│ │ Use previously built image for test/dockerfile
│ │      name: container-registry.your-gitlab-address/username-or-groupname/repo-name:594be819ed90f0081179a4a268c6045413df7b83b21e1a225badccdd-1760658483401
│ │        id: 9b378fddd07c
│ │   created: 2025-10-17 08:48:03 +0900 JST
│ │      size: 44.2 MiB
│ └ Copy suitable stage from secondary :local (18.60 seconds)
└ ???   (1/1) image test (19.27 seconds)

Running time 28.24 seconds

docker images を見ると先ほどビルドしたイメージに gitlab にプッシュするためのタグが作成されてそれがプッシュされていることが確認できます

コンテナレジストリにログインしていない場合は

以下のようなエラーになります

Error: unable to init storage manager: error get synchronization: unable to init http synchronization: unable to get client id for the http synchronization server: unable to get repo container-registry.your-gitlab-address/username-or-groupname/repo-name tags: unable to fetch tags for repo "container-registry.your-gitlab-address/username-or-groupname/repo-name": reading tags for "container-registry.your-gitlab-address/username-or-groupname/repo-name": GET https://xxx/jwt/auth?scope=repository%3Ausername-or-group%2Frepo-name%3Apull&service=container_registry: DENIED: access forbidden

素直に docker login すれば OK です

  • docker login container-registry.your-gitlab-address

タグを設定するには

werf はデフォルトだと UUID のようなランダムな文字列をタグとして付与します
latest やバージョンなど独自のタグを付与して push したい場合には以下のようにします

  • werf build --repo container-registry.your-gitlab-address/username-or-groupname/repo-name --add-custom-tag latest --add-custom-tag hoge

--add-custom-tag を使います
--add-custom-tag は複数指定できます
以下のように複数のタグが push されていることが確認できます

Version: v2.45.1
WARNING: unable to parse ssh key /home/devops/.ssh/id_dsa: error parsing private key /home/devops/.ssh/id_dsa: ssh: unhandled key type
Using werf config render file: /tmp/werf-config-render-4112436980

┌ ???   (1/1) image test
│ ┌ Copy suitable stage from secondary :local
│ │ Use previously built image for test/dockerfile
│ │      name: container-registry.your-gitlab-address/username-or-groupname/repo-name:594be819ed90f0081179a4a268c6045413df7b83b21e1a225badccdd-1760658483401
│ │        id: 9b378fddd07c
│ │   created: 2025-10-17 08:48:03 +0900 JST
│ │      size: 44.2 MiB
│ └ Copy suitable stage from secondary :local (2.14 seconds)
└ ???   (1/1) image test (2.90 seconds)

┌ Adding custom tags
│ ┌ tag latest
│ │   name: container-registry.your-gitlab-address/username-or-groupname/repo-name:latest
│ └ tag latest (3.27 seconds)
│
│ ┌ tag hoge
│ │   name: container-registry.your-gitlab-address/username-or-groupname/repo-name:hoge
│ └ tag hoge (3.23 seconds)
└ Adding custom tags (6.51 seconds)

Running time 17.49 seconds

最後に

kaniko の代用として werf を使ってみました
kaniko のようにビルド -> プッシュを一回のコマンドでできるは良い点です
次回は GitlabCI で werf を使ってみます

参考サイト

時刻: 0 件のコメント:
ラベル: , , ,

2022年9月6日火曜日

kaniko超入門

kaniko超入門

概要

kaniko は Docker イメージを作成することができるツールです
dind を使うことなくイメージを作成できることができるので GitlabCI などでよく使われます
今回は GitlabCi で使って見ました

環境

  • macOS 11.6.8
  • kaniko 1.9.0

ContainerRegistry をオンにする

今回は Gitlab の ContainerRegistry に push するのでプロジェクトの ContainerRegistry をオンにしましょう
オンになっていないと CI でエラーになります

Dockerfile

プロジェクトの直下に Dockerfile を配置します
この Dockerfile を元にイメージを作成します

FROM ubuntu
ENTRYPOINT ["/bin/bash", "-c", "echo hello"]

.gitlab-ci.yml

これもプロジェクト直下に作成します
kaniko/executor というイメージを使って先程作成した Dockerfile を元にイメージを作成し push まで行います

認証情報を配置してあとは executor コマンドで Dockerfile とイメージの push 先を指定するだけで使えます

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG

動作確認

push したイメージを container registry から pull して実行してみましょう
「hello」と表示されれば OK です

最後に

ローカルで単体で使用するのは難しいかもです
基本的には k8s や docker 上で使います

参考サイト

https://github.com/GoogleContainerTools/kaniko/blob/main/docs/tutorial.md

時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)