Docker 이미지 구축 속도를 높이는 방법에 대한 몇 가지 팁입니다. 예를 들어 최대 30초입니다.

복잡한 오케스트레이터와 CI/CD가 존재하는 요즘에는 기능이 프로덕션에 도입되기 전에 커밋에서 테스트 및 제공까지 갈 길이 멀습니다. 이전에는 FTP를 통해 새 파일을 업로드할 수 있었고(아무도 더 이상 그렇게 하지 않죠?) "배포" 프로세스에 몇 초밖에 걸리지 않았습니다. 이제 병합 요청을 생성하고 해당 기능이 사용자에게 제공될 때까지 오랜 시간 기다려야 합니다.

이 경로의 일부는 Docker 이미지를 구축하는 것입니다. 조립은 때로는 몇 분, 때로는 수십 분 동안 지속되는데 이는 정상이라고 할 수 없습니다. 이 기사에서는 이미지로 패키징할 간단한 애플리케이션을 가져와서 빌드 속도를 높이기 위해 여러 가지 방법을 적용하고 이러한 방법이 어떻게 작동하는지 미묘한 차이를 살펴보겠습니다.

우리는 미디어 웹사이트 제작 및 지원에 있어 좋은 경험을 갖고 있습니다. TASS, 벨, "새 신문", 공화국… 얼마 전 제품 웹 사이트를 출시하여 포트폴리오를 확장했습니다. 알림. 새로운 기능이 빠르게 추가되고 오래된 버그가 수정되었지만 느린 배포가 큰 문제가 되었습니다.

GitLab에 배포합니다. 우리는 이미지를 수집하여 GitLab Registry에 푸시하고 프로덕션에 출시합니다. 이 목록에서 가장 긴 일은 이미지를 조립하는 것입니다. 예를 들어 최적화하지 않으면 각 백엔드 빌드에 14분이 걸렸습니다.

결국 우리는 더 이상 이렇게 살 수 없다는 것이 분명해졌고, 우리는 왜 이미지를 수집하는 데 그렇게 오랜 시간이 걸리는지 알아보기 위해 자리에 앉았습니다. 그 결과, 조립 시간을 30초로 단축할 수 있었습니다!

이번 글에서는 Reminder 환경에 얽매이지 않기 위해 빈 Angular 애플리케이션을 조립하는 예를 살펴보겠습니다. 이제 애플리케이션을 만들어 보겠습니다.

ng n app

PWA를 추가하세요(우리는 진보적입니다):

ng add @angular/pwa --project app

백만 개의 npm 패키지가 다운로드되는 동안 docker 이미지가 어떻게 작동하는지 살펴보겠습니다. Docker는 애플리케이션을 패키징하고 컨테이너라는 격리된 환경에서 실행하는 기능을 제공합니다. 격리 덕분에 하나의 서버에서 여러 컨테이너를 동시에 실행할 수 있습니다. 컨테이너는 시스템 커널에서 직접 실행되기 때문에 가상 머신보다 훨씬 가볍습니다. 애플리케이션과 함께 컨테이너를 실행하려면 먼저 애플리케이션 실행에 필요한 모든 것을 패키징할 이미지를 생성해야 합니다. 기본적으로 이미지는 파일 시스템의 복사본입니다. 예를 들어 Dockerfile을 살펴보겠습니다.

FROM node:12.16.2
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

Dockerfile은 일련의 지침입니다. 각각의 작업을 수행함으로써 Docker는 변경 사항을 파일 시스템에 저장하고 이를 이전 시스템에 오버레이합니다. 각 팀은 자체 레이어를 만듭니다. 그리고 완성된 이미지는 레이어들이 합쳐진 결과물입니다.

알아야 할 중요한 사항: 각 Docker 레이어는 캐시할 수 있습니다. 마지막 빌드 이후 변경된 사항이 없으면 명령을 실행하는 대신 Docker가 미리 만들어진 레이어를 사용합니다. 빌드 속도의 주요 증가는 캐시 사용으로 인해 발생하므로 빌드 속도를 측정할 때 기성 캐시를 사용하여 이미지를 빌드하는 데 특히 주의를 기울일 것입니다. 따라서 단계별로 다음을 수행하십시오.

1. 이전 실행이 테스트에 영향을 주지 않도록 이미지를 로컬에서 삭제합니다.
   docker rmi $(docker images -q)
2. 우리는 처음으로 빌드를 시작합니다.
   time docker build -t app .
3. src/index.html 파일을 변경합니다. 프로그래머의 작업을 모방합니다.
4. 빌드를 두 번째로 실행합니다.
   time docker build -t app .

