React 개인 블 로그 구축 (2) consul - template + nginx + docker 부하 균형 실현

13083 단어 부하 균형 nginx consul

프로필
지난 편 에 서 는 블 로그 의 전단 문제 만 이야기 하 였 는데, 이 편 에 서 는 백 엔 드 의 마이크로 서비스 구축 에 대해 이야기 하 였 다.프로젝트 의 백 엔 드 에 사용 되 는 thinkjs 프레임 워 크 는 제 이전 블 로그 에 이미 썼 습 니 다. 여 기 는 중점적으로 설명 하지 않 겠 습 니 다.백 엔 드 항목 은 세 개 로 나 뉜 다.

블 로그 프론트 페이지 서버: 여기 있 습 니 다.

블 로그 백 스테이지 페이지 서버: 여기 있 습 니 다.

consul - template + nginx 가 실현 한 마이크로 서비스 등록 을 바탕 으로 발 견 된 부하 균형: 여기 있 습 니 다.

앞의 두 데이터 업무 와 관련 된 서비스 즉 아래 그림 의 service웹, 세 번 째 항목 은 consul - template + nginx 의 부하 균형 입 니 다.콘 솔 의 기본 개념 에 대해 잘 모 르 신다 면 제 블 로그 에 있 는 이 두 편의 글 을 읽 고 다음 내용 을 계속 보 시 는 것 을 권장 합 니 다.consul + docker 서비스 등록 실현.consul + docker 는 서비스 발견 및 게 이 트 웨 이 를 실현 합 니 다.먼저 구조 도 를 보 세 요.
구조 도 해석
consul - template 는 consul 등록 센터 의 서비스 정 보 를 구독 합 니 다. service - web 가 바 뀌 면 consul 등록 센터 는 새로운 service 웹 정 보 를 consul - template 에 보 냅 니 다. consul - template 는 nginx 설정 파일 을 수정 하고 nginx 는 설정 을 다시 불 러 오 면 자동 으로 업데이트 할 수 있 는 부하 균형 에 이 릅 니 다.
2. consul - template + nginx 는 마이크로 서비스 기반 부하 균형 을 실현 합 니 다.
consul - template 소개
Consul - template 는 Consul 을 기반 으로 설정 파일 을 자동 으로 교체 하 는 응용 프로그램 입 니 다.Consul - Template 가 나타 나 기 전에 여러분 이 서 비 스 를 구축 한 결과 시스템 은 대부분이 Zookeeper, Etcd + Confd 와 같은 유사 한 시스템 을 사 용 했 습 니 다.
사용 장면: Consul 의 서비스 디 렉 터 리, Key, Key - values 등 을 조회 할 수 있 습 니 다.이러한 강력 한 추상 적 인 기능 과 언어 템 플 릿 을 조회 하면 Consul - Template 는 동적 으로 프로필 을 만 드 는 데 특히 적합 합 니 다.예 를 들 어 아파 치 / Nginx Proxy Balancers, Haproxy Backends, Varnish Servers, Application Configurations 등 을 만 듭 니 다.
코드 소개
consul 등록 센터 의 서비스 가 바 뀌 었 을 때 consul - template 는 nginx - consul - template 에 따라 nginx. conf 를 다시 생 성 합 니 다.먼저 nginx. conf. ctmpl 의 코드 를 보십시오.
nginx.conf.ctmpl

