서비스 발견 이란 무엇 입 니까?

요약: 용 기 를 클 러 스 터 에 배치 할 때 서비스 주소, 즉 IP 와 포트 는 클 러 스 터 시스템 에서 동적 으로 분 배 됩 니 다.그렇다면, 우리 가 이 서 비 스 를 방문 해 야 할 때, 어떻게 그것 의 주 소 를 확정 합 니까?이 럴 때 는 서비스 발견 (Service Discovery) 이 필요 하 다.본 고 는 Nginx 의 배 치 를 예 로 들 어 서비스 발견 의 원리 와 실천 을 소개 할 것 이다.

저자: KiwenLau

날짜: 2016 - 09 - 04

1. 단기 배치 Nginx
Nginx 는 웹 서버 로 아파 치 와 기능 이 일치 합 니 다.Docker 를 사용 하면 Nginx 를 빠르게 배치 할 수 있 습 니 다.
1. Nginx 미 러 다운로드

sudo docker pull nginx:1.10

2. Nginx 용기 실행

sudo docker run -d \
                -p 8080:80 \
                nginx:1.10

그 중에서 - d 옵션 은 Nginx 용기 가 배경 에서 실행 되 고 있 음 을 나타 내 며 - p 옵션 은 호스트 의 8080 포트 가 용기 의 80 포트 로 비 치 는 것 을 나타 낸다.
3. Nginx 서비스 방문
브 라 우 저 서비스 사용 Nginx
http://192.168.59.1:8080
또는 curl 명령 을 사용 하여 Nginx 에 접근 하면 html 파일 로 되 돌아 갑 니 다.

curl 192.168.59.1:8080

Nginx 의 서비스 주 소 는 192.168.59.1: 8080 이 고 그 중에서 192.168.59.1 은 Nginx 용 기 를 실행 하 는 호스트 의 IP 이 며 8080 은 Nginx 가 서 비 스 를 제공 하 는 포트 이다.
이 를 통 해 알 수 있 듯 이 용 기 를 하나의 호스트 에 배치 할 때 서비스의 IP 는 용 기 를 실행 하 는 호스트 IP 이 고 서비스의 포트 는 - p 옵션 을 통 해 수 동 으로 지정 할 수 있 습 니 다. 이때 서비스 주 소 는 정적 으로 분 배 된 것 이기 때문에 서비스 에서 발견 한 문제 가 존재 하지 않 습 니 다.그러나 우리 가 용 기 를 여러 노드 의 군집 에 배치 할 때 는?
2. Mesos / marathon 클 러 스 터 에 Nginx 배치
먼저, Docker 를 바탕 으로 다 중 노드 Mesos / marathon 을 구축 하 는 방법 에 따라 3 개의 노드 의 Mesos / marathon 클 러 스 터 를 신속하게 구축 할 수 있 습 니 다.Nginx 배치 시 서비스 발견 을 사용 하지 않 아 도 되 고, 마라톤 LB 로 서비스 발견 을 제공 할 수도 있다.두 가지 방식 을 비교 해 보면 서 비 스 를 더 잘 이해 할 수 있다.
1. 서비스 사용 안 함 발견
Nginx 정의 (nginx1. json):

{
    "id": "nginx1",
    "cpus": 0.2,
    "mem": 20.0,
    "instances": 1,
    "healthChecks": [{
        "path": "/"
    }],
    "container": {
        "type": "DOCKER",
        "docker": {
            "image": "nginx:1.10",
            "network": "BRIDGE",
            "portMappings": [{ "containerPort": 80, "hostPort": 0, "protocol": "tcp" }]
        }
    }
}

그 중에서 인 스 턴 스 는 1 로 하나의 Nginx 용기 만 배치 하 는 것 을 나타 낸다.hostPort 는 0 으로 Nginx 용기 에 연 결 된 호스트 포트 는 Marathon 에서 무 작위 로 분 배 됩 니 다.
Nginx 배치:

curl -Ss \
     -X POST \
     -H "Content-Type: application/json" \
     --data "@nginx1.json" \
     http://127.0.0.1:8080/v2/apps | python2.7 -mjson.tool

이때 Nginx 용 기 는 node 2 (192.168.59.2) 에서 실 행 될 수도 있 고 node 3 (192.168.59.3) 에서 실 행 될 수도 있 기 때문에 Nginx 서비스의 IP 는 사전에 확인 할 수 없다.Nginx 용기 에 연 결 된 호스트 포트 는 Marathon 에서 무 작위 로 분 배 됩 니 다. 확실 하지 않 습 니 다.
물론 서비스 포트 는 hostPort 를 통 해 지정 할 수 있 지만 포트 충돌 이 발생 할 수 있 기 때문에 적합 하지 않 습 니 다.클 러 스 터 에서 매우 많은 서로 다른 서 비 스 를 실 행 했 을 때 정적 분배 포트 는 비 현실 적 이 고 클 러 스 터 의 유연성 과 확장 성 을 제한 했다.
Slave 노드 에서 docker ps 명령 을 사용 하면 Nginx 서비스의 IP 와 포트 를 가 져 올 수 있 습 니 다.
node2(192.168.59.2)

sudo docker ps | grep nginx
b863d407b880        nginx:1.10              "nginx -g 'daemon off"   15 minutes ago      Up 15 minutes       443/tcp, 0.0.0.0:31575->80/tcp   mesos-d34d0b5b-c3b1-4020-9bb2-bb8582252bf3-S0.d2de6d05-9751-4fbe-af10-d7e35e9e6c7b