이미지 빌드 환경이 올바르게 구성된 경우(자세한 내용은 아래 참조) 빌드가 시작될 때 Docker에 이미 많은 캐시가 탑재되어 있을 것입니다. 우리의 임무는 빌드가 최대한 빨리 진행되도록 캐시를 사용하는 방법을 배우는 것입니다. 캐시 없이 빌드를 실행하는 것은 처음 한 번만 발생한다고 가정하므로 첫 번째 실행이 얼마나 느린지는 무시할 수 있습니다. 테스트에서는 캐시가 이미 예열되고 케이크를 구울 준비가 된 두 번째 빌드 실행이 중요합니다. 그러나 일부 팁은 첫 번째 빌드에도 영향을 미칩니다.

위에서 설명한 Dockerfile을 프로젝트 폴더에 넣고 빌드를 시작해 보겠습니다. 읽기 쉽도록 모든 목록이 요약되어 있습니다.

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Status: Downloaded newer image for node:12.16.2
Step 2/5 : WORKDIR /app
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Time: 37581ms
Successfully built c8c279335f46
Successfully tagged app:latest

real 5m4.541s
user 0m0.000s
sys 0m0.000s

src/index.html의 내용을 변경하고 두 번째로 실행합니다.

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Time: 37902ms
Successfully built 79f335df92d3
Successfully tagged app:latest

real 3m33.262s
user 0m0.000s
sys 0m0.000s

이미지가 있는지 확인하려면 다음 명령을 실행하세요. docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   About a minute ago   1.74GB

빌드하기 전에 docker는 현재 컨텍스트의 모든 파일을 가져와 데몬으로 보냅니다. Sending build context to Docker daemon 409MB. 빌드 컨텍스트는 빌드 명령의 마지막 인수로 지정됩니다. 우리의 경우 이것은 현재 디렉터리인 "."이며 Docker는 이 폴더에 있는 모든 것을 드래그합니다. 409MB는 많은 양입니다. 이를 해결하는 방법을 생각해 보겠습니다.

맥락 줄이기

컨텍스트를 줄이기 위한 두 가지 옵션이 있습니다. 또는 어셈블리에 필요한 모든 파일을 별도의 폴더에 넣고 docker 컨텍스트가 이 폴더를 가리키도록 합니다. 이는 항상 편리하지 않을 수 있으므로 예외를 지정하는 것이 가능합니다. 즉, 컨텍스트에 끌어서는 안 되는 항목입니다. 이렇게 하려면 프로젝트에 .dockerignore 파일을 넣고 빌드에 필요하지 않은 항목을 표시합니다.

.git
/node_modules

빌드를 다시 실행하세요.

$ time docker build -t app .
Sending build context to Docker daemon 607.2kB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Time: 37313ms
Successfully built 4942f010792a
Successfully tagged app:latest

real 1m47.763s
user 0m0.000s
sys 0m0.000s

607.2KB는 409MB보다 훨씬 좋습니다. 또한 이미지 크기를 1.74GB에서 1.38GB로 줄였습니다.

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   3 minutes ago   1.38GB

이미지 크기를 더 줄여보겠습니다.

우리는 알파인을 사용합니다

이미지 크기를 절약하는 또 다른 방법은 작은 상위 이미지를 사용하는 것입니다. 부모 이미지는 우리의 이미지가 준비되는 기반이 되는 이미지입니다. 맨 아래 레이어는 명령으로 지정됩니다. FROM Dockerfile에서. 우리의 경우에는 이미 nodejs가 설치된 Ubuntu 기반 이미지를 사용하고 있습니다. 그리고 무게도 나가고...

$ docker images -a | grep node
node 12.16.2 406aa3abbc6c 17 minutes ago 916MB

... 거의 기가바이트입니다. Alpine Linux 기반 이미지를 사용하면 볼륨을 크게 줄일 수 있습니다. 알파인(Alpine)은 아주 작은 리눅스입니다. alpine 기반 nodejs용 docker 이미지의 무게는 88.5MB에 불과합니다. 이제 집의 생생한 이미지를 바꿔 보겠습니다.

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

우리는 애플리케이션을 구축하는 데 필요한 몇 가지 항목을 설치해야 했습니다. 예, Angular는 Python 없이는 빌드되지 않습니다. ̅(°_o)/̅

그러나 이미지 크기는 150MB로 떨어졌습니다.

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   aa031edc315a   22 minutes ago   761MB

더 나아가 보자.

다단계 조립

이미지에 있는 모든 것이 제작에 필요한 것은 아닙니다.

