CI: Multi-arch images #145

New issue

Closed

opened 2021-09-02 13:20:47 +00:00 by jfowl · 6 comments

jfowl commented

2021-09-02 13:20:47 +00:00

(Migrated from gitlab.com)

I have two possible routes in mind for publishing docker images for multiple archs via the CI:

Doing it the "proper" way: Using docker buildx, building Conduit in docker, which requires quemu. Should be available on the famedly runners, but probably not on forks. Could be handled by gating it behind a "CAN_USE_QUEMU" env.
Doing it the "cheap" way: Taking the cross-compile build artifacts from other ci stages and putting them into a already-existing container for that arch. I was thinking of using curlimages/curl for that, which should contain all runtime dependencies for Conduit. Would be fast, because it would just copy already built binaries, but also result in separate tags for separate arches (e.g. conduit:latest-x86, conduit:latest-arch64, ...). Also unconventional.

Part of #103

I have two possible routes in mind for publishing docker images for multiple archs via the CI: - Doing it the "proper" way: Using `docker buildx`, building Conduit in docker, which requires quemu. Should be available on the famedly runners, but probably not on forks. Could be handled by gating it behind a "CAN_USE_QUEMU" env. - Doing it the "cheap" way: Taking the cross-compile build artifacts from other ci stages and putting them into a already-existing container for that arch. I was thinking of using [`curlimages/curl`](https://hub.docker.com/r/curlimages/curl) for that, which should contain all runtime dependencies for Conduit. Would be fast, because it would just copy already built binaries, but also result in separate tags for separate arches (e.g. `conduit:latest-x86`, `conduit:latest-arch64`, ...). Also unconventional. ---------- Part of #103

jfowl commented

2021-09-02 13:36:51 +00:00

(Migrated from gitlab.com)

@Weasy would you have any objections if we would remove the

# Build it from the copied local files or from the official git repository
RUN if [[ $LOCAL == "true" ]]; then \
        mv ./docker/healthcheck.sh . ; \
        echo "Building from local source..." ; \
        cargo install --path . ; \
    else \
        echo "Building revision '${GIT_REF}' from online source..." ; \
        cargo install --git "https://gitlab.com/famedly/conduit.git" --rev ${GIT_REF} ; \
        echo "Loadings healthcheck script from online source..." ; \
        wget "https://gitlab.com/famedly/conduit/-/raw/${GIT_REF#origin/}/docker/healthcheck.sh" ; \
    fi

part from the dockerfile?

So that to build conduit with docker yourself, you should always do

git clone https://gitlab.com/famedly/conduit.git
cd conduit
docker build .

While this is kinda nifty to build up to date versions, it also adds a bit of confusion.
And if you got the dockerfile, you probably have the git cloned anyway.

@Weasy would you have any objections if we would remove the ```dockerfile # Build it from the copied local files or from the official git repository RUN if [[ $LOCAL == "true" ]]; then \ mv ./docker/healthcheck.sh . ; \ echo "Building from local source..." ; \ cargo install --path . ; \ else \ echo "Building revision '${GIT_REF}' from online source..." ; \ cargo install --git "https://gitlab.com/famedly/conduit.git" --rev ${GIT_REF} ; \ echo "Loadings healthcheck script from online source..." ; \ wget "https://gitlab.com/famedly/conduit/-/raw/${GIT_REF#origin/}/docker/healthcheck.sh" ; \ fi ``` part from the dockerfile? So that to build conduit with docker yourself, you should always do ```bash git clone https://gitlab.com/famedly/conduit.git cd conduit docker build . ``` While this is kinda nifty to build up to date versions, it also adds a bit of confusion. And if you got the dockerfile, you probably have the git cloned anyway.

Weasy commented

2021-09-02 16:04:33 +00:00

(Migrated from gitlab.com)

No, is ok for me. It was practical for building the image on a server without git. It would then even be better, if we change cargo install into what vaultwarden is doing

# Build time options to avoid dpkg warnings and help with reproducible builds.
ENV DEBIAN_FRONTEND=noninteractive LANG=C.UTF-8 TZ=UTC TERM=xterm-256color

# Don't download rust docs
RUN rustup set profile minimal

ENV USER "root"
ENV RUSTFLAGS='-C link-arg=-s'

# Creates a dummy project used to grab dependencies
RUN USER=root cargo new --bin /app
WORKDIR /app

# Copies over *only* your manifests and build files
COPY ./Cargo.* ./
COPY ./rust-toolchain ./rust-toolchain
COPY ./build.rs ./build.rs

RUN rustup target add x86_64-unknown-linux-musl

ARG FEATURES=conduit_bin,backend_sqlite

# Builds your dependencies and removes the
# dummy project, except the target folder
# This folder contains the compiled dependencies
RUN cargo build --features ${FEATURES} --release --target=x86_64-unknown-linux-musl \
    && find . -not -path "./target*" -delete

# Copies the complete project
# To avoid copying unneeded files, use .dockerignore
COPY . .

# Make sure that we actually build the project
RUN touch src/main.rs

# Builds again, this time it'll just be
# your actual source files being built
RUN cargo build --features ${FEATURES} --release --target=x86_64-unknown-linux-musl

Don't know if cargo build is better for multi-arch images than cargo install, but i think we should add the FEATURES arg in any case.

No, is ok for me. It was practical for building the image on a server without git. It would then even be better, if we change `cargo install` into what [`vaultwarden`](https://github.com/dani-garcia/vaultwarden/blob/main/docker/amd64/Dockerfile.alpine) is doing ```dockerfile # Build time options to avoid dpkg warnings and help with reproducible builds. ENV DEBIAN_FRONTEND=noninteractive LANG=C.UTF-8 TZ=UTC TERM=xterm-256color # Don't download rust docs RUN rustup set profile minimal ENV USER "root" ENV RUSTFLAGS='-C link-arg=-s' # Creates a dummy project used to grab dependencies RUN USER=root cargo new --bin /app WORKDIR /app # Copies over *only* your manifests and build files COPY ./Cargo.* ./ COPY ./rust-toolchain ./rust-toolchain COPY ./build.rs ./build.rs RUN rustup target add x86_64-unknown-linux-musl ARG FEATURES=conduit_bin,backend_sqlite # Builds your dependencies and removes the # dummy project, except the target folder # This folder contains the compiled dependencies RUN cargo build --features ${FEATURES} --release --target=x86_64-unknown-linux-musl \ && find . -not -path "./target*" -delete # Copies the complete project # To avoid copying unneeded files, use .dockerignore COPY . . # Make sure that we actually build the project RUN touch src/main.rs # Builds again, this time it'll just be # your actual source files being built RUN cargo build --features ${FEATURES} --release --target=x86_64-unknown-linux-musl ``` Don't know if `cargo build` is better for multi-arch images than `cargo install`, but i think we should add the `FEATURES` arg in any case.

jfowl commented

2021-10-29 19:53:54 +00:00

(Migrated from gitlab.com)

How to use cross in gitlab ci:

How to use cross in gitlab ci: - https://github.com/rust-embedded/cross/issues/273#issuecomment-528300479 - https://github.com/rust-embedded/cross/issues/513

jfowl commented

2021-11-09 16:32:29 +00:00

(Migrated from gitlab.com)

Maybe test with this: https://gitlab.com/TobiP64/rust-gitlab-ci