Docker

Docker 실습

<httpd 서비스를 컨테이너에서 실행>

1. docker exec 컨테이너명 yum -y install httpd # 패키지 설치
2. docker exec -d 컨테이너명 httpd -D FOREGROUND # 서비스 실행

-> 서비스 실행시에 systemd가 존재하지 않아 systemctl start등을 사용하지 못한다. 즉, 임의적으로 실행시켜야 함
📗 "httpd -D FOREGROUND" : 임의적 실행
📗 -d (=detach) : 백그라운드로 실행
📗 패키지 설치할때 -y옵션을 사용하지 않으면 사용자와 커뮤니케이션을 요구하기 때문에 커뮤니케이션을 할 수 없는 exec명령어 특성상 설치가 되지 않는다

도커에서의 데이터 관리

• 기본적으로 컨테이너에 생성되는 모든 파일은 컨테이너 레이어에 저장됨. 이 데이터들은 컨테이너와 함께 삭제되는 런타임 데이터인데, 이 데이터를 영구적으로 저장하려면 반드시 볼륨을 사용해야 함.

• 도커에서 볼륨을 사용하는 방법은 Bind Mount와 볼륨(Volume) 두 가지 방법이 존재

Bind Mount

• 초기 도커부터 사용했던 방식이며, 호스트의 특정 디렉토리와 컨테이너의 디렉토리를 연결하는 방식
• Bind Mount는 쉽게 사용할 수 있지만 도커에 의해 관리되지 않기 때문에 따로 기록하지 않으면 관리하기가 쉽지 않음
• 성능이 뛰어나지만, 호스트의 파일 시스템에 대한 의존도가 높음
• 만약 애플리케이션을 개발한다면 Bind Moount보다 볼륨을 사용하는 것을 권장
• Bind Mount는 호스트의 민감한 파일가지 접근할 수 있으므로 보안 측면인 문제가 발생

<Bind Mout에 관한 사용 사례>

• 호스트와 컨테이너가 /etc/resolv.conf와 같은 설정 파일을 공유할 때
• 호스트와 컨테이너가 개발 환경 사이에서 소스 코드나 빌드 아티팩트를 공유할 때
• 호스트의 파일 또는 디렉토리 구조가 컨테이너의 Bind Mount와 일치하도록 보장된 경우

1 . Bind Mount 사용 예시

mkdir bmdir1 # 바운드할 디렉터리 
docker run -itd --name os1 -v /root/bmdir1:/root/bmdir centos:7

-> os1 컨테이너의 bmdir을 생성해 호스트의 bmdir1 디렉터리와 링크시킨다
-> 호스트의 bmdir1에 어떤 파일을 생성해도 os1의 bmdir에도 생성된다. 마찬가지로 os1의 bmdir에 어떤 파일을 생성해도 호스트의 bmdir1에 생성된다.

📗 만일 호스트의 해당 경로에 디렉터리가 없다면 비어있는 디렉터리 자동 생성 후 링크 시킨다

2 . Bind Mount 단점 : 컨테이너 경로 주의

docker run -itd --name os3 -v /root/bmdir1/:/root/ centos:7

-> 컨테이너의 위치를 root 디렉터리로 지정하게 되면 호스트의 bmdir1의 내용이 컨테이너의 root디렉터리에 덮어지게 된다.

-> 이때 root 디렉터리에 있어야 할 bash관련 파일들이 덮어지면서 없어진다

-> 따라서 prompt를 담당하는 bash파일들이 없어지면서 실제로 해당 컨테이너에 exec으로 접속하게 되면 prompt창이 바뀌어져 있는 것을 확인
-> cp를 이용해 다른 컨테이너의 root에 있는 .bashrc, .bash_profile을 다시 링크된 bmdir1에 넣으면 다시 prompt가 원래대로 돌아온다

Volume

• 도커에 의해 관리되는 스토리지
• docker 명령을 사용하여 생성할 수 있고, 사용되지 않으면 한꺼번에 삭제할 수 도 있음
• 이미지의 Volumes부분에 어떤 값이 지정되어 있으면, 컨테이너로 실행할 때 볼륨을 지정해야 함
• 그렇지 않으면 임의의 이름으로 볼륨을 생성하게 되고 이런 볼륨은 어떤 데이터를 저장하는지 그리고 어떤 데이터를 저장하고 있는지 모르기 때문에 관리가 어려움
• 볼륨은 Bind Mount와 다르게 다양한 드라이버를 지원

