Consul 클 러 스 터 용기 화 배치 및 응용 통합

배경
현재 회사 의 주요 제품 이 사용 하 는 등록 센터 는 consul 이기 때문에 consul 클 러 스 터 로 높 은 사용 을 확보 해 야 합 니 다. 전통 적 인 방식 (Nginx / HAProxy) 은 한 가지 고장 문제 가 있 을 수 있 습 니 다. 이 문 제 를 해결 하기 위해 저 는 클 러 스 터 의 등록 방식 에 만 의존 하 는 방법 을 연구 하기 시 작 했 습 니 다. 하루 의 고생 끝 에클 러 스 터 버 전 ConsultClient 를 통 해 클 러 스 터 등록 을 할 수 있 음 을 검 증 했 습 니 다. 배치 실시 과정 에서 도 문제 가 생 겼 습 니 다. 이 기록 을 공유 하고 필요 한 학생 들 에 게 도움 이 되 기 를 바 랍 니 다.
호스트 버 전 클 러 스 터 와 docker 버 전 클 러 스 터 비교
client + server 퍼 가기 모델 의 클 러 스 터 배 치 는 두 가지 선택 과 관련된다. 첫 번 째 는 직접 호스트 모델 배치 이 고 2 개 consul + 3 개 client, 각 server 인 스 턴 스 는 호스트 (부자 에 게 적합) 를 배치 하 는 것 이다. 이 모델 의 장점 은 간단 하고 폭력 적 이 며 운영 이 상대 적 으로 간단 하 다 는 것 이다.이 모델 의 구조 배치 도 는 다음 과 같다. 
우리 가 선택 한 것 은 다른 경제 절약 모델 이다. consul 화 배 치 는 자원 을 절약 하 는 것 이 장점 이다. 약점 은 바로 많은 docker 미 러 를 관리 하 는 것 이다. k8s 이런 용기 관리 플랫폼 을 도입 하기 전에 후속 docker 의 운영 이 비교적 번 거 로 울 것 이다. 이런 모델 의 구조 배치 도 는 다음 과 같다.
상기 두 가지 모델 의 구조 도 를 통 해 우 리 는 호스트 배치 모델 이 가장 간단 하고 직접적 이라는 것 을 잘 알 수 있다. docker 의 모델 은 자원 을 절약 하지만 복잡성 을 강화 하여 운영 의 어려움 을 증가 했다.그러나 이런 모델 은 현재 용기 화 된 환경 에서 좋 은 선택 이 어야 한다. 이 유 는 간단 하 다. 자원 을 충분히 이용 하기 때문에 용기 의 운송 비 는 용기 운송 플랫폼 에 맡 길 수 있다. 예 를 들 어 k8s 등 이다.용기 화 docker 군집 배 치 를 어떻게 하 는 지 실천 해 보 자.
환경 준비
여기에 가상 호스트 두 대 를 준 비 했 습 니 다. 가상 호스트 이기 때문에 대외 ip 은 같 기 때문에 우 리 는 포트 로 구분 합 니 다.

  A:192.168.23.222:10385   ip:192.168.236.3   B:192.168.23.222:10585   ip:192.168.236.5 

배치
단계 1: 호스트 에 Docker 환경 설치 (Centos 를 예 로 들 면)

yum install docker

STEP 2: Consult 미 러 를 끌 어 당 겨 배치

docker pull consul

STEP 3: 호스트 Docker 에 ip 세그먼트 할당, 다 중 호스트 ip 중복 방지

호스트 A 에서 편집 consul 한 docker 파일 에 아래 내용 추가

 "bip": "172.17.1.252/24"

호스트 B 에서 편집 /etc/docker/daemon.json 한 docker 파일 에 아래 내용 추가

  "bip": "172.17.2.252/24"

이 설정 은 호스트 의 /etc/docker/daemon.json 인 스 턴 스 에 ip 을 할당 합 니 다. 후속 docker 은 크로스 호스트 등록 을 할 것 입 니 다. 기본 등록 을 하면 docker 호스트 네트워크 로 ip 이 중복 되 기 때문에 수 동 으로 ip 분 배 를 할 수 있 습 니 다. 물론 상기 ip 설정 은 사용자 정의 할 수 있 습 니 다.
STEP 4: 호스트 A 에 Consul 배치
Node1:

         docker run -d --name=node_31 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 11300:8300 \
             -p 11301:8301 \
             -p 11301:8301/udp www.jintianxuesha.com\
             -p 11302:8302/udp \
             -p 11302:8302 \
             -p 11400:8400 \
             -p 11500:8500 \
             -p 11600:8600 \
             consul agent -server -join=172.17.1.1  -bootstrap-expect=3 -node=node31 \
             -data-dir=/consul/data/ -client 0.0.0.0 -ui

