consul + consul - template + registrator + nginx 로 진정 으로 동적 확장 가능 한 서비스 구 조 를 만 듭 니 다.

인터넷 응용 분야 에서 서비스의 동태 적 수요 가 매우 흔 하기 때문에 서비스의 자동 발견 과 동적 확장 에 높 은 요 구 를 제기 했다.
Docker 의 등장 과 마이크로 서비스 구조의 발전 으로 인해 많은 오픈 소스 프로젝트 들 이 소나무 결합 의 구조 전제 에서 Docker 를 바탕 으로 진정 으로 동적 으로 확장 할 수 있 는 서비스 구 조 를 어떻게 실현 하 는 지 주목 하기 시작 했다.
기본 수요
기본 적 인 수 요 는 다음 과 같다.
서비스 가 시 작 된 후에 자동 으로 발견 되 어야 합 니 다 (vs 전통 은 수 동 으로 등록 해 야 합 니 다)
부하 가 사용 가능 한 서비스 인 스 턴 스 에서 동적 으로 균형 을 이 룰 수 있어 야 합 니 다 (vs 전통 적 으로 정적 기록 설정 이 필요 합 니 다)
서비스 규 모 는 빠 른 조정 을 편리 하 게 해 야 한다 (vs 전통 적 으로 오 랜 시간 수 동 조정 이 필요 하 다)
관련 항목
서비스 발견
서비스 에서 발 견 된 항목 은 이미 적지 않다. 그리고 skydns, serf, 그리고 일치 성에 주목 하 는 강력 한 zookeeper 기다리다
이런 항목 들 은 각각 장단 점 이 있 고 기능 적 으로 대동소이 하 며 모두 특정한 체 제 를 통 해 서비스 정 보 를 얻 은 다음 에 (분포 식) 데이터 베 이 스 를 유지 함으로써 서비스의 정 보 를 저장 해 야 한다.이것 도 왜? etcd 모두의 관심 과 집적 을 받다.
여기 서 HashiCorp 회사 의 consul 을 서비스 발견 관리 단 으로 사용 합 니 다. 그의 소 개 는 참고 할 수 있 습 니 다. 여기 요.
서비스 등록
서비스 등록 의 수단 은 매우 많다. 물론 발기인 이 누구 인지 두 가지 로 나 눌 수 있 고 주동 적 으로 등록 할 수 있 는 지 수 동적 으로 탐지 할 수 있다.
자 발 적 등록 은 말 그대로 서비스 가 시 작 된 후 지 정 된 서비스 발견 관리 단의 API 에 요청 을 보 내 자신의 관련 정 보 를 제공한다.이렇게 하면 관리 단 에 대한 요구 가 매우 간단 해 졌 지만 서비스 자체 가 등록 업 무 를 완성 해 야 한 다 는 것 을 의미 하고 극단 적 인 상황 에서 관리 단 은 진정 으로 생존 하 는 서 비 스 를 탐지 하기 어렵다.
수 동적 탐 사 는 서비스 발견 관리 단 이 특정한 체 제 를 통 해 생존 을 탐지 하 는 서비스 이다.이렇게 하면 진실 한 서비스 상황 을 얻 을 수 있 지만 어떻게 탐지 하 는 지 는 디자인 하기 어 려 운 점 이다. 특히 서비스 유형 이 비교적 복잡 할 때.
상기 두 가 지 는 모두 네트워크 연결 성에 대한 요구 가 비교적 높다.단기 적 으로 볼 때 주동 적 인 등록 방식 은 비교적 쉽게 실현 되 고 응용 상황 이 더욱 광범 위 할 것 이다.그러나 장기 적 인 유지 에 있어 서 수 동적 인 탐지 방식 은 더욱 효율 적 인 디자인 이 어야 한다.
여기, 우 리 는 gliderlabs 의 registrator 는 로 컬 docker 엔진 과 통신 하여 로 컬 에서 시작 하 는 용기 정 보 를 얻 고 지정 한 서비스 발견 관리 단 에 등록 할 수 있 습 니 다.
업데이트 설정
서비스 가 조 정 된 후 부하 균형 기 가 동적 으로 부 하 를 재배 치 하려 면 설정 을 통 해 업 데 이 트 를 받 아야 합 니 다.이러한 방안 도 적지 않다. 기본적으로 로 컬 에이 전 트 를 설치 하여 서비스 발견 관리자 의 정 보 를 감청 하고 새로운 설정 을 생 성하 고 업데이트 명령 을 실행 해 야 한다.
HashiCorp 회사 의 consul - template 는 consul 의 등록 정 보 를 감청 하여 로 컬 애플 리 케 이 션 의 설정 업 데 이 트 를 완성 할 수 있 습 니 다.
부하 균형
부하 균형 은 성능 에 대한 요구 가 높 지만 소프트웨어 가 잘 하 는 분 야 는 아니 지만 소프트웨어 방안 은 원가 가 낮 고 유지 가 편리 하 다.포괄 하 다 lvs、haproxy 모두 훌륭 한 디자인 방안 입 니 다.
여기 nginx。nginx 는 강력 한 웹 프 록 시 서버 일 뿐만 아니 라 부하 균형 에 도 잘 나타난다.더 중요 한 것 은 새로운 버 전의 nginx 가 온라인 업그레이드 지원 을 극 대화 했다.실시 간 설정 업 데 이 트 는 물론 서비스의 연속 성 을 확보 할 수 있 습 니 다.
실험 과정
준비 작업
먼저 여기, 이곳 템 플 릿 파일 을 다운로드 하 다.
주요 내용 은 다음 과 같다.

