4장 쿠버네티스를 이루는 컨테이너 도우미, 도커

sua·2022년 9월 22일

컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커

목록 보기

4/4

4.1 도커를 알아야 하는 이유

쿠버네티스를 이루는 기본 오브젝트가 파드고, 파드는 컨테이너로 이루어져 있고, 컨테이너를 만들고 관리하는 도구가 도커이기 때문에 도커를 배우고 나서 쿠버네티스를 배우는 것이 흐름에 맞다. 트러블 슈팅을 제대로 하려면 컨테이너를 잘 알아야 함.

4.1.1 파드, 컨테이너, 도커, 쿠버네티스의 관계

파드(컨테이너 1개 이상)들은 워커 노드라는 노드 단위로 관리, 워커 노드와 마스터 노드가 모여 쿠버네티스 클러스터가 됨.
파드는 쿠버네티스로부터 IP를 받아 컨테이너가 외부와 통신할 수 있는 경로를 제공하고 컨테이너들이 정상적으로 작동하는지 확인하고 네트워크나 저장 공간을 서로 공유하게 함.
-> 컨테이너를 돌보는 것이 파드, 파드를 돌보는 것이 쿠버네티스 워커 노드, 워커 노드를 돌보는 것이 쿠버네티스 마스터. (쿠버네티스 마스터 역시 파드로 이루어짐)

컨테이너 : 하나의 운영 체제 안에서 커널을 공유하며 개별적인 실행 환경을 제공하는 격리된 공간

개별적인 실행 환경 : CPU, 네트워크, 메모리와 같은 시스템 자원을 독자적으로 사용하도록 할당된 환경
-> 각 컨테이너 내부에서 실행되는 애플리케이션들은 서로 영향을 미치지 않고 독립적으로 작동

각 컨테이너가 독립적으로 작동하기 때문에 여러 컨테이너를 효과적으로 쉽게 다룰 방법이 필요해졌는데 이를 제공하는 도구가 도커임.
도커는 컨테이너를 사용하는 방법을 명령어로 정리한 것이다.
도커를 사용하면 사용자가 따로 신경 쓰지 않아도 컨테이너를 생성할 때 개별적인 실행 환경을 분리하고 자원을 할당

4.1.2 다양한 컨테이너 관리 도구

구분	컨테이너디	크라이오	카타 컨테이너	도커
명령어 도구	별도 지원	타 도구 사용	자체 지원	자체 지원
내부 구조	단순	매우 단순	복잡	복잡
확장성	좋음	좋지 못함	좋지 못함	매우 좋음
컨테이너 관리	좋음	좋음	좋음	매우 좋음
이미지 관리	좋음	좋음	좋음	매우 좋음
보안성	좋음	좋음	매우 좋음	좋음
자원 사용량	매우 좋음	매우 좋음	좋지 못함	좋음
정보량	적음	거의 없음	거의 없음	매우 많음

-> 도구들의 특징을 비교했을 때 현재 쿠버네티스 인프라를 구성하는 데 가장 적합한 도구로 도커를 선택함

4.2 도커로 컨테이너 다루기

컨테이너 이미지는 베이그런트 이미지와 유사. 베이그런트 이미지는 이미지 자체로는 사용할 수 없고 베이그런트를 실행할 때 추가해야만 사용할 수 있음. 이와 마찬가지로 컨테이너 이미지도 그대로는 사용할 수 없고 도커와 같은 CRI로 불러들여야 컨테이너가 실제로 작동.

4.2.1 컨테이너 이미지 알아보기

이미지 검색하고 내려받기
이미지는 레지스트리라는 저장소에 모여있음. 별도의 레지스트리를 지정하지 않으면 기본으로 도커 허브에서 이미지를 찾음.

현재 사용할 수 있는 nginx 이미지 찾아보기

