0부터 시작하는 Docker Swarm 공부 - Cli 환경 변환 & 일반 컨테이너와 비교 & Update 정보 & 복습

Jaehong Lee·2022년 8월 24일

0부터 시작하는 Docker Swarm 공부

목록 보기

10/20

1. Worker Node Cli 전환

xwindows -> cli

sudo systemctl set-default multi-user.target

startx : 일시적으로 xwindows 로 전환된다

cli -> xwindows

sudo systemctl set-default graphical-user.target

worker node 들은 cli 로 전환하자. xwindows 환경은 memory 소모가 심하기 때문에 cli 환경으로 전환하여 좀 더 쾌적하게 사용하자
변환되었다
시작전 manager node 에서 node 들이 잘 연결되어 있는지 Swarm 환경을 확인하자
전에 만든 사용자 network 도 삭제하자

2. IT 지식

bash / python 을 이용하여 다수의 서버를 관리할 수 있다

이미 웹 서버가 설치되어 있는 상태에서..인프라 관리 툴 -> ansible ( 멱등성 : 최종 상태만을 확인하여 그 상태를 만들면 된다)

bash : start 해라

ansible : started 를 보장해라

ansible 의 실체는 ssh 이다

aws 나 gcp 에서 제공하는 컨테이너 클러스터링 서비스는 EKS, GKE 가 있다. 이들은 별도의 manager 용 VM 을 제공해주는 것이 아니라, 전체 관리용 VM ( CONSOLE VM ) 에 Docker 를 설치하여 사용한다

worker Node 는 완전 관리형 Service 로 제공된다

위와 같이 manager 에서 파일에 token join 명령어를 담아서, worker node 생성시 해당 파일을 붙여넣기 하고, firstboot-command 로 해당 파일을 실행시켜, worker node 가 manager 에 자동으로 Join 되게 할 수 있다

3. Service 배포

Service 를 배포하는 2 가지 방식
1. replicas : 지정된 개수만큼 컨테이너를 동작시킨다. 이 개수는 무조건 유지된다. 이를 통해 scale 과 연계하여 확장 / 축소가 용이하다
2. global : 지정된 Node 에 각 1 개씩 global 하게 배포한다

docker service create --name test1 --replicas 3 --constraint node.role!=manager -p 80:80 nginx

node.role!=manager 는 manager node 가 아닌 node 들을 지정하는 것이다. 이는 node.role==worker 와 같은 의미다
nginx 서비스를 배포하자
어떤 Node 에 접근해도 잘 접속된다. manager node 는 컨테이너가 없지만 접속된다. 이는 overlay Network 덕분이다

scale 줄이기

위와 같이 scale 조정이 가능하다. scale 을 줄이면, 개수에 맞게 Container 의 개수가 줄어든다
worker3 의 Container 만 동작한다

4. Inspect pretty 옵션 & 일반 컨테이너와 비교

일반 컨테이너와 비교

test2 는 일반 컨테이너이다. Service 로 배포한 컨테이너와 비교하면 Ports 부분이 일반 컨테이너는 8888->80 과 같이 Host 의 Port 에 종속적이지만, Service 로 배포한 컨테이너는 Host 의 Port 번호가 표시되있지 않으며 Host 의 Port 에 종속적이지 않다

pretty 옵션

inspect 할 때, pretty 옵션을 사용하면, 더 사용자 친화적으로 정보를 출력해준다
- 이 옵션은 Swarm 에서만 가능하다

5. Update 정보

update 정보

parallelism 은 task 한 번에 실행할 컨테이너 개수를 말한다
on failure 는 업데이트 진행시 오류가 발생하면 실행하는 옵션이다. pause 는 오류가 발생하면 중단시킨다. continue 는 오류가 발생해도 업데이트를 계속 진행시킨다

update 시키기

다른 이미지로 Service 를 update 시키자

실제 환경에서는 다음과 같은 방식으로 Update 를 진행한다

gitlab 은 저장소를 모니터링 한다. 해당 저장소에 code 가 저장되어 commit 이 변경되면, gitlab 은 commit 변경을 감지하고, 자동으로 script 를 실행한다
- script 에는 새 이미지를 build 하여, 도커 저장소에 push 하게 설정한다
도커 저장소에서 image 를 pull 하는데, 이때, ansible 이 명령을 manager node 에게 전달해준다. manager node 에서는 해당 명령을 받고, worker node 에게 전달한다
- gitlab 에서 manager node 에게 명령을 바로 전달하게 Pipe Line 을 만들수도 있다
git lab 과 jenkins 를 같이 사용할수도 있다

roll back

다시 roll back 시키자. roll back 을 시키면, update 전 컨테이너의 이미지를 가지고, 새 컨테이너를 생성하여 서비스를 제공하게 하는 것이다. 중지된 이전 컨테이너를 실행시키는 것이 아니다

6. Config & Secret

기존 명령에서 password 를 지정하거나, 변수를 선언했던 것처럼 하는 것이 아니라, 별도의 config 또는 secret 객체를 생성하고, 이를 컨테이너에 적용하는 방식으로 운영하는 것
- config - 레지스트리 설정 파일, 변수 선언, index.html 과 같은 보안성이 낮은 파일 자체
- secret - DB 패스워드, SSH Key ( Public Key ) , 인증서
이는 Swarm 뿐만이 아니라 K8S 에서도 사용한다
- ConfigMap, Secret 이라고 한다

Secret 생성

뒤에 - 는 앞에 echo 명령의 실행 결과를 입력으로 받겠다는 것이다. Secret 객체 testsecret 를 생성하자
잘 생성됬는지 Secret 객체 list 를 확인하자

Config 생성

index.html 을 생성하고, 이를 통해 Config 객체를 생성하자

상세 정보 확인

testsecret 상세 정보 확인
testconfig 상세 정보 확인
config 는 secret 과 다르게 원본 Data 를 암호화한 Data 를 상세 정보에서 확인할 수 있다. 이는 base64 로 암호화 되있으므로, -d 를 통해 암호를 풀면 원본 Data 를 확인할 수 있다
- Secret 는 Data 를 상세 정보에서 확인할 수 없다

Secret 적용

secret 은 기본적으로 컨테이너의 /run/secrets 이라는 디렉터리 아래에 파일 형태로 보관된다. 또한 컨테이너내에 파일에서는 암호문이 아닌 평문으로 보관된다

docker service create --name sql --replicas 3 --constraint node.role==worker --secret source=testsecret,target=testsecret -e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/testsecret" -e MYSQL_DATABASE=testdb  mysql:5.7

Secret 의 target 은 /run/secrets/ 아래에 저장할 파일의 이름을 지정해준다
- 이 파일을 이용해 mysql 의 환경 변수를 지정해줄 수 있다
Secret 을 이용하여 Service 를 배포하자
worker Node 에 들어가서 확인하면 잘 배포되있는 것을 확인 가능하다
배포한 컨테이너에 exec 로 명령을 전달하여 파일 이름과 파일 내용을 확인하자. 파일 내에 Data 가 저장되있으며, 해당 Data 는 암호문이 아닌 평문으로 저장되있는 것을 확인할 수 있다. 이와 같이 Secret 객체에 저장한 Data 는 컨테이너 배포후, 해당 컨테이너의 파일을 통해 확인할 수 있다

Config 적용

docker service create --name nginx1 --replicas 3 --constraint node.role==worker -p 8003:80 --config source=testconfig,target=/usr/share/nginx/html/index.html nginx