1 . 볼륨 리스트 보기

docker volume ls 

2 . 볼륨 생성 및 확인

docker volume create vol1  # 볼륨 생성

docker run -itd --name os5 -v vol1:/root/testdir centos:7
# 컨테이너 생성시 볼륨 생성 

-> 호스트 대상 경로 앞에 '/' 없으면 volume 생성
-> '/' 있으면 Bind Mount 생성

ls /var/lib/docker/volumes/ 
# 생성한 볼륨은 기본적으로 해당 경로에 존재한다

docker inspect os1 | grep Type
# 볼륨의 타입이 Volume인지 Bind mount인지 확인

docker inspect vol1 
# 도커 볼륨이 연결되어 있는 호스트 디렉터리의 위치 확인  

-> inspect를 통해 볼륨에 관한 자세한 정보 확인 가능

3 . 볼룸 삭제

docker volume rm vol1 

4 . DB에 volume 지정

docker run -itd --name mydb mysql:5.7

• MYSQL이미지로 컨테이너를 만들면 기본적으로 볼륨이 탑재되서 나온다. 하지만 위 사진처럼 이름이 복잡하게 설정되기때문에 관리가 힘들다

docker run -itd --name mydb1 -v dbvol:/root/testdir mysql:5.7

• 호스트 경로에 dbvol이라는 이름을 지정해서 Volume을 생성하면 관리하기 편하다

📗 host의 볼륨에 여러 컨테이너의 경로를 링크시켜주면 볼륨에 변경사항이 있을 때 여러 컨테이너들이 변경사항을 반영한다. 반대로 컨테이너 하나가 해당 경로에 변경사항이 생기면 호스트의 볼륨에 변경사항이 반영되면서 연결된 다른 컨테이너들도 변경사항이 반영된다

docker Network

Bridge

• bridge는 컨테이너가 사용하는 프라이빗 네트워크이며, 같은 bridge에 연결되어 있으면 컨테이너의 ip주소로 통신할 수 있다
• 외부로 통신할 때에는 NAPT통신을 사용하며, 외부에서 bridge로 통신하려면 포트포워딩을 사용해야 한다
• 도커를 설치하면 이름이 docker0인 리눅스 브릿지가 생성되는데, 이는 docker network ls 명령의 출력에서 이름이 bridge인 네트워크와 동일하다

docker network ls # 도커 네트워크 확인
ip addr # docker 0가 있는 것을 확인
docker inspect bridge # docker 0 확인 

• docker inspect bridge에서 마지막 Options 섹션에 bridge 네트워크의 옵션들이 나열되어 있는데 그 중 연결되어 있는 브릿지는 docker0라고 나와있다

1 . Bridge 생성 및 확인

• Bridge 드라이버를 사용하는 네트워크는 여러 개 생성가능
• 형식 : docker network create [option] network

docker network create --driver bridge docker1 # 네트워크 생성 

docker network create --subnet 192.168.0.0/24 --gateway 192.168.0.1 docker2
docker inspect docker2 # 네트워크 스펙 확인(= 위 사진)

-> subnet을 지정해서 지정된 ip범위내에서 네트워크를 생성할 수도 있고, 게이트웨이를 지정할 수도 있다.

-> ip addr을 통해 생성한 network를 확인 가능

2 . 이전에 만든 네트워크를 탑재한 컨테이너 생성

docker run -itd --name os3 --network docker2 centos:7

-> docker2의 지정된 서브넷 범위 내에세 os2 컨테이너에 ip가 할당된 것을 볼 수 있다.

3 . 네트워크 삭제

docker network rm -f 네트워크

💡 컨테이너에 탑재되어 실행중인 네트워크는 삭제할 수 없다
-> 컨테이너를 삭제한 후 네트워크 삭제 가능

host