여기 서 몇 가지 매개 변 수 를 중점적으로 설명 한다.docker: --name 용기 의 이름 입 니 다. 용기 마다 인 스 턴 스 가 다 릅 니 다.docker: -node 노드 의 이름 으로 노드 마다 다 릅 니 다.consul: 클 러 스 터 를 시작 하여 최소 몇 개의 노드 를 기대 하 는 것 입 니 다. 여기 설정 은 3 개 입 니 다.-bootstrap-expect: -data-dir 데이터 센터 의 디 렉 터 리 입 니 다. consul 읽 기와 쓰기 권한 을 부여 해 야 합 니 다. 그렇지 않 으 면 시작 이 잘못 될 수 있 습 니 다.
시작 에 성공 하면 명령 을 실행 하여 consul 의 노드 를 봅 니 다.

docker exec -t node_31 consul members

결 과 는 다음 과 같 습 니 다.

Node    Address          Status  Type    Build Protocol DC Segment node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all> 

이것 은 첫 번 째 노드 가 정상적으로 시작 되 었 고 그 다음 에 호스트 A 의 나머지 노드 를 정상적으로 시작 했다 는 것 을 의미한다.
Node2:

docker run -d --name=node_32 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 9300:8300 \
             -p 9301:8301 \ -p 9301:8301/udp \ -p 9302:8302/udp \ -p 9302:8302 \ -p 9400:8400 \ -p 9500:8500 \ -p 9600:8600 \ consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node32 \ -data-dir=/consul/data/ -client 0.0.0.0 -ui 

Node3:

          docker run -d --name=node_33 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 10300:8300 \
             -p 10301:8301 \ -p 10301:8301/udp \ -p 10302:8302/udp \ -p 10302:8302 \ -p 10400:8400 \ -p 10500:8500 \ -p 10600:8600 \ consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node33 \ -data-dir=/consul/data/ -client 0.0.0.0 -ui 

세 개의 노드 가 시 작 된 후에 명령 을 실행 하고 노드 의 상 태 를 봅 니 다.

docker exec -t node_31 consul operator raft list-peers

결 과 는 다음 과 같다.

Node    ID                                    Address          State     Voter RaftProtocol node32 ee186aef-5f8a-976b-2a33-b20bf79e7da9 172.17.1.2:8300 follower true 3 node33 d86b6b92-19e6-bb00-9437-f988b6dac4b2 172.17.1.3:8300 follower true 3 node31 0ab60093-bed5-be77-f551-6051da7fe790 172.17.1.1:8300 leader true 3 

여기 서 세 개의 consul 노드 가 클 러 스 터 배 치 를 완 성 했 고 server 를 주요 노드 로 선택 한 것 으로 나 타 났 다.마지막 으로 이 호스트 그룹 에 클 라 이언 트 를 배치 하면 큰 성 과 를 거 둘 수 있 습 니 다.
Node 4 (client 노드)

   docker run -d --name=node_34  --restart=always \
            -e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \
            -p 8300:8300 \
            -p 8301:8301 \ -p 8301:8301/udp \ -p 8302:8302/udp \ -p 8302:8302 \ -p 8400:8400 \ -p 8500:8500 \ -p 8600:8600 \ consul agent -retry-join=172.17.1.1 \ -node-id=$(uuidgen | awk '{print tolower($0)}') \ -node=node34 -client 0.0.0.0 -ui 

node_31 명령 을 실행 한 결 과 는 다음 과 같 습 니 다.

Node    Address          Status  Type    Build Protocol DC Segment node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all> node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all> node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all> node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default> 