1) INDEX : 이미지가 저장된 레지스트리의 이름
2) NAME : 검색된 이미지 이름 (레지스트리 주소/저장소 소유자/이미지 이름)
3) DESCRIPTION : 이미지에 대한 설명
4) STARS : 해당 이미지를 내려받은 사용자에게 받은 평가 횟수
5) OFFICIAL : OK 표시는 해당 이미지에 포함된 애플리케이션, 미들웨어 등을 개발한 업체에서 공식적으로 제공한 이미지라는 의미
6) AUTOMATED : OK 표시는 도커 허브에서 자체적으로 제공하는 이미지 빌드 자동화 기능을 활용해 생성한 이미지를 의미

nginx 이미지를 내려받기

1) 태그 : Using default tag와 함께 뒤에 따라오는 태그 이름을 통해 이미지를 내려받을 때 사용한 태그를 알 수 있음. 기본으로 latest 태그가 적용됨. 가장 최신 이미지를 의미
2) 레이어 : 31b3f1ad4ce1 등은 pull을 수행해 내려받은 레이어. 하나의 이미지는 여러 개의 레이어로 이루어져 있어서 레이어마다 Pull complete 메시지가 발생
3) 다이제스트 : 이미지의 고유 식별자로, 이미지에 포함된 내용과 이미지의 생성 환경을 식별할 수 있음. 다이제스트는 고유한 값이므로 다이제스트가 같은 이미지는 이름이나 태그가 다르더라도 같은 이미지임
4) 상태 : 이미지를 내려받은 레지스트리, 이미지, 태그 등의 상태 정보를 확인

이미지 태그
태그 : 이름이 동일한 이미지에 추가하는 식별자. 이름이 동일해도 도커 이미지의 버전이나 플랫폼이 다를 수 있기 때문에 이를 구분하는 데 사용. 컨테이너를 배포할 때는 latest 태그가 아닌 검증된 버전으로 배포해야 문제가 생기지 않음

이미지의 레이어 구조
이미지는 ZIP 같은 압축 파일에 더 가까움
이미지는 같은 내용일 경우 여러 이미지에 동일한 레이어를 공유하므로 전체 용량이 감소함.

stable 태그 적용하여 nginx 이미지 내려받기

-> 이미 존재하는 레이어는 내려받지 않고 재사용함

내려받은 이미지 조회
stable 이미지가 어떤 과정을 거쳐 생성됐는지 확인

-> SIZE 열의 용량을 모두 더하면 142MB의 이미지가 생성된 것을 알 수 있음. 마지막은 80.5MB

latest 이미지의 생성 과정과 용량 확인

-> 80.5MB 부분이 nginx:stable 부분과 같음.

-> 레이어를 두 이미지가 공유하고 있기 때문이다!

4.2.2 컨테이너 실행하기

새로운 컨테이너 실행

-> 결과 값으로 16진수 문자열이 나옴. 컨테이너를 식별할 수 있는 고유한 ID임. -d : 컨테이너를 백그라운드에서 구동한다는 의미. / --restart always : 가상 머신을 중지한 후 다시 실행해도 자동으로 컨테이너가 기존 상태를 이어갈 수 있게 함

컨테이너 상태 확인

1) CONTAINER_ID : 컨테이너를 식별하기 위한 고유 ID
2) IMAGE : 컨테이너를 만드는 데 사용한 이미지
3) COMMAND : 컨테이너가 생성될 때 내부에서 작동할 프로그램을 실행하는 명령어
4) CREATED : 컨테이너가 생성된 시각을 표시
5) STATUS : 컨테이너가 작동을 시작한 시각을 표시
6) PORTS : 컨테이너가 사용하는 포트와 프로토콜을 표시.
7) NAMES : 컨테이너 이름을 표시

컨테이너를 지정해 검색

-f : 검색 결과를 필터링할 수 있음. key-value 형식으로 입력. 이때 value에 해당하는 문자열을 포함하는 경우를 필터링함.

컨테이너가 제공하는 nginx 웹 페이지 정보를 가져오게 함.

-> 오류가 발생함