#backend web application, scale this with docker-compose scale web=3
web:
  image: yeasy/simple-web:latest
  environment:
    SERVICE_80_NAME: http
    SERVICE_NAME: web
    SERVICE_TAGS: backend
  ports:
  - "80"

#load balancer will automatically update the config using consul-template
lb:
  image: yeasy/nginx-consul-template:latest
  hostname: lb
  links:
  - consulserver:consul
  ports:
  - "80:80"

consulserver:
  image: gliderlabs/consul-server:latest
  hostname: consulserver
  ports:
  - "8300"
  - "8400"
  - "8500:8500"
  - "53"
  command: -data-dir /tmp/consul -bootstrap -client 0.0.0.0

# listen on local docker sock to register the container with public ports to the consul service
registrator:
  image: gliderlabs/registrator:master
  hostname: registrator
  links:
  - consulserver:consul
  volumes:
  - "/var/run/docker.sock:/tmp/docker.sock"
  command: -internal consul://consul:8500

docker 와 docker - compose 가 설치 되 어 있 지 않 으 면 먼저 설치 해 야 합 니 다. ubuntu 시스템 을 예 로 들 면.

$ curl -sSL https://get.docker.com/ | sh
$ sudo pip install docker-compose

집행 하 다.
docker - compose 템 플 릿 이 있 는 디 렉 터 리, 실행

$ sudo docker-compose up

관련 미 러 는 자동 으로 다운로드 되 고 다운로드 가 끝나 면 용기 가 작 동 된다.
방문 하 다. http://localhost 실제 방문 대상 주 소 를 알려 주 는 웹 페이지 를 볼 수 있 습 니 다.
여러 번 새로 고침 하면 대상 주소 가 변 하지 않 은 것 을 볼 수 있 습 니 다. 이것 은 현재 웹 백 엔 드 서버 가 하나 밖 에 없 기 때 문 입 니 다.

2015-08-18 03:37:58: 6 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.148>

백 엔 드 를 3 개의 서버 로 조정 합 니 다.

$ sudo docker-compose scale web=3

그리고 다시 방문 합 니 다. http://localhost여러 번 새로 고침 하면 방문 한 실제 목표 주소 가 달라 진 것 을 볼 수 있 습 니 다. 새로 시작 한 웹 서버 는 자동 으로 등록 되 고 nginx 는 자동 으로 부하 균형 을 이 루 었 습 니 다.

2015-08-18 03:37:58: 6 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.148>
2015-08-18 03:38:17: 5 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.152>
2015-08-18 03:38:20: 5 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.153>

전재 설명:http://blog.csdn.net/yeasy/article/details/47749725