docker-build - 클라우드에서의 온라인

프로그램:

이름

docker-build - PATH의 소스 코드에서 새 이미지를 빌드합니다.

개요

도커 빌드 [--빌드-인수[=[]]] [--cpu 공유[=0]] [--cgroup-부모[=CGROUP-부모]]
[--도움] [-f|--파일[=경로/도커파일]] [--force-rm] [--격리[=디폴트 값]] [--캐시 없음]
[--당기다] [-q|--조용한] [--NS[=참된]] [-t|--꼬리표[=[]]] [-m|--메모리[=메모리]]
[--메모리 스왑[=제한]] [--shm-크기[=SHM-크기]] [--cpu 기간[=0]] [--cpu 할당량[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] 경로 | URL | -

기술

그러면 지정된 디렉터리에서 Dockerfile을 읽습니다. PATH. 그것은 또한 어떤 것을 보낸다.
현재 디렉터리에 있는 다른 파일과 디렉터리를 Docker 데몬으로 보냅니다. 그만큼
이 디렉토리의 내용은 다음에서 사용됩니다. ADD Dockerfile 내에 있는 명령입니다.

경고: 이렇게 하면 내용에 따라 Docker 데몬에 많은 데이터가 전송됩니다.
현재 디렉토리. 빌드는 CLI가 아닌 Docker 데몬에 의해 실행되므로 전체
컨텍스트는 데몬으로 전송되어야 합니다. Docker CLI는 "빌드 컨텍스트 전송 중"을 보고합니다.
Docker 데몬으로" 컨텍스트가 데몬으로 전송될 때.

tarball 아카이브 또는 단일 Dockerfile에 대한 URL이 제공되면 컨텍스트가 전송되지 않습니다.
클라이언트에서 Docker 데몬으로. 이 경우 루트에 있는 Dockerfile은
아카이브와 나머지 아카이브는 빌드의 컨텍스트로 사용됩니다. 힘내 때
저장소는 다음과 같이 설정됩니다. URL, 저장소는 로컬로 복제된 다음
문맥.

옵션

-f, --파일=경로/도커파일
사용할 Dockerfile의 경로입니다. 경로가 상대 경로이고 다음과 같은 경우
로컬 디렉터리에서 빌드하는 경우 경로는 해당 디렉터리에 상대적이어야 합니다.
예배 규칙서. 다음 중 하나를 가리키는 원격 URL에서 구축하는 경우
tarball 또는 Git 저장소인 경우 경로는 루트에 상대적이어야 합니다.
원격 컨텍스트. 모든 경우에 파일은 빌드 컨텍스트 내에 있어야 합니다.
디폴트는 도커 파일.

--빌드-인수=변수
이름과 값 buildarg.

예를 들어, 다음에 대한 값을 전달하려는 경우 http_proxy사용
--build-arg=http_proxy="http://some.proxy.url"

사용자는 빌드 시 이러한 값을 전달합니다. 도커는 buildargs 로
Dockerfile을 통해 실행되는 명령에 대한 환경 컨텍스트 운영 교수
또는 다른 Dockerfile 명령어의 변수 확장을 위해. 이런 뜻은 아니다
비밀 값을 전달하기 위해. ⟨/참조/빌더/#arg⟩

--force-rm=참된|그릇된
빌드가 실패한 후에도 항상 중간 컨테이너를 제거하십시오. 기본값은
그릇된.

--격리="디폴트 값"
격리는 컨테이너에서 사용하는 격리 기술의 유형을 지정합니다.

--캐시 없음=참된|그릇된
이미지를 빌드할 때 캐시를 사용하지 마세요. 기본값은 그릇된.

--도움
사용 명세서 인쇄

--당기다=참된|그릇된
항상 최신 버전의 이미지를 가져오도록 시도하십시오. 기본값은 그릇된.

-q, --조용한=참된|그릇된
성공 시 빌드 출력을 억제하고 이미지 ID를 인쇄합니다. 기본값은 그릇된.

--NS=참된|그릇된
성공적인 빌드 후 중간 컨테이너를 제거합니다. 기본값은 참된.

-t, --꼬리표= ""
결과 이미지에 적용할 저장소 이름(및 선택적으로 태그 포함)
성공사례.

-m, --메모리=메모리
메모리 제한

--메모리 스왑=제한
메모리에 스왑을 더한 것과 같은 제한 값입니다. 와 함께 사용해야 합니다. -m (--메모리) 깃발. NS
교환 제한 항상 다음보다 커야 합니다. -m (--메모리) 값.

형식 제한 is [ ]. 단위 수 b (바이트), k (킬로바이트), m
(메가바이트) 또는 g (기가바이트). 단위를 지정하지 않으면 b 사용. LIMIT를 다음으로 설정 -1 에
무제한 스왑을 활성화합니다.

--shm-크기=SHM-크기
크기 /dev/shm. 형식은 . 번호 보다 커야합니다 0.
단위는 선택 사항이며 다음이 될 수 있습니다. b (바이트), k (킬로바이트), m (메가바이트) 또는 g (기가바이트).
단위를 생략하면 시스템에서 바이트를 사용합니다.
크기를 완전히 생략하면 시스템은 다음을 사용합니다. 64m.

--cpu 공유=0
CPU 공유(상대적 가중치).

기본적으로 모든 컨테이너는 동일한 비율의 CPU 주기를 갖습니다.
CPU 공유는 기본 설정인 1024를 기준으로 한 '상대적 가중치'입니다.
이 기본값은 여기에 정의되어 있습니다.

방법 /sys/fs/cgroup/cpu/cpu.shares
1024

컨테이너의 CPU 공유를 조정하여 이 비율을 변경할 수 있습니다.
실행 중인 다른 모든 컨테이너의 가중치를 기준으로 가중치를 적용합니다.

기본값인 1024에서 비율을 수정하려면 --cpu 공유
가중치를 2 이상으로 설정하는 플래그입니다.

컨테이너 CPU 공유 플래그
{C0} CPU의 60% --cpu-shares=614(614는 60의 1024%)
{C1} CPU의 40% --cpu-shares=410(410는 40의 1024%)

이 비율은 CPU 집약적인 프로세스가 실행 중인 경우에만 적용됩니다.
한 컨테이너의 작업이 유휴 상태이면 다른 컨테이너가 해당 작업을 사용할 수 있습니다.
남은 CPU 시간. 실제 사용된 CPU 시간은 다음에 따라 다릅니다.
시스템에서 실행 중인 컨테이너의 수

예를 들어 세 개의 컨테이너를 생각해 보세요. --cpu-shares=1024 과
다른 두 명은 --cpu-shares=512. 세 가지 모두에서 프로세스가 수행되는 경우
컨테이너가 CPU를 100% 사용하려고 시도하면 첫 번째 컨테이너는
총 CPU 시간의 50%입니다. 네 번째 컨테이너를 추가하면 --cpu-shares=1024,
첫 번째 컨테이너는 CPU의 33%만 가져옵니다. 남은 컨테이너
CPU의 16.5%, 16.5%, 33%를 받습니다.

컨테이너 CPU 공유 플래그 CPU 시간
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%

멀티 코어 시스템에서는 CPU 시간 공유가 CPU 전체에 분산됩니다.
코어. 컨테이너가 CPU 시간의 100% 미만으로 제한되더라도
각 개별 CPU 코어를 100% 사용합니다.

예를 들어 코어가 XNUMX개 이상인 시스템을 생각해 보세요. 하나 시작하면
컨테이너 {C0} 과 --cpu-shares=512 하나의 프로세스와 다른 컨테이너 실행
{C1} 과 --cpu-shares=1024 두 개의 프로세스를 실행하면 다음과 같은 결과가 발생할 수 있습니다.
CPU 공유 분할:

PID 컨테이너 CPU CPU 점유율
100 {C0} 0 CPU100의 0%
101 {C1} 1 CPU100의 1%
102 {C1} 2 CPU100의 2%

--cpu 기간=0
CPU CFS(Completely Fair Scheduler) 기간을 제한합니다.

컨테이너의 CPU 사용량을 제한합니다. 이 플래그는 커널이
컨테이너의 CPU 사용량을 지정한 기간만큼 적용합니다.

--cpu 할당량=0
CPU CFS(Completely Fair Scheduler) 할당량을 제한합니다.

기본적으로 컨테이너는 전체 CPU 리소스를 사용하여 실행됩니다. 이 플래그는 커널이
컨테이너의 CPU 사용량을 지정한 할당량으로 제한합니다.

--cpuset-cpus=CPUSET-CPU
실행을 허용하는 CPU입니다(0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
실행을 허용하는 메모리 노드(MEM)(0-3, 0,1). 다음에 대해서만 유효합니다.
NUMA 시스템.

예를 들어, 시스템에 0개의 메모리 노드(3-XNUMX)가 있는 경우 다음을 사용하십시오. --cpuset-mems=0,1 에
Docker 컨테이너의 프로세스가 처음 두 메모리의 메모리만 사용하는지 확인하세요.
노드.

--cgroup-부모=CGROUP-부모
경로 cgroup 그 아래 컨테이너의 씨그룹 생성됩니다.

경로가 절대 경로가 아닌 경우 경로는 상대 경로로 간주됩니다. cgroup 의 경로
초기화 프로세스. Cgroup이 아직 존재하지 않으면 생성됩니다.

--ulimit=[]
Ulimit 옵션

에 대한 자세한 내용은 한계 참조
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

사용 예

건물 an 영상 사용 a 도커 파일 위치한 내부 전에, current 예배 규칙서

Docker 이미지는 build 명령과 Dockerfile을 사용하여 빌드할 수 있습니다.

도커 빌드 .

빌드 프로세스 중에 Docker는 중간 이미지를 생성합니다. 그것들을 지키기 위해서 당신은
명시적으로 설정해야 함 --rm=거짓.

docker build --rm=false .

좋은 방법은 관련 이름을 가진 하위 디렉터리를 만들고 Dockerfile을 만드는 것입니다.
그 디렉토리에. 예를 들어 mongo라는 디렉터리에는 Dockerfile이 포함될 수 있습니다.
Docker MongoDB 이미지를 만듭니다. 마찬가지로 httpd라는 다른 디렉토리를 사용하여
Apache 웹 서버 이미지용 Dockerfile을 저장합니다.

이미지에 필요한 파일을 하위 디렉터리에 추가하는 것도 좋은 방법입니다.
그런 다음 이러한 파일은 다음과 같이 지정됩니다. 복사 or ADD 의 지침 도커 파일.

참고: tar 파일을 포함하면(좋은 습관) Docker가 자동으로 압축을 푼다.
내에 지정된 tar 파일의 내용 ADD 지정된 것에 대한 지시
대상입니다.

건물 an 영상 과 명명 그 영상

좋은 방법은 구축 중인 이미지에 이름을 지정하는 것입니다. a-z0-9-_만 참고하세요.
일관성을 위해 사용해야 합니다. 여기에는 엄격한 규칙이 없지만 다음을 제공하는 것이 가장 좋습니다.
이름 고려.

XNUMXD덴탈의 -t/--꼬리표 플래그는 이미지의 이름을 바꾸는 데 사용됩니다. 여기 몇 가지 예가 있어요.

좋은 습관은 아니지만 이미지 이름은 임의적일 수 있습니다.

docker build -t myimage .

더 나은 접근 방식은 정규화되고 의미 있는 저장소, 이름 및 태그를 제공하는 것입니다.
(여기서 태그는 ":" 뒤의 한정자를 의미합니다). 이 예에서 우리는
Fedora 저장소용 JBoss 이미지를 빌드하고 버전 1.0을 제공합니다.

docker build -t fedora/jboss:1.0 .

다음 예는 "whenry" 사용자 저장소에 대한 것이며 Fedora와 JBoss를 사용하고 다음을 제공합니다.
버전 2.1입니다.

docker build -t whenry/fedora-jboss:v2.1 .

버전 태그를 제공하지 않으면 Docker가 버전 태그를 할당합니다. 최근:

docker build -t whenry/fedora-jboss .

이미지를 나열하면 위 이미지에 태그가 표시됩니다. 최근.

이미지에 여러 태그를 적용할 수 있습니다. 예를 들어 다음을 적용할 수 있습니다. 최근 에 태그를 지정하세요
새로 빌드된 이미지를 선택하고 특정 버전을 참조하는 다른 태그를 추가하세요. 예를 들어,
이미지에 둘 다 태그 지정 whenry/fedora-jboss:최신 과 whenry/fedora-jboss:v2.1, 사용
다음 :

docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .

따라서 이미지 이름을 바꾸는 것은 임의적이지만 유용한 규칙을 고려해야 합니다.
이는 소비자에게 적합하며 Docker 커뮤니티도 고려해야 합니다.
관례.

건물 an 영상 사용 a URL

그러면 URL에서 지정된 GitHub 저장소가 복제되어 컨텍스트로 사용됩니다. 그만큼
저장소 루트에 있는 Dockerfile이 Dockerfile로 사용됩니다. 이는 다음과 같은 경우에만 작동합니다.
GitHub 저장소는 전용 저장소입니다.

도커 빌드 github.com/scollier/purpletest

참고: 다음을 통해 임의의 Git 저장소를 설정할 수 있습니다. 자식:// 개요.

건물 an 영상 사용 a URL 에 a 타르볼 처리됨 문맥

그러면 URL 자체가 Docker 데몬으로 전송됩니다. 데몬이 타르볼을 가져옵니다
보관하고 압축을 풀고 해당 콘텐츠를 빌드 컨텍스트로 사용합니다. Dockerfile은
아카이브의 루트와 아카이브의 나머지 부분은 빌드의 컨텍스트로 사용됩니다.
만약 당신이 -f 경로/도커파일 옵션을 선택하면 시스템이 해당 파일을 찾습니다.
타르볼의 내용 내부.

docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz

참고: 지원되는 압축 형식은 'xz', 'bzip2', 'gzip' 및 'identity'입니다(없음
압축).

지정 격리 technology for 컨테이너 (--격리)

이 옵션은 Windows에서 Docker 컨테이너를 실행하는 상황에서 유용합니다.
XNUMXD덴탈의 --격리= 옵션은 컨테이너의 격리 기술을 설정합니다. Linux에서는 유일한
지원되는 것은 디폴트 값 Linux 네임스페이스를 사용하는 옵션입니다. Microsoft Windows에서는 다음을 수행할 수 있습니다.
다음 값을 지정합니다.

· 디폴트 값: Docker 데몬에서 지정한 값을 사용합니다. --exec-opt . 경우 악마 하지
격리 기술을 지정하지 않고 Microsoft Windows는 방법 기본값으로
값.

· 방법: 네임스페이스 격리 전용입니다.

· 하이퍼브: Hyper-V 하이퍼바이저 파티션 기반 격리.

지정 --격리 값이 없는 플래그는 설정과 동일합니다.
--isolation="기본값".

연혁

2014년 XNUMX월, 원래는 William Henry(redhat dot com의 Whenry)가 다음을 기반으로 편집했습니다.
docker.com 소스 자료 및 내부 작업. 2014년 XNUMX월, Sven Dowideit에 의해 업데이트됨
⟨[이메일 보호]⟩ 2015년 XNUMX월, Sally O'Malley가 업데이트함 ⟨[이메일 보호]⟩

onworks.net 서비스를 사용하여 온라인으로 docker-build를 사용하세요.