퍼포먼스 오케스트라

최고의 남자라고 해도 과언이 아닐 것이다.
고난을 통해 기쁨을 찾으십시오.
루트비히 판 베토벤

저는 Sergey입니다. Yandex.Money의 성과 연구팀에서 일하고 있습니다. 저는 오케스트레이션을 사용하는 과정, 즉 악기를 선택하는 방법과 고려한 사항에 대한 이야기의 시작을 말씀드리고 싶습니다. 기사의 모든 이벤트는 실시간으로 진행되므로 독자 여러분은 상황의 전개를 거의 실시간으로 따라가고 있습니다.

우리 팀에 지휘자가 필요한 이유는 무엇입니까?

지휘자는 누구입니까? fr에서. diriger - 음악의 세계에서 관리하고, 지휘하고, 이끄는 - 앙상블 음악의 학습과 연주를 주도하는 사람입니다. 우리의 경우 이 자리는 오케스트레이션 및 자동화 시스템이 차지합니다.

그들의 역할은 음악 지휘자의 역할과 다르지 않습니다. 그들은 팀을 돕고, 연극을 안내하고 조직하는 데 필요합니다.

일반적으로 팀에는 프로젝트를 구현하는 특정 용량(서버라고 부르자)이 있습니다.

이러한 서버를 확보하고 운영하는 접근 방식은 다양합니다. 몇 가지 예:

• 팀은 예를 들어 운영 그룹에 특정 매개변수가 포함된 리소스를 제공하도록 요청합니다.
• 운영팀은 필요한 수량(클라우드 또는 베어 메탈)을 제공하고 SLA에 따라 적절한 상태로 유지 관리합니다. 설정도 운영팀에서 수행합니다.
• 팀은 운영 그룹으로부터 클라우드 또는 베어메탈 리소스만 받아 자체적으로 구성합니다.
• 팀 자체가 리소스를 "구매"하고 이를 완전히 독립적으로 유지/설정합니다.

우리 팀은 OS 업데이트, 새 패키지 설치 등 지원이 필요한 서버를 사용합니다.

우리는 이를 두 가지 주요 유형으로 나누었습니다.

• 탱크 그룹,
• 서비스 그룹.

탱크 그룹은 Yandex.Tank가 있는 호스트로 구성됩니다.

서비스 그룹에는 유지 관리와 관련된 모든 것이 포함됩니다. 이는 릴리스 주기 지원, 자동 보고서 생성 등을 제공하는 다양한 서비스입니다.

어느 순간 이 모든 것을 수동으로 관리하기가 불편해졌고, 우리는 서버 '로딩'부터 시작하여 내부 서비스의 개발, 출시, 출시까지 전체 프로세스를 자동화하는 것을 고려했습니다.

오케스트라 자체는 연주할 수 있는데 왜 지휘자가 필요한가?

우선, 우리는 Ansible을 마스터하고 시스템 관리자에 대한 의존도를 줄이기 위해 베어메탈 서버를 "부어"하기 시작했습니다. 여기서 모두가 승리하고 새로운 기술을 습득하며 관리자가 우리 없이는 항상 충분했던 일부 작업을 덜어줍니다. . 우리는 전문성과 팀 자율성을 최대한 뛰어넘어 발전하기 위해 노력합니다.

회사에서는 Ansible을 사용한 작업이 오랫동안 구성 및 규제되어 왔기 때문에 우리 솔루션을 이 프로세스에 쉽게 통합했습니다.

현재 호스트 풀은 세 가지 Ansible 역할로 구성됩니다.

• 첫 번째 역할은 OS를 설치하고,
• 두 번째는 호스트에 대한 기본 설정인 LDAP 인증을 실행합니다. 예를 들면 다음과 같습니다.
• 세 번째는 Yandex.Tank 및 관련 종속성을 Docker 컨테이너에 설치합니다.

팀 내에서 사용하는 서비스로 넘어가겠습니다.

우리 작업에서는 Kotlin과 Python을 동일하게 사용하고 Golang을 조금 더 사용합니다. 서비스 개발 및 배포를 통합하기 위해 서비스를 Docker 컨테이너에 패키징하기로 결정했습니다. 이를 통해 프로그래밍 언어를 자유롭게 선택할 수 있으며 동시에 애플리케이션에 대한 균일한 전달 형식을 규제할 수 있습니다.

Docker의 ipv6에 대한 작은 참고 사항

우리가 상호 작용하는 일부 서비스는 ipv6을 통해서만 사용할 수 있으므로 컨테이너용 ipv6을 만드는 방법을 알아내야 했습니다.

공식 Docker 웹사이트의 ipv6 문서에 따르면 ipv6은 daemon.json에 매개변수를 추가하여 활성화됩니다.

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

이 경우 공급자는 귀하가 등록할 ipv6 서브넷을 발급해야 합니다. fixed-cidr-v6.
그러나 우리는 다른 옵션인 ipv6 NAT를 선택했으며 그 이유는 다음과 같습니다.

• 이제 도커 사용할 수 없다 ipv6에서만 가능합니다.
• 각 컨테이너에 전역적으로 라우팅 가능한 주소가 있다는 것은 추가 필터링을 수행하지 않는 한 모든 포트(게시되지 않은 포트도 포함)가 모든 사람에게 노출된다는 의미입니다.
• 게시 포트를 위한 사용자 영역 프록시, ipv4 전용 iptables.

IPv6 NAT는 도커 컨테이너, 이는 자체적으로 ip6tables의 규칙을 관리하고 새 컨테이너를 추가할 때 규칙을 편집합니다.

