Using uv in DockerDockerでのuvの使用
Getting startedはじめに
Tipヒント
Check out the uv-docker-example project for
an example of best practices when using uv to build an application in Docker.Check out the uv-docker-example project for
an example of best practices when using uv to build an application in Docker.
uv provides both distroless Docker images, which are useful for copying uv binaries into your own image builds, and images derived from popular base images, which are useful for using uv in a container. The distroless images do not contain anything but the uv binaries. In contrast, the derived images include an operating system with uv pre-installed.uvは、独自のイメージビルドにuvバイナリをコピーするのに便利なdistroless Dockerイメージと、コンテナ内でuvを使用するのに便利な人気のあるベースイメージから派生したイメージの両方を提供します。distrolessイメージにはuvバイナリ以外のものは含まれていません。それに対して、派生イメージにはuvが事前にインストールされたオペレーティングシステムが含まれています。
As an example, to run uv in a container using a Debian-based image:例として、Debianベースのイメージを使用してコンテナ内でuvを実行するには:
Available images利用可能なイメージ
The following distroless images are available:以下のdistrolessイメージが利用可能です:
ghcr.io/astral-sh/uv:latestghcr.io/astral-sh/uv:latestghcr.io/astral-sh/uv:{major}.{minor}.{patch}, e.g.,ghcr.io/astral-sh/uv:0.9.13ghcr.io/astral-sh/uv:{major}.{minor}.{patch}、例：ghcr.io/astral-sh/uv:0.9.13ghcr.io/astral-sh/uv:{major}.{minor}, e.g.,ghcr.io/astral-sh/uv:0.8(the latest patch version)ghcr.io/astral-sh/uv:{major}.{minor}、例：ghcr.io/astral-sh/uv:0.8（最新のパッチバージョン）
And the following derived images are available:次の派生イメージが利用可能です：
- Based on
alpine:3.22:ghcr.io/astral-sh/uv:alpineghcr.io/astral-sh/uv:alpineghcr.io/astral-sh/uv:alpine3.22ghcr.io/astral-sh/uv:alpine3.22
- Based on
alpine:3.21:ghcr.io/astral-sh/uv:alpine3.21ghcr.io/astral-sh/uv:alpine3.21
- Based on
debian:trixie-slim:ghcr.io/astral-sh/uv:debian-slimghcr.io/astral-sh/uv:debian-slimghcr.io/astral-sh/uv:trixie-slimghcr.io/astral-sh/uv:trixie-slim
- Based on
debian:bookworm-slim:ghcr.io/astral-sh/uv:bookworm-slimghcr.io/astral-sh/uv:bookworm-slim
- Based on
buildpack-deps:trixie:ghcr.io/astral-sh/uv:debianghcr.io/astral-sh/uv:debianghcr.io/astral-sh/uv:trixieghcr.io/astral-sh/uv:trixie
- Based on
buildpack-deps:bookworm:ghcr.io/astral-sh/uv:bookwormghcr.io/astral-sh/uv:bookworm
- Based on
python3.x-alpine:ghcr.io/astral-sh/uv:python3.14-alpineghcr.io/astral-sh/uv:python3.14-alpineghcr.io/astral-sh/uv:python3.13-alpineghcr.io/astral-sh/uv:python3.13-alpineghcr.io/astral-sh/uv:python3.12-alpineghcr.io/astral-sh/uv:python3.12-alpineghcr.io/astral-sh/uv:python3.11-alpineghcr.io/astral-sh/uv:python3.11-alpineghcr.io/astral-sh/uv:python3.10-alpineghcr.io/astral-sh/uv:python3.10-alpineghcr.io/astral-sh/uv:python3.9-alpineghcr.io/astral-sh/uv:python3.9-alpineghcr.io/astral-sh/uv:python3.8-alpineghcr.io/astral-sh/uv:python3.8-alpine
- Based on
python3.x-trixie:ghcr.io/astral-sh/uv:python3.14-trixieghcr.io/astral-sh/uv:python3.14-trixieghcr.io/astral-sh/uv:python3.13-trixieghcr.io/astral-sh/uv:python3.13-trixieghcr.io/astral-sh/uv:python3.12-trixieghcr.io/astral-sh/uv:python3.12-trixieghcr.io/astral-sh/uv:python3.11-trixieghcr.io/astral-sh/uv:python3.11-trixieghcr.io/astral-sh/uv:python3.10-trixieghcr.io/astral-sh/uv:python3.10-trixieghcr.io/astral-sh/uv:python3.9-trixieghcr.io/astral-sh/uv:python3.9-trixie
- Based on
python3.x-slim-trixie:ghcr.io/astral-sh/uv:python3.14-trixie-slimghcr.io/astral-sh/uv:python3.14-trixie-slimghcr.io/astral-sh/uv:python3.13-trixie-slimghcr.io/astral-sh/uv:python3.13-trixie-slimghcr.io/astral-sh/uv:python3.12-trixie-slimghcr.io/astral-sh/uv:python3.12-trixie-slimghcr.io/astral-sh/uv:python3.11-trixie-slimghcr.io/astral-sh/uv:python3.11-trixie-slimghcr.io/astral-sh/uv:python3.10-trixie-slimghcr.io/astral-sh/uv:python3.10-trixie-slimghcr.io/astral-sh/uv:python3.9-trixie-slimghcr.io/astral-sh/uv:python3.9-trixie-slim
- Based on
python3.x-bookworm:ghcr.io/astral-sh/uv:python3.14-bookwormghcr.io/astral-sh/uv:python3.14-bookwormghcr.io/astral-sh/uv:python3.13-bookwormghcr.io/astral-sh/uv:python3.13-bookwormghcr.io/astral-sh/uv:python3.12-bookwormghcr.io/astral-sh/uv:python3.12-bookwormghcr.io/astral-sh/uv:python3.11-bookwormghcr.io/astral-sh/uv:python3.11-bookwormghcr.io/astral-sh/uv:python3.10-bookwormghcr.io/astral-sh/uv:python3.10-bookwormghcr.io/astral-sh/uv:python3.9-bookwormghcr.io/astral-sh/uv:python3.9-bookwormghcr.io/astral-sh/uv:python3.8-bookwormghcr.io/astral-sh/uv:python3.8-bookworm
- Based on
python3.x-slim-bookworm:ghcr.io/astral-sh/uv:python3.14-bookworm-slimghcr.io/astral-sh/uv:python3.14-bookworm-slimghcr.io/astral-sh/uv:python3.13-bookworm-slimghcr.io/astral-sh/uv:python3.13-bookworm-slimghcr.io/astral-sh/uv:python3.12-bookworm-slimghcr.io/astral-sh/uv:python3.12-bookworm-slimghcr.io/astral-sh/uv:python3.11-bookworm-slimghcr.io/astral-sh/uv:python3.11-bookworm-slimghcr.io/astral-sh/uv:python3.10-bookworm-slimghcr.io/astral-sh/uv:python3.10-bookworm-slimghcr.io/astral-sh/uv:python3.9-bookworm-slimghcr.io/astral-sh/uv:python3.9-bookworm-slimghcr.io/astral-sh/uv:python3.8-bookworm-slimghcr.io/astral-sh/uv:python3.8-bookworm-slim
As with the distroless image, each derived image is published with uv version tags as
ghcr.io/astral-sh/uv:{major}.{minor}.{patch}-{base} and
ghcr.io/astral-sh/uv:{major}.{minor}-{base}, e.g., ghcr.io/astral-sh/uv:0.9.13-alpine.distrolessイメージと同様に、各派生イメージはuvバージョンタグと共に公開されます。
ghcr.io/astral-sh/uv:{major}.{minor}.{patch}-{base}および
ghcr.io/astral-sh/uv:{major}.{minor}-{base}、例えば、ghcr.io/astral-sh/uv:0.9.13-alpine。
In addition, starting with 0.8 each derived image also sets UV_TOOL_BIN_DIR to /usr/local/bin
to allow uv tool install to work as expected with the default user.さらに、0.8以降、各派生イメージはUV_TOOL_BIN_DIRを/usr/local/binに設定し、
uv tool installがデフォルトユーザーで期待通りに動作するようにします。
For more details, see the GitHub Container page.詳細については、GitHub Container ページを参照してください。
Installing uvuvのインストール
Use one of the above images with uv pre-installed or install uv by copying the binary from the official distroless Docker image:上記のいずれかのイメージを使用してuvを事前インストールするか、公式のdistroless Dockerイメージからバイナリをコピーしてuvをインストールしてください:
Or, with the installer:または、インストーラーを使用して：
FROM python:3.12-slim-trixie
# The installer requires curl (and certificates) to download the release archive
RUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates
# Download the latest installer
ADD https://astral.sh/uv/install.sh /uv-installer.sh
# Run the installer then remove it
RUN sh /uv-installer.sh && rm /uv-installer.sh
# Ensure the installed binary is on the `PATH`
ENV PATH="/root/.local/bin/:$PATH"
Note this requires curl to be available.これには curl が利用可能である必要があります。
In either case, it is best practice to pin to a specific uv version, e.g., with:いずれの場合でも、特定の uv バージョンに固定することがベストプラクティスです。例えば、次のように：
Tipヒント
While the Dockerfile example above pins to a specific tag, it's also possible to pin a specific SHA256. Pinning a specific SHA256 is considered best practice in environments that require reproducible builds as tags can be moved across different commit SHAs.上記の Dockerfile の例は特定のタグに固定していますが、特定の SHA256 に固定することも可能です。特定の SHA256 に固定することは、タグが異なるコミット SHA に移動できるため、再現可能なビルドが必要な環境ではベストプラクティスと見なされます。
Or, with the installer:または、インストーラーを使用して：
Installing a projectプロジェクトのインストール
If you're using uv to manage your project, you can copy it into the image and install it:プロジェクトを管理するために uv を使用している場合、イメージにコピーしてインストールできます：
# Copy the project into the image
ADD . /app
# Sync the project into a new environment, asserting the lockfile is up to date
WORKDIR /app
RUN uv sync --locked
Important重要
It is best practice to add .venv to a .dockerignore file
in your repository to prevent it from being included in image builds. The project virtual
environment is dependent on your local platform and should be created from scratch in the image..venv を .dockerignore ファイル に追加することがベストプラクティスです。これにより、イメージビルドに含まれないようにします。プロジェクトの仮想環境はローカルプラットフォームに依存しており、イメージ内でゼロから作成する必要があります。
Then, to start your application by default:次に、アプリケーションをデフォルトで起動するには：
# Presuming there is a `my_app` command provided by the project
CMD ["uv", "run", "my_app"]
Tipヒント
It is best practice to use intermediate layers separating installation of dependencies and the project itself to improve Docker image build times.依存関係のインストールとプロジェクト自体を分離するために 中間レイヤー を使用することがベストプラクティスです。これにより、Docker イメージのビルド時間が改善されます。
See a complete example in the
uv-docker-example project.完全な例は、
uv-docker-exampleプロジェクトで確認できます。
Using the environment環境の使用
Once the project is installed, you can either activate the project virtual environment by placing its binary directory at the front of the path:プロジェクトがインストールされたら、バイナリディレクトリをパスの先頭に置くことでプロジェクトの仮想環境をアクティブ化できます:
Or, you can use uv run for any commands that require the environment:または、環境を必要とするコマンドにはuv runを使用できます:
Tipヒント
Alternatively, the
UV_PROJECT_ENVIRONMENT setting can
be set before syncing to install to the system Python environment and skip environment activation
entirely.また、UV_PROJECT_ENVIRONMENT設定を設定して、システムPython環境にインストールするために同期する前に環境のアクティベーションを完全にスキップすることもできます。
Using installed toolsインストールされたツールの使用
To use installed tools, ensure the tool bin directory is on the path:インストールされたツールを使用するには、ツールのバイナリディレクトリがパスに含まれていることを確認してください:
$ docker run -it $(docker build -q .) /bin/bash -c "cowsay -t hello"
_____
| hello |
=====
\
\
^__^
(oo)\_______
(__)\ )\/\
||----w |
|| ||
Note注意
The tool bin directory's location can be determined by running the uv tool dir --bin command
in the container.ツールのバイナリディレクトリの場所は、コンテナ内でuv tool dir --binコマンドを実行することで確認できます。
Alternatively, it can be set to a constant location:また、一定の場所に設定することもできます:
Installing Python in ARM musl imagesARM muslイメージにPythonをインストールする
While uv will attempt to install a compatible Python version if no such version is available in the image, uv does not yet support installing Python for musl Linux on ARM. For example, if you are using an Alpine Linux base image on an ARM machine, you may need to add it with the system package manager:uvは、イメージにそのようなバージョンがない場合に互換性のあるPythonバージョンをインストールしようとしますが、uvはまだARM上のmusl Linux用のPythonのインストールをサポートしていません。例えば、ARMマシンでAlpine Linuxベースのイメージを使用している場合、システムパッケージマネージャーを使用して追加する必要があります。
Developing in a containerコンテナ内での開発
When developing, it's useful to mount the project directory into a container. With this setup,
changes to the project can be immediately reflected in a containerized service without rebuilding
the image. However, it is important not to include the project virtual environment (.venv) in
the mount, because the virtual environment is platform specific and the one built for the image
should be kept.開発中は、プロジェクトディレクトリをコンテナにマウントすることが便利です。このセットアップでは、プロジェクトへの変更がイメージを再構築することなく、コンテナ化されたサービスに即座に反映されます。ただし、プロジェクトの仮想環境（.venv）をマウントに含めないことが重要です。なぜなら、仮想環境はプラットフォーム固有であり、イメージ用に構築されたものを保持する必要があるからです。
Mounting the project with docker rundocker runを使用したプロジェクトのマウント
Bind mount the project (in the working directory) to /app while retaining the .venv directory
with an anonymous volume:プロジェクト（作業ディレクトリ内）を/appにバインドマウントし、匿名ボリュームで.venvディレクトリを保持します：
Tipヒント
The --rm flag is included to ensure the container and anonymous volume are cleaned up when the
container exits.--rmフラグは、コンテナが終了したときにコンテナと匿名ボリュームがクリーンアップされることを保証するために含まれています。
See a complete example in the
uv-docker-example project.完全な例は、uv-docker-exampleプロジェクトで確認できます。
Configuring watch with docker composedocker composeを使用したwatchの設定
When using Docker compose, more sophisticated tooling is available for container development. The
watch option
allows for greater granularity than is practical with a bind mount and supports triggering updates
to the containerized service when files change.Docker composeを使用すると、コンテナ開発のためのより洗練されたツールが利用可能です。watchオプションは、バインドマウントでは実用的な粒度よりも高い粒度を提供し、ファイルが変更されたときにコンテナ化されたサービスへの更新をトリガーすることをサポートします。
Note注意
This feature requires Compose 2.22.0 which is bundled with Docker Desktop 4.24.この機能は、Docker Desktop 4.24にバンドルされているCompose 2.22.0を必要とします。
Configure watch in your
Docker compose file
to mount the project directory without syncing the project virtual environment and to rebuild the
image when the configuration changes:watchを設定して、プロジェクトの仮想環境を同期せずにプロジェクトディレクトリをマウントし、設定が変更されたときにイメージを再構築します。Docker composeファイルで。
services:
example:
build: .
# ...
develop:
# Create a `watch` configuration to update the app
#
watch:
# Sync the working directory with the `/app` directory in the container
- action: sync
path: .
target: /app
# Exclude the project virtual environment
ignore:
- .venv/
# Rebuild the image on changes to the `pyproject.toml`
- action: rebuild
path: ./pyproject.toml
Then, run docker compose watch to run the container with the development setup.次に、docker compose watchを実行して、開発セットアップでコンテナを実行します。
See a complete example in the
uv-docker-example project.完全な例は、uv-docker-exampleプロジェクトで確認できます。
Optimizations最適化
Compiling bytecodeバイトコードのコンパイル
Compiling Python source files to bytecode is typically desirable for production images as it tends to improve startup time (at the cost of increased installation time).Pythonのソースファイルをバイトコードにコンパイルすることは、通常、プロダクションイメージにとって望ましいです。これは、起動時間を改善する傾向があるためです（インストール時間が増加するコストを伴います）。
To enable bytecode compilation, use the --compile-bytecode flag:バイトコードコンパイルを有効にするには、--compile-bytecodeフラグを使用します。
Alternatively, you can set the UV_COMPILE_BYTECODE environment variable to ensure that all
commands within the Dockerfile compile bytecode:または、UV_COMPILE_BYTECODE環境変数を設定して、Dockerfile内のすべてのコマンドがバイトコードをコンパイルするようにすることができます。
Cachingキャッシング
A cache mount can be used to improve performance across builds:キャッシュマウントを使用して、ビルド間のパフォーマンスを向上させることができます。
Changing the default UV_LINK_MODE silences warnings about
not being able to use hard links since the cache and sync target are on separate file systems.デフォルトのUV_LINK_MODEを変更すると、キャッシュと同期ターゲットが別々のファイルシステムにあるため、ハードリンクを使用できないという警告が抑制されます。
If you're not mounting the cache, image size can be reduced by using the --no-cache flag or
setting UV_NO_CACHE.キャッシュをマウントしていない場合、--no-cacheフラグを使用するか、UV_NO_CACHEを設定することで、イメージサイズを削減できます。
By default, managed Python installations are not cached before being installed. Setting
UV_PYTHON_CACHE_DIR can be used in combination with a cache mount:デフォルトでは、管理されたPythonインストールはインストール前にキャッシュされません。UV_PYTHON_CACHE_DIRを設定することで、キャッシュマウントと組み合わせて使用できます。
ENV UV_PYTHON_CACHE_DIR=/root/.cache/uv/python
RUN --mount=type=cache,target=/root/.cache/uv \
uv python install
Note注意
The cache directory's location can be determined by running the uv cache dir command in the
container.キャッシュディレクトリの場所は、コンテナ内でuv cache dirコマンドを実行することで確認できます。
Alternatively, the cache can be set to a constant location:また、キャッシュを一定の場所に設定することもできます。
Intermediate layers中間レイヤー
If you're using uv to manage your project, you can improve build times by moving your transitive
dependency installation into its own layer via the --no-install options.プロジェクトを管理するためにuvを使用している場合、--no-installオプションを使用して、遷移依存関係のインストールを独自のレイヤーに移動することでビルド時間を短縮できます。
uv sync --no-install-project will install the dependencies of the project but not the project
itself. Since the project changes frequently, but its dependencies are generally static, this can be
a big time saver.uv sync --no-install-projectはプロジェクトの依存関係をインストールしますが、プロジェクト自体はインストールしません。プロジェクトは頻繁に変更されますが、その依存関係は一般的に静的であるため、これは大きな時間の節約になります。
# Install uv
FROM python:3.12-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
# Change the working directory to the `app` directory
WORKDIR /app
# Install dependencies
RUN --mount=type=cache,target=/root/.cache/uv \
--mount=type=bind,source=uv.lock,target=uv.lock \
--mount=type=bind,source=pyproject.toml,target=pyproject.toml \
uv sync --locked --no-install-project
# Copy the project into the image
ADD . /app
# Sync the project
RUN --mount=type=cache,target=/root/.cache/uv \
uv sync --locked
Note that the pyproject.toml is required to identify the project root and name, but the project
contents are not copied into the image until the final uv sync command.pyproject.tomlはプロジェクトのルートと名前を特定するために必要ですが、プロジェクトの内容は最終的なuv syncコマンドまでイメージにコピーされません。
Tipヒント
If you want to remove additional, specific packages from the sync,
use --no-install-package <name>.同期から特定の追加パッケージを削除したい場合は、--no-install-package <name>を使用してください。
Intermediate layers in workspacesワークスペース内の中間レイヤー
If you're using a workspace, then a couple changes are needed:もしワークスペースを使用している場合、いくつかの変更が必要です：
- Use
--frozeninstead of--lockedduring the initially sync.--lockedの代わりに初回の同期中に--frozenを使用してください。 - Use the
--no-install-workspaceflag which excludes the project and any workspace members.--no-install-workspaceフラグを使用すると、プロジェクトおよびワークスペースメンバーを除外できます。
# Install uv
FROM python:3.12-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
WORKDIR /app
RUN --mount=type=cache,target=/root/.cache/uv \
--mount=type=bind,source=uv.lock,target=uv.lock \
--mount=type=bind,source=pyproject.toml,target=pyproject.toml \
uv sync --frozen --no-install-workspace
ADD . /app
RUN --mount=type=cache,target=/root/.cache/uv \
uv sync --locked
uv cannot assert that the uv.lock file is up-to-date without each of the workspace member
pyproject.toml files, so we use --frozen instead of --locked to skip the check during the
initial sync. The next sync, after all the workspace members have been copied, can still use
--locked and will validate that the lockfile is correct for all workspace members.uvは、各ワークスペースメンバーのpyproject.tomlファイルがないとuv.lockファイルが最新であると主張できないため、初回の同期中にチェックをスキップするために--lockedの代わりに--frozenを使用します。すべてのワークスペースメンバーがコピーされた後の次回の同期では、--lockedを使用して、すべてのワークスペースメンバーに対してロックファイルが正しいことを検証できます。
Non-editable installs非編集可能なインストール
By default, uv installs projects and workspace members in editable mode, such that changes to the source code are immediately reflected in the environment.デフォルトでは、uvはプロジェクトとワークスペースメンバーを編集可能モードでインストールし、ソースコードの変更が環境に即座に反映されます。
uv sync and uv run both accept a --no-editable flag, which instructs uv to install the project
in non-editable mode, removing any dependency on the source code.uv syncとuv runはどちらも--no-editableフラグを受け入れ、uvにプロジェクトを非編集可能モードでインストールさせ、ソースコードへの依存関係を取り除きます。
In the context of a multi-stage Docker image, --no-editable can be used to include the project in
the synced virtual environment from one stage, then copy the virtual environment alone (and not the
source code) into the final image.マルチステージDockerイメージのコンテキストでは、--no-editableを使用して、あるステージから同期された仮想環境にプロジェクトを含め、その後ソースコードではなく仮想環境のみを最終イメージにコピーできます。
For example:例えば:
# Install uv
FROM python:3.12-slim AS builder
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
# Change the working directory to the `app` directory
WORKDIR /app
# Install dependencies
RUN --mount=type=cache,target=/root/.cache/uv \
--mount=type=bind,source=uv.lock,target=uv.lock \
--mount=type=bind,source=pyproject.toml,target=pyproject.toml \
uv sync --locked --no-install-project --no-editable
# Copy the project into the intermediate image
ADD . /app
# Sync the project
RUN --mount=type=cache,target=/root/.cache/uv \
uv sync --locked --no-editable
FROM python:3.12-slim
# Copy the environment, but not the source code
COPY --from=builder --chown=app:app /app/.venv /app/.venv
# Run the application
CMD ["/app/.venv/bin/hello"]
Using uv temporarilyuvを一時的に使用する
If uv isn't needed in the final image, the binary can be mounted in each invocation:最終イメージでuvが必要ない場合、各呼び出しでバイナリをマウントできます：
Using the pip interfacepipインターフェースの使用
Installing a packageパッケージのインストール
The system Python environment is safe to use this context, since a container is already isolated.
The --system flag can be used to install in the system environment:システムPython環境はこのコンテキストで安全に使用できます。すでにコンテナが隔離されているためです。
--systemフラグを使用してシステム環境にインストールできます:
To use the system Python environment by default, set the UV_SYSTEM_PYTHON variable:デフォルトでシステムPython環境を使用するには、UV_SYSTEM_PYTHON変数を設定します:
Alternatively, a virtual environment can be created and activated:または、仮想環境を作成してアクティブ化することもできます:
RUN uv venv /opt/venv
# Use the virtual environment automatically
ENV VIRTUAL_ENV=/opt/venv
# Place entry points in the environment at the front of the path
ENV PATH="/opt/venv/bin:$PATH"
When using a virtual environment, the --system flag should be omitted from uv invocations:仮想環境を使用する場合、uvの呼び出しから--systemフラグは省略するべきです:
Installing requirements依存関係のインストール
To install requirements files, copy them into the container:依存関係ファイルをインストールするには、それらをコンテナにコピーします:
Installing a projectプロジェクトのインストール
When installing a project alongside requirements, it is best practice to separate copying the requirements from the rest of the source code. This allows the dependencies of the project (which do not change often) to be cached separately from the project itself (which changes very frequently).依存関係と一緒にプロジェクトをインストールする際は、依存関係のコピーをソースコードの残りの部分から分けることがベストプラクティスです。これにより、プロジェクトの依存関係（あまり変更されないもの）をプロジェクト自体（非常に頻繁に変更されるもの）から別にキャッシュできます。
COPY pyproject.toml .
RUN uv pip install -r pyproject.toml
COPY . .
RUN uv pip install -e .
Verifying image provenance画像の出所の確認
The Docker images are signed during the build process to provide proof of their origin. These attestations can be used to verify that an image was produced from an official channel.Dockerイメージは、その起源を証明するためにビルドプロセス中に署名されます。これらの 証明書は、イメージが公式のチャネルから生成されたことを確認するために使用できます。
For example, you can verify the attestations with the
GitHub CLI tool gh:例えば、GitHub CLIツール ghを使用して証明書を確認できます：
$ gh attestation verify --owner astral-sh oci://ghcr.io/astral-sh/uv:latest
Loaded digest sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx for oci://ghcr.io/astral-sh/uv:latest
Loaded 1 attestation from GitHub API
The following policy criteria will be enforced:
- OIDC Issuer must match:................... https://token.actions.githubusercontent.com
- Source Repository Owner URI must match:... https://github.com/astral-sh
- Predicate type must match:................ https://slsa.dev/provenance/v1
- Subject Alternative Name must match regex: (?i)^https://github.com/astral-sh/
✓ Verification succeeded!
sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx was attested by:
REPO PREDICATE_TYPE WORKFLOW
astral-sh/uv https://slsa.dev/provenance/v1 .github/workflows/build-docker.yml@refs/heads/main
This tells you that the specific Docker image was built by the official uv GitHub release workflow and hasn't been tampered with since.これにより、特定のDockerイメージが公式のuv GitHubリリースワークフローによってビルドされ、以降は改ざんされていないことがわかります。
GitHub attestations build on the sigstore.dev infrastructure. As such
you can also use the cosign command to verify the
attestation blob against the (multi-platform) manifest for uv:GitHubの証明書は、sigstore.devインフラストラクチャに基づいています。そのため、cosignコマンドを使用して、
証明書のバイナリをuvの（マルチプラットフォーム）マニフェストと照合することもできます：
$ REPO=astral-sh/uv
$ gh attestation download --repo $REPO oci://ghcr.io/${REPO}:latest
Wrote attestations to file sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jsonl.
Any previous content has been overwritten
The trusted metadata is now available at sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jsonl
$ docker buildx imagetools inspect ghcr.io/${REPO}:latest --format "{{json .Manifest}}" > manifest.json
$ cosign verify-blob-attestation \
--new-bundle-format \
--bundle "$(jq -r .digest manifest.json).jsonl" \
--certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
--certificate-identity-regexp="^https://github\.com/${REPO}/.*" \
<(jq -j '.|del(.digest,.size)' manifest.json)
Verified OK
Tipヒント
These examples use latest, but best practice is to verify the attestation for a specific
version tag, e.g., ghcr.io/astral-sh/uv:0.9.13, or (even better) the specific image digest,
such as ghcr.io/astral-sh/uv:0.5.27@sha256:5adf09a5a526f380237408032a9308000d14d5947eafa687ad6c6a2476787b4f.これらの例ではlatestを使用していますが、ベストプラクティスは特定の
バージョンタッグ、例えばghcr.io/astral-sh/uv:0.9.13、または（さらに良いことに）特定のイメージダイジェスト、
例えばghcr.io/astral-sh/uv:0.5.27@sha256:5adf09a5a526f380237408032a9308000d14d5947eafa687ad6c6a2476787b4fの証明書を確認することです。