curl 127.0.0.1로 전달한 요청을 로컬호스트의 80번 포트로 전달만 될 뿐 컨테이너까지는 도달하지 못함. -> 호스트에 도달한 후 컨테이너로 도달하기 위한 추가 경로 설정이 돼 있지 않은 것. -> 80번으로 들어온 것을 컨테이너에서 받아줄 수 있는 포트로 연결해 주는 설정이 추가로 필요.

새로운 컨테이너를 실행

-p : 외부에서 호스트로 보낸 요청을 컨테이너 내부로 전달하는 옵션 (요청 받을 호스트 포트 : 연결할 컨테이너 포트)

컨테이너가 제대로 작동하는지 확인 (이름으로 필터링)

1) 0.0.0.0:8080->80/tcp : 0.0.0.0의 8080번 포트로 들어오는 요청을 컨테이너 내부의 80번 포트로 전달한다는 의미.
2) nginx-exposed : 현재 작동 중인 컨테이너의 이름

웹 브라우저에 접속

-> 영속적으로 웹 페이지 파일을 사용하기 위해서는 특정 디렉터리와 컨테이너 내부의 디렉터리를 연결하는 것이 효과적인 사용법임

4.2.3 컨테이너 내부 파일 변경하기

[컨테이너 내부에서 외부 파일을 사용하는 방법]

구분	docker cp	Dockerfile ADD	바인드 마운트	볼륨
컨테이너 적용	구동 중 복사	이미지 생성 시 복사	구동 시 디렉터리 연결	구동 시 도커의 볼륨 연결
파일 보관 위치	컨테이너 내부	컨테이너 내부	호스트(디렉터리)	호스트(도커 볼륨)
주 활용 용도	임시 파일	컨테이너 생성 시 필요한 파일	보존이 필요한 파일	보존이 필요한 파일
관리 편의성	좋지 못함	좋음	좋음	매우 좋음
파일 보존성	좋지 못함	좋음	매우 좋음	매우 좋음

-> 4가지 방법 중에 nginx 웹 페이지를 사용자가 변경하기에 가장 용이한 바인드 마운트와 볼륨을 실습을 통해 확인

바인드 마운트로 호스트와 컨테이너 연결하기
1. 컨테이너 내부에 연결할 /root/html 디렉터리를 호스트에 생성

nginx-bind-mounts라는 이름의 컨테이너 구동하고, 컨테이너의 /usr/share/nginx/html/ 디렉터리와 호스트의 /root/html 디렉터리를 연결

-v : 호스트 디렉터리와 컨테이너 디렉터리를 연결하는 옵션(호스트 디렉터리 경로:컨테이너 디렉터리 경로)

nginx-bind-mounts 컨테이너를 조회해 STATUS가 정상인지 확인
컨테이너 내부와 연결된 /root/html/ 디렉터리를 확인

-> 빈 디렉터리가 컨테이너와 연결됐기 때문에 현재 컨테이너의 nginx는 초기 화면으로 보여 줄 파일이 없음

웹 브라우저를 열고 132.168.1.10:8081에 연결해 nginx에 접속되는지 확인

-> 오류 화면이 보임. 해당 파일이 존재하지 않기 때문임.

호스트 디렉터리와 컨테이너 디렉터리를 연결할 때 사용할 index.html을 /root/html에 복사

웹 브라우저에서 다시 접속

볼륨으로 호스트와 컨테이너 연결하기
볼륨은 도커가 직접 관리하며 컨테이너에 제공하는 호스트의 공간.

볼륨 생성 nginx-volume은 생성할 볼륨의 이름
생성된 볼륨을 조회

-> 볼륨에 적용된 드라이버 종류, 실제 호스트에 연결된 디렉터리, 볼륨 이름 등을 조회 / Mountpoint 행의 디렉터리가 볼륨 디렉터리임.