node3(192.168.59.3)

sudo docker ps | grep nginx

알 수 있 듯 이 Nginx 서비스의 IP 와 포트 는 각각 192.168.59.2 와 31575 이다. 즉, Nginx 의 서비스 주 소 는 다음 과 같다.http://192.168.59.2:31575
Nginx 를 재배 치 할 때마다 IP 와 포트 가 달라 집 니 다. 이 는 매번 수 동 으로 서비스 주 소 를 조회 해 야 한 다 는 뜻 입 니 다. 불편 하고 배치 임 무 를 자동화 할 수 없습니다.용기 집단 에서 통상 적 으로 매우 많은 다른 응용 을 실행 해 야 하 는데 이것 은 서비스 발견 이 용기 집단 시스템 의 필수 기능 이라는 것 을 의미한다.
2. Marathon LB 로 서비스 제공 발견
마라톤 LB 는 마라톤 의 서비스 발견 시스템 이다.마라톤 LB 는 해 프 록 시 를 사용 해 프 록 시 기능 을 구현 했다.
Marathon LB 를 사용 하면 서비스의 고정 포트 를 설정 할 수 있 고 서비스의 IP 는 Marathon LB 를 실행 하 는 노드 IP 입 니 다.Marathon LB 는 Marathon 의 스케줄 링 이 벤트 를 감청 하고 용기 가 실제 실행 중인 IP 와 포트 를 가 져 온 다음 Haproxy 의 프로필 을 업데이트 합 니 다.따라서 Nginx 를 재배 치 할 때 저 희 는 고정된 IP 와 포트 를 통 해 이 서 비 스 를 방문 할 수 있 습 니 다.
Nginx 정의 (nginx2. json):

{
    "id": "nginx2",
    "labels": {
        "HAPROXY_GROUP": "external"
    },
    "cpus": 0.2,
    "mem": 20.0,
    "instances": 1,
    "healthChecks": [{
        "path": "/"
    }],
    "container": {
        "type": "DOCKER",
        "docker": {
            "image": "nginx:1.10",
            "network": "BRIDGE",
            "portMappings": [{ "containerPort": 80, "hostPort": 0, "servicePort": 10000, "protocol": "tcp" }]
        }
    }
}

그 중 nginx2. json 은 HAPROXY 밖 에 없어 요.GROUP 과 servicePort 두 곳 이 수정 되 었 습 니 다.HAPROXY_GROUP 은 external 로 Nginx 가 external 로 구 성 된 Marathon LB 를 서비스 로 발견 할 것 임 을 나타 낸다.servicePort 는 10000 으로 Nginx 가 Marathon LB 노드 의 10000 포트 를 사용 하여 서 비 스 를 제공 할 것 임 을 나타 낸다.
Nginx 배치:

curl -Ss \
     -X POST \
     -H "Content-Type: application/json" \
     --data "@nginx2.json" \
     http://127.0.0.1:8080/v2/apps | python2.7 -mjson.tool

이때 Nginx 서비스의 IP 는 Marathon LB 를 실행 하 는 노드 IP 인 192.168.5.9.1 이 고 Nginx 서비스의 포트 는 servicePort 가 지정 한 포트 인 10000 이다.따라서 Nginx 의 서비스 주 소 는 다음 과 같 습 니 다.http://192.168.59.1:10000。Nginx 용기 의 실제 주 소 는?http://192.168.59.2:31270, Marathon LB 는 프 록 시 서버 리 트 윗 서비스 요청 으로 Haproxy 를 사용 합 니 다.Marathon LB 는 Marathon 의 스케줄 링 이 벤트 를 감청 하고 용기 가 실제 실행 중인 IP 와 포트 를 가 져 온 다음 Haproxy 의 프로필 을 업데이트 합 니 다.다음은 Marathon LB 에서 자동 으로 생 성 되 는 Haproxy 프로필 입 니 다.

frontend nginx2_10000
  bind *:10000
  mode http
  use_backend nginx2_10000

backend nginx2_10000
  balance roundrobin
  mode http
  option forwardfor
  http-request set-header X-Forwarded-Port %[dst_port]
  http-request add-header X-Forwarded-Proto https if { ssl_fc }
  option  httpchk GET /
  timeout check 20s
  server 192_168_59_2_31270 192.168.59.2:31270 check inter 60s fall 4

Haproxy 에서 Niginx 서비스의 전단 (frontend) 주 소 는 *: 10000 이 고 백 엔 드 (backend) 주 소 는 192.168.5.9.2: 31270 임 을 알 수 있 습 니 다.해 프 록 시 는 서비스 요청 을 Nginx 용기 로 전달 하 는 역할 을 한다.
Nginx 를 재배 치 할 때 Nginx 용기 의 IP 와 포트 가 변 하고, Marathon LB 는 Haproxy 설정 파일 을 업데이트 하기 때문에 우 리 는 여전히 통과 할 수 있 습 니 다.http://192.168.59.1:10000방문 서비스.
따라서 Marathon LB 의 임 무 는 서비스의 주소 (IP 와 포트) 를 발견 한 다음 에 사용 자 는 매번 수 동 으로 조회 하지 않 아 도 된다.bamboo 와 nixy 는 같은 기능 을 실현 했다.
참고

Understanding Modern Service Discovery with Docker

Docker 기술 을 바탕 으로 PaaS 클 라 우 드 플랫폼 구축

유 잔 서비스 발견 개술