<이론>
- 주제
- 컨테이너 통신 원리
- 컨테이너의 통신 방법
- 사용자 정의 브릿지 네트워크
- 컨테이너간의 통신
네트워킹 구조
CNM(Container Network Model)
Docker Network의 근본적인 아웃라인을 잡는 디자인 스펙인 설계문서
역할
- Container network 를 제공하는 데 필요한 단계(Step)를 정의
- 다수의 네트워크 드라이버를 지원하기 위해 필요한 추상화를 제공
⇒ 격리된 것과 같은 네트워크 구조를 구성하고 설정에 따라 로컬/원격 컨테이너와의 통신을 가능하게 함
구성
- Sandbox container 의 격리된 Network Stack으로 네트워크 스택 구성을 포함한다. container network interface, routing table 및 DNS 설정 관리 등을 할 수 있고 많은 여러 네트워크의 많은 Endpoints들을 가질 수 있습니다.
- Endpoint 1개의 네트워크와 1개의 Sandbox를 연결하는
veth
와 같은 가상 네트워크 인터페이스
- Network 다수의 Endpoint로 구성된 Switch(802.1d bridge)를 소프트웨어로 구현한 것 ⇒ 서로 통신해야 하는 Endpoint 그룹을 그룹화하거나 격리한다.
Libnetwork
CNM에 대한 표준 구현체으로서 네트워크에 대해 제어하고 관리함 오픈소스이며 Go로 작성되어 cross-flatform을 지원함
네트워킹에서의 도커데몬의 역할
- 초기 도커에서는 대부분의 역할을 도커 데몬이 했기에 네트워킹에 관련된 코드도 데몬 내에 존재 → 시간이 지나면서 데몬은 점점 무거워졌고 “작은 것이 아름답다”라는 리눅스 원칙을 따르지 않았습니다. 독립적으로 잘 작동하는 작고 모듈화된 복합적인 도구들을 개발한다는 철학으로서 이로인해 도커 네트워킹이 다른 프로젝트에 활용하기 쉽게 구성되지도 않았습니다 (재사용 불가)
- 현재 CNM에 기반을 둔 libnetwork 외부의 라이브러리로 리팩터링되었습니다. 그래서 현재는 모든 핵심 도커 네트워킹 코드는 libnetwork에 존재합니다. libnetwork는 독립적이고 모듈화되어 조립하여 사용할 수 있게끔 제작되었습니다. 기본 Service Discovery, 수신 기반의 ingress-based 컨테이너 로드밸런싱, 네트워크 제어부분와 관리부분 기능을 구현합니다.
Driver
데이터들을 다룸
장점
플러그형 인터페이스로 인해 연결될 수 있다 ⇒ Libnetwork의 이식성 확대의 이유 즉, 플러그형의 드라이버를 사용하여 네트워크를 구성가능하다.
종류
- 내장 네트워크 드라이버 Docker Engine에 포함
- User-defined bridge networks(bridge networks) 같은 호스트 상에서 여러 컨테이너의 통신이 필요할 때
- None networks 최소한의 네트워크 환경만을 생성하고 싶을 때
- Host networks 컨테이너로 분리되길 원하지만 네트워크 스택은 분리되지 않길 원할 때 (호스트 네트워크를 같이 쓰길 원할 때)
- Overlay networks 다른 호스트 상에서 실행되는 컨테이너가 통신해야 할 때나 스웜 서비스로 여러 앱이 실행되어야 할 때
- Macvlan networks VM 환경에서부터 마이그레이션 해야하거나 네트워크 상에서 고유한 MAC 주소를 가진 물리적인 호스트처럼 보여야 할 때
- 플러그인 네트워크 드라이버 네트워킹 벤더와 커뮤니티에서 제공
컨테이너 통신 원리
docker0(도커제로)
도커데몬이 시작되면 만들어짐으로써 (도커를 처음 설치하게 되면 도커 호스트에 docker0라는 가상 네트워크 인터페이스가 생성됩니다.) 도커가 자체적으로 제공하는 L2 통신기반의 가상 네트워크 인터페이스
특징
# docker host $ ip link show docker0 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc... link/ether 02:42:af:f9:eb:4f brd ff:ff:ff:ff:ff:ff
- 모든 컨테이너가 외부로 통신하고 외부 엔드유저가 호스트 이더넷(eth0)에서 컨테이너로 접속할 수 있는 컨테이너의 게이트웨이 역할을 한다.
- 내장 네트워크 드라이버 중 브리지(Bridge)에 해당 =>컨테이너 간 통신을 할 수 있게 하는 소프트웨어 브리지이자 다른 브리지 네트워크에 연결된 컨테이너와 격리시켜준다.
- 도커 컨테이너를 생성하면 자동으로 이 docker0 브리지를 활용하도록 설정되어 있습니다.
- 브릿지네트워크(virtual ethernet bridge : 172.17.0.0/16(사이더 16 값) 서브넷)를 지원해준다.
- 브릿지 네트워크 대역대 안에서 도커0 자체는 172.17.0.1 아이피를 가짐
- 브릿지네트워크 컨테이너가 가지고 있는 대역대와 호스트(물리)장비가 가지고 있는 네트워크를 연결해주는 고리 역할.
- 브릿지 네트워크 세그먼트 간에 트래픽을 전달하는 역할로서 하드웨어 장치일 수도 있고 호스트 시스템의 커널 내에서 실행되는 소프트웨어 장치일 수 있는 링크 계층 장치
- 네트워크 세그먼트 네트워크 세그먼테이션은 네트워크를 여러 개의 세그먼트나 서브넷으로 나누는 아키텍처 방식으로서 각각이 소규모 네트워크 역할을 함
- 브릿지 네트워크를 지원해주기 위해서 내부적으로 NAT(Network Address Translation) 서비스와 iptables을 통한 포트포워딩 기능을 지원
cf) iptables 시스템 관리자가 리눅스 커널 방화벽이 제공하는 테이블들과 그것을 저장하는 체인, 규칙들을 구성할 수 있게 해주는 리눅스상의 사용자 공간 응용 프로그램 패킷의 헤더를 보고 그 패킷 전체를 어떻게 처리할지 결정하는 패킷필터링 기능을 제공함으로써 특정 조건을 가지고있는 패킷에 대해 허용(ACCEPT), 차단(DROP) 등을 지정할 수 있다. - 패킷필터링 구성 - 헤더 필터링할 정보인 출발지, 도착지, checksum, 프로토콜 등 - 데이터 각각의 정보 - Chain 패킷이 어떻게 조작될지 상태를 지정하는 것으로 기본으로 내장되어있다. (-N을 통해 사용자 정의 체인 가능) - 내장으로 정의되어있는 정책 네트워크 트래픽에 대한 규칙들을 수행 - INPUT : 서버로 들어오는 패킷에 대한 기본 정책 (호스트를 향한 모든 패킷) - FORWARD : 서버를 거쳐 나가는 패킷에 대한 기본 정책 (호스트 컴퓨터가 목적지가 아닌 모든 패킷. 즉, 라우터로 사용되는 호스트 컴퓨터를 통과하는 패킷) - OUTPUT : 서버에서 나가는 패킷에 대한 기본 정책 (호스트 컴퓨터에서 발생하는 모든 패킷) --------> INPUT --------> My server ---------> OUTPUT ( <---------------------------FORWARD-------------------------> ) 가운데에 있는 내 서버를 기준으로 INPUT Chain : 내 서버를 목적지로 삼는 패킷이 통과됨 OUTPUT Chain : 내 서버에서 생성되어 외부로 나가는 패킷이 통과됨 FORWARD Chain : 내 서버를 통과해 다른 서버가 목적지인 패킷이 통과됨 - PREROUTING NAT 관련 설정을 위해 주로 사용된다. 들어오는 패킷에 대해 처리하는 지점. - POSTROUTING 나가는 패킷에 대해 처리하는 지점. - 명령어 및 옵션 -t : 테이블을 선택할 때 사용하는 옵션 -L : 현재 구성되어 있는 체인의 정책을 본다 -v(Verbose : 장황한, 상세한) : 상세정보
- 마스커레이드 (Masquerade) 내부의 사설 IP들이 외부 인터넷에 연결되도록 해주는 기능 cf) NAT (Network Address Translation) IP주소를 자신의 호스트 IP 어드레스로 바꿔서 외부로 보내주는 기능 (MASQUERADE 서비스) - 종류 - SNAT (Source NAT) 내부 사설 IP들이 외부로 나갈 때 공인 IP로 변환되는 것. 마스커레이드와 유사함. (내부 --> 외부) - DNAT (Destination NAT) 외부에서 요청이 들어오는 IP주소를 내부 사설 IP주소로 변환한다. (외부 --> 내부)
- 확인방법 iptables -t nat -L -v로 nat 테이블 보면 되는데 도커0가 172.17.0.0 네트워크에서 어디로든(ANYWERE) 나가게 되면 MASQUERADE 해주겠다. 즉, 호스트의 아이디로 바꿔서 송출해주겟다고 표시되어있음
- 기본적으로 도커가 동작될 때, 브릿지,호스트,none 네트워크가 동작이 돼. 그 중 브릿지 네트워크 쓰는 애가 도커0(기본 네트워크)야.
PROCESS
172.17.0.2이 도커0 만남(도커제로가 게이트웨이주소라서) → 도커0가 NAT 기능 적용시킴
- 도커데몬이 돌아가고 있는 상황에서 ipaddress 하면 정보가 출력됨
- 확인방법 docker inspect c1 ⇒ 그 중 NetworkSettings 컬럼의 SandboxID가 c1의 네트워크 환경을 만듬 그리고 veth0 생성되는데 얘가 컨테이너 안에있는 네트워크 인터페이스라고 생각하셈. 글고 그거 말고도 gateway,ip주소 등등 다 있으니까 확인 가능
내부 네트워크 인터페이스
- 도커 컨테이너가 가지는 기본적인 인터페이스 lo, eth0 인터페이스
- 한계 각 컨테이너의 eth0에는 127.17.x.x/16 대역에 해당하는 IP를 할당 받지만 이 대역은 호스트 내부의 사설 IP이므로 외부에서 접속이 불가능합니다. (Container에 할당되는 IP는 컨테이너가 재시작될 때마다 변경될 수 있으니 참고)
- 대안 도커 엔진에서는 외부 환경과 통신을 위해 한쌍(2개)의 네트워크 인터페이스(리눅스의 버추얼 이더넷 인터페이스)를 생성
- eth0 인터페이스 호스트의 이더넷 인터페이스로서 컨테이너 내부 Namespace에 할당됨
- veth 가상 네트워크 인터페이스 vethXXXXXXX 이름을 가지며 호스트 네트워크 브리지 docker0에 바인딩됨.
docker network link
명령어를 이용해서 네트워크 네임스페이스들을 터널로서 연결하거나 물리 디바이스와 다른 네트워크 네임스페이스의 장비를 연결하는 용도로 사용
Docker Container 실행 시 Process
container run → Container 기술로 설정된 환경을 격리 시킴 → 도커엔진이 한 쌍의 네트워크 인터페이스를 생성 → 172.17.X.Y인 가상 ip 주소가 컨테이너의 실행 순서대로 순차적으로 할당
컨테이너의 통신 방법
port-forwarding
- container port를 열어서 컨테이너를 매핑하고 외부 연결 허용하게 한다.
- 컨테이너화된 어플리케이션이 외부에 서비스를 해주게끔 외부에서 접속이 가능하도록 하는 방법
ex) 도커호스트안에 nignx컨테이너(웹서버),appjs컨테이너가 있는 상황에서 웹서버 내의 웹 기반 컨테이너 서비스 러닝 시, 172.17.0.2에 80 포트 열어서 외부에서 접근할 수 있게 하려면 port-forwarding(포트포워딩 작업)이 필요함. ( ∵ eth0 인터페이스를 통해서만 컨테이너로 접근 가능. 물론 밖에선 veth로 접근했겠지)
방법
nginx컨테이너에서 docker run --name web -d -p 80:80 nginx:1.14
작업 → 도커호스트의 백엔드로, 리눅스 상의 방화벽 룰(iptables rule)에 등록하여서 포트 노출시켜줌 → 확인 : iptables -t nat -L -n -v
옵션
-p <hostPort(ip주소:포트 혹은 포트):containerPort>
해당 호스트포트로 접속하면 해당 컨테이너 포트로 포워딩 시켜줌
- -
p <containerPort>
컨테이너 포트만 열어서 사용하는 경우이므로 호스트의 랜덤 포트(실행순으로 발급되는 차수)가 열리게 되고 지정한 컨테이너 포트로 포워딩 시켜줌
-P(대문자)
컨테이너 포트는 dockerfile의 expose 명령어로 정의된 포트들 중 하나가 되고 호스트포트는 랜덤 포트(실행순으로 발급되는 차수)로 골라서 포워딩 시켜줌
특징
한 포트당 하나의 포워딩만 가능(중복이 불가함) 각각의 컨테이너가 같은 포트로 실행되는 건 다르게 할당된 아이피내에서의 실행이라 상관없지만 호스트의 포트는 하나만 열리게 되고 그 포트를 가지고 누구한테 포워딩은 해줘야하는지는 선택이 필요 ⇒ 대신, 호스트쪽은 다르게 열고 컨테이너 포트를 같게/다르게 하는 식은 가능함. ex) docker run --name test -p 80:8080 -d smlinux/appjs
호스트쪽은 80으로 열고 컨테이너는 8080으로 연결해주는 것 컨테이너는 기본으로 8080 포트를 사용하고 있고 외부에서는 호스트쪽에 80으로 접속하면 컨테이너 8080으로 포트포워딩 시켜주겠다.
사용자 정의 브릿지 네트워크
user-defined bridge network(사용자 정의 브릿지 네트워크)를 생성해서 컨테이너 네트워크 정의가 가능하다.
기본적으로 도커0 인터페이스 안에 있는 네트워크는 스태틱 ip 할당이 안됨. static ip(고정 ip)를 정하지 않으면 랜덤 순차 할당 ip를 받으므로 static ip 할당하거나 커스텀 네트워크 대역대 넣고싶으면
- 도커0 네트워크 대역대를 바꾸는 방법
- 사용자정의브릿지네트워크를 생성하는 방법(여기선 이걸 다룸)
- HOW TO
docker network create
--driver --subnet --gateway + network명
이후, run 해줄 때--net
옵션 + 지정해준 network명
- --driver 네트워크의 타입(bridge/host/none) 설정 옵션 기본은 bridge(생략가능함)
- --subnet 정하거나 생략가능 생략 시, 172.18로 자동 할당( ∵ 도커제로가 172.17로 사용중) 이미 그거 또 쓰고 있으면 171.19로…반복되는 순차 할당..
- --gateway 정하거나 생략가능 생략 시, 192.168.100.1이 자동으로 할당
- ex)
# 1. 사용자 정의 브릿지 네트워크 생성 $ docker network create --driver bridge \ --subnet 192.168.100.0/24 \ --gateway 192.168.100.254 mynet # 만들어진 네트워크 확인 $ docker network ls
# 네트워크 아무것도 안넣어주면 기본으로 도커제로 네트워크 씀 # 따라서, 아이피 주소는 지정해준 대역대로 192.168.100.1부터 순차적으로 할당됨 $ docker run -d --name web -p 80:80 nginx:1.14 $ curl localhost # 2. # appjs를 실행해주는데 만들어준 네트워크인 mynet로 지정해서 실행하게 함 # static 네트워크로 192.168.100.100 설정 $ docker run -d --name appjs --net mynet --ip 192.168.100.100 -p 8080:8080 smlinux/appjs $ curl localhost:8080 # static ip 할당 후에 컨테이너 안에 바로 들어가도록 실행하는 것 $ docker run -it --name appjs --net mynet --ip 192.168.100.100 busybox $ ip addr #하면 고정된 static ip가 할당된 게 보이고 $ ping -c 3 8.8.8.8 #이 네트워크는 브릿지네트워크라서 도커0처럼 웹으로 통신되는 게 가능함. $ exit $ crm
컨테이너간의 통신
프론트/백엔드 컨테이너 형태로 두 컨테이너 간의 통신을 통해 데이터를 주고받는 server & client 멀티티어 서비스 예제
⇒ wordpress으로 만드는 웹 어플리케이션(웹서버)
- mysql 컨테이너 실행
$ docker run -d --name mysql -v /dbdata:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=wordpress \ -e MYSQL_PASSWORD=wordpress mysql:5.7
- 볼륨 마운트 작업 mysql에서 만들어진 데이터를 따로 호스트 시스템에도 저장하기 위함.
- -e 환경변수로 루트패스워드랑 mysql 패스워드(==워드프레스가 사용하는 패스워드)를 지정.
- wordpress 컨테이너 실행 wordpress를 통해서 만들어진 웹서버가 동작됨.
$ docker run -d --name wordpress --link mysql:mysql \ -e WORDPRESS_DB_PASSWORD=wordpress -p 80:80 wordpress:4
- wordpress 웹 페이지를 쉽게 제작할 수 있게 만들어주는 웹 어플리케이션 아파치웹서버가 내장, PHP로 작성, DB는 MySQL 또는 마리아DB 사용됨 필요하면 워드프레스의 다양한 기능들을 이용해서 웹 서비스 구축 가능함.
-link + 연결시키고자하는 컨테이너이름 + :그 컨테이너의 별칭
두개의 컨테이너를 연결해주는 옵션- wordpress 어플리케이션 내에서 MySQL이나 마리아DB 쓰도록 정의되어있어서 연동을 시키는 것임.
- -e 환경변수로 mysql에서 사용하는 디비패스워드를 지정.
- -p 워드프레스는 외부에서 접근가능해야하니까 포트포워딩 시켜줌.
- PROCESS 클라잉언트 사용자가 eth0(172.27.20.50:80)에 접속 → 도커제로가 받아서 172.17.0.2에 80 포트로 wordpress 컨테이너 연결시키고 후 워드프레스 버전 4 접속가능해짐 → wordpress 컨테이너는 mysql의 디비 패스워드를 가지고 디비랑 연동해서 워드프레스에서 만들어지는 모든 데이터는 mysql에 저장되게 함 → 그 저장된 데이터는 도커호스트의 dbdata라는 스토리지에도 저장되게 됨. → 웹브라우저에서 로드밸런스 ip와 80포트로 wordpress 서버에 접속하면 워드프레스 첫 화면이 뜸
- 로드밸런스 ip ip addr 하면 나오는 eth0의 172.27.20.50와 연동되는 것이다. 동그라미그림이 게이트웨이고 처음에 접근한 로드밸런스 ip인거야.
- dbdata에서 ls 해보면 wordpress 폴더가 있꼬거기서 만들어진 데이터가 쌓이는 중임
<실습>
- 컨테이너 네트워크 사용하기
- 컨테이너 포트 외부로 노출하기
- user-defined network 구성하기
컨테이너 네트워크 사용하기
$ ip addr # docker0 인터페이스는 ip주소는 172.17.0.1인 것 확인 가능 $ brctl show # 도커0가 브릿지인터페이스란 것을 확인 가능 $ docker run --name c1 -it busybox # 첫 번째로 실행되는 컨테이너라서 ip주소는 172.17.0.2 가짐 $ docker inspect c1 혹은 ip addr # 확인 가능 $ docker run --name c2 -it busybox # 두 번째로 실행되는 컨테이너라서 ip주소는 172.17.0.3 가짐 $ docker inspect c1 혹은 ip addr # 확인 가능 $ docker run -d -p 80:80 --name web1 nginx # 세 번째로 실행되는 컨테이너라서 ip주소는 172.17.0.4 가짐 $ curl 172.17.0.4 # 실행 시, nginx 홈 페이지 뜸 $ ping -c 3 8.8.8.8 # 외부 통신되는지 보기 위해 커넥션 3개를 구글의 dns(8.8.8.8)로 보낸다 $ exit $ crm #crm 명령하면 컨테이너 초기화 시켜주는 명령어 지정해준 적 있었짢아 예전에. #alias로 확인하면 됨. docker rm -f $(docker ps -aq)로 정의해있음. #그래서 crm 한번 해준다.
컨테이너 포트 외부로 노출하기
이 컨테이너 3개는 외부로 연결받아서 서비스해줄 수 있음. 즉, 호스트포트는 각각 따로 사용하고 있지만 컨테이너는 3개의 nginx가 동작되고 있고 이에 대해서는 호스트의 80,49154,5 포트로 커넥션해서 서비스 가능함.
# 로컬호스트의 80으로 접속하면 컨테이너 80포트로 연결해주라는 것 $ docker run --name web1 -d -p 80:80 nginx:1.14 $ curl localhost:80 # 연결 시, 바로 web1 컨테이너로 연결되는 것 확인 가능. # 로컬호스트포트는 대역대 중에서 랜덤으로 열리고 컨포만 80포트로 매핑됨 $ docker run --name web2 -d -p 80 nginx:1.14 $ curl localhost:49154 # 연결 시, 바로 web2 컨테이너 연결되는 것 확인 가능. # 랜덤 호포 + 도커파일 내의 EXPOSE로 지정된 포트 중 랜덤 컨포 매핑 $ docker run --name web3 -d -p nginx:1.14 $ curl localhost:49155 # 연결 시, 바로 web3 컨테이너 연결되는 것 확인 가능. $ crm
user-defined network 구성하기
mynet이라는 네트워크만들고 mynet안에서 appjs,busybox 컨테이너를 실행해보도록 하자. 그리고 실제 고정된 ip할당됐는지, 외부통신 되는지 알아보자
#기본적으로 도커가 동작될 떄는 브릿지,호스트,none 네트워크가 동작이 돼. #그 중 브릿지 네트워크 쓰는 애가 도커0(기본 네트워크)야. $ docker network ls #네트워크 정보 조회 #그럼 mynet 네트워크 써서 c1이라는 네트워크 컨테이너 만들면 #얘는 아이피주소가 192.168.100.1가 돼. $ docker network inspeect mynet
<과제>
빌드된 내용으로 nginx 연동시켜서 컨테이너를 운영시키는 예제
- 다음의 containe를 빌드하라
$ cat genid.sh #!/bin/bash mkdir -p /webdata while true do /usr/bin/rig | /usr/bin/boxes -d boy > #둘 중 파일이 디렉토리면 boy를 index 파일에 합친다(만들어준다) /webdata/index.html sleep 5 #5초 잠재우고 done $cat Dockerfile FROM ubuntu:18.04 RUN apt-get update ; apt-get -y install rig boxes ADD genid.sh /bin/genid.sh RUN chmod +x /bin/genid.sh ENTRYPOINT ["/bin/genid.sh"] $docker build -t genid .
- 빌드한 containe를 이용해 multi-tier 컨테이너를 구축하라
genid에서 생성한 index.html은 volume을 통해 nginx의 웹컨테츠로 공유되어야한다.
nginx 웹서버는 80포트를 통해 genid가 생성한 html문서를 고객에게 서비스한다.
결과 : genid는 웹문서를 생성하고 nginx는 고객에게 서비스하는 식으로 운영됨
⇒
$cd Docker $mkdir genid # 문제에서 주어진 내용 복붙 $vim genid.sh $vim Dockerfile $docker build -t genid . #2 [internal] load .dockerignore #2 sha256:2ec5ad77ec4ec58b687e86904529ff93ef2987e189a6d7e2922ed000af7eac68 #2 transferring context: 2B 0.0s done #2 DONE 0.2s #1 [internal] load build definition from Dockerfile #1 sha256:348b241c5ad48a1f46ac9f7c4975a357f787c7ada468f9609f08c4b4abf9ca91 #1 transferring dockerfile: 192B 0.0s done #1 DONE 0.3s #3 [internal] load metadata for docker.io/library/ubuntu:18.04 #3 sha256:ae46bbb1b755529d0da663ca0256a22acd7c9fe21844946c149800baa67c4e4b #3 ... #4 [auth] library/ubuntu:pull token for registry-1.docker.io #4 sha256:e604e5c8adf08523dd9f6f562301fdeb02b8479f3ef2f53cc18bdffa00d259ad #4 DONE 0.0s #3 [internal] load metadata for docker.io/library/ubuntu:18.04 #3 sha256:ae46bbb1b755529d0da663ca0256a22acd7c9fe21844946c149800baa67c4e4b #3 DONE 10.2s #5 [1/4] FROM docker.io/library/ubuntu:18.04@sha256:d21b6ba9e19feffa328cb3864316e6918e30acfd55e285b5d3df1d8ca3c7fd3f #5 sha256:53273ad4520aa1284152d7e1f19bf0313614c3b43953cf750421d3783f9631cc #5 resolve docker.io/library/ubuntu:18.04@sha256:d21b6ba9e19feffa328cb3864316e6918e30acfd55e285b5d3df1d8ca3c7fd3f 0.1s done #5 ... #7 [internal] load build context #7 sha256:fc0a7cc74ca98ea934b703fff92b1a343f3c93211dcd274e60776fa34dad5d3e #7 transferring context: 155B 0.0s done #7 DONE 0.1s #5 [1/4] FROM docker.io/library/ubuntu:18.04@sha256:d21b6ba9e19feffa328cb3864316e6918e30acfd55e285b5d3df1d8ca3c7fd3f #5 sha256:53273ad4520aa1284152d7e1f19bf0313614c3b43953cf750421d3783f9631cc #5 sha256:971a12d7e92a23183dead8bfc415aa650e7deb1cc5fed11a3d21f759a891fde9 529B / 529B done #5 sha256:c6ad7e71ba7d4969784c76f57c4cc9083aa96bb969d802f2ea38f4aaed90ff93 1.46kB / 1.46kB done #5 sha256:d21b6ba9e19feffa328cb3864316e6918e30acfd55e285b5d3df1d8ca3c7fd3f 1.41kB / 1.41kB done #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 0B / 26.71MB 0.3s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 2.10MB / 26.71MB 1.1s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 4.19MB / 26.71MB 1.6s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 6.29MB / 26.71MB 2.1s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 8.39MB / 26.71MB 2.6s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 10.49MB / 26.71MB 3.3s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 12.58MB / 26.71MB 5.0s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 14.68MB / 26.71MB 5.5s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 16.78MB / 26.71MB 6.1s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 18.87MB / 26.71MB 6.7s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 20.97MB / 26.71MB 7.2s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 23.07MB / 26.71MB 7.8s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 25.17MB / 26.71MB 8.4s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 26.71MB / 26.71MB 8.9s #5 sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 26.71MB / 26.71MB 9.4s done #5 extracting sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 #5 extracting sha256:40dd5be53814ae70b2898558673b7ea18d58bf7ab3433560b9ce3cb76d9ff0b1 3.6s done #5 DONE 15.7s #6 [2/4] RUN apt-get update ; apt-get -y install rig boxes #6 sha256:58f578a1d106094db83654435c82daf138ef6b43aa02c1924271c50fb5954df4 #6 1.698 Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] #6 1.720 Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB] #6 2.908 Get:3 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [22.8 kB] #6 2.983 Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] #6 3.257 Get:5 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [954 kB] #6 3.430 Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] #6 3.875 Get:7 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 kB] #6 4.523 Get:8 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [13.5 kB] #6 4.536 Get:9 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB] #6 7.227 Get:10 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [2792 kB] #6 8.927 Get:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 MB] #6 19.11 Get:12 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [1507 kB] #6 46.58 Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [2281 kB] #6 53.94 Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [988 kB] #6 57.16 Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [3223 kB] #6 67.97 Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [29.8 kB] #6 68.06 Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [12.2 kB] #6 68.09 Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [12.9 kB] #6 68.35 Fetched 25.2 MB in 1min 7s (374 kB/s) #6 68.35 Reading package lists... #6 70.02 Reading package lists... #6 71.50 Building dependency tree... #6 71.81 Reading state information... #6 72.18 The following NEW packages will be installed: #6 72.18 boxes rig #6 72.68 0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded. #6 72.68 Need to get 91.4 kB of archives. #6 72.68 After this operation, 269 kB of additional disk space will be used. #6 72.68 Get:1 http://archive.ubuntu.com/ubuntu bionic/universe amd64 boxes amd64 1.2-2 [66.6 kB] #6 73.39 Get:2 http://archive.ubuntu.com/ubuntu bionic/universe amd64 rig amd64 1.11-1build2 [24.8 kB] #6 73.68 debconf: delaying package configuration, since apt-utils is not installed #6 73.75 Fetched 91.4 kB in 1s (74.2 kB/s) #6 73.84 Selecting previously unselected package boxes. (Reading database ... 4051 files and directories currently installed.) #6 73.85 Preparing to unpack .../archives/boxes_1.2-2_amd64.deb ... #6 73.89 Unpacking boxes (1.2-2) ... #6 74.07 Selecting previously unselected package rig. #6 74.08 Preparing to unpack .../rig_1.11-1build2_amd64.deb ... #6 74.13 Unpacking rig (1.11-1build2) ... #6 74.36 Setting up boxes (1.2-2) ... #6 74.52 Setting up rig (1.11-1build2) ... #6 DONE 75.5s #8 [3/4] ADD genid.sh /bin/genid.sh #8 sha256:b2df10449da6707d766cfdd74e66684fc42db0024a5b7c946f131ede5dd0a9e9 #8 DONE 0.3s #9 [4/4] RUN chmod +x /bin/genid.sh #9 sha256:4e5ff93acb54ca118761f3aaf648ed21c4001fb10b82e7476b2efb9b7aea38f6 #9 DONE 0.9s #10 exporting to image #10 sha256:e8c613e07b0b7ff33893b694f7759a10d42e180f2b4dc349fb57dc6b71dcab00 #10 exporting layers #10 exporting layers 0.8s done #10 writing image sha256:703d5a7b24cc7308f5dad9c1b8d2a6e12a1b0793ea1d58ba257a499c832ca549 0.0s done #10 naming to docker.io/library/genid 0.1s done #10 DONE 0.8s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them $docker run -d -v /webdata:/webdata --name genid genid f07d04cc2c859adcd19a56f6fa786642aa13f2032f7ce278dbb89928e24f1021 $docker run -d --name nginx -v /webdata:/usr/share/nginx/html:ro -p 80:80 nginx 86c899d3cfe409c7b52e9d29021044d70463f7a1dc5de404f7d97ed0234fb4f4 $curl localhost:80 <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> <hr><center>nginx/1.21.6</center> </body> </html>
ㅡㅡ.. 저거 결과 아닌 거 같아서 다시 보니까 빌드해서 genid 실행했는데 실행되자마자 바로 꺼지는지 docker ps 해도 없고 webdata폴더도 당연히 없음 빌드부터 다시 해야할 듯..
'DEVOPS > Docker' 카테고리의 다른 글
[따배도] 10장 - 빌드에서 운영까지 (0) | 2022.06.01 |
---|---|
[따배도] 8강 - 컨테이너 스토리지 관리 (0) | 2022.05.12 |
[따배도] 7강 - 컨테이너 리소스 관리 (0) | 2022.05.12 |
[따배도] 6강 - 컨테이너 사용하기 (0) | 2022.05.12 |
[따배도] 5강 - 컨테이너 Registry (0) | 2022.05.12 |
Uploaded by Notion2Tistory v1.1.0