Ansible 설정에서 프로비저닝 및 구성을 테스트하는 방법은 무엇입니까?

프로비저닝 및 구성을 처리하는 Ansible 설정에 복원성을 구축하려고합니다.

구성 측면에서 테스트하는 몇 가지 방법을 이해하지만 프로비저닝 측면에서 테스트를 구현하는 가장 좋은 방법과 이러한 유형의 구현에 도움이되는 도구가 있는지 궁금합니다.

현재 우리의 많은 테스트는 플레이 북에서 연속적으로 수행되는데, "서비스가 제공되고 VIP가 가능합니까? 애플리케이션 및 프로비저닝 계층 모두에서 구성 (예 : VM 구성) Ansible이 구성 드리프트 작업에 가장 적합한 도구는 아니지만 자신의 의견이 궁금합니다.

프로세스를 완전히 자동화 할 무언가가 있다면 더욱 좋습니다. (매우 느슨하게 다시보고하는 몇 가지 추악한 스크립트가 있습니다).

참고 : 현재 재 프로비저닝이 발생할 수있는 몇 가지 조건 (예 : 백업에서 재 구축, 중요한 시스템 문제)이 있지만 일반적으로 일부 구성 가능한 작업을 반복하고 더 이상 생각하지 않습니다.

몇 가지 옵션이 있습니다.

테스트 도구 : github stars로 정렬

• Serverspec- 루비의 rspec을 기반으로하는 가장 인기있는 도구 인 Ruby
• Goss -YAML, 단순, <10MB의 자체 포함 바이너리, 매우 빠름, 시스템 상태에서 테스트 생성 가능
• Inspec -Ruby, 이것은 요리사가 만든 거의 동일한 구문 인 개선 된 serverspec으로 생각하십시오. serverspec보다 쉽게 ​​확장 할 수 있도록 구축
• Testinfra -Python, Ansible의 인벤토리 / 바를 사용할 수있는 멋진 기능이 있습니다

그들 사이의 주요 차이점 :

궁극적으로, 나는 그들 스스로를 결정하기 전에 그들에 대한 느낌을 얻기 위해 그들 모두와 실험을하는 것이 좋습니다.

• Goss를 제외하고 모든 프레임 워크는 원격 시스템 (예 : ssh 이상)에 대해 실행될 수 있습니다. Goss는 로컬 또는 dgoss가있는 docker에서만 실행됩니다.
• 모든 프레임 워크는 서버에서 로컬로 실행할 수 있지만 Python 또는 Ruby를 설치하거나 내장해야합니다. Inspec은 내장 버전의 루비가 포함 된 독립형 <150MB 번들을 제공합니다. Goss는 외부 의존성이없는 단일 <10MB 바이너리입니다.
• Goss는 nagios / sensu 출력을 기본적으로 지원하므로 모니터링 도구와 쉽게 통합 할 수 있습니다.
• Goss 테스트는 YAML을 기반으로하기 때문에 더 단순하지만 유연성이 떨어집니다. 다른 프레임 워크를 사용하면 기본 언어 인 Python / Ruby의 모든 기능을 활용하여 테스트를 작성하거나 도구 기능을 확장 할 수 있습니다. (단순성과 유연성)
• Goss를 사용하면 현재 시스템 상태에서 테스트를 생성 할 수 있습니다
• 내 지식에 대한 Testinfra는 유일한 재고 및 변수를 기본적으로 지원합니다.
• Inspec은 Chef의 지원을받습니다.

연속 / 분산 테스트 :

• Chef Compliance -inspec과 협력하여 서버, 유료 제품을 지속적으로 테스트
• Goss -Nagios 또는 Sensu에 쉽게 연결할 수 있습니다. 또한 서버 테스트를 http 엔드 포인트로 노출하는 것을 지원합니다.

개발을위한 테스트 장치 :

• kitchen- 테스트 도구 도구, 인스턴스 시작, 구성 관리 코드 실행, 테스트 스위트 실행 요리사들에 의해 만들어진
• 분자 -테스트 키친과 유사하지만 특별히 사용하기 위해 작성되었습니다.