이 솔루션이 올바르게 작동하려면 다른 여러 가지 조작이 필요했습니다. 시스템에서 ip6table_nat를 초기화해야 합니다. 시스템에 모듈이 설치되어 있다고 해서 시작 시 모듈이 커널에 로드된다는 보장은 없습니다. 새로운 호스트에서 NAT를 사용하여 컨테이너를 실행할 때 이 오류가 발생했을 때 이 문제가 발생했습니다.

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)

modprobe 모듈을 사용하여 Ansible 역할에 초기화를 추가하고 lineinfile을 사용하여 OS 시작 시 이를 로드한 후 문제가 해결되었습니다.

- name: Add ip6table_nat module
 modprobe:
   name: ip6table_nat
   state: present
- name: Add ip6table_nat to boot
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

그건 그렇고, 허브에 좋은 것이 있습니다 기사, docker에서 ipv6을 실행하는 여러 가지 방법의 장점과 단점을 간단하고 명확하게 설명합니다.

하지만 처음에 했던 질문으로 돌아가 보겠습니다.
오케스트라 자체는 연주할 수 있는데 왜 지휘자가 필요한가?

이제 모두가 우리 팀에서 플레이하는 방법을 상상합니다.

• 서버를 "푸어"하는 프로세스가 생성되었습니다.
• 서비스 개발과 배포가 통합됩니다.

합리적인 질문이 생깁니다. Docker 컨테이너에서 서비스를 어떻게 효율적이고 자동으로 배포, 업데이트 및 제어할 수 있을까요?

각 오케스트라 단원은 자신의 역할을 알고 있음에도 불구하고 혼란스러워하고 원래 생각에서 벗어날 수 있습니다. 여기서 우리는 지휘자가 없으면 우리 오케스트라가 효과적으로 리허설하고 일관되게 연주할 수 없다는 결론에 도달합니다. 지휘자는 공연의 모든 매개변수를 담당하여 모든 것이 하나의 템포와 분위기로 통합되도록 합니다.

최소한의 투자로 좋은 지휘자를 얻는 방법은 무엇입니까?

오케스트레이션이라는 주제는 시장에서 꽤 잘 발달되어 있습니다. 하지만 먼저 지휘자에게 도움이 될 수 있는 보조 도구에 대해 이야기해 보겠습니다.

영사 - 두 가지 주요 기능을 제공하는 시스템:

• 서비스 발견,
• 분산된 키-값 저장소.

우리 오케스트라에서는 Consul이 서비스 등록 및 구성 저장을 담당합니다. 두 가지 등록 옵션이 있습니다:

• 활성은 서비스가 HTTP API를 사용하여 자체적으로 등록되는 경우입니다.
• 수동 - 서비스를 수동으로 등록해야 합니다.

Vault는 비밀번호, 인증서 등 비밀의 보안 저장 및 처리를 표준화하고 통합하는 저장소입니다.
이 도구를 사용하여 얻을 수 있는 이점은 다음과 같습니다.

• HTTP API를 사용하여 비밀을 생성 및 저장하고 비밀의 수명 주기를 관리하는 단일 센터입니다.
• Transit Secrets Engine - 데이터를 저장하지 않고 암호화 및 해독합니다. 보안되지 않은 통신 채널을 통해 암호화된 형식으로 데이터를 전송하는 기능입니다.
• 구성하기 쉬운 액세스 정책.
• 비밀에 대한 액세스 감사.
• 인프라 내에서 자체 서명된 인증서를 관리하기 위해 자체 CA(인증 기관)를 생성하는 기능.

모든 요구 사항을 고려할 때 지휘자의 역할에는 Kubernetes와 Nomad라는 두 가지 옵션이 적합했습니다.

Kubernetes

그에 대해 이미 얼마나 많은 기사와 책이 쓰여졌습니까 (여기 그런, 예를 들어) 간략하게 작성할 보고서가 있습니다. 이것은 거의 모든 작업을 수행할 수 있는 만능 수확기입니다. 이에 대한 대가는 Kubernetes에서 클러스터를 설정하고 유지 관리하는 것이 항상 쉬운 것은 아니라는 것입니다.

유목민

수단 위에서 언급한 영사 및 금고로 유명한 HashiCorp 회사의 제품입니다.

우리는 Nomad가 Kubernetes보다 설치 및 구성이 훨씬 쉽다는 것을 알았습니다. 하나의 바이너리 파일은 서버와 클라이언트 모드 모두에서 작동합니다. 동시에 Nomad는 클러스터 관리, 빠른 스케줄러, 멀티 데이터 센터 지원 등 우리가 해결하고자 하는 작업의 전체 목록을 다룹니다. 또한 consul과 Vault를 사용하면 서비스 조정을 위한 통합이 더욱 긴밀해집니다.

현재 진행 중인 작업:

• Consul 배포를 위해 준비된 서버,
• nomad 클러스터 구성은 Consul에 입력되며, 이를 통해 nomad가 자동으로 배포됩니다.
• 동시에 비밀을 저장하기 위해 저장소를 설치할 것입니다.

청중을 위한 질문: 그러한 작업을 위해 지휘자를 고용할 가치가 있습니까? 아니면 지휘자가 없어도 오케스트라가 잘 되고 있습니까? 이에 대해 어떻게 생각하는지 댓글로 알려주세요.

블로그를 구독하고 연락을 유지하세요. 결국 무슨 일이 일어났는지, 그리고 노마드 클러스터를 원하는 방식으로 구성했는지 여부를 곧 알려드리겠습니다.

우리 아늑한 곳으로 오세요 전보 채팅에서는 언제든지 조언을 구하고, 동료를 돕고, 생산성 연구 등에 관해 대화를 나눌 수 있습니다.

출처 : habr.com