볼륨으로 생성된 디렉터리를 확인
nginx-volume이라는 컨테이너를 구동하고 컨테이너 내부의 /usr/share/nginx/html 디렉터리와 호스트의 nginx-volume 볼륨을 연결

-v [볼륨 이름]:[컨테이너 디렉터리]

볼륨 디렉터리의 내용을 다시 확인

-> 바인드 마운트와 달리 빈 디렉터리를 덮어 쓰지 않고 컨테이너 내부에 있는 파일을 보존함.

웹 브라우저로 nginx-volume 컨테이너의 nginx에 접속

볼륨은 바인드 마운트와 달리 양쪽을 서로 동기화 시키는 구조이기 때문에 비어 있는 볼륨을 연결하는 경우에는 컨테이너 디렉터리에 있는 파일이 보존됨. 하지만 볼륨에 컨테이너 디렉터리와 동일한 파일이 존재한 상태로 연결하는 경우에는 덮어쓰기가 됨

바꿀 파일을 볼륨 디렉터리로 복사해 볼륨에서 변경한 내용이 컨테이너 디렉터리에 동기화되는지 테스트
웹 브라우저에서 다시 연결하여 바뀐 내용 표시

-> 바인드 마운트보다 볼륨이 관리하기가 더 쉬움

4.2.4 사용하지 않는 컨테이너 정리하기

컨테이너 정지하기

nginx 이미지를 기반으로 생성된 컨테이너를 조회

ancestor 키 : 컨테이너를 생성하는 데 사용한 이미지를 기준으로 필터링

elastic_colden 컨테이너를 정지
nginx-exposed 컨테이너를 컨테이너 ID로 정지
nginx 이미지를 사용하는 모든 컨테이너 ID 조회

-q : 컨테이너 ID만 출력하게 함

nginx 이미지를 사용하는 모든 컨테이너를 한꺼번에 정지
모든 컨테이너가 정지됐는지 확인
정지된 컨테이너를 포함해 모든 컨테이너 목록을 조회

-a : 정지된 컨테이너를 포함해 조회함

컨테이너와 이미지 삭제하기
1. 현재 정지된 모든 컨테이너를 삭제

컨테이너가 정상적으로 삭제됐는지 확인
용량 확보를 위해 더 이상 필요 없는 이미지를 삭제

4.3 4가지 방법으로 컨테이너 이미지 만들기

4.3.1 기본 방법으로 빌드하기

기본적인 컨테이너 빌드 도구와 파일이 있는 빌드 디렉터리로 이동해 어떤 파일이 있는지 확인

1) Dockerfile : 컨테이너 이미지를 빌드하기 위한 정보를 담고 있음
2) mvnw : 메이븐 실행을 위한 환경 설정을 자동화함
3) pom.xml : 메이븐 래퍼가 작동할 때 필요한 절차와 빌드 정보를 담고 있음
4) src : 메이븐으로 빌드할 자바 소스 디렉터리

자바 개발 도구 설치
자바를 빌드하기 위해 메이븐 실행
생성된 JAR 파일 확인
컨테이너 이미지 빌드

-t : 만들어질 이미지를 의미 / . : 이미지에 원하는 내용을 추가하거나 변경하는 데 필요한 작업 공간을 현재 디렉터리로 지정

Dockerfile 살펴보기

1) 1번째 줄 : 이미지를 가져옴. 가져온 이미지 내부에서 컨테이너 이미지를 빌드함.
2) 2번째 줄 : 이미지에 부가적인 설명을 위한 레이블을 추가할 때 사용
3) 3번째 줄 : 생성된 이미지로 컨테이너를 구동할 때 어떤 포트를 사용하는지 알려줌.
4) 4번째 줄 : 호스트에서 새로 생성하는 컨테이너 이미지로 필요한 파일을 복사.
5) 5번째 줄 : 이미지의 현재 작업 위치를 opt로 변경
6) 6번째 줄 : 컨테이너 구동 시 ENTRIYPINT 뒤에 나오는 대괄호 안에 든 명령을 실행. 첫 번째 문자열은 실행할 명령어, 두번째 문자열부터 명령어를 실행할 때 추가하는 옵션