• 호스트에서 컨테이너의 네트워크 격리를 해제하여 호스트의 네트워크 정보를 공유해서 사용하는 방법
• 컨테이너는 호스트 입장에서 하나의 프로세스이기 때문에 가상머신과 다르게 네트워크 정보를 공유할 수 있음
• 컨테이너가 해당 네트워크를 사용할 때 컨테이너의 포트가 호스트에서 사용하는 포트와 충돌해서는 안된다

docker run -d --name web2 --network host httpd # host네트워크를 가진 컨테이너 생성


docker inspect web2 | grep IPA # host 네트워크 확인  

-> 네트워크를 확인해보면 IP주소가 없는 것을 확인 = 컨테이너가 Host의 ip를 가져다 쓴다는 느낌

firewall-cmd --add-sevice=http --permanent
firewall-cmd --reload # 방화벽 해제 

echo network host test > index.html
docker cp index.html web2:/usr/local/apache2/htdocs/ # index.html작성

-> 브라우저에 host의 ip를 입력하니 web1 컨테이너의 index.html의 text가 나타나는것을 확인

📒 host는 컨테이너 하나밖에 사용하지 못한다

null

• 네트워크가 필요없는 컨테이너를 운용할 경우 적용

docker run -itd --name os2 --network none centos:7 # null 네트워크 생성
docker inspect os2 | grep IPA # null 네트워크 확인 

-> IP가 비어있는 것을 확인

link

• 컨테이너 생성시 같은 네트워크에 있는 특정 컨테이너의 별칭을 부여하기 위한 옵션
• 주의사항 : default bridge에서만 적용

docker exec os1 ping -c 3 web1   

-> os1컨테이너에서 web1컨테이너에게 ping을 날리면 알 수 없다고 뜬다. 당연히 os1은 web1이 /etc/hosts파일에 등록되어 있지 않기 때문에 web1의 ip를 알지 못한다

docker exec -it os1 bash # os1 접속
vi /etc/hosts # /etc/hosts파일 작성
172.17.0.3 web2

-> /etc/hosts파일을 작성하면 ping이 보내진다. 하지만 이것을 일일이 하기에는 비효율적이다. 이때 사용하는 것이 link이다.

docker run -itd --name os2 --link web1 centos:7
# os2와 web1 link

docker exec os2 cat /etc/hosts
# os2의 /etc/hosts 확인 
# 자동으로 web1에 대한 ip가 작성된 것을 볼 수 있다

docker exec os2 ping -c 3 web1
# ping이 작동하는 것을 확인 

포트 포워딩

• 호스트의 특정 포트에 컨테이너의 포트를 매칭 시키기 위한 옵션
• host는 하나의 컨테이너만 사용할 수 있기 때문에 포트 포워딩을 통해 host ip를 port로 구분해 여러 컨테이너가 사용할 수 있게 한다

docker run -d --name web3 -p 8080:80 httpd
#web3에 대해 8080으로 포트포워딩

docker exec -it web3 bash
cd htdocs
cat > index.html
test port 8080 작성
#web3의 index.html text수정

-> 브라우저에 호스트ip:8080을 입력하니 web3에 접속되는 것을 확인

docker run -d --name web4 -p 8090:80 httpd
# web4에 대해 8090으로 포트포워딩 

docker exec -it web4 bash
cd htdocs
cat > index.html
test port 8090 작성
# web4에 index.html text수정 

-> 브라우저에 호스트ip:8090을 입력하니 web4에 접속되는 것을 확인
-> 위의 결과와 똑같은 호스트 ip를 입력했지만 포트를 구분하여 접속되는 컨테이너가 달라짐을 확인

overray

• 다수의 호스트에 있는 컨테이너들이 통신을 하기 위한 네트워크

< docker >

• 하나의 호스트에서 하나의 컨테이너만을 컨트롤 할 수 있음

< docker-compose >

• 하나의 호스트에서 다수의 컨테이너를 관리해주는 플랫폼

< 오케스트레이션 >

• 다수의 호스트에서 다수의 컨테이너를 관리해주는 플랫폼
• 주로 Kubernetes가 있다
  -> 따라서 어차피 Kubernetes를 사용할 것이기 때문에 overray를 사용할 필요가 없다

macvlan

• 호스트의 물리 인터페이스에 가상으로 IP 주소를 적용하기 위한 네트워크