Ansible: 120개월 만에 CoreOS에서 CentOS로 18개의 VM 구성 마이그레이션

연설문 전문입니다 데브옵스컨퍼런스 2019-10-01 и SPbLUG 2019-09-25.

자체 작성 구성 관리 시스템을 사용한 프로젝트와 Ansible로 전환하는 데 18개월이 걸린 이유에 대한 이야기입니다.

요일 번호 -ХХХ: 시작 전

처음에 인프라는 Hyper-V를 실행하는 여러 개별 호스트로 구성되었습니다. 가상 머신을 생성하려면 디스크를 올바른 위치에 배치하고, DNS를 등록하고, DHCP를 예약하고, VM 구성을 git 저장소에 넣는 등 여러 단계가 필요했습니다. 이 프로세스는 부분적으로 기계화되었지만 예를 들어 VM은 호스트 간에 수동으로 배포되었습니다. 그러나 예를 들어 개발자는 git에서 VM 구성을 수정하고 VM을 재부팅하여 이를 적용할 수 있습니다.

맞춤형 구성 관리 솔루션

원래 아이디어는 재부팅 시 상태를 XNUMX으로 재설정하는 많은 상태 비저장 VM인 IaC로 구상된 것 같습니다. VM 구성 관리란 무엇입니까? 개략적으로 보면 간단해 보입니다.

1. VM에 대해 정적 MAC이 고정되었습니다.
2. CoreOS가 포함된 ISO와 부팅 디스크가 VM에 연결되었습니다.
3. CoreOS는 해당 IP를 기반으로 웹 서버에서 사용자 정의 스크립트를 다운로드하여 실행합니다.
4. 스크립트는 IP 주소를 기반으로 SCP를 통해 VM 구성을 다운로드합니다.
5. systemd 유닛 파일의 footcloth와 bash 스크립트의 footcloth가 실행됩니다.

이 솔루션에는 다음과 같은 명백한 문제가 많이 있었습니다.

1. CoreOS ISO는 더 이상 사용되지 않습니다.
2. VM을 마이그레이션/생성할 때 복잡하고 자동화된 작업과 마법이 많이 있습니다.
3. 업데이트가 어렵고 특정 버전의 소프트웨어가 필요한 경우. 커널 모듈을 사용하면 더욱 재미있습니다.
4. VM은 데이터 없이 획득되지 않았습니다. VM은 추가 사용자 데이터가 탑재된 디스크와 함께 나타났습니다.
5. 누군가 시스템 장치 종속성을 지속적으로 망쳐 놓고 재부팅할 때 CoreOS가 정지되었습니다. CoreOS에서 사용 가능한 도구를 사용하여 이를 포착하는 것은 어려웠습니다.
6. 비밀 관리.
7. CM이 없었습니다. CoreOS에는 bash 및 YML 구성이 있었습니다.

VM 구성을 적용하려면 재부팅해야 하지만 재부팅되지 않을 수 있습니다. 명백한 문제인 것 같지만 영구 디스크가 없습니다. 로그를 저장할 곳이 없습니다. 자, 로그가 전송되도록 커널 로딩 옵션을 추가해 보겠습니다. 하지만 아닙니다. 이 모든 것이 얼마나 복잡합니까?

Day #0: 문제 인식

젠킨스, 테스트 환경, 모니터링, 레지스트리 등 일반적인 개발 인프라였습니다. CoreOS는 k8s 클러스터를 호스팅하도록 설계되었습니다. 문제는 CoreOS를 사용하는 방법이었습니다. 첫 번째 단계는 스택을 선택하는 것이었습니다. 우리는 다음을 결정했습니다.

1. CentOS에 기본 배포판으로 사용되기 때문에 이는 프로덕션 환경에 가장 가까운 배포입니다.
2. 책임감있는 구성 관리를 위해 그것에 대한 광범위한 조사가있었습니다.
3. 젠킨스 기존 프로세스를 자동화하기 위한 프레임워크로서 이미 개발 프로세스에 적극적으로 사용되었습니다.
4. 하이퍼-V 가상화 플랫폼으로. 이야기의 범위를 넘어서는 여러 가지 이유가 있지만 간단히 말해서 클라우드를 사용할 수 없고 자체 하드웨어를 사용해야 합니다.

30일차: 기존 계약 수정 - 코드로서의 계약

스택이 정리되자 이동 준비가 시작되었습니다. 기존 계약을 코드 형식으로 수정(코드로서의 계약!). 이행 손 작업 -> 기계화 -> 오토메이션.

1. VM 구성

Ansible은 이 작업을 훌륭하게 수행합니다. 최소한의 신체 움직임으로 VM 구성을 제어할 수 있습니다.

1. Git 저장소를 만듭니다.
2. VM 목록을 인벤토리에, 구성을 플레이북에, 역할에 넣습니다.
3. 우리는 Ansible을 실행할 수 있는 특별한 젠킨스 슬레이브를 설정하고 있습니다.
4. 작업을 생성하고 Jenkins를 구성합니다.

첫 번째 프로세스가 준비되었습니다. 계약은 확정되었습니다.

2. 새 VM 생성

여기의 모든 것이 그다지 편리하지 않았습니다. Linux에서 Hyper-V에 VM을 생성하는 것은 그리 편리하지 않습니다. 이 프로세스를 기계화하려는 시도 중 하나는 다음과 같습니다.

1. Ansbile은 WinRM을 통해 Windows 호스트에 연결합니다.
2. Ansible은 powershell 스크립트를 실행합니다.
3. Powershell 스크립트는 새 VM을 만듭니다.
4. Hyper-V/ScVMM을 사용하여 게스트 OS에서 VM을 생성할 때 호스트 이름이 구성됩니다.
5. DHCP 임대를 업데이트할 때 VM은 해당 호스트 이름을 보냅니다.
6. 도메인 컨트롤러 측의 표준 ddns 및 dhcp 통합은 DNS 레코드를 구성합니다.
7. 인벤토리에 VM을 추가하고 Ansible을 사용하여 구성할 수 있습니다.