생성한 이미지 확인
1.0과 2.0 태그의 이미지도 생성해보기

-> 캐시가 사용돼 매우 빠르게 빌드됨

생성된 이미지 확인

-> 이미지가 모두 ID와 용량이 같음. 태그 정보만 다를 뿐 모두 같은 이미지이며, 한 공간을 사용함

Dockerfile의 2번째 줄에 있는 Application 부분을 Development로 변경하고 다시 빌드. 태그는 3.0 사용
생성된 이미지 확인

-> 완전히 다른 ID의 이미지가 생성됨. 이름은 같지만 실제로는 다른 컨테이너 이미지다.

생성한 컨테이너 이미지가 컨테이너로 작동하는지 확인하기 위해 컨테이너 실행
컨테이너 상태 출력
curl을 이용해 컨테이너가 정상적으로 외부 요청에 응답하는지 확인
작동 중인 컨테이너를 바로 삭제
빌드한 컨테이너 이미지 모두 삭제
다음 절에서 빌드할 이미지와 용량을 비교하기 위해 컨테이너 이미지 하나를 다시 빌드
빌드한 컨테이너 이미지 보기

4.3.2 컨테이너 용량 줄이기

컨테이너 용량을 줄여서 빌드하는 과정을 담고 있는 디렉터리로 이동해 어떤 파일이 있는지 살펴보기
추가된 파일 cat으로 살펴보기
Dockerfile 변경된 내용 확인하기

사용되는 기초 이미지가 openjdk에서 distroless로 변경됨. 이것은 자바 실행을 위해 경량화된 이미지임.

메이븐에 실행 권한 부여
build-in-host.sh를 실행해 경량화 이미지 빌드
용량을 줄여 빌드한 컨테이너 이미지와 기본 방법으로 빌드한 이미지를 비교

-> 새로 생성된 optimal-img가 기존 basic-img보다 396MB 작음

생성한 컨테이너 이미지가 컨테이너로 작동하는지 컨테이너 실행
curl로 확인
빌드한 컨테이너 삭제

4.3.3 컨테이너 내부에서 컨테이너 빌드하기

openjdk 이미지에서 자바 소스를 빌드하는 내용이 있는 디렉터리로 이동해 어떤 파일이 있는지 살펴보기
Dockerfile 살펴보기

이미지 내부에 소스 코드를 내려받으려고 깃을 사용. 내려받은 소스 코드를 이미지 내부에서 실행하기 위해 RUN을 추가. 그리고 이미지 내부에서 파일의 위치만 옮기면 되므로 mv를 사용

이미지 내부에 내려받은 inbuilder 저장소가 어떤 구조인지 확인
컨테이너 이미지 빌드하기
새로 빌드한 컨테이너 이미지를 기존 이미지들과 비교

-> 새로 생성된 nohost-img가 633MB로 이미지 중에서 가장 용량이 큼. 컨테이너 내부에서 빌드를 진행하기 때문에 빌드 중간에 생성한 파일들과 내려받은 라이브러리 캐시들이 최종 이미지인 nohost-img에 그대로 남기 때문에

생성한 컨테이너 이미지가 컨테이너로 잘 작동하는지 컨테이너를 실행
curl로 확인
컨테이너를 삭제

4.3.4 최적화해 컨테이너 빌드하기

멀티 스테이지 빌드 방법은 최종 이미지의 용량을 줄일 수 있고 호스트에 어떠한 빌드 도구도 설치할 필요가 없음.

현재 사용하는 도커 버전을 확인
호스트 윈도 명령창에서 기존에 사용하던 가상 머신들을 제거
멀티 스테이지를 지원하는 버전의 도커가 포함된 새로운 쿠버네티스 클러스터 환경을 구성
슈퍼푸티로 m-k8s에 접속
도커 버전 확인
멀티 스테이지를 위한 파일이 있는 디렉터리로 이동해 Dockerfile이 있는지 확인
Dockerfile 살펴보기

