"스타트업"부터 XNUMX개 데이터 센터에 있는 수천 대의 서버까지. Linux 인프라의 성장을 추적한 방법

IT 인프라가 너무 빠르게 성장하면 조만간 이를 지원할 인적 자원을 선형적으로 늘리거나 자동화를 시작하는 선택에 직면하게 될 것입니다. 어느 시점까지 우리는 첫 번째 패러다임에 살았고, 이후 인프라형 코드(Infrastructure-as-Code)를 향한 긴 여정이 시작되었습니다.

물론 NSPK는 스타트업은 아니지만 창립 첫해에는 그러한 분위기가 회사를 지배했고 매우 흥미로운 해였습니다. 내 이름은 코르냐코프 드미트리, 저는 10년 넘게 고가용성 요구 사항을 갖춘 Linux 인프라를 지원해 왔습니다. 그는 2016년 XNUMX월 NSPK 팀에 합류했고, 안타깝게도 회사의 시작을 보지 못했지만 큰 변화의 단계에 이르렀습니다.

일반적으로 우리 팀은 회사에 2개의 제품을 공급한다고 말할 수 있습니다. 첫 번째는 인프라입니다. 메일이 작동해야 하고, DNS도 작동해야 하며, 도메인 컨트롤러를 통해 충돌이 발생하지 않아야 하는 서버에 들어갈 수 있어야 합니다. 회사의 IT 환경은 엄청납니다! 이는 비즈니스 및 미션 크리티컬 시스템이며 일부 가용성 요구 사항은 99,999입니다. 두 번째 제품은 물리적 및 가상 서버 자체입니다. 기존 제품은 모니터링해야 하고, 새로운 제품은 여러 부서의 고객에게 정기적으로 전달되어야 합니다. 이 기사에서는 서버 수명 주기를 담당하는 인프라를 어떻게 개발했는지에 초점을 맞추고 싶습니다.

여행의 시작

여정 초기에 우리의 기술 스택은 다음과 같았습니다.
OS 센트OS 7
FreeIPA 도메인 컨트롤러
자동화 - Ansible(+Tower), Cobbler

이 모든 것은 여러 데이터 센터에 분산된 3개의 도메인에 위치했습니다. 한 데이터 센터에는 사무실 시스템과 테스트 사이트가 있고 나머지에는 PROD가 있습니다.

한 지점에서 서버를 생성하는 방법은 다음과 같습니다.

VM 템플릿에서 CentOS는 최소이고 필요한 최소값은 올바른 /etc/resolv.conf와 같으며 나머지는 Ansible을 통해 제공됩니다.

CMDB - 엑셀.

서버가 물리적인 경우 가상 머신을 복사하는 대신 Cobbler를 사용하여 OS를 설치했습니다. 대상 서버의 MAC 주소가 Cobbler 구성에 추가되고 서버는 DHCP를 통해 IP 주소를 받은 다음 OS가 추가됩니다.

처음에는 Cobbler에서 일종의 구성 관리를 시도하기도 했습니다. 그러나 시간이 지나면서 이는 다른 데이터 센터와 VM 준비를 위한 Ansible 코드 모두에 대한 구성 이식성에 문제를 일으키기 시작했습니다.

그 당시 우리 중 많은 사람들은 Ansible을 Bash의 편리한 확장으로 인식했으며 Shell과 sed를 사용한 설계를 간과하지 않았습니다. 전반적으로 Bashsible. 이는 궁극적으로 어떤 이유로 플레이북이 서버에서 작동하지 않는 경우 서버를 삭제하고 플레이북을 수정한 후 다시 실행하는 것이 더 쉽다는 사실로 이어졌습니다. 본질적으로 스크립트 버전 관리나 구성 이식성이 없었습니다.

예를 들어, 모든 서버의 일부 구성을 변경하고 싶었습니다.

1. 논리 세그먼트/데이터 센터의 기존 서버 구성을 변경합니다. 때로는 하루 만에 적용되지 않는 경우도 있습니다. 접근성 요구 사항과 대수의 법칙으로 인해 모든 변경 사항을 한 번에 적용할 수는 없습니다. 그리고 일부 변경 사항은 잠재적으로 파괴적이며 서비스에서 OS 자체에 이르기까지 무언가를 다시 시작해야 합니다.
2. Ansible에서 수정
3. Cobbler에서 해결해 드립니다.
4. 각 논리적 세그먼트/데이터 센터에 대해 N번 반복합니다.

모든 변화가 원활하게 진행되기 위해서는 많은 요소들을 고려해야 했고, 변화는 끊임없이 발생했습니다.

• Ansible 코드, 구성 파일 리팩토링
• 내부 모범 사례 변경
• 사건/사고 분석 결과에 따른 변경
• 내부 및 외부 모두에서 보안 표준을 변경합니다. 예를 들어 PCI DSS는 매년 새로운 요구 사항으로 업데이트됩니다.

인프라 성장과 여정의 시작

서버/논리 도메인/데이터 센터의 수가 증가했고 그에 따라 구성 오류도 늘어났습니다. 어느 시점에서 우리는 구성 관리를 개발해야 하는 세 가지 방향에 이르렀습니다.

1. 오토메이션. 반복적인 작업에서는 인적 오류를 최대한 방지해야 합니다.
2. 반복성. 예측이 가능하면 인프라를 관리하는 것이 훨씬 쉽습니다. 준비를 위한 서버 및 도구 구성은 모든 곳에서 동일해야 합니다. 이는 제품 팀에게도 중요합니다. 테스트 후에 애플리케이션은 테스트 환경과 유사하게 구성된 프로덕션 환경에서 끝나도록 보장되어야 합니다.
3. 구성 관리 변경의 단순성과 투명성.

