Почему в Docker собирается не тот Rust?

Question

[Eugene Usachev]

Вопрос звучит странно, но я даже не способен по-другому это описать. Я решил протестировать, как мой проект работает на других платформах, для этого я использовал Docker. Я изучаю Rust относительно недолго, так что воспользовался помощью гугла для написания Dockerfile.

Dockerfile

FROM rust:latest as build

RUN USER=root cargo new --bin test-tcp
WORKDIR /test-tcp

COPY ./Cargo.lock ./Cargo.lock
COPY ./Cargo.toml ./Cargo.toml

RUN cargo build --release
RUN rm src/*.rs

COPY ./src ./src

# Build for release.
RUN cargo build --release

FROM debian:buster-slim

COPY --from=build /test-tcp/target/release/test-tcp /usr/src/test-tcp

CMD ["/usr/src/test-tcp"]

Cargo.toml

[package]
name = "test-tcp"
version = "0.1.0"
edition = "2021"

[dependencies]
tokio = { version = "1.29.1", features = ["full"] }
mio = "0.8.8"
net2 = "0.2.39"
ahash = "0.8.3"

Дальше я пробую запустить проект. Структура проекта (примерная, можете спросить больше в комментариях)

bench2
--src
----main.rs
--Cargo.toml
--Cargo.lock
--Dockerfile

Теперь самое интересное. Если я запускаю свой код через терминал, как обычно, я вижу нужный результат (старт бенчмарков). Однако когда я пробую запустить Dockerfile, я вижу сборку и совершенно неожиданный результат в консоле

Hello, world!

Я проверил через поиск по проекту и у меня в проекте нигде нет этой строки! Что я сделал не так?

Comments

[mayton2019]

Покажи всю командную строку как запускаешь.

[Eugene Usachev]

mayton2019, C:/Users/Eugene/.cargo/bin/cargo.exe run --color=always --package test-tcp --bin test-tcp

[mayton2019]

Eugene-Usachev, я не про это. Ты запускаешь старый образ docker и видишь старую версию софта.

[Eugene Usachev]

mayton2019, Я около 10 раз пересобрал Docker, в том числе с нуля. Собираю я обычно с помощью IDE, но даже через

docker build -t bench2_linux .
docker run bench2_linux

результат лишь

Hello, world!

[mayton2019]

Тут какая-то путаница.

Расскажи мне в какой последовательности у тебя идут действия.
- Запуск твоего бенмарка
- Сборка твоего кода
- Сборка образа докера.

[Eugene Usachev]

mayton2019, скорее всего, я неправильно понял ваш вопрос, но попытаюсь ответь. Я запускаю benchmark в один лишь Dockerfile, который представлен выше. Сборка коды происходит во время сборки образа докера и потом идёт запуск.

[mayton2019]

Сборка коды происходит во время сборки образа докера и потом идёт запуск.

Ты можешь доказать что сборка rust кода действительно происходит?

[Eugene Usachev]

mayton2019, Ваш вопрос вызвал у меня недоумение. Я даже не знаю, что думать. Я пересобирал с нуля Docker около 5 раз, так что я могу быть уверен, что Docker все разы вызывал код выше (образы я чистил, volumes пустые). Более того, уже с первой попытки я собирал код с бенчмарком, а не с Hello, world. Так что поведение очень странное.

[mayton2019]

Ага. Почистил образы? И это был фикс?

Answer 1

[Дмитрий Беляев]

FROM rust:latest as build

WORKDIR /test-tcp

COPY ./Cargo.lock ./Cargo.lock
COPY ./Cargo.toml ./Cargo.toml
COPY ./src ./src

RUN cargo build --release

FROM debian:buster-slim

COPY --from=build /test-tcp/target/release/test-tcp /usr/src/test-tcp

CMD ["/usr/src/test-tcp"]

Проблема в том, что в докере Вы создаете пустой проект из шаблона cargo
RUN USER=root cargo new --bin test-tcp
и компилируете его, потом копируете src
Да, там есть еще один билд после этого, но я попробовал собрать Ваш Dockerfile у себя, и получил на втором билде результат инкрементальной сборки без изменений. То есть cargo не увидел, что папка src поменялась.

Comments

[mayton2019]

Я-бы предложил не смешивать в одну кучу компилляцию rust приложения и сборку образа.
Тут должны быть разные steps. Типа такого

Makefile:

compile:
     cargo build --release
docker: compile
     docker build -t bench2_linux .
benchmark: docker
     docker run bench2_linux

[Eugene Usachev]

Дмитрий Беляев, ваше решение сработало, благодарю. Однако я хочу задать пару вопросов.

1 вопрос. Я до этого уже подозревал что-то подобное из этой строчки, так как в других Dockerfile никогда не использовал такую команду, но я ловил ошибку, если я её не использовал, с текстом:

Step 5/11 : RUN cargo build --release
 ---> Running in 1f144422e617
error: failed to parse manifest at `/test-tcp/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present
Error response from daemon: The command '/bin/sh -c cargo build --release' returned a non-zero code: 101
Failed to deploy '<unknown> Dockerfile: bench2/Dockerfile': Can't retrieve image ID from build stream

почему эта команда позволяла обойти ошибку?

2 вопрос. Почему с командами

RUN cargo build --release
RUN rm src/*.rs

возникает ошибка? Я предполагаю, что это из-за того, что я удаляю все rust файлы и дальше собирать нечего, однако я "дёрнул" этот код из вполне внушающей доверие статьи, я сомневаюсь, что автор бы допустил такую ошибку и в комментариях её не отметили бы.

[Дмитрий Беляев]

Eugene-Usachev, данная ошибка возникает, когда cargo не находит точку входа в crate
Так как в Cargo.toml не описаны кастомные точки входа, он ищет стандартные src/lib.rs или src/main.rs, а когда их не находит, то не понимает что делать.
Вот он и пишет об этом, что нужен или один из стандартных файлов или описание в Cargo.toml где брать нестандартные.

[Дмитрий Беляев]

mayton2019, у него винда, crate собранный под виндой в докере не запустится, ибо там будет linux.
Можно конечно через кросс-компиляцию собирать, но зачем, если создатели Rust сделали docker-image специально для целей сборки.

Answer 2

[Василий Банников]

Как уже выше сказали - cargo не увидел, что src поменялись и не стал собирать заново.
Определяет он, что файл изменился по дате изменения файла. Если дата изменения файла меньше либо равна дате компиляции, то повторной компиляции не будет.
Чтобы обновить дату изменения файла - достаточно сделать touch main.rs после первой сборки.
В docker появился docker init, который сам делает корректный dockerfile - так что в принципе уже и не нужно руками dockerfile писать.
Генерирует он примерно такое для компиляции (зачем так - описано в комментариях):

ARG RUST_VERSION=1.71.0
ARG APP_NAME=project
FROM rust:${RUST_VERSION}-slim-bullseye AS build
ARG APP_NAME
WORKDIR /app

# Build the application.
# Leverage a cache mount to /usr/local/cargo/registry/
# for downloaded dependencies and a cache mount to /app/target/ for
# compiled dependencies which will speed up subsequent builds.
# Leverage a bind mount to the src directory to avoid having to copy the
# source code into the container. Once built, copy the executable to an
# output directory before the cache mounted /app/target is unmounted.
RUN --mount=type=bind,source=src,target=src \
    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
    --mount=type=cache,target=/app/target/ \
    --mount=type=cache,target=/usr/local/cargo/registry/ \
    <<EOF
set -e
cargo build --locked --release
cp ./target/release/$APP_NAME /bin/server
EOF

Ещё можно попробовать написать так (этим пользовался я раньше):

# FROM, Установка rust и прочих зависимостей
# ...

RUN cargo new /app
COPY app/Cargo.toml /app/

# This step compiles only our dependencies and saves them in a layer. This is the most impactful time savings
# Note the use of --mount=type=cache. On subsequent runs, we'll have the crates already downloaded
WORKDIR /app
RUN --mount=type=cache,target=/usr/local/cargo/registry cargo build --release

COPY ./app /app

# touch нужен, чтобы изменить дату изменения файла
RUN --mount=type=cache,target=/usr/local/cargo/registry \
  set -e; \
  touch /app/src/main.rs; \
  cargo build --release;

Оба варианта позволяют активно использовать фичи кэширования в Docker, чтобы не выкачивать все зависимости и не перекомпилировать их при каждой сборке образа.