프로덕션 환경에서 docker mesos 실행

저희는 신선식품 전자상거래 기업으로, 시스템 구축 초기부터 마이크로서비스 아키텍처를 도입하고 DevOps 시스템을 기반으로 배송의 품질과 효율성을 지속적으로 개선하고 있습니다. 비즈니스 및 팀 규모가 발전함에 따라 서비스는 점차 분할되고 서비스 간의 상호 작용은 점점 더 복잡해집니다. 현재 전체 마이크로 서비스에는 로드 밸런싱, API 게이트웨이, Dubbo- 현재로서는 전체 클러스터의 리소스 활용에 대한 합리적인 계획 및 평가가 없습니다. 또한 가상 머신에 배포된 여러 애플리케이션 서비스를 격리하는 데에도 문제가 있습니다. 점점 더 많은 매장과 제3자 트래픽에 대한 접근, 시스템의 빠른 확장성을 고려해야 하며, 통합 리소스 관리 기반의 Docker 컨테이너 기술은 이러한 측면에서 자연스러운 장점을 가지고 있으며 마이크로서비스 아키텍처와 완벽하게 연결되며 DevOps 시스템.

연구와 비교 끝에 우리는 마침내 기본 리소스의 관리 및 스케줄링으로 Mesos를, Docker 실행 프레임워크로 Marathon을, 서비스 등록 및 검색으로 ZooKeeper, Consul 및 Nginx를 채택했습니다. 현재 일부 핵심 사업은 이미 Docker 컨테이너 기반의 Mesos 자원 관리 플랫폼에서 원활하게 운영되고 있습니다.

논리적 아키텍처

배포 아키텍처

릴리스 프로세스에서 릴리스가 온라인으로 전환되기 전의 링크는 사전 릴리스 환경 검증 후입니다. 완료되면 패키지화되고 생성됩니다. 가상 머신 배포를 기반으로 하는 Docker 이미지와 애플리케이션 배포 패키지가 해당 웨어하우스로 푸시되고 태그가 지정됩니다.

프로덕션 환경 출시 과정에서 메소스 클러스터와 원본 가상머신 클러스터에 동시에 출시되며, 두 클러스터 네트워크가 연결된다.

네트워크 아키텍처

네트워크 아키텍처를 선택할 때 몇 가지 원칙이 고려됩니다.

Docker 브리지는 기본 docker0 브리지를 사용하며 컨테이너는 독립적인 네트워크를 갖습니다. 네임스페이스, 호스트 간 컨테이너 통신에는 포트 NAT 매핑이 필요합니다. 호스트 방법은 호스트와 동일한 네트워크 네임스페이스를 사용하며 네트워크를 격리할 수 없으며 이러한 방법은 포트 경합 제한이 많습니다.

Docker Overlay 방식은 호스트 간 통신을 해결할 수 있습니다. 기존의 두 번째 또는 세 번째 계층 네트워크 위에 독립적인 네트워크가 구축됩니다. 이 네트워크는 일반적으로 자체적인 IP 주소 공간과 스위칭을 갖습니다. 라우팅 구현.

Docker는 오버레이 네트워크를 완성할 수 있는 다중 호스트 네트워크 기능을 제공합니다. 터널링과 라우팅의 두 가지 주요 방법이 있습니다. 터널링 원리는 다음과 같이 표현되는 기본 네트워크 프로토콜을 패키지하는 것입니다. 플란넬.

다른 하나는 Calico와 같은 호스트 전체의 컨테이너 간 통신을 달성하기 위해 호스트에서 라우팅 구성을 구현하는 것입니다.

Calico는 3계층 BGP 프로토콜을 기반으로 하는 라우팅 솔루션으로, 패킷 터널을 사용하지 않고 NAT도 없어 보안 격리 보호와 매우 상세한 ACL 제어를 지원합니다. 하이브리드 클라우드에 적합합니다. 조화도가 비교적 높습니다. 포괄적인 비교와 고려 후에 우리는 Calico를 사용하여 호스트 간 네트워크 통신을 달성합니다.

ETCD 클러스터를 설치하고 로드 밸런싱 VIP 모드(LVS+keepalived)를 통해 ETCD 클러스터에 액세스합니다.

ETCD_AUTHORITY=10.10.195.193:2379

내보내기 ETCD_AUTHORITY