여기 서 호스트 A 의 docker exec -t node_31 consul members 노드 가 모두 시작 되 었 고 클 러 스 터 배 치 를 완 료 했 습 니 다. 이것 이 바로 단일 호스트 버 전의 consul 클 러 스 터 라 고 할 수 있 습 니 다. 그러면 다음 에 우리 가 해 야 할 일 은 호스트 B 의 consul 를 호스트 A 의 클 러 스 터 에 가입 하면 됩 니 다.
STEP 5: 호스트 B 에 Consul 배치
Node5

       docker run -d --name=node_51 --restart=always \
               -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
               -p 11300:8300 \
               -p 11301:8301 \ -p 11301:8301/udp \ -p 11302:8302/udp \ -p 11302:8302 \ -p 11400:8400 \ -p 11500:8500 \ -p 11600:8600 \ consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_51 \ -data-dir=/consul/data/ -client 0.0.0.0 -ui 

Node6

       docker run -d --name=node_52 --restart=always \
               -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
               -p 9300:8300 \
               -p 9301:8301 \ -p 9301:8301/udp \ -p 9302:8302/udp \ -p 9302:8302 \ -p 9400:8400 \ -p 9500:8500 \ -p 9600:8600 \ consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_52 \ -data-dir=/consul/data/ -client 0.0.0.0 -ui 

Node7

       docker run -d --name=node_53 --restart=always \
               -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
               -p 10300:8300 \
               -p 10301:8301 \ -p 10301:8301/udp \ -p 10302:8302/udp \ -p 10302:8302 \ -p 10400:8400 \ -p 10500:8500 \ -p 10600:8600 \ consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_53 \ -data-dir=/consul/data/ -client 0.0.0.0 -ui 

호스트 B 의 세 개의 server 노드 배치 가 완 료 된 후에 우 리 는 명령 consul 을 실행 하여 클 러 스 터 노드 상 태 를 봅 니 다.

Node     Address          Status  Type    Build Protocol DC Segment node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all> 

왜 docker exec -t node_51 consul members 이라는 단독 노드 만 있 습 니까?노드 문제 아니 야?우 리 는 호스트 B 에서 똑 같이 조회 한 결과 다음 과 같다.

node31  172.17.1.1:8301 alive server 1.6.2 2 dc1 <all> node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all> node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all> node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default> 

호스트 A 의 노드 는 그들 자신의 기계 의 노드 만 있 고 호스트 B 의 노드 는 모두 등록 되 지 않 았 습 니 다. 이것 은 왜 일 까요?그 이 유 는 node_51 연 결 된 ip 은 용기 의 내부 네트워크 ip 입 니 다. 호스트 내부 통신 은 가능 합 니 다. 크로스 호스트 통신 은 내부 네트워크 주 소 를 통 해 통신 할 수 없습니다. 그러면 우 리 는 어떻게 합 니까?우 리 는 경로 규칙 을 통 해 리 트 윗 을 하면 됩 니 다. 호스트 A 가 호스트 B 용기 의 내부 네트워크 주 소 를 호스트 B 로 전송 하도록 요청 하면 됩 니 다. 여기 서 우리 가 용기 에 ip 을 분배 하기 시작 한 역할 을 나타 냅 니 다.호스트 A 에서 다음 명령 을 수행 합 니 다.

route add -net 172.17.2.0 netmask 255.255.255.0 gw 192.168.236.5 

이 명령 은 경로 규칙 consul 범위 의 ip 요청 을 추가 하여 모두 172.17.2.1~172.17.2.254 주소 로 전송 하 는 것 을 의미 합 니 다. 즉, 우리 의 호스트 B 입 니 다.같은 호스트 B 도 다음 명령 을 수행 합 니 다.

route add -net 172.17.1.0 netmask 255.255.255.0 gw 192.168.236.3 

추가 완료 후 실행 192.168.236.5 명령:

Node     Address          Status  Type    Build Protocol DC Segment node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all> node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all> node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all> node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all> node_52 172.17.2.2:8301 alive server 1.6.2 2 dc1 <all> node_53 172.17.2.3:8301 alive server 1.6.2 2 dc1 <all> node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default> 

클 러 스 터 가입 에 성 공 했 습 니 다. 호스트 를 뛰 어 넘 는 docker 용기 가입 이 완료 되 었 습 니 다.마지막 으로 호스트 B 에 게 하나 배치 하기 docker exec -t node_53 consul membersNode 8 (client 노드)

 docker run -d --name=node_54  --restart=always \
            -e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \
            -p 8300:8300 \
            -p 8301:8301 \ -p 8301:8301/udp \ -p 8302:8302/udp \ -p 8302:8302 \ -p 8400:8400 \ -p 8500:8500 \ -p 8600:8600 \ consul agent -retry-join=172.17.1.1 \ -node-id=$(uuidgen | awk '{print tolower($0)}') \ -node=node54 -client 0.0.0.0 -ui 

