도커로 구축

소개

클라이언트 엔지니어, 임베디드 시스템 엔지니어 및 백엔드로 작업한 적이 없는 기타 엔지니어는 여전히 컨테이너를 사용하여 상당한 이점을 얻을 수 있습니다. 이 기사에서는 make 및 docker가 설치된 모든 시스템에서 빌드할 수 있도록 거의 모든 사이드 프로젝트를 구성하는 방법을 공유하고 싶습니다.

동기 부여

환경 보장. 여러 기여자와 CI(지속적인 통합 서버)는 정확히 동일한 환경에서 빌드하고 있다고 확신할 수 있습니다.

환경 버전 관리. 모든 팀원이 로컬에서 빌더 이미지를 빌드할 필요가 없습니다. Docker Registry를 사용하여 이미지를 저장하고 버전을 지정할 수 있습니다.

간편한 워크스테이션/빌드 에이전트 설정. 위에서 언급했듯이 이러한 프로젝트를 빌드하는 데 필요한 유일한 도구는 make 및 docker 입니다.
Make는 여기서 프로젝트 빌드 시스템으로 사용되지 않고 오히려 긴 docker 명령을 래핑하는 편리한 도구로 사용됩니다. 이 기사의 범위에서는 $(ROOT_DIR)/main 빌드 시스템을 사용하여 cargo에 위치한 Rust 프로젝트를 가정합니다.

리눅스 대상

간단하게 시작합시다. Docker는 항상 Linux이므로 대상 플랫폼을 구축하는 가장 쉬운 방법은 Linux입니다. 이는 또한 Linux 또는 플랫폼 독립적인 애플리케이션을 작성하는 경우 단위 테스트에 완벽하게 작동합니다.


메이크파일

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main

IMAGE_BUILDER_LINUX := rust:1.61.0

build_linux: builder_linux
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_LINUX) \
    sh -c 'cd /src && cargo build'

test_linux: builder_linux
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_TESTER_LINUX) \
    sh -c 'cd /src && cargo test'

builder_linux:
    @docker pull $(IMAGE_BUILDER_LINUX)

이제 간단한 make build_linux 및 make test_linux는 다음을 수행해야 합니다.

빌더 Docker 이미지를 가져왔는지 확인합니다

.

이미지를 사용하여 빌드/테스트 실행

커스텀 빌더

결국에는 빌더 이미지를 사용자 지정해야 할 가능성이 큽니다. 이는 위에서 한 것처럼 이미지를 가져오는 대신 Dockerfile를 생성하고 이를 사용하여 이미지를 빌드하는 것을 의미합니다.
Dockerfile가 $(ROOT_DIR)/image/x에 있다고 가정합니다.


메이크파일

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main
PROJECT_NAME := $(shell basename $(ROOT_DIR))

IMAGE_BUILDER_X := $(PROJECT_NAME)-builder-x

builder_x:
    @docker build -t $(IMAGE_BUILDER_X) $(ROOT_DIR)/image/x

웹어셈블리

이 기회를 이용하여 일부 스크립트를 공유하여 Rust 코드를 WebAssembly에 빌드하고 단위 테스트를 실행하겠습니다.


메이크파일

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main
PROJECT_NAME := $(shell basename $(ROOT_DIR))

RUST_TARGET_WEB := wasm32-unknown-unknown

IMAGE_BUILDER_WEB := $(PROJECT_NAME)-builder-web

build_web: builder_web
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_WEB) \
    sh -c 'cd /src && cargo build --target $(RUST_TARGET_WEB)'

test_web: builder_web
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_WEB) \
    sh -c 'cd /src && CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER=wasmtime_test_runner.sh cargo test --target $(RUST_TARGET_WEB)'

builder_web:
    @docker build -t $(IMAGE_BUILDER_WEB) $(ROOT_DIR)/image/web

이미지/웹/Dockerfile

FROM rust:1.61.0

RUN \
rustup toolchain install '1.61.0-x86_64-unknown-linux-gnu' \
--target 'wasm32-unknown-unknown' \
--component 'rust-std'

RUN curl https://wasmtime.dev/install.sh -sSf | bash

COPY wasmtime_test_runner.sh /usr/bin

VOLUME ["/usr/local/cargo/registry"]

이미지/웹/wasmtime_test_runner.sh

#!/bin/sh

/root/.wasmtime/bin/wasmtime "$@" --invoke main 0 0

rustup에는 다운로드할 준비가 된 wasm32 툴체인이 있기 때문에 Rust에서는 비교적 쉽습니다.

생각

필요한 빌드 설정이 복잡할수록 Docker 기반 빌드를 살펴보는 것이 좋습니다. 특히 일부 사용자 수정이 필요할 수 있는 특정 도구 체인을 사용할 때 여러 교차 컴파일러가 필요한 프로젝트를 빌드하도록 워크스테이션을 설정하려면 최대 수백 개의 bash 명령이 필요할 수 있습니다. 이론적으로 컨테이너 없이 bash 스크립트로 수행할 수 있지만 다음을 포함하여 얼마나 많은 주의 사항이 있습니다.

스크립트를 실행하기 전에 상태 0이 동일해야 함

워크스테이션 간에 동일하게 유지하면서 빌드 설정 업데이트

환경 보증 없음

빌드 설정 버전 간 전환 없음