Calico 네트워크 클러스터를 구축하고 현재 노드를 클러스터에 추가합니다. Calico 노드는 Etcd를 쿼리합니다. 시작된 후 BGP 프로토콜을 사용하여 다른 Calico 노드와 연결을 설정합니다.

./calicoctl node –libnetwork –ip=10.10.3.210

사용 가능한 주소 풀 IP 풀 추가

./calicoctl pool add 10.4.10.0/24 –nat-outgoing

./calicoctl pool show

네트워크를 생성하고 Calico IPAM 플러그인을 사용합니다. 드라이버(IPAM 포함)는 다음을 포함한 네트워크 관리를 담당합니다. 리소스 할당 및 재활용), - d는 드라이버 유형을 Calico로 지정하고 online_net 드라이버를 Calico로 사용하여 네트워크를 만듭니다.

docker network create -d calico –ipam-driver calico –subnet=10.4.10.0 /24 online_net

컨테이너를 시작하고 방금 생성한 online_net을 네트워크용으로 지정합니다. 컨테이너가 시작되면 해당 Docker API가 하이재킹되고 네트워크가 초기화됩니다. Etcd를 쿼리하여 사용 가능한 IP를 자동으로 할당하고, 컨테이너와 호스트 간의 통신을 위한 veth 인터페이스 쌍을 생성하고, 컨테이너에 IP를 설정하고, IP ​​전달을 활성화하고, 호스트 라우팅 테이블에서 이 인터페이스에 경로를 추가하고, 호스트 10.10.3.210 라우팅 테이블:

호스트 10.10.50.145의 라우팅 테이블:

컨테이너 패키지 전송 패키지의 라우팅 프로세스는 위 그림과 같습니다. 컨테이너 IP 10.4. 호스트 10.10.3.210의 10.64가 라우팅됩니다. 테이블은 데이터 패킷을 다른 호스트 10.10.50.145의 컨테이너 10.4.10.55로 보냅니다.

상태 저장 데이터베이스, 캐시 등의 경우 물리적 머신(가상 머신)이 계속 사용되는 반면 애플리케이션 클러스터는 가상 머신에 연결되어 서비스에 액세스하고 상호 작용해야 합니다. 그리고 데이터. 그런 다음 실제 머신(가상 머신)의 컨테이너 네트워크 클러스터에 현재 노드를 추가하기만 하면 됩니다.

ETCD_AUTHORITY=10.10.195.193:2379

내보내기 ETCD_AUTHORITY

./calicoctl node –ip=10.10.16.201

서비스 자체 등록 및 검색

API 게이트웨이는 두 개의 계층으로 나누어진 통합 API 액세스 입구를 제공합니다. 첫 번째 레이어는 통합 라우팅, 흐름 제어, 보안 인증, WAF, 그레이스케일 기능 릴리스 및 기타 기능을 제공하고, 두 번째 레이어는 Dubbo 서비스를 호출하여 서비스 오케스트레이션을 실현하고 외부 게이트웨이 오케스트레이션 서비스 기능을 제공하는 웹 애플리케이션 레이어입니다. 비즈니스 서비스 인터페이스의 변화 웹 계층의 신속한 액세스와 확장을 빠르고 원활하게 달성하기 위해 Consul을 서비스 등록 센터로 사용하여 웹 서비스의 자동 등록 및 검색을 실현합니다.

웹 서비스 등록을 위해 우리는 Consul의 API를 호출하여 등록하는 Register를 직접 구현했으며 TTL 메커니즘을 사용하여 애플리케이션의 상태에 대한 하트비트 보고서를 정기적으로 수행했습니다.

웹 서비스 검색을 위해 Netflix Zuul을 기반으로 확장 및 변형했으며 라우팅 측면에서는 Consul의 검색 메커니즘을 통합하고 도메인 이름 기반 라우팅 방법을 추가했으며 라우팅을 강화했습니다. 구성 기능을 구성한 동적 다시 로드 기능을 구현합니다. API 게이트웨이는 예약된 작업을 시작하고, Consul API를 통해 웹 서비스 인스턴스의 상태를 획득하고, 로컬 라우팅 캐시를 업데이트하고, 동적 라우팅 기능을 구현합니다.

플랫폼의 마이크로서비스 프레임워크는 Dubbo RPC를 기반으로 구현되며 Dubbo는 서비스 검색 및 등록을 위해 ZooKeeper를 사용합니다.