$ docker run app ls -lah
total 576K
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 .
drwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..
-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore
-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig
-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore
-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile
-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md
-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json
-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist
drwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist
drwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e
-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js
-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules
-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json
-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json
drwxr-xr-x 5 root root 4.0K Apr 17 2020 src
-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json
-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json
-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json
-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json

과 docker run app ls -lah 이미지를 기반으로 컨테이너를 출시했습니다. app 그리고 그 안에 있는 명령을 실행했습니다. ls -lah, 그 후 컨테이너가 작업을 완료했습니다.

프로덕션 환경에서는 폴더만 필요합니다. dist. 이 경우 어떻게든 파일을 외부에 제공해야 합니다. nodejs에서 일부 HTTP 서버를 실행할 수 있습니다. 하지만 우리는 그것을 더 쉽게 만들 것입니다. 네 글자 "y"로 구성된 러시아어 단어를 추측해 보세요. 오른쪽! Ynzhynyksy. nginx로 이미지를 찍어서 폴더를 넣어보자 dist 그리고 작은 구성:

server {
    listen 80 default_server;
    server_name localhost;
    charset utf-8;
    root /app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

다단계 빌드는 이 모든 작업을 수행하는 데 도움이 됩니다. Dockerfile을 변경해 보겠습니다.

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

이제 두 가지 지침이 있습니다. FROM Dockerfile에서 각각은 다른 빌드 단계를 실행합니다. 우리는 첫 번째 사람에게 전화했습니다. builder, 하지만 마지막 FROM부터 시작하여 최종 이미지가 준비됩니다. 마지막 단계는 nginx를 사용하여 이전 단계에서 어셈블리의 아티팩트를 최종 이미지에 복사하는 것입니다. 이미지 크기가 크게 감소했습니다.

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   2c6c5da07802   29 minutes ago   36MB

이미지로 컨테이너를 실행하고 모든 것이 작동하는지 확인해 보겠습니다.

docker run -p8080:80 app

-p8080:80 옵션을 사용하여 호스트 시스템의 포트 8080을 nginx가 실행되는 컨테이너 내부의 포트 80으로 전달했습니다. 브라우저에서 열려 http://localhost:8080/ 그리고 우리는 우리의 응용 프로그램을 봅니다. 모든 것이 작동하고 있습니다!

이미지 크기를 1.74GB에서 36MB로 줄이면 애플리케이션을 프로덕션에 전달하는 데 걸리는 시간이 크게 단축됩니다. 하지만 조립 시간으로 돌아가 보겠습니다.

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/11 : FROM node:12.16.2-alpine3.11 as builder
Step 2/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/11 : WORKDIR /app
 ---> Using cache
Step 4/11 : COPY . .
Step 5/11 : RUN npm ci
added 1357 packages in 47.338s
Step 6/11 : RUN npm run build --prod
Date: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms
 ---> 27f1479221e4
Step 7/11 : FROM nginx:stable-alpine
Step 8/11 : WORKDIR /app
 ---> Using cache
Step 9/11 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 10/11 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 11/11 : COPY --from=builder /app/dist/app .
Successfully built d201471c91ad
Successfully tagged app:latest

real 2m17.700s
user 0m0.000s
sys 0m0.000s

레이어 순서 변경

처음 세 단계는 캐시되었습니다(힌트 Using cache). 네 번째 단계에서는 모든 프로젝트 파일이 복사되고 다섯 번째 단계에서는 종속성이 설치됩니다. RUN npm ci - 최대 47.338초. 매우 드물게 변경되는 경우 종속성을 매번 다시 설치하는 이유는 무엇입니까? 왜 캐시되지 않았는지 알아봅시다. 요점은 Docker가 계층별로 명령과 관련 파일이 변경되었는지 확인한다는 것입니다. 네 번째 단계에서는 프로젝트의 모든 파일을 복사하고 그 중에는 물론 변경 사항도 있으므로 Docker는 이 레이어를 캐시에서 가져올 뿐만 아니라 모든 후속 레이어도 가져옵니다! Dockerfile을 약간 변경해 보겠습니다.

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

먼저 package.json 및 package-lock.json이 복사된 다음 종속성이 설치되고 그 후에야 전체 프로젝트가 복사됩니다. 결과적으로:

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/12 : FROM node:12.16.2-alpine3.11 as builder
Step 2/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/12 : WORKDIR /app
 ---> Using cache
Step 4/12 : COPY package*.json ./
 ---> Using cache
Step 5/12 : RUN npm ci
 ---> Using cache
Step 6/12 : COPY . .
Step 7/12 : RUN npm run build --prod
Date: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Time: 38287ms
 ---> 1b9448c73558
Step 8/12 : FROM nginx:stable-alpine
Step 9/12 : WORKDIR /app
 ---> Using cache
Step 10/12 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 11/12 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 12/12 : COPY --from=builder /app/dist/app .
Successfully built a44dd7c217c3
Successfully tagged app:latest

real 0m46.497s
user 0m0.000s
sys 0m0.000s

46분이 아닌 3초 - 훨씬 좋습니다! 레이어의 올바른 순서가 중요합니다. 먼저 변경되지 않는 항목을 복사한 다음 거의 변경되지 않는 항목, 마지막으로 자주 변경되는 항목을 복사합니다.

다음으로 CI/CD 시스템에서 이미지를 조립하는 방법에 대해 몇 마디 말씀드리겠습니다.

캐시에 이전 이미지 사용

빌드에 일종의 SaaS 솔루션을 사용하면 로컬 Docker 캐시가 깨끗하고 신선할 수 있습니다. 도커에게 구운 레이어를 얻을 수 있는 장소를 제공하려면 이전에 빌드된 이미지를 그에게 제공하십시오.

GitHub Actions에서 애플리케이션을 구축하는 예를 살펴보겠습니다. 우리는 이 구성을 사용합니다

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Build
      run: |
        docker build 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

20분 XNUMX초 만에 이미지가 수집되어 GitHub 패키지에 푸시됩니다.

이제 이전에 빌드된 이미지를 기반으로 캐시가 사용되도록 빌드를 변경해 보겠습니다.

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Pull latest images
      run: |
        docker pull $IMAGE_NAME:latest || true
        docker pull $IMAGE_NAME-builder-stage:latest || true

    - name: Images list
      run: |
        docker images

    - name: Build
      run: |
        docker build 
          --target builder 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          -t $IMAGE_NAME-builder-stage 
          .
        docker build 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          --cache-from $IMAGE_NAME:latest 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME-builder-stage:latest
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

먼저 두 명령이 실행되는 이유를 설명해야 합니다. build. 사실 다단계 어셈블리에서 결과 이미지는 마지막 단계의 레이어 세트가 됩니다. 이 경우 이전 레이어의 레이어는 이미지에 포함되지 않습니다. 따라서 이전 빌드의 최종 이미지를 사용할 때 Docker는 nodejs(빌더 단계)를 사용하여 이미지를 빌드하기 위해 준비된 레이어를 찾을 수 없습니다. 이 문제를 해결하기 위해 중간 이미지가 생성됩니다. $IMAGE_NAME-builder-stage 후속 빌드에서 캐시 소스로 사용할 수 있도록 GitHub 패키지에 푸시됩니다.

총 조립 시간은 XNUMX분 XNUMX초로 단축되었습니다. 이전 이미지를 불러오는 데 XNUMX분이 소요됩니다.

사전 이미징

깨끗한 Docker 캐시 문제를 해결하는 또 다른 방법은 일부 레이어를 다른 Dockerfile로 이동하고 별도로 빌드한 후 Container Registry에 푸시하고 상위 항목으로 사용하는 것입니다.

우리는 Angular 애플리케이션을 구축하기 위해 자체 nodejs 이미지를 만듭니다. 프로젝트에 Dockerfile.node를 생성합니다.

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++

Docker Hub에서 공개 이미지를 수집하고 푸시합니다.

docker build -t exsmund/node-for-angular -f Dockerfile.node .
docker push exsmund/node-for-angular:latest

이제 기본 Dockerfile에서 완성된 이미지를 사용합니다.

FROM exsmund/node-for-angular:latest as builder
...

이 예에서는 빌드 시간이 줄어들지 않았지만 프로젝트가 많고 각 프로젝트에 동일한 종속성을 설치해야 하는 경우 사전 빌드된 이미지가 유용할 수 있습니다.

Docker 이미지 빌드 속도를 높이기 위한 몇 가지 방법을 살펴보았습니다. 배포를 빠르게 진행하려면 프로젝트에서 다음을 사용해 보세요.

• 맥락 감소;
• 작은 부모 이미지 사용;
• 다단계 조립;
• 캐시를 효율적으로 사용하기 위해 Dockerfile의 명령 순서를 변경합니다.
• CI/CD 시스템에서 캐시 설정
• 이미지의 예비 생성.

예제를 통해 Docker의 작동 방식이 더 명확해지고 배포를 최적으로 구성할 수 있기를 바랍니다. 기사의 예제를 실행하기 위해 저장소가 생성되었습니다. https://github.com/devopsprodigy/test-docker-build.

출처 : habr.com