마지막 클 러 스 터 노드 가 모두 가입 에 성 공 했 습 니 다. 결 과 는 다음 과 같 습 니 다.

node31   172.17.1.1:8301 alive server 1.6.2 2 dc1 <all> node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all> node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all> node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all> node_52 172.17.2.2:8301 alive server 1.6.2 2 dc1 <all> node_53 172.17.2.3:8301 alive server 1.6.2 2 dc1 <all> node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default> node54 172.17.2.4:8301 alive client 1.6.2 2 dc1 <default> 

노드 상태 명령 실행 client:

node32   ee186aef-5f8a-976b-2a33-b20bf79e7da9  www.wuji5pingtai.cn 172.17.1.2:8300 follower true 3 node33 d86b6b92-19e6-bb00-9437-f988b6dac4b2 www.moyouyul.cn 172.17.1.3:8300 follower true 3 node31 0ab60093-bed5-be77-f551-6051da7fe790 www.jinyang3.xyz  172.17.1.1:8300 leader true 3 node_51 cfac3b67-fb47-8726-fa31-158516467792  www.wujiu5zhuce.cn 172.17.2.1:8300 follower true 3 node_53 31679abe-923f-0eb7-9709-1ed09980ca9d www.jiuyueguojizc.cn 172.17.2.3:8300 follower true 3 node_52 207eeb6d-57f2-c65f-0be6-079c402f6afe www.zheshengjpt.com 172.17.2.2:8300 follower true 3 

6 개 docker exec -t node_31 consul operator raft list-peers + 2 개 server 를 포함 하 는 client 용기 화 클 러 스 터 가 배치 되 었 습 니 다. consul 의 consul 패 널 은 다음 과 같 습 니 다. 
응용 통합
클 러 스 터 버 전 web 은 우리 가 배 치 했 습 니 다. 그러면 우 리 는 어떻게 응용 과 통합 합 니까?우 리 는 클 라 이언 트 를 클 라 이언 트 버 전 consul 으로 통합 하면 된다.우선 가입 의존

        <dependency>
		<groupId>com.github.pengglegroupId> <artifactId>spring-cloud-starter-consul-clusterartifactId> <version>2.1.0.RELEASEversion> dependency> 

두 번 째 단 계 는 consul 에서 다 중 노드 로 지정 하고 다음 과 같다.

spring.cloud.consul.host=192.168.23.222:10385,192.168.23.222:10585

등 록 된 로 그 를 출력 하려 면 로그 백 에 로그 설정 을 추가 할 수도 있 습 니 다.

<logger name="org.springframework.cloud.consul" level="TRACE"/> 

이렇게 설정 이 완 료 된 후에 시작 하면 우리 의 응용 프로그램 등록 이 성공 한 것 을 볼 수 있 습 니 다. 다음 그림 은 제 가 테스트 한 등록 성공 효과 입 니 다. 
여기 서 제 응용 노드 가 각각 클 러 스 터 의 2 개 bootstrap.yml|properties 에 등록 되 었 고 spring.cloud.consul.host 의 대리 리 트 윗 을 통 해 건강 한 client 에 요청 하여 client 의 높 은 사용 을 실현 했다 는 것 을 보 여 줍 니 다.
총결산
이 글 은 기술 건 화 를 연구 하지 않 았 다. 순 전 히 업무 경험 공유 이다. 주로 server 클 러 스 터 배치 방식 을 말 했다. 전통 적 인 모델 은 consul 을 통 해 클 러 스 터 배 치 를 완성 할 수 있 지만 이런 방식 의 단점 이 뚜렷 하 다. 가상 ip 을 통 해 고장 난 노드 를 가리 킬 수 있 기 때문에 우 리 는 consul 의 HAProxy + consul 모델 의 클 러 스 터 배 치 를 사용 했다.client 화 를 통 해 기계 의 자원 을 충분히 이용 하여 2 대의 기계 만 있 으 면 군집 의 높 은 사용 효 과 를 완성 할 수 있다.