세팅
vmware에서 서버 b를 복사해서 ip를 바꾼다
바꾸기 전에 b와 c를 같이 부팅하면 같은 ip를 사용하고 있기 때문에 에러날 수 있다.
그래서 c부터 먼저 바꾸고 나서 b를 부팅해야 한다.
서버c
서버a의 /etc/hosts 다음과 같이 수정
그리고 scp를 이용하여 복사 serverb와 serverc에 복사
Docker Swarm Cluster 구축하기
Servera 설정하기
# docker swarm init –-advertise-addr=213.0.113.3docker swarm init -> swarm 만들기 => 이 명령어가 실행되는 곳이 manager가 된다.
docker swarm 과 연결하는 네트워크를 213.0.113.3으로 하겠다
토큰 정보가 만들어진다
Worker Node 설정하기(b, c에서 동일하게 설정)
토큰 정보를 이용하여 serverb, c에서 join한다.
servera에서 docker node ls를 하면 a,b,c가 뜨고 a는 리더라고 뜸 -> master(manager)
Docker Swarm 서비스 사용하기
주의: 아래 예제에서 Dockerfile 을 이용한 이미지 생성은 모든 노드에서 이루어져야 한다.
#Dockerfile
FROM centos:7
MAINTAINER servera <admin@example.com>
RUN yum -y install httpd
RUN echo "Docker node: servera.example.com" > /var/www/html/index.html
EXPOSE 80
CMD ["-D", "FOREGROUND"]
ENTRYPOINT ["/usr/sbin/httpd"]# docker build -t web_server:latest .
이미지 이용 서비스 생성하기
# docker service create --name web_swarm \
> --replicas=2 -p 80:80 web_server:latest- docker service create => 차이점 1
- swarm 모드에서는 service라고 부름. service가 container임
- --replicas=2 => 차이점 2
- replication의 약자
- 동일한 컨테이너의 개수를 나타냄
cf ) 서버 b 서버c에서 도커파일을 만들지 않으면 에러가 나서 서버a에서만 컨테이너를 2개 만들어버린다.
cf) 서버 a b c에서 컨테이너를 만들때 nginx 같은 경우에는 이미지가 없어도 그냥 pull이 된다. 그러나, 우리기 만든 이미지는 public에 없는 이미지이므로 b와 c에 도커파일과 함께 이미지가 안만들어진다면 컨테이너가 생성안된다.
web_swarm이라는 컨테이너를 생성할거임 가각의 컨테이너는 80번 포트를 사용할 거임 근데 그 컨테이너의 개수가 2개임
=> 웹 서버가 2개 생성되는 거임 각각 서버 b와 서버c에서 실행되는 거임
=> 컨테이너가 어디서 실행되고 있는지
=> 노드가 저렇게 생성된 것은 상관이 없음 -> container가 몇개가 만들어졌는가만 중요하다. -> docker swarm은 manager에도 컨테이너 생성이 가능하기 때문이다.
cf ) swarm을 만들면 좋은점?
1. 로드밸런싱의 효과를 가지게 됨
노드가 분산이 되는 효과
2. DDOS => 서비스가 다운됨
DDOS 예방효과
3. 웹서버 조절 가능
이미지 만들때 index.html 파일을 설정해주었다. 똑같은 이미지에 대해 컨테이너가 생성되었기 때문에 컨테이너가 a, b, c 어디든 생성이 되든 결과는 같다.
근데 serverc로 접속해도 결과가 나온다. 위에서 container가 servera와 serverb에서만 생성된것을 확인할 수 있었다.
왜 이렇게 되는걸까?
=> 하나의 클러스터이기 때문에 (하나의 그룹이기 때문에) 실제 접속은 다 됨
=> 클러스터 환경에서는 하나로 인식함
=> 이미지는 같아야 됨, 컨테이너 내부는 다를 수 있음 => 컨테이너 자체에서 변경하는 것은 가능함. 이미지는 무조건 같은거 사용해야 된다
서비스 복제 배포(scale)
docker service scale web_swarm=5
컨테이너의 개수가 5개로 증가하였다.
임의대로 컨테이너의 개수 조정이 가능하다.
=> 동시접속자 수가 늘어나고 줄어남에 따라서 조절해주면 된다.
줄어드는 것도 가능하다.
swarm 삭제
docker service rm web_swarm
Rolling Update & Rollback
Rolling Update
이미지가 업데이트되면 컨테이너도 업데이트 되어야 한다.
이때 컨테이너 기존것은 shutdown되고 새로운 컨테이너가 만들어져서 running이 된다.
만약에 replica=1이고 컨테이너를 삭제한다면 새로운 컨테이너가 자동으로 생성이 된다.
기존의 이미지로 다시 업데이트해도 shutdown된 컨테이너가 다시 running 되는게 아니라 새로운 컨테이너가 생성이 된다.
-> 이때 ip가 변경이 계속 됨(만들어질 때마다) -> ip 신뢰할 수 없음 -> 이름만 신뢰가능
=> 그래서 외부에서 컨테이너로 접속할때 ip로 접속할 수 없다(port는 안바뀌어서 신뢰가능)
그래서 외부에서 접속할때는 이름과 port로 접속을 함 => 쿠버네틱스와 오픈시프트에서 서비스라고 부른다
Rollback
Rollback 은 현재의 작업을 취소하고 이전 작업으로 되돌리는 작업
-> 이전에 shutdown 된것은 실행되지 않고 새로운 것이 다시 만들어진다
Docker Swarm Network - Overlay
도커 내 로드밸런서가 그 안에서 랜덤으로 컨테이너로 전달 할 수 있는데 같은 클러스터에 있기 때문에 overlay로 묶여 있어서 서로 통신이 가능
기존 네트워크 외에 사용할 네트워크를 새롭게 생성해야 한다.
# docker network create --driver=overlay overnet
새롭게 만든 Overlay 네트워크 적용한 서비스 생성하기
docker service create --name webserver \
> --replicas=3 -p 80:80 --network=overnet web_server:latest
각 컨테이너의 ip확인
서버a
서버 b
서버 c
ping확인
서버a
서버b
서버c
서버b
서버c
/etc/resolv.conf를 보면 dns 기능을 확인할 수 있다.
따라서 webserver라는 이름을 찾아서 ping을 해준다.
즉, 내부에 dns서버가 만들어진것이다 -> service discovery
그런데 webserver는 컨테이너가 아닌데 ip를 가지고 있다.
서버a에서 webserver 정보를 확인해보면 다음과 같다.
밑에있는것이 서비스의 ip가 된다.
기본적으로 서비스도 object로 인식해서 ip를 가지고 있다.
client는 container로 직접 접속하지 않고 서비스로 접속을 한다. 서비스가 연결을 컨테이너로 해준다. 따라서 서비스도 ip를 가지고 있고 서비스가 접속 통로가 되는 것이다.