upstream admin {
  {{range service "service-admin"}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=60 weight=1;
  {{else}}server 127.0.0.1:65535; # force a 502{{end}}
}
upstream app {
  {{range service "service-web"}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=60 weight=1;
  {{else}}server 127.0.0.1:65535; # force a 502{{end}}
}

server {
  listen 80 default_server;
#           
  location  /admin{
    proxy_pass http://admin/;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
   #              
   location  ^~/static/blog-backend-react{
    proxy_pass http://admin/static/blog-backend-react;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
 #              
location  ^~/static/blog-react{
    proxy_pass http://app/static/blog-react;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
 #     ，        
  location  /font{
    proxy_pass http://app;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
  #     ，        
  location  /api{
    proxy_pass http://admin/api;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
  #            
    location  / {
    proxy_pass http://app;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

template 와 정상 nginx. conf 의 차 이 는 바로 upstream 의 부분 입 니 다. 서비스 이름 에 따라 여 기 는 두 가지 서비스 입 니 다. self - blog - backend 블 로그 배경 관리 서비스 와 self - blog - fontend 블 로그 프론트 서비스 - 동적 생 성 서비스 에 대응 하 는 ip 입 니 다.template 의 역방향 프 록 시 부분 은 정상 적 인 nginx 설정 과 일치 합 니 다. 두 항목 이 있 기 때문에 모든 url 요청 인터페이스, 정적 자원, 서 비 스 는 특정한 서비스 에 투사 해 야 합 니 다.서비스 가 시 작 된 후 모델 에 따라 생 성 된 nginx 설정 파일 은 다음 과 같 습 니 다.

upstream admin {
  server 172.25.0.7:8362 max_fails=3 fail_timeout=60 weight=1;
  server 172.25.0.8:8362 max_fails=3 fail_timeout=60 weight=1;
   server 172.25.0.11:8362 max_fails=3 fail_timeout=60 weight=1;
}
upstream app {
  server 172.25.0.4:8365 max_fails=3 fail_timeout=60 weight=1;
  server 172.25.0.9:8365 max_fails=3 fail_timeout=60 weight=1;
  server 172.25.0.10:8365 max_fails=3 fail_timeout=60 weight=1;
}

server {
 ....
}

upstream 에서 서비스 이름 에 따라 해당 하 는 ip 을 찾 았 습 니 다.이 배경 에서 프론트 프로젝트 는 각각 세 개의 인 스 턴 스 를 시작 합 니 다. 사용자 가 방문 할 때 설정 한 nginx 부하 균형 전략 에 따라 하나의 ip 에 접근 합 니 다.
nginx.service
nginx 서비스 시작 에 사용

#!/bin/sh
#   nginx
# daemon off       ,  nginx    
nginx -c /etc/nginx/nginx.conf -t && \
  nginx -c /etc/nginx/nginx.conf -g "daemon off;"

consul.template.service
consul - template 시작 에 사용

#!/bin/sh
#   consul-template,  consul  
# consul   ，     nginx.conf ，  nigix     reload
exec consul-template \
     -consul-addr=consul:8500 \
     -template "/etc/consul-templates/nginx.conf:/etc/nginx/conf.d/app.conf:nginx -s reload"

Dockerfile
전체 부하 균형 서 비 스 는 미 러 를 만들어 다른 서비스 와 함께 배치 해 야 하기 때문에 Dockerfile 을 유지 해 야 합 니 다.

FROM nginx
 #       ，         （    ）
RUN DEBIAN_FRONTEND=noninteractive \
    #        
    apt-get update -qq && \
    #    curl runit
    apt-get -y install curl runit && \
    # rm   ，-r        , -f     
    rm -rf /var/lib/apt/lists/*

ADD consul-template_0.19.4_linux_amd64.tgz /usr/local/bin/
#   nginx.service        ，  run  
ADD nginx.service /etc/service/nginx/run
#               
RUN chmod a+x /etc/service/nginx/run
ADD consul-template.service /etc/service/consul-template/run
RUN chmod a+x /etc/service/consul-template/run

RUN rm -v /etc/nginx/conf.d/*
ADD nginx.conf /etc/consul-templates/nginx.conf
#   runit ,  runsvdir /etc/service/          ，
#   runsv        /etc/service  run  
CMD ["/usr/bin/runsvdir", "/etc/service"]

잘 지 키 면 자신의 nginx - consul - template 미 러 를 만 들 수 있 습 니 다.
docker-compose.yml
블 로그 배경 과 프론트 데스크 톱 서버 프로젝트 github 에는 모두 자신의 Dockerfile 이 있 습 니 다. 그들 을 미 러 로 만 든 후 nginx - consul - template 미 러 와 함께 docker - compose 를 통 해 이 몇 가지 서 비 스 를 통일 적 으로 배치 합 니 다.

version: "2.0"
services:
    consulserver:
        image: progrium/consul:latest
        hostname: consulserver
        ports:
            - "8300"
            - "8400"
            - 8500:8500
            - "53"
        command: -server -ui-dir /ui -data-dir /tmp/consul --bootstrap-expect=3
    consulserver1:
        image: progrium/consul:latest
        hostname: consulserver1
        depends_on:
            - consulserver
        ports:
            - "8300"
            - "8400"
            - "8500"
            - "53"
        command: -server -data-dir /tmp/consul -join consulserver
    consulserver2:
        image: progrium/consul:latest
        hostname: consulserver2
        depends_on:
            - consulserver
        ports:
            - "8300"
            - "8400"
            - "8500"
            - "53"
        command: -server -data-dir /tmp/consul -join consulserver
    registrator:
        image: gliderlabs/registrator:master
        hostname: registrator
        depends_on:
            - consulserver
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock
        command: -internal consul://consulserver:8500
    serviceadmin1:
        image: daocloud.io/sunxing102005/self-blog-backend:latest
        depends_on:
            - consulserver
        environment:
            SERVICE_8362_NAME: service-admin
        ports:
            - 3002:3002
            - "8362"
    serviceweb1:
        image: daocloud.io/sunxing102005/self-blog-fontend:latest
        depends_on:
            - consulserver
        environment:
            SERVICE_8365_NAME: service-web
        ports:
            - 3005:3005
            - "8365"
    lb:
        image: daocloud.io/sunxing102005/consul-template-nginx-blog:latest
        hostname: lb
        links:
            - consulserver:consul
        ports:
            - 80:80

명령 실행, 서비스 시작

docker-compose up -d

실행 하면 등록 센터 에서 consul 에 등 록 된 서 비 스 를 볼 수 있 습 니 다. 그 중에서 consul - template - nginx - blog 는 lb, service - admin, service - web 는 각각 블 로그 의 프론트 데스크 이 고 백 스테이지 서비스 (3002, 3005 두 서 비 스 는 prometheus 에 게 데 이 터 를 잡 아 주 는 것 입 니 다. 신경 쓰 지 마 세 요) 는 각각 하나의 인 스 턴 스 만 시 작 했 기 때문에 그들 은 각각 하나의 서비스 만 있 습 니 다.다음은 nginx 의 효 과 를 보고 기본 80 포트 를 방문 하고 블 로그 전단 서 비 스 를 직접 방문 하여 80 포트 에 admin 접 두 사 를 추가 하면 블 로그 관리 사이트 로 이동 합 니 다.
개발 노트
여기에 개발 과정 에서 자신 이 기록 한 문제 와 지식 을 놓 아 라.
docker 용기 에 들 어가 서 consul - template 에서 생 성 된 nginx. conf 를 보 는 방법

docker ps                                  //  consul-template-nginx  id
docker exec -it exec 22fff6c360f1 /bin/sh //     
cat /etc/nginx/conf.d/app.conf           //

docker 가 nginx 를 실행 하 는데 왜 daemon off 를 실행 합 니까?
docker 용기 백 스테이지 가 실 행 될 때 프론트 데스크 톱 프로 세 스 가 있어 야 합 니 다.용기 가 실행 되 는 명령 은 계속 걸 려 있 지 않 으 면 자동 으로 종 료 됩 니 다.nginx 는 백 엔 드 프로 세 스 모드 가 실행 되 기 때문에 프론트 데스크 톱 에서 실행 되 는 응용 프로그램 이 없 으 면 바로 응용 프로그램 을 종료 합 니 다.해결 방법:

실행 할 용 기 를 이전 데스크 톱 으로 실행 하고 수위 프로 세 스 를 닫 습 니 다

nginx -g " daemon off"

tail, top 같은 프론트 데스크 톱 에서 실행 할 수 있 는 프로그램 을 추가 하고 tail 을 사용 한 다음 에 log

service nginx start && tail -f /var/log/nginx/error.log

를 지속 적 으로 출력 하 는 것 을 추천 합 니 다.
nginx. conf. ctmpl 주의사항

upstream admin {
  {{range service "service-admin"}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=60 weight=1;
  {{else}}server 127.0.0.1:65535; # force a 502{{end}}
}
upstream app {
  {{range service "service-web"}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=60 weight=1;
  {{else}}server 127.0.0.1:65535; # force a 502{{end}}
}

server {
  listen 80 default_server;

  location  /admin{
    proxy_pass http://admin/;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }

location 가 일치 하 는 것 이 아니라면 /, 이 서비스의 루트 디 렉 터 리 로 이동 하려 면 proxypass 정의 url, 뒤에 /, 예 를 들 어 여기 일치 하 는 / admin, proxy패스http://admin/하면, 만약, 만약...http://admin역방향 에이전트 의 경 로 는?http://XXXX:8362/admin8362 서비스의 경로 가 아 닙 니 다.http://XXXX:8362。
nginx 상용 명령

nginx        ，  
nginx -s reload ：           
nginx -s reopen ：        
nginx -t -c /path/to/nginx.conf   nginx        

  nginx：
nginx -s stop :    nginx
quit ：       nginx

     nginx   ：

ps -ef | grep nginx

kill -QUIT      ：    Nginx
kill -TERM      ：    Nginx
pkill -9 nginx ：    Nginx

 

  nginx:
nginx -c /path/to/nginx.conf

    nginx：
kill -HUP

nginx 역방향 에이전트
전단 에서 요청 할 때마다 token 은 request header 에 넣 었 습 니 다.이전에 header 에 설 치 된 필드 는 access 라 고 합 니 다.token, 전달 할 수 없습니다. nginx 역방향 대 리 를 발견 하면 밑줄 친 header 가 약간 있 기 때문에 accesstoken 으로 바 뀌 었 습 니 다.
docker 상용 명령

          systemctl start docker
         sudo systemctl daemon-reload
  docker     systemctl restart  docker
  docker    sudo service docker restart
  docker   service docker stop   
  docker  systemctl stop docker

docker 일괄 삭제 용기

docker rm `docker ps -a -q` //      
docker rmi `docker images -q` //      

//       
    //     
docker rmi `docker images -q | awk '/^/ {print $3}'`
    //     
docker rmi `docker images | grep doss api | awk 'print $3'`

linx chmod 명령

모든 사람 에 게 실행 가능 한 권한 을 추가 하면 chmod a + x 파일 이름

파일 소유자 에 게 실행 가능 한 권한 을 추가 하면 chmod u + x 파일 이름

해당 그룹 에 실행 가능 한 권한 을 추가 하면 chmod g + x 파일 이름

해당 그룹 이외 의 사람 에 게 실행 가능 한 권한 을 추가 하면 chmod o + x 파일 이름

상세 chmod 명령 은 여 기 를 참고 하 십시오.

linx 서비스 관리
ubuntu 자체 서 비 스 를 통 해 백 엔 드 실행 프로그램 을 쉽게 만 들 수 있 습 니 다.service 파일 경로: / lib / systemd / ystemservice 파일 은 여러 부분 을 포함 하고 다음은 간단 한 배경 에서 실행 되 는 service 파일 입 니 다.시작 서비스

service leshan-erver start

서비스 정지

service leshan-erver stop

서비스 상태 보기

systemctl status lenshan-server

서비스 파일 다시 불 러 오기

systemctl daemon-reload

총화
이 편 은 주로 consul - template + nginx 의 부하 균형 실현 을 설명 합 니 다. 인터넷 에서 비슷 한 설명 이 많 습 니 다. consul + nginx + consul - template 는 간단 한 마이크로 서 비 스 를 구축 하 는 것 도 기본 적 으로 자주 사용 되 는 방안 입 니 다.이 부분 은 이전에 제 가 리 트 윗 한 consul + docker 와 서비스 발견 과 게 이 트 웨 이 도 사실은 게 이 트 웨 이와 부하 균형 이 떨 어 졌 을 뿐 입 니 다.조금 주의해 야 할 것 은 본 프로젝트 에서 두 가지 업무 차원 의 서비스 인 블 로그 프론트 와 백 스테이지 두 가지 서 비 스 를 사 용 했 습 니 다. 단일 프로젝트 가 아니 라 약간 마이크로 서비스 느낌 이 들 어서 큰 프로젝트 를 분리 하여 관리 합 니 다.그래서 nginx 이 부분 은 두 항목 에 각각 역방향 으로 대리 해 야 합 니 다. 여기 서 인터페이스, 정적 등 을 요청 합 니 다. 두 서 비 스 는 구분 되 고 nginx 가 대리 로 구분 하 는 기준 이 있어 야 합 니 다.이로써 블 로그 의 전단, 백 엔 드 마이크로 서비스 구축 이 모두 끝 났 습 니 다. 시간 이 있 으 면 다음 편 은 daocloud 플랫폼 배치 와 prometheus + grafana 의 모니터링 시스템 에 대해 말씀 드 리 겠 습 니 다.
참고
https://www.jianshu.com/p/a4c...http://blog.zongwu233.com/Con...

이 내용에 흥미가 있습니까?

현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:

Haproxy 웹 클러스터 구축

실험 준비: Haproxy 서버 1대, Nginx 서버 2대, 클라이언트 1대(로컬 컴퓨터 사용) Nginx 서버: ### 참고: 둘 다 비슷한 작업을 수행해야 합니다. Haproxy 서비스: 테스트: 클라이언트가 ...

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.

Linux 커 널 파라미터 최적화

Debian 에서 Python + Django + Nginx + uWSGI + MySQL 의 튜 토리 얼 을 설정 합 니 다.

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다