몇 가지 도구를 추가해야 합니다.

우리는 특히 내장된 CI/CD 모듈을 위해 GitLab CE를 코드 저장소로 선택했습니다.

비밀 금고 - Hashicorp Vault, incl. 훌륭한 API를 위해.

구성 및 Ansible 역할 테스트 – Molecule+Testinfra. ansible mitogen에 연결하면 테스트가 훨씬 빠르게 진행됩니다. 동시에 우리는 자동 배포를 위한 자체 CMDB와 오케스트레이터를 작성하기 시작했습니다(Cobbler 위 그림 참조). 그러나 이것은 완전히 다른 이야기이며, 내 동료이자 이러한 시스템의 주요 개발자가 앞으로 말할 것입니다.

우리의 선택:

분자 + 테스트인프라
앤서블 + 타워 + AWX
World of Servers + DITNET (자체 개발)
구두 수선공
Gitlab + GitLab 러너
하시코프 금고

그건 그렇고, Ansible 역할에 대해. 처음에는 하나만 있었지만 여러 번의 리팩토링을 거쳐 17개가 되었습니다. 모놀리스를 멱등성 역할로 분리한 다음 별도로 시작할 수 있고 추가로 태그를 추가할 수 있는 것이 좋습니다. 우리는 네트워크, 로깅, 패키지, 하드웨어, 분자 등 기능별로 역할을 나누었습니다. 일반적으로 우리는 아래 전략을 따랐습니다. 나는 이것이 유일한 진실이라고 주장하지는 않지만 그것은 우리에게 효과가 있었습니다.

• "골든 이미지"에서 서버를 복사하는 것은 사악합니다!가장 큰 단점은 현재 이미지가 어떤 상태인지 정확히 알 수 없으며 모든 변경 사항이 모든 가상화 팜의 모든 이미지에 적용된다는 점입니다.
• 기본 구성 파일을 최소한으로 사용하고 기본 시스템 파일을 담당하는 다른 부서와 동의합니다.예 :
  1. /etc/sysctl.conf를 비워두고 설정은 /etc/sysctl.d/에만 있어야 합니다. 한 파일의 기본값은 다른 파일의 애플리케이션에 대한 사용자 정의입니다.
  2. 대체 파일을 사용하여 시스템 단위를 편집하십시오.
• 모든 구성을 템플릿화하고 완전히 포함합니다. 가능하면 플레이북에 sed나 그 유사 항목이 없습니다.
• 구성 관리 시스템 코드 리팩터링:
  1. 작업을 논리적 엔터티로 나누고 모놀리스를 역할로 다시 작성합니다.
  2. 린터를 사용하세요! Ansible-lint, yaml-lint 등
  3. 접근 방식을 바꿔보세요! 배시할 수 없습니다. 시스템의 상태를 기술하는 것이 필요하다
• 모든 Ansible 역할에 대해 분자 단위로 테스트를 작성하고 하루에 한 번 보고서를 생성해야 합니다.
• 우리의 경우 테스트(100개 이상)를 준비한 후 약 70000개의 오류가 발견되었습니다. 그것을 고치는 데 몇 달이 걸렸습니다.

우리의 구현

따라서 Ansible 역할이 준비되고 템플릿화되었으며 Linter에 의해 확인되었습니다. 심지어 gits도 어디에서나 자랍니다. 그러나 다양한 부문에 대한 안정적인 코드 전달 문제는 아직 해결되지 않았습니다. 우리는 스크립트와 동기화하기로 결정했습니다. 다음과 같습니다.

변경 사항이 적용되면 CI가 시작되고, 테스트 서버가 생성되고, 역할이 롤아웃되고, 분자에 의해 테스트됩니다. 모든 것이 정상이면 코드는 prod 분기로 이동합니다. 그러나 우리는 기계의 기존 서버에 새로운 코드를 적용하지 않습니다. 이는 우리 시스템의 고가용성을 위해 필요한 일종의 스토퍼입니다. 인프라가 거대해지면 대수의 법칙이 적용됩니다. 변경이 무해하다고 확신하더라도 심각한 결과를 초래할 수 있습니다.

서버 생성을 위한 다양한 옵션도 있습니다. 결국 우리는 사용자 정의 Python 스크립트를 선택했습니다. CI ansible의 경우:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

이것이 우리가 온 것이며 시스템은 계속해서 살아 있고 발전하고 있습니다.

• 서버 설정을 위한 17개의 Ansible 역할. 각 역할은 별도의 논리적 작업(로깅, 감사, 사용자 권한 부여, 모니터링 등)을 해결하도록 설계되었습니다.
• 역할 테스트. 분자 + 테스트인프라.
• 자체 개발: CMDB + Orchestrator.
• 서버 생성 시간은 최대 30분이며 자동화되어 있으며 작업 대기열과 실질적으로 독립적입니다.
• 플레이북, 리포지토리, 가상화 요소 등 모든 세그먼트의 인프라 상태/이름이 동일합니다.
• 표준과의 불일치에 대한 보고서 생성을 통해 서버 상태를 매일 확인합니다.

제 이야기가 여행을 시작하는 분들에게 도움이 되기를 바랍니다. 어떤 자동화 스택을 사용하시나요?

출처 : habr.com