Mesos Docker 클러스터에서 Consul 배포 계획:

Consul Agent와 컨테이너 애플리케이션을 미러로 패키징하는 것은 권장되지 않으므로 Consul Agent는 각 Mesos에 배포됩니다. 슬레이브 호스트. 그러면 컨테이너는 서비스를 등록하고 등록 취소하기 위해 호스트의 IP 주소를 어떻게 얻습니까? 컨테이너 시작 프로세스 중에 기본적으로 현재 호스트 IP가 환경 변수로 컨테이너에 전달되므로 등록 모듈이 컨테이너 애플리케이션의 Consul을 얻을 수 있습니다. 프록시 IP는 Consul의 API를 호출하여 서비스를 등록하고 제거합니다.

일일 애플리케이션 릴리스에서는 릴리스 프로세스가 온라인 비즈니스에 영향을 미치지 않도록 하고 원활한 롤링 릴리스를 달성해야 합니다. 그런 다음 애플리케이션이 중지되면 경로를 알리고 트래픽 전환을 수행해야 합니다. 수행됩니다.

docker stop 명령이 실행되면 먼저 컨테이너에 있는 PID 1을 가진 프로세스에 시스템 신호 SIGTERM을 보낸 다음 대기 시간 동안 컨테이너에 있는 애플리케이션이 실행을 종료할 때까지 기다립니다. 설정된 시간 초과에 도달하거나 기본 10초 동안 SIGKILL 시스템 신호를 계속 보내 프로세스를 강제로 종료합니다. 이런 방식으로 프로그램이 SIGTERM 신호를 수신한 후 프로그램 실행 장면을 처리하고 저장하는 데 일정 시간을 허용하고 프로그램을 정상적으로 종료하도록 허용하고 처리합니다. 신호를 받은 후 애플리케이션의 PID를 찾고 애플리케이션 프로세스를 원활하게 종료합니다.

애플리케이션의 원활한 롤링 릴리스 및 충돌 복구

Marathon은 실행 중인 애플리케이션을 위한 유연한 재시작 전략을 제공합니다. 애플리케이션에 하나의 인스턴스만 실행 중이고 이때 다시 시작되면 Marathon은 기본적으로 새 인스턴스가 다시 시작된 후 원래 인스턴스가 중지되므로 원활하게 다시 시작되고 원활한 롤링 릴리스를 충족합니다. 신청 요구 사항.

물론 Marathon에서 제공하는 매개변수를 통해 원하는 재시작 전략을 설정할 수 있습니다.

“upgradeStrategy”:{ “minimumHealthCapacity”: N1, “maximumOverCapacity”: N2 }

p>

새 인스턴스가 시작되어 서비스를 제공할 수 있는지, 현재 컨테이너의 애플리케이션 인스턴스가 정상인지, 인스턴스를 사용할 수 없어 복원해야 하는지 여부를 확인하는 방법입니다. Marathon은 healthchecks 상태 모니터링 모듈을 제공합니다

" healthChecks": [{

"protocol": "COMMAND",

"command":{

"value":"sh /data/soft/ healthcheck.sh app 10.10.195.193"

},

"gracePeriodSeconds": 90,

"intervalSeconds": 60,

"timeoutSeconds": 50,

"maxConsecutiveFailures": 3

}]

상태 확인 .sh는 로드 밸런싱을 통해 HealthMonitor를 호출하여 애플리케이션 인스턴스의 모니터링 상태를 얻습니다. HealthMonitor는 애플리케이션 인스턴스의 전체 토폴로지 정보를 얻을 수 있는 당사의 Health Check 센터입니다.

컨테이너 모니터링 및 로그

컨테이너 모니터링을 위해 Mesos Docker의 컨테이너 자원 관리 아키텍처를 채택하고 있으므로 mesos-exporter+Prometheus+Grafana, mesos 모니터링 솔루션을 사용하는 것이 특징입니다. -exporter는 상관관계가 없는 개별 컨테이너가 아닌 작업 관점에서 작업 모니터링 데이터를 수집하고 리소스 사용량을 파악할 수 있다는 점입니다. mesos-exporter는 Mesos 클러스터의 모니터링 데이터를 Prometheus로 내보냅니다. Prometheus는 모니터링 알람과 시계열 데이터베이스의 조합으로, 매우 강력한 저장 기능을 제공하며 데이터 표현에는 Grafana가 사용됩니다.