전체 공개 : 나는 goss의 저자입니다

업데이트 : InSpec 4.x 이상은 혼합 상용 / 오픈 소스 라이센스를 사용합니다 (주석 참조).

내가 본 두 가지 도구는 InSpec 과 ServerSpec 입니다. Serverspec은 RSpec 기반의 Ruby 기반 도구입니다 . InSpec은 RSpec 및 ServerSpec에서 영감을 얻었습니다.

ServerSpec을 사용했습니다. 시원하지만 100 % 안정적이지는 않습니다. 우분투에서 특정 버전의 소프트웨어를 테스트하는 데 문제가 있습니다.

InSpec 문서를 읽었지만 깊이 파고 들지 않았습니다. 본질적으로 Serverspec과 동일합니다.

Github 커밋으로 판단하면 ServerSpec에 대한 작업이 다소 마무리되었지만 InSpec이 급증하는 것처럼 보입니다.

업데이트 : InSpec 4.x 이상은 혼합 상용 / 오픈 소스 라이센스를 사용합니다 (주석 참조).

Ansible과 같은 구성 관리 도구를 사용하는 경우 도구 자체가 구성 편차를 방지해야합니다. Ansible을 사용하여 특정 구성을 설정 한 후에 Ansible을 반복적으로 실행하면 구성이 정의한대로 구성됩니다. 또한 Ansible 코드를 dem 등원 방식으로 작성해야합니다.

위와 같이 Ansible 플레이 북을 일부 서버에서 루프로 실행하면 테스트 프로비저닝을 수행 할 수 있습니다. 예를 들어 크론 작업 또는 Jenkins는 30 분마다 플레이 북을 실행하고 실패에 대해 다시보고 할 수 있습니다. 장애가 없다는 것은 구성이 점검 중임을 의미하며 장애가 발생하면 서버를 원하는 상태 로 만드는 데 문제가 있음을 의미합니다 .

코드가 dem 등원으로 작성되는 것을 신뢰할 수 없으므로 자동 서버의 루프에서 Ansible을 반복적으로 실제로 실행할 수없는 경우 해결 방법이 있습니다. 위와 동일하게 수행 할 수 있지만 (루프에서 Ansible 실행) 드라이 런 모드를 사용 하십시오 . Ansible에서 변경이 필요하다고보고 할 때마다 Jenkins 작업 (또는 cron 작업)은 프로비저닝 된 구성이 변경되었고 서버가 원하는 상태 가 아님을 알릴 수 있습니다 .

Ansible 코드가 실제로 예상대로 작동하는지 확인하기 위해 Dave Swersky가 언급 한 솔루션이 적용됩니다. InSpec 과 Serverspec 은 모두 플레이 북이 실제로 의미하는 바를 다른 방식으로 확인하는 도구입니다 . 테스트 환경 (도커 컨테이너 포함)에서 이러한 종류의 도구를 실행하는 가장 좋은 방법 은 다양한 인프라 단위 테스트 도구와 플레이 북 / 모듈 / 요리 책 실행 사이의 모든 접착제를 처리 하는 kitchen.ci 를 사용 하는 것입니다.

Kitchen.ci는 원래 Chef 요리 책을 테스트하는 데 사용되었지만 Ansible 및 기타 CM 도구에도 플러그인이 있습니다.

Test Kitchen에는 Ansible 코드를 테스트하기 위해 부엌에서 사용할 수있는 프로비저닝 플러그인이 있습니다. Chef 통합만큼 깊지는 않지만 대부분의 경우 작업을 수행합니다. 전용 Ansible 테스트 시스템 인 최신 Molecule 프로젝트도 있습니다.

Outthentic을 사용하여 구성 / 인프라 불일치 / 드리프트를 추적 할 수 있으며 , 원하는 상태를 "고정"하여 원하지 않는 변경 사항을 추적해야 할 때마다 다시 실행하는 테스트 스위트를 쉽게 만들 수 있습니다.