This PR rewords the instructions for using uv in a container. I'm a new
user and was somewhat confused by it, so I've rewritten it as I'd have
liked to have read it.
It makes it more clear what distroless means, to avoid confusion with
other projects that ship OS files with an image with its tag name clear
of qualifiers(`astral-sh/uv`, in this case). An example of that is
caddy, which ships with alpine.
This also modifies the original example to use a distroful image instead
of distroless one while #8635 doesn't get resolved.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
As requested in https://github.com/astral-sh/uv/issues/6565, this adds a
tip discussing the ability to pin the image to a specific SHA digest and
why it may be useful.
## Test Plan
<!-- How was it tested? -->
Start serving the documentation locally
```shell
uvx --with-requirements docs/requirements.txt -- mkdocs serve -f mkdocs.public.yml
```
Then navigate to http://127.0.0.1:8000/uv/guides/integration/docker/ to
see the tool tip being rendered properly
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
- Adds a collapsible section for the project concept
- Splits the project concept document into several child documents.
- Moves the workspace and dependencies documents to under the project
section
- Adds a mkdocs plugin for redirects, so links to the moved documents
still work
I attempted to make the minimum required changes to the contents of the
documents here. There is a lot of room for improvement on the content of
each new child document. For review purposes, I want to do that work
separately. I'd prefer if the review focused on this structure and idea
rather than the content of the files.
I expect to do this to other documentation pages that would otherwise be
very nested.
The project concept landing page and nav (collapsed by default) looks
like this now:
<img width="1507" alt="Screenshot 2024-11-14 at 11 28 45 AM"
src="https://github.com/user-attachments/assets/88288b09-8463-49d4-84ba-ee27144b62a5">
## Summary
It was all too easy to just copy the non-qualified name of the Docker
images and wonder why they couldn't be found – well, because they're on
`ghcr.io`, and you need to read the prose before the list to figure that
out.
## Test Plan
No plan.
## Summary
Update the extended docker example to use bind mounts and avoid creating
extra layers and avoid copying files into layers
This is in line with the official Docker templates for Python
applications (you can try them out using `docker init`. I found them
very helpful!)
## Summary
Closes https://github.com/astral-sh/uv/issues/5610
This PR introduces additional images with the uv/uvx binaries from
scratch for both amd64/arm64 and make the mapping easy to configure by
generating the Dockerfile on the fly. This approach focuses on
minimizing CI time by taking advantage of dedicating a worker per
mapping (20-30s~ per job).
This PR also fixes `org.opencontainers.image.version` for all tags
(including the one from `scratch) to contain the right release version
instead of branch name `main` (default when no tag patterns are
specified).
For example, on release `x.y.z`, this will publish the following image
tags with format `ghcr.io/astral-sh/uv:{tag}` with manifests for both
amd64/arm64. This also include `x.y` tags for each respective additional
tag.
* From **scratch**: `latest`, `x.y.z`, `x.y` (currently being published)
* From **alpine:3.20**: `alpine`, `alpine3.20`, `x.y.z-alpine`,
`x.y.z-alpine3.20`
* From **debian:bookworm-slim**: `debian-slim`, `bookworm-slim`,
`x.y.z-debian-slim`, `x.y.z-bookworm-slim`
* From **buildpack-deps:bookworm**: `debian`, `bookworm`,
`x.y.z-debian`, `x.y.z-bookworm`
* From **python:3.12-alpine**: `python3.12-alpine`,
`x.y.z-python3.12-alpine`
* From **python:3.11-alpine**: `python3.11-alpine`,
`x.y.z-python3.11-alpine`
* From **python:3.10-alpine**: `python3.10-alpine`,
`x.y.z-python3.10-alpine`
* From **python:3.9-alpine**: `python3.9-alpine`,
`x.y.z-python3.9-alpine`
* From **python:3.8-alpine**: `python3.8-alpine`,
`x.y.z-python3.8-alpine`
* From **python:3.12-bookworm**: `python3.12-bookworm`,
`x.y.z-python3.12-bookworm`
* From **python:3.11-bookworm**: `python3.11-bookworm`,
`x.y.z-python3.11-bookworm`
* From **python:3.10-bookworm**: `python3.10-bookworm`,
`x.y.z-python3.10-bookworm`
* From **python:3.9-bookworm**: `python3.9-bookworm`,
`x.y.z-python3.9-bookworm`
* From **python:3.8-bookworm**: `python3.8-bookworm`,
`x.y.z-python3.8-bookworm`
* From **python:3.12-slim-bookworm**: `python3.12-slim-bookworm`,
`x.y.z-python3.12-slim-bookworm`
* From **python:3.11-slim-bookworm**: `python3.11-slim-bookworm`,
`x.y.z-python3.11-slim-bookworm`
* From **python:3.10-slim-bookworm**: `python3.10-slim-bookworm`,
`x.y.z-python3.10-slim-bookworm`
* From **python:3.9-slim-bookworm**: `python3.9-slim-bookworm`,
`x.y.z-python3.9-slim-bookworm`
* From **python:3.8-slim-bookworm**: `python3.8-slim-bookworm`,
`x.y.z-python3.8-slim-bookworm`
When not using a python base image and using alpine, you need to install
python by yourself. You should also pin the python version when doing
so; currently, i see only python 3.12 in the alpine repository.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
The following Dockerfile command fails:
```
[...]
RUN --mount=from=uv,source=/uv,target=/bin/uv \
cd /opt/opencti-connector-webhook && \
uv pip install --system -r requirements.txt && \
apk del git build-base
[...]
```
Result
```
yo@opencti:~/connectors/stream/webhook$ docker build -t opencti/connector-webhook:d .
[+] Building 1.0s (3/3) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 557B 0.1s
=> ERROR [internal] load metadata for docker.io/library/uv:latest 0.8s
=> [internal] load metadata for docker.io/library/python:3.11-alpine 0.8s
------
> [internal] load metadata for docker.io/library/uv:latest:
------
ERROR: failed to solve: uv: failed to resolve source metadata for docker.io/library/uv:latest: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
```
Fix:
```
[...]
RUN --mount=from=ghcr.io/astral-sh/uv,source=/uv,target=/bin/uv \
cd /opt/opencti-connector-webhook && \
uv pip install --system -r requirements.txt && \
apk del git build-base
[...]
```
## Test Plan
<!-- How was it tested? -->
```
$ docker --version
Docker version 26.0.0, build 2ae903e
$ date
Mon Aug 26 20:31:53 UTC 2024
$ docker build -t opencti/connector-webhook:e .
[+] Building 41.8s (13/13) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 587B 0.0s
=> [internal] load metadata for ghcr.io/astral-sh/uv:latest 0.5s
=> [internal] load metadata for docker.io/library/python:3.11-alpine 0.5s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [stage-0 1/6] FROM docker.io/library/python:3.11-alpine@sha256:700b4aa84090748aafb348fc042b5970abb0a73c8f1b4fcfe0f4e3c2a4a9fcca 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 130B 0.0s
=> CACHED FROM ghcr.io/astral-sh/uv:latest@sha256:f6b18f4a7408c5244374b00c8832089258d130f7a77a38807348072e714ffa0c 0.0s
=> CACHED [stage-0 2/6] COPY src /opt/opencti-connector-webhook 0.0s
=> CACHED [stage-0 3/6] RUN apk --no-cache add git build-base libmagic libffi-dev libxml2-dev libxslt-dev 0.0s
=> [stage-0 4/6] RUN --mount=from=ghcr.io/astral-sh/uv,source=/uv,target=/bin/uv cd /opt/opencti-connector-webhook && uv pip install --system -r requirements.txt 38.3s
=> [stage-0 5/6] COPY entrypoint.sh / 0.1s
=> [stage-0 6/6] RUN chmod +x /entrypoint.sh 0.8s
=> exporting to image 1.7s
=> => exporting layers 1.6s
=> => writing image sha256:aa6810f883d104c838f35e848c0d7d8b4df5c7c3929f18a88b7139d0ec892a0b 0.0s
=> => naming to docker.io/opencti/connector-webhook:e 0.0s
```
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Updated docs dockerfile from Debian 11 (bullseye) to latest stable
Debian 12 (bookworm).
## Test Plan
<!-- How was it tested? -->
A dockerfile using `ubuntu` instead of `python` as base image currently
silently fails to install.
```dockerfile
FROM ubuntu
RUN apt-get update && apt-get install -y curl --no-install-recommends
RUN curl -LsSf https://astral.sh/uv/install.sh | sh
RUN uv --version
```
```console
$ docker buildx build --progress plain --no-cache .
[...]
#6 [3/4] RUN curl -LsSf https://astral.sh/uv/install.sh | sh
#6 0.144 curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
#6 DONE 0.2s
#7 [4/4] RUN uv --version
#7 0.113 /bin/sh: 1: uv: not found
#7 ERROR: process "/bin/sh -c uv --version" did not complete successfully: exit code: 127
```
There's two underlying problems: Pipefail, and missing
`ca-certificates`.
In most shells, the source of a pipe erroring doesn't fail the entire
command, so `curl -LsSf https://astral.sh/uv/install.sh | sh` passes
even if the curl part fails. In bash, you can prefix the command with
`set -o pipefail &&` to change this behavior. But in the `ubuntu` docker
container, dash is the default shell, not bash. dash doesn't have a
pipefail option (in the version in ubuntu), so the [best
practice](https://docs.docker.com/build/building/best-practices/#using-pipes)
is `RUN ["/bin/bash", "-c", "set -o pipefail && curl -LsSf
https://astral.sh/uv/install.sh | sh"]`. That's not very readable, so
i'm going for `RUN curl -LsSf https://astral.sh/uv/install.sh >
/tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm
/tmp/uv-installer.sh` instead.
```dockerfile
FROM ubuntu
RUN apt-get update && apt-get install -y curl --no-install-recommends
RUN curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh \
RUN uv --version
```
```console
$ docker buildx build --progress plain --no-cache .
[...]
#6 [3/3] RUN curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh RUN uv --version
#6 0.179 curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
#6 ERROR: process "/bin/sh -c curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh RUN uv --version" did not complete successfully: exit code: 77
```
The source for this error is `ca-certificates` missing, which is a
recommended package. We need to drop `--no-install-recommends` and the
installation passes again.
Zanie Blue
Charlie Marsh
Martijn Pieters
Danilo Rezende
Ryan
Aditya Pratap Singh
samypr100
Aarni Koskela
David Bern
Ed Morley
konsti
2*yo
Altaher Emhemed