official images
1.0.0
Docker 공식 이미지는 Docker Hub에서 호스팅되는 선별된 이미지입니다. 주요 원칙은 다음과 같습니다.
무료 및 오픈 소스 소프트웨어에 중점
다양한 아키텍처 지원
Dockerfile 모범 사례 예시
업데이트 및 보안 수정을 위해 적극적으로 재구축
업스트림 권장사항 준수
적합한 컨테이너 환경에 대해 최소한의 삶의 질 동작을 추가합니다.
프로그램에 대한 높은 수준의 개요는 Docker 설명서를 참조하세요.
본질적으로 우리는 소프트웨어 사용 방법에 대한 업스트림의 권장 사항에 귀를 기울이려고 노력합니다. 많은 이미지는 해당 업스트림 프로젝트에서 직접 유지 관리하지 않는 경우 해당 업스트림 프로젝트와 공동으로 유지 관리됩니다. 또한 우리는 Dockerfile에서 자신만의 이미지를 만들거나 파생할 때 참조로 사용할 수 있는 모범 사례를 예시하는 것을 목표로 합니다.
(이미지가 존재하는 업스트림의 대표이고 참여하고 싶다면 아래 유지 관리 섹션을 참조하세요!)
일부 이미지는 다른 아키텍처용으로 포팅되었으며 이들 중 다수는 공식적으로 (다양한 수준으로) 지원됩니다.
arm32v6 ): https://hub.docker.com/u/arm32v6/arm32v7 ): https://hub.docker.com/u/arm32v7/arm64v8 ): https://hub.docker.com/u/arm64v8/amd64 ): https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ): https://hub.docker.com/u/arm32v5/ppc64le ): https://hub.docker.com/u/ppc64le/s390x ): https://hub.docker.com/u/s390x/mips64le ): https://hub.docker.com/u/mips64le/riscv64 ): https://hub.docker.com/u/riscv64/i386 ): https://hub.docker.com/u/i386/ 2017년 9월 12일 기준으로 이러한 다른 아키텍처는 "매니페스트 목록"(OCI 이미지 사양에서 "인덱스"라고도 함)을 통해 접두사가 없는 이미지 아래에 포함됩니다. 예를 들어 docker run hello-world 다음과 같습니다. 지원되는 모든 플랫폼에서 있는 그대로 실행됩니다.
이것이 어떻게 구축되는지 궁금하다면 https://doi-janky.infosiftr.net/job/multiarch/로 이동하여 빌드 스캐폴딩을 확인하세요.
공식 이미지에 더 많은 아키텍처를 추가하는 방법에 대한 권장 사항은 아래 다중 아키텍처 섹션을 참조하세요.
예! 우리는 다른 일반적인 질문(프로그램 및 관행에 관한)을 수집하는 전용 FAQ 저장소를 보유하고 있습니다.
Docker 공식 이미지 프로젝트에 관심을 가져주셔서 감사합니다! 우리는 이러한 지침을 가능한 한 간단하고 간단하게 만들기 위해 노력하고 있지만, 길을 잃었다면 주저하지 말고 Libera.Chat IRC 채널 #docker-library 에서 우리를 찾거나 여기에서 GitHub 문제를 생성하여 우리를 찾아보세요.
Docker Hub의 공식 리포지토리와 Docker 설명서의 Dockerfile 작성 모범 사례를 숙지하세요. 이는 공식 이미지 관리자가 수행하는 검토 프로세스의 기초가 됩니다. 검토 프로세스를 보다 원활하게 진행하려면 끌어오기 요청을 제출하기 전에 Dockerfile 이 여기에 언급된 모든 사항과 아래 사항을 준수하는지 확인하세요.
또한 이러한 이미지에 대한 허브 설명은 현재 docker-library/docs 저장소에 별도로 저장되어 있으며, README.md 파일에서 해당 이미지의 구조와 기여 방법에 대해 자세히 설명합니다. 여기에서 귀하의 이미지가 승인될 때까지 PR을 제출할 준비를 하십시오.
공식 이미지는 Docker를 처음 접하는 사용자를 위한 학습 도구이자 고급 사용자가 프로덕션 릴리스를 구축하기 위한 기본 이미지로 사용되기 때문에 제안된 각 Dockerfile 검토하여 품질 및 유지 관리 가능성에 대한 최소 표준을 충족하는지 확인합니다. 해당 표준 중 일부는 주관성으로 인해 정의하기 어렵지만 여기에는 가능한 한 많이 정의하고 적절한 경우 "모범 사례"를 준수합니다.
검토 중에 관리자가 사용할 수 있는 체크리스트는 NEW-IMAGE-CHECKLIST.md 에서 찾을 수 있습니다.
버전 범프 및 보안 수정 사항은 적시에 처리되어야 합니다.
업스트림을 대표하지 않고 업스트림이 이미지 유지 관리에 관심을 가지게 되면 이미지 유지 관리가 업스트림으로 원활하게 전환되도록 조치를 취해야 합니다.
기존 저장소의 유지 관리에 관심이 있는 업스트림의 경우 첫 번째 단계는 기존 저장소에 참여하는 것입니다. 문제에 대해 의견을 제시하고, 변경 사항을 제안하고, "이미지 커뮤니티" 내에서 자신을 알리는 것(해당 "커뮤니티"가 현재 관리자일지라도)은 모두 전환이 기존 기여자와 사용자에게 놀라운 일이 아닌지 확인하기 위해 시작하는 중요한 장소입니다.
기존 리포지토리를 인계받는 경우 전환 중에 검토 프로세스가 중단되지 않도록 원래 리포지토리의 전체 Git 기록이 새로운 업스트림 유지 관리 리포지토리에 유지되는지 확인하세요. 기존 저장소에서 새 저장소를 포크하면 가장 쉽게 수행할 수 있지만 원본에서 직접 커밋을 가져와서 새 저장소로 푸시하여 수행할 수도 있습니다(예: git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). GitHub에서 대안은 git 저장소의 소유권을 이동하는 것입니다. 두 그룹 모두에게 다른 소유자의 저장소에 대한 관리자 액세스 권한을 부여하지 않고도 이 작업을 수행할 수 있습니다.
동일한 Dockerfile 다시 빌드하면 두 번째 빌드가 여러 버전 이후에 발생하더라도 동일한 버전의 이미지가 패키징되거나 빌드가 완전히 실패하여 0.1.0 으로 태그가 지정된 Dockerfile 의 실수로 다시 빌드가 끝나지 않는 경우에도 패키징됩니다. 0.2.3 포함합니다. 예를 들어 apt 사용하여 이미지의 기본 프로그램을 설치하는 경우 해당 프로그램을 특정 버전에 고정해야 합니다(예: ... apt-get install -y my-package=0.1.0 ... ). apt 에 의해 설치된 종속 패키지의 경우 일반적으로 해당 패키지를 버전에 고정할 필요가 없습니다.
공식 이미지는 비공식 이미지에서 파생되거나 이에 의존할 수 없습니다(비이미지 scratch 및 .external-pins 에 고정된 의도적으로 제한된 예외 허용 - .external-pins/list.sh 참조).
모든 공식 이미지는 일관된 인터페이스를 제공해야 합니다. 초보 사용자는 --entrypoint 에 대해 배울 필요 없이 docker run official-image bash (또는 sh )를 docker 실행할 수 있어야 합니다. 또한 고급 사용자가 진입점을 활용하여 실행할 바이너리를 지정하지 않고도 docker run official-image --arg1 --arg2 실행할 수 있다는 점도 좋습니다.
시작 프로세스에 인수가 필요하지 않으면 CMD 사용하세요.
CMD [ "irb" ] 초기 데이터베이스 생성과 같이 시작 시 수행해야 하는 초기화가 있는 경우 CMD 와 함께 ENTRYPOINT 사용합니다.
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] docker run official-image bash (또는 sh )도 작동하는지 확인하세요. 가장 쉬운 방법은 예상되는 명령을 확인하고 다른 명령인 경우 exec "$@" 것입니다(전달된 모든 항목을 실행하고 인수를 적절하게 이스케이프된 상태로 유지).
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ " 이미지에 기본 실행 파일과 연결된 라이브러리만 포함되어 있는 경우(즉, 셸 없음) 실행 파일만 실행할 수 있으므로 실행 파일을 ENTRYPOINT 로 사용하는 것이 좋습니다.
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] 이것이 적절한지 여부를 나타내는 가장 일반적인 지표는 이미지 Dockerfile scratch ( FROM scratch )로 시작한다는 것입니다.
Dockerfile 을 이해하고 읽기 쉽게 만드세요. 간결함을 위해 복잡한 초기화 세부 사항을 독립형 스크립트에 넣고 Dockerfile 에 RUN 명령만 추가하고 싶은 유혹이 있을 수 있습니다. 그러나 이로 인해 결과 Dockerfile 지나치게 불투명해지며 이러한 Dockerfile 은 검토를 통과할 가능성이 낮습니다. 대신 초기화를 위한 모든 명령을 적절한 RUN 또는 ENV 명령 조합으로 Dockerfile 에 넣는 것이 좋습니다. 좋은 예를 찾으려면 현재 공식 이미지를 살펴보세요.
글을 쓰는 시점의 몇 가지 예:
Docker 지침에 따라 결과 이미지는 컨테이너당 하나의 관심사일 뿐인 것이 좋습니다. 이는 주로 컨테이너당 하나의 프로세스만 의미하므로 전체 초기화 시스템이 필요하지 않습니다. init와 유사한 프로세스가 컨테이너에 도움이 되는 두 가지 상황이 있습니다. 첫 번째는 신호 처리입니다. 시작된 프로세스가 종료하여 SIGTERM 처리하지 않는 경우 컨테이너의 PID 1이므로 종료되지 않습니다(docker 문서의 Foreground 섹션 끝에 있는 "NOTE" 참조). 두 번째 상황은 좀비 수확입니다. 프로세스가 하위 프로세스를 생성하고 적절하게 회수하지 않으면 전체 프로세스 테이블이 생성되어 전체 시스템이 새 프로세스를 생성하지 못하게 될 수 있습니다. 이 두 가지 문제에 대해 우리는 Tini를 추천합니다. 믿을 수 없을 정도로 작고 외부 종속성이 최소화되어 이러한 각 역할을 수행하며 수확 및 신호 전달에 필요한 부분만 수행합니다.
CMD 또는 ENTRYPOINT 에서 적절하게 Tini를 사용하십시오.
배포판에서 제공하는 패키지(예: apt-get install tini )에서 tini를 설치하는 것이 가장 좋습니다. 배포판에서 Tini를 사용할 수 없거나 너무 오래된 경우 Tini에 추가할 Dockerfile 조각은 다음과 같습니다.
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --version이것은 깨달음의 길에 대한 문서보다 경험이 가장 중요한 곳이지만 다음 팁이 도움이 될 수 있습니다.
가능하면 COPY / ADD 피하세요. 하지만 필요한 경우 최대한 구체적으로 작성하세요(예: COPY . /somewhere COPY one-file.sh /somewhere/ somewhere/ ).
그 이유는 COPY 명령에 대한 캐시가 파일 mtime 변경을 캐시 버스트로 간주하여 COPY 의 캐시 동작을 예측할 수 없게 만들 수 있기 때문입니다. 특히 .git COPY 해야 하는 항목의 일부일 때(예를 들어) 더욱 그렇습니다.
변경될 가능성이 낮은 행이 변경될 가능성이 높은 행 앞에 오도록 하십시오(각 행은 나중 행에 대한 가정 없이 계속 성공적으로 실행되는 이미지를 생성해야 한다는 주의 사항).
예를 들어, 소프트웨어 버전 번호( ENV MYSOFTWARE_VERSION 4.2 )가 포함된 줄은 APT 저장소 .list 파일( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list 설정하는 줄 뒤에 와야 합니다. RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
빌드 중에 가로채기 공격을 완화하는 데 도움이 되도록 Dockerfile 작성해야 합니다. 우리의 요구 사항은 소스 확인, 작성자 확인, 콘텐츠 확인이라는 세 가지 주요 목표에 중점을 둡니다. 이는 각각 다음을 통해 수행됩니다. 가능한 경우 https를 사용합니다. 서명을 확인하기 위해 Dockerfile 의 전체 지문이 포함된 PGP 키를 가져옵니다. Dockerfile 에 체크섬을 직접 삽입합니다. 가능하면 세 가지를 모두 사용해야 합니다. 서명이 게시되지 않은 경우 https 및 포함된 체크섬만 사용할 수 있습니다. 최후의 수단으로 사이트에 https를 사용할 수 없고 서명이 없는 경우 내장된 체크섬만 허용됩니다.
필요한 아티팩트를 다운로드하기 위해 https 사용을 권장하는 목적은 다운로드가 신뢰할 수 있는 소스에서 이루어지므로 가로채기가 훨씬 더 어려워지는 것입니다.
PGP 서명 확인을 권장하는 목적은 권한이 있는 사용자만 해당 아티팩트를 게시하도록 보장하는 것입니다. PGP 키를 가져올 때 가능하면 keys.openpgp.org 서비스를 사용하세요(그렇지 않으면 keyserver.ubuntu.com 선호). 키 및 확인에 대한 FAQ 섹션도 참조하세요.
체크섬 확인을 권장하는 목적은 아티팩트가 예상한 대로인지 확인하는 것입니다. 이렇게 하면 원격 콘텐츠가 변경되면 Dockerfile도 변경되어 자연스러운 docker build 캐시 버스트가 제공됩니다. 또한 이는 버전이 잘못된 파일에서 예상보다 새로운 아티팩트를 실수로 다운로드하는 것을 방지합니다.
다음은 몇 가지 예입니다.
선호 : https를 통해 다운로드, PGP 키 전체 지문 가져오기 및 asc 확인, 내장된 체크섬 확인.
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# install대안 : 패키지를 다운로드하고 설치할 때 서명과 체크섬을 확인하는 apt로 전체 키 지문을 가져옵니다.
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (참고로 rm -rf /var/lib/apt/lists/* 는 apt-get update 와 대략 반대입니다. 이는 레이어에 추가 ~8MB의 APT 패키지 목록 데이터가 포함되지 않도록 보장하며, 적절한 apt-get update 사용을 시행합니다.)
덜 안전한 대안 : 체크섬을 Dockerfile 에 포함합니다.
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# install참고: SHA1 또는 MD5 중 하나를 사용하는 것은 일반적으로 안전하지 않은 것으로 간주되므로 "최후의 체크섬"으로 간주해야 합니다.
허용되지 않음 : 확인 없이 http를 통해 파일을 다운로드합니다.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install 기본적으로 Docker 컨테이너는 허용된 Linux 기능, 제어 그룹 및 기본 Seccomp 프로필(1.10+, 호스트 지원 포함)과 같이 제한된 권한으로 실행됩니다. 컨테이너에서 실행되는 소프트웨어가 올바르게 작동하려면 추가 권한이 필요할 수 있으며, 컨테이너 실행을 사용자 정의하기 위한 다양한 명령줄 옵션이 있습니다. 참조는 docker run Reference 및 Docker용 Seccomp를 참조하세요.
추가 권한이 필요한 공식 저장소는 소프트웨어가 작동하기 위한 최소한의 명령줄 옵션 세트를 지정해야 하며 이로 인해 심각한 이식성 또는 보안 문제가 발생할 경우 여전히 거부될 수 있습니다. 일반적으로 --privileged 허용되지 않지만 --cap-add 및 --device 옵션의 조합은 허용될 수 있습니다. 또한 이식성/보안 문제(예: X11 소켓)를 유발하는 호스트 파일 시스템 위치가 많기 때문에 --volume 까다로울 수 있습니다.
보안 수정을 구성하는 이미지 업데이트의 경우 업데이트가 가능한 한 빨리 병합, 빌드 및 릴리스되도록 하기 위해 권장되는 몇 가지 사항이 있습니다.
[email protected] 으로 이메일을 보내 미리 알림과 예상 시기를 알려주세요(수신되는 업데이트에 대한 시간을 적절하게 예약할 수 있도록).[security] 포함합니다(예: [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). 각 저장소는 모든 태그에 대해 여러 아키텍처를 지정할 수 있습니다. 아키텍처가 지정되지 않으면 이미지는 amd64 (즉 x86-64)의 Linux에서 빌드됩니다. 더 많거나 다른 아키텍처를 지정하려면 Architectures 필드를 사용하십시오(쉼표로 구분된 목록, 공백은 잘림). 유효한 아키텍처는 Bashbrew의 oci-platform.go 파일에서 찾을 수 있습니다.
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 지정된 태그의 Architectures 해당 태그가 FROM 에 있는 태그 Architectures 의 엄격한 하위 집합이어야 합니다.
이미지에는 여러 아키텍처에 사용할 수 있는 라이브러리 파일의 항목당 하나의 Dockerfile 있어야 합니다. 이는 지원되는 각 아키텍처가 동일한 FROM 행(예: FROM debian:bookworm )을 갖는다는 것을 의미합니다. 항목당 하나의 Dockerfile 을 사용하는 라이브러리 파일의 예는 golang , docker , haproxy 및 php 참조하고 Dockerfile 과 같은 해당 git 저장소를 참조하세요.
Dockerfile의 다른 부분이 하나의 아키텍처에서만 발생하는 경우 dpkg --print-architecture 또는 apk -print-arch 와 함께 제어 흐름(예: if / case )을 사용하여 사용자 공간 아키텍처를 감지합니다. 더 정확한 도구를 설치할 수 없는 경우 아키텍처 감지에만 uname 사용하십시오. 일부 아키텍처에서는 업스트림 소스 패키지에서 바이너리를 빌드해야 하고 일부는 바이너리 릴리스만 다운로드하는 예를 보려면 golang을 참조하세요.
debian 과 같은 기본 이미지의 경우 아키텍처별 바이너리를 ADD 하려면 다른 Dockerfile 과 빌드 컨텍스트가 필요하며 이는 위에 대한 유효한 예외입니다. 이러한 이미지는 동일한 Tags 사용하므로 동일한 항목에 있어야 합니다. 하이픈( - )과 필드(예: arm32v7-GitCommit )로 연결된 아키텍처인 GitRepo , GitFetch , GitCommit 및 Directory 에 대한 아키텍처별 필드를 사용합니다. 아키텍처별 필드가 없는 모든 아키텍처는 기본 필드를 사용합니다. 예를 들어 arm32v7-Directory 가 없으면 Directory arm32v7 에 사용된다는 의미입니다. 예제는 라이브러리의 debian 또는 ubuntu 파일을 참조하세요. 다음은 hello-world 의 예입니다.
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
라이브러리 파일 형식에 대한 자세한 내용은 명령 형식 섹션을 참조하세요.
새로운 공식 이미지를 제안하는 일은 가볍게 이루어져서는 안 됩니다. 당사는 귀하의 이미지를 유지하기 위한 노력(위에 언급된 대로 특히 적절한 시기적절한 업데이트 포함)을 기대하고 요구합니다.
라이브러리 정의 파일은 official-images 저장소의 library/ 디렉토리에 있는 일반 텍스트 파일입니다. 각 라이브러리 파일은 Docker Hub 설명에 표시되는 현재 "지원되는" 이미지 태그 세트를 제어합니다. 라이브러리 파일에서 제거된 태그는 Docker Hub에서 제거되지 않으므로 이전 버전을 계속 사용할 수 있지만 공식 이미지의 업스트림이나 관리자가 유지 관리하지 않습니다. 라이브러리 파일의 태그는 해당 라이브러리 파일을 업데이트하거나 기본 이미지가 업데이트된 결과로만 빌드됩니다(즉, FROM debian:bookworm 이 빌드될 때 debian:bookworm 의 이미지가 다시 빌드됩니다). 베이스가 업데이트되면 라이브러리 파일에 있는 내용만 다시 작성됩니다.
이 정책을 고려할 때 백필 버전, 릴리스 후보, 지속적인 통합 빌드 등 몇 가지 사례를 명확히 하는 것이 좋습니다. 새로운 저장소가 제안되면 초기 풀 요청에 지원되지 않는 일부 이전 버전을 포함하고 수락 후 즉시 제거하겠다는 합의를 하는 것이 일반적입니다. 이것을 의도하지 않은 포괄적인 역사적 기록 보관소와 혼동하지 마십시오. "지원"이라는 용어가 약간 확장되는 또 다른 일반적인 경우는 릴리스 후보에 대한 것입니다. 릴리스 후보는 실제로 수명이 짧은 릴리스에 대한 명명 규칙일 뿐이므로 완전히 수용되고 권장됩니다. 릴리스 후보와 달리 코드 커밋이나 정기적인 일정을 기반으로 완전히 자동화된 릴리스 주기를 갖춘 지속적인 통합 빌드는 적합하지 않습니다.
일반적인 규칙에 익숙해지고 검토 프로세스를 더욱 간소화하는 데 도움이 되도록 새 콘텐츠를 만들기 전에 기존 library/ 파일 콘텐츠(및 시간에 따른 변경 내용을 파악하기 위한 기록) 중 일부를 탐색하는 것이 좋습니다. 난해한 형식이나 태그 사용/이름 지정 대신 콘텐츠에 집중할 수 있습니다.
정의 파일의 파일 이름은 Docker Hub에 생성되는 이미지 저장소의 이름을 결정합니다. 예를 들어, library/ubuntu 파일은 ubuntu 저장소에 태그를 생성합니다.
저장소의 태그는 업스트림 버전이나 변형을 반영해야 합니다. 예를 들어 Ubuntu 14.04는 Ubuntu Trusty Tahr라고도 알려져 있지만 간단히 Ubuntu Trusty(특히 사용 시)로 사용되는 경우가 많으므로 ubuntu:14.04 (버전 번호) 및 ubuntu:trusty (버전 이름)는 동일한 이미지 콘텐츠에 대한 적절한 별칭입니다. Docker에서 latest 태그는 특별한 경우이지만 약간 잘못된 이름입니다. latest 실제로 "기본" 태그입니다. docker run xyz 수행하면 Docker는 이를 docker run xyz:latest 의미하는 것으로 해석합니다. 이러한 배경을 고려하면 사용자가 실제로 입력하도록 기대하거나 권장하는 것이 아니기 때문에 다른 태그에는 latest 문자열이 포함되지 않습니다(예: xyz:latest 실제로 단순히 xyz 로 사용해야 함). 다르게 말하면, "XYZ의 최고 2.2 시리즈 릴리스"에 대한 별칭은 xyz:2.2 xyz:2.2-latest :2.2 여야 합니다. 마찬가지로 xyz:latest 의 Alpine 변형이 있는 경우 xyz:alpine xyz:alpine-latest 또는 xyz:latest-alpine 이 아닌 xyz:alpine 으로 별칭을 지정해야 합니다.
사용자가 특정 시리즈의 "최신" 릴리스를 쉽게 유지할 수 있도록 버전 번호 태그에 별칭을 제공하는 것이 좋습니다. 예를 들어 현재 지원되는 XYZ 소프트웨어 버전 2.3.7 및 2.2.4의 경우 제안되는 별칭은 각각 Tags: 2.3.7, 2.3, 2, latest 및 Tags: 2.2.4, 2.2 입니다. 이 예에서 사용자는 xyz:2.2 사용하여 2.2 시리즈의 최신 패치 릴리스를 쉽게 사용할 수 있으며, 덜 세분성이 필요한 경우 xyz:2 사용할 수 있습니다(Python은 이것이 가장 명백하게 유용한 좋은 예입니다 -- python:2 python:3과 python:3 매우 다르며 Python의 각 주요 릴리스 트랙에 대한 latest 태그로 생각할 수 있습니다.)
위에서 설명한 대로 latest 실제로 "기본값"이므로 별칭인 이미지는 사용자가 어떤 버전을 사용하는지 모르거나 관심이 없는 경우 사용해야 하는 소프트웨어의 버전이나 변형을 반영해야 합니다. 예를 들어 Ubuntu를 사용하면 ubuntu:latest 최신 LTS 릴리스를 가리킵니다. 이는 대부분의 사용자가 Ubuntu를 원한다는 것을 알지만 어떤 버전인지 모르거나 신경쓰지 않는 경우(특히 그것이 언제든지 가장 "안정적"이고 잘 지원되는 릴리스입니다).
매니페스트 파일 형식은 공식적으로 RFC 2822를 기반으로 하므로 HTTP나 이메일과 같은 널리 사용되는 인터넷 프로토콜/형식의 "헤더"에 이미 익숙한 사람들에게는 친숙할 것입니다.
주요 추가 사항은 데비안이 일반적으로 2822를 사용하는 방식에서 영감을 받았습니다. 즉, # 으로 시작하는 줄은 무시되고 "항목"은 빈 줄로 구분됩니다.
첫 번째 항목은 이미지의 "전역" 메타데이터입니다. 전역 항목의 유일한 필수 필드는 Maintainers 이며, 해당 값은 Name <email> (@github) 또는 Name (@github) 형식으로 쉼표로 구분됩니다. 전역 항목에 지정된 모든 필드는 나머지 항목의 기본값이 되며 개별 항목에서 재정의될 수 있습니다.
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew는 지정된 커밋( GitCommit )에서 Git 저장소( GitRepo )에서 코드를 가져옵니다. 연결된 GitRepo 의 master 가져와서 참조된 커밋을 사용할 수 없는 경우 필요한 커밋을 가져오기 위해 가져올 참조를 Bashbrew에 알리기 위해 GitFetch 에 대한 값을 제공해야 합니다.
빌드된 이미지는 <manifest-filename>:<tag> 태그가 지정됩니다(즉, Tags 값이 1.6, 1, latest 인 library/golang , 최신은 golang:1.6 , golang:1 및 golang:latest 태그를 생성합니다).
선택적으로 Directory 있는 경우 Bashbrew는 루트가 아닌 지정된 하위 디렉터리 내에서 Dockerfile 을 찾습니다(그리고 Directory 저장소의 최상위 수준 대신 빌드의 "컨텍스트"로 사용됩니다). File 있으면 Dockerfile 대신 지정된 파일 이름이 사용됩니다.
특정 아키텍처에 대해 다른 GitRepo , GitFetch , GitCommit 또는 Directory 지정하는 방법에 대한 자세한 내용은 다중 아키텍처 섹션을 참조하세요.
library/ 폴더에 새 파일을 만듭니다. 해당 이름은 허브에 있는 저장소의 이름이 됩니다. Bashbrew( bashbrew )는 Docker 공식 이미지를 복제, 빌드, 태그 지정 및 푸시하기 위한 도구입니다. 자세한 내용은 Bashbrew README 참조하세요.
