Упаковать самосбор в docker

Зависит от того, для чего ты собираешь, если контейнер в прод, то можно собирать все в докере, в конце докерфайла можно удалить папку с исходниками, чтобы образ получился меньшего размера

Если это не для пакетирования готового приложения, а для локальной разработки, то удобнеее собрать базовый образ с зависимостями, в него монтировать папку с исходниками и потом внутри докера деать make и можно запускать прогу даже не исталлируя

В итоге должен получиться контейнер/образ, который можно вообще не включая мозг подтянуть из гита и запустить одной командой на произвольной машине. «Разработки» как таковой нет и обновлений тоже.

ОК, буду пробовать внутри докера всё собрать и подчистить лишний мусор.

Собирать всё внутри докера с дебианом изначально?

Судя по этому вопросу, этот вариант не нравится тем, что хочется иметь минимальный контейнер для запуска в проде безо всяких билд-тайм зависимостей и прочего ненужного хлама. Если так, то перфекционистский вариант — опакетить сборку всех компонентов и доустановить собранные пакеты в минимальную целевую систему, например, в докер-контейнер с Alpine Linux

О, это прям вообще красиво. Обязательно попробую.

В таком варианте и без докера можно обойтись, например, у меня на прошлой работе собирали для софта rpm-пакеты и накатывали их puppet’ом на рабочие сервера. Но тут уже как кому удобнее в развёртывании.

Как вообще принято грамотно такие вещи заворачивать в докер?

Ну типа такого, там делается Dockerfile в котором 2 контейнера, первый содержит все инструменты для сборки и делает бинарники, готовые бинарники копирует во второй, куда доставляешь зависимости если требуется. итого у тебя готовый контейнер с софтиной без лишнего барахла (которое для сборки нужно).

Вот первый попавшийся пример из сети:

FROM eclipse-temurin:17-jdk-alpine as builder
WORKDIR /opt/app
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline
COPY ./src ./src
RUN ./mvnw clean install

FROM eclipse-temurin:17-jre-alpine
WORKDIR /opt/app
COPY --from=builder /opt/app/target/*.jar /opt/app/*.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/opt/app/*.jar"]

Ну как бы ты это делал без докера, так же делай и с докером.

в конце докерфайла можно удалить папку с исходниками, чтобы образ получился меньшего размера

Только если удалить в том же слое, в котором файлы добавлены. Иначе останутся и размер не уменьшится.

Тут нужна multistage сборка. В одном stage dev окружение, в котором собирается приложение. В другом stage минимальное продовое окружение только для работы приложения, без dev пакетов, в которое копируются файлы из первого.

Только если удалить в том же слое, в котором файлы добавлены. Иначе останутся и размер не уменьшится.

Всегда можно в конце сделать так:

FROM scratch
COPY --from=build / /

Полезно, когда наследуешься от большого удаленного образа, или хочешь избавиться от пачки слоев. К топику почти не относится

Оно нормально отработает симлинки, права и прочую метаинформацию?

Вообще для этого multi-stage сборки делаются. Тебе Kolins правильно написал, в первом контейнере делаешь среду сборки, подтягиваешь зависимости и т.п. Во второй копируешь только результат сборки, в любимый образ. Потом первый выкидываешь, а второй кладешь в registry, что бы из него запускаться.

Я такое на собеседование в astra linux делал, но посоны не поняли, сказали ересь, у них chroot был в фаворе… В общем не сложилось у нас.

Оно нормально отработает симлинки, права и прочую метаинформацию?

да, попробуй