멀티 스테이지의 핵심은 빌드하는 위치와 최종 이미지를 '분리'하는 것 -> 용량을 줄일 수 있음

멀티 스테이지 방식으로 작성된 Dockerfile로 컨테이너 이미지 빌드
멀티 스테이지로 빌드된 컨테이너 이미지의 용량을 확인

-> optimal-img와 같음. none으로 표시된 이미지가 있는데 이런 이미지를 댕글링 이미지라고 함. 멀티 스테이지 과정에서 자바 소스를 빌드하는 과정에 생성된 이미지임.

댕글링 이미지 삭제
컨테이너 실행
컨테이너가 잘 작동하는지 curl로 확인
컨테이너를 삭제하고 홈 디렉터리로 이동

4.4 쿠버네티스에서 직접 만든 컨테이너 사용하기

4.4.1 쿠버네티스에서 도커 이미지 구동하기

multistage-img 이미지가 노드에 존재하는지 확인
디플로이먼트 생성

--image 옵션으로 주어 multistage-img 이미지를 사용하게 하고 이름은 failure1로 설정

파드의 상태 및 변화를 확인

-> 이미지를 내려받는 데 문제가 발생해 오류 메시지가 번갈아 표시됨. -> 이미지가 호스트에 존재함에도 기본 설정에 따라 이미지를 외부에서 받으려고 시도하기 때문임.

내부에 존재하는 컨테이너 이미지를 사용하도록 설정해서 디플로이먼트를 생성

-> 현재 수행되는 구문을 야믈 형태로 뽑아냄. --dry-run=client : 해당 내용을 실제로 적용하지 않은 채 명령을 수행, -o yaml : 현재 수행되는 명령을 야믈 형태로 바꿈.

failure2.yaml을 열어 컨테이너 설정에 옵션을 추가

-> 외부에서 이미지를 가져오지 않고 호스트에 존재하는 이미지를 사용하게 함

수정한 failure2.yaml 파일을 디플로이먼트에 적용
상태 확인

-> 형태는 바뀌었지만 여전히 오류가 발생.

오류가 발생하는 디플로이먼트를 모두 삭제
슈퍼푸티로 w3-k8s에 접속
Dockerfile을 받아 와 테스트를 위한 컨테이너 이미지 만들기
컨테이너 이미지 multistage-img를 워커 노드 3번에 빌드하고 확인
마스터 노드로 돌아와 failure2.yaml을 success1.yaml로 복사
sucess1.yaml 파일에 replicas를 1에서 3으로 변경하고 failure2이름도 success1로 변경
success1.yaml를 실행
배포에 성공한 노드가 워커 노드 3번인지 확인

-> 컨테이너 이미지가 워커 노드 3번에만 있기 때문에 3번만 배포에 성공

배포한 Deployment 삭제
워커 노드 3번에 생성한 컨테이너 이미지와 댕글링 이미지도 삭제

4.4.2 레지스트리 구성하기

호스트에서 생성한 이미지를 쿠버네티스에서 사용하려면 모든 노드에서 공통으로 접근하는 레지스트리(저장소)가 필요. 도커 허브라는 레지스트리에서 이미지를 내려받을 순 있지만 외부에 공개되기를 원하지 않을 때도 있음 -> 제약 없이 사용할 수 있는 레지스트리를 직접 구축하는 방법이 있음.
여기서는 도커에서 제공하는 도커 레지스트리 이미지를 사용해 사설 도커 레지스트리를 만들 예정.

사설 이미지 레지스트리 구성을 위한 파일들을 확인.

인증서를 만들어 배포한 뒤 레지스트리를 구동하는 create-registry.sh 파일. 인증서를 만들 때 사용하는 tls.csr 파일. 인증 문제가 생겼을 때 모든 설정을 지우는 스크립트인 remover.sh 가 있음.