3.VM 템플릿 생성

그들은 여기서 아무것도 발명하지 않았습니다. 그들은 포장업자를 데려갔습니다.

1. git 저장소에 packer, kickstart 구성을 추가합니다.
2. Hyper-V 및 Packer를 사용하여 특수 젠킨스 슬레이브를 설정합니다.
3. 작업을 생성하고 Jenkins를 구성합니다.

이 링크의 작동 방식:

1. Packer는 빈 VM을 만들고 ISO를 선택합니다.
2. VM이 부팅되고 Packer는 플로피 디스크 또는 http에서 킥스타트 파일을 사용하기 위해 부트로더에 명령을 입력합니다.
3. Anaconda가 구성으로 시작되고 초기 OS 구성이 완료됩니다.
4. Packer는 VM을 사용할 수 있을 때까지 기다립니다.
5. VM 내부의 Packer는 로컬 모드에서 ansible을 실행합니다.
6. Ansible은 1단계에서 작동하는 것과 정확히 동일한 역할을 사용합니다.
7. Packer는 VM 템플릿을 내보냅니다.

75일차: 계약을 위반하지 않고 리팩토링 = 테스트 앤서블 + 테스트키친

코드의 규칙을 캡처하는 것만으로는 충분하지 않을 수 있습니다. 결국 프로세스의 모든 면에서 무언가를 변경하고 싶다면 무언가를 깨뜨릴 수 있습니다. 따라서 인프라의 경우 바로 이 인프라에 대한 테스트가 나타납니다. 팀 내에서 지식을 동기화하기 위해 Ansible 역할을 테스트하기 시작했습니다. 깊게 들어가진 않을 거니까... 그 당시 사건을 설명하는 기사가 있습니다. 가능하다면 저를 테스트해 보세요. 아니면 YML 프로그래머가 Ansible 테스트를 꿈꾸나요?(스포일러 이것은 최종 버전이 아니었고 나중에 모든 것이 더 복잡해졌습니다. Ansible 테스트를 시작하고 XNUMX년 안에 프로젝트를 리팩토링하며 당황하지 않는 방법).

Day #130: CentOS+ansible이 필요하지 않을 수도 있나요? 아마 오픈시프트?

인프라를 도입하는 과정이 유일한 것이 아니고 부수적인 하위 프로젝트도 있었다는 점을 이해해야 합니다. 예를 들어, 우리 애플리케이션을 오픈시프트로 실행해 달라는 요청이 들어왔고 이로 인해 일주일 이상 연구가 진행되었습니다. Openshift에서 애플리케이션을 시작하고 기존 도구를 비교합니다. 이동 과정이 느려졌습니다. 결과적으로 openshift가 모든 요구 사항을 충족할 수는 없으며 실제 하드웨어가 필요하거나 최소한 커널을 사용할 수 있는 기능이 필요하다는 것이 밝혀졌습니다.

Day #170: Openshift는 적합하지 않습니다. Windows Azure 팩을 사용해 볼까요?

Hyper-V는 그다지 친숙하지 않으며 SCVMM은 그다지 나아지지 않습니다. 그러나 SCVMM의 추가 기능이며 Azure를 모방하는 Windows Azure 팩과 같은 것이 있습니다. 그러나 실제로는 제품이 버려진 것처럼 보입니다. 문서의 링크가 끊어지고 매우 드물기 때문입니다. 그러나 클라우드 수명을 단순화하기 위한 옵션에 대한 연구의 일환으로 클라우드도 고려했습니다.

250일차: Windows Azure 팩이 별로 좋지 않습니다. 우리는 SCVMM에 남아 있습니다

Windows Azure 팩은 유망해 보였지만 불필요한 기능을 위해 복잡한 WAP를 시스템에 도입하지 않기로 결정하고 SCVMM을 유지했습니다.

Day #360: 코끼리를 한 조각씩 먹어치운다

불과 XNUMX년 만에 이전을 위한 플랫폼이 준비되었고 이전 과정이 시작되었습니다. 이를 위해 SMART 작업이 설정되었습니다. 우리는 모든 VM을 확인하고 구성을 하나씩 파악하고 이를 Ansible에서 설명하고 테스트로 다루기 시작했습니다.

Day #450: 어떤 종류의 시스템을 얻었나요?

과정 자체는 흥미롭지 않습니다. 이는 일상적인 일이며 대부분의 구성은 상대적으로 단순하거나 동형이었으며 파레토 원칙에 따르면 VM 구성의 80%에는 20%의 시간이 필요했습니다. 동일한 원칙에 따라 이동 준비에 80%의 시간이 소요되고 이동 자체에 소요되는 시간은 20%에 불과합니다.

540일차: 최종

18개월 동안 무슨 일이 있었던 걸까요?

1. 계약은 코드가 되었습니다.
2. 손 작업 -> 기계화 -> 오토메이션.

링크

• 영문판
• 개인 블로그의 교차 게시물
• 슬라이드
• Ansible 테스트를 시작하고 XNUMX년 안에 프로젝트를 리팩토링하며 당황하지 않는 방법
• 200줄이 넘는 인프라 코드 테스트를 통해 얻은 교훈
• 오픈시프트에 배포하자
• 자체 OS 배포판을 테스트하는 방법
• 가능하다면 나를 시험해 보세요. YML 개발자는 Ansible 테스트를 꿈꾸나요?

출처 : habr.com