tls.csr 파일 살펴보기

1) 2번째 줄 : 인증서를 생성함.
3) 3번째줄 : 15~17번째줄을 추가 정보로 이용
4) 6~12번째 줄 : 인증서 요청자의 국가, 도시, 소속, 이름, 인증서를 설치하는 서버의 주소 등의 정보
5) 4~17번째 줄 : 키의 사용 목적을 기입, 19~21번째 줄의 정보를 주체 대체 이름으로 사용
6) 19~21번째 줄 : 도메인 이름과 사이트가 일치하는지를 확인할 때 사용하는 추가적인 정보. (이 부분이 없으면 도커에서 인증서 검증이 실패 사설 도커 레지스트리를 정상적으로 사용할 수 없음)

실제로 레지스트리를 생성하고 구동하는 과정이 담긴 create-registry.sh 살펴보기

1) 2번째 줄 : 해당 경로를 변수 certs에 설정. 도커는 디렉터리 하위 경로에서 레지스트리 주소와 일치하는 디렉터리에 위치한 인증서를 찾아 레지스트리에 HTTPS로 접속. 따라서 마스터 노드와 워커 노드에 인증서 디렉터리를 생성할 때 변수 certs를 인증서 디렉터리 경로로 사용
2) 3번째 줄 : 디렉터리 생성. 22번째 줄에서 컨테이너 내부의 경로에 연결돼 레지스트리 이미지가 저장됨
3) 4번째 줄 : 디렉터리를 생성. 이 디렉터리는 레지스트리 서버의 인증서들을 보관. 24~25번째 줄에서 레지스트리 컨테이너 내부에 연결돼 인증서를 컨테이너에서도 사용할 수 있게 함.
4) 5번째 줄 : 변수 certs에 입력된 경로를 이용해 인증서를 보관할 디렉터리를 생성
5) 6~7번째 줄 : 암호화와 복호화에 사용하는 키를 생성.
6) 9번째 줄 : SSH 접속을 위한 비밀번호를 자동으로 입력하는 sshpass를 설치.
7) 10번째 줄 : 1~3의 숫자를 반복해 변수 i에 설정하고 10~13번째 줄을 반복. 변수 i로 워커 노드 192.168.1.10{i}에 대한 인증서 디렉터리를 생성하고 인증서를 복사하는 작업을 반복
8) 12번째 줄 : 워커 노드에 인증서 디렉터리를 생성.
9) 13번째 줄 : 레지스트리 서버의 인증서 파일을 워커 노드로 복사
10) 16~17번째 줄 : 인증서 파일과 암호화 복호화에 사용하는 키를 해당 디렉터리로 복사하고 디렉터리로 옮김.
11) 19~21번째 줄 : 컨테이너를 백그라운드에서 데몬으로 실행하고, 정지되면 자동으로 재시작하며, 생성하는 컨테이너의 이름은 registry로 정함
12) 22번째 줄 : 사설 인증서와 관련된 파일들이 위치한 디렉터리를 컨테이너 내부에서 사용할 수 있도록 컨테이너 내부의 디렉터리와 연결
13) 23번째 줄 : 레지스트리에 컨테이너 이미지가 계속 저장될 수 있도록 호스트에 저장 공간으로 설정한 registry-image 디렉터리를 컨테이너 내부의 디렉터리와 연결
14) 24번째 줄 : 레지스트리가 요청을 받아들이는 포트로 443번 포트를 설정
15) 25번째 줄 : 레지스트리가 사용할 HTTPS 인증서의 경로를 설정
16) 26번째 줄 : HTTPS로 데이터를 주고받을 때 데이터의 암호화와 복화를 위한 키로 사용할 파일의 경로를 설정
17) 27번째 줄 : 호스트 컴퓨터의 8443번 포트와 컨테이너 내부의 443번 포트를 연결
18) 28번째 줄 : 도커 허브에 있는 registry 이미지로 레지스트리 컨테이너를 생성