코드 및 TDD로서의 인프라

코드로서의 인프라는 빌드를 자동화하는 도구를 사용하도록합니다. 큰. ansible , chef , puppet , salt stack 등과 같은 도구를 사용하면 인프라의 모양을 작성하는 동시에 차이점을 해결할 수 있습니다.

솔트 스택에서 이러한 비트를 상태 라고 합니다 . 상태가 현실과 일치하지 않으면 도구가이를 해결합니다. 즉, 우리는 인프라에 대한 테스트를 작성하고 있으며 테스트에 실패하면 도구가 자체적으로 수정합니다. 적어도 그것이 아이디어입니다.

XP는 우리에게 TDD를 사용하도록 지시하고 그것이 인프라에 적용 가능한지에 대한 질문입니까? 툴링은 그것이 제안합니다.

매우 유용 할 수있는 몇 가지 유형의 테스트를 상상할 수 있습니다.

배포 된 서비스와 함께 제공되는 연기 테스트를 작성하여 배포 된 서비스가 예상대로 작동하고 실행되도록합니다. 이것은 방금 배포 한 것이 작동하는지 확인하기위한 API 호출 또는 systemctl 검사입니다. ansible과 같은 도구에는 서비스가 실행되고 있는지 확인하는 상태가 있으므로이 기능 중 많은 부분을 동일한 상태로 처리 할 수 ​​있습니다.

Docker 또는 다른 임시 가상화 엔진에 대해 개별 역할을 수행 할 수있는 프로젝트 Molecule 이 있습니다 (상태를 호출 할 수 있음). 이로 인해 역할이 분리되고 작업하면서 플레이 북과 분리하여 역할을 실행할 수 있습니다. 테스트는 대부분 역할이 작동해야하는 변수를 조롱 할 수있게합니다. 다른 예제는 ansible 엔진의 중복처럼 보입니다 (파일이 사용자에게 속한다고 가정하십시오 ...).

ThoughtWorks 기술 레이더는 현재 inspec , serverspec 또는 goss 와 같은 도구 를 사용하여 서버가 사양을 충족하는지 확인합니다. 그러나 우리는 사양을 작성하고 있습니까?

우리가 인프라를 상태 / 역할로 설명한다면 인프라 스트럭처의 추가 테스트에 요점이 있습니까? 한 팀이 사양을 제공하고 다른 팀이 다음과 같은 대규모 조직에서 이것이 더 필요하다고 생각할 수도 있습니다. 동일한 질문에 대한 역할 / 상태가있을 수있는 경우 왜 시험을 작성해야하는지 확인하기 위해 고심하고 있습니다.

간단히 말해, 인프라에 대한 두 가지 범주의 테스트가 있습니다. 1) 응용 프로그램을 실행하는 데 필요한 모든 것이 있는지, 2) 불필요한 항목이 없는지 확인하십시오.

무엇보다도 실제 소프트웨어의 테스트 스위트를 인프라에 대한 일종의 "메타 테스트"로 취급 할 수 있습니다. 테스트 실행마다 인프라를 처음부터 새로 작성하고 테스트 스위트가 해당 인프라에서 완전히 실행되는 경우 (즉, 외부 서비스를 사용하지 않음) 전체 스위트가 녹색이라는 사실은 체계화 된 인프라도 충분하다는 의미입니다. .

둘째, 특히 보안 측면에서 인프라에 대한 테스트를 작성할 수 있습니다. 즉, 인프라의 일부가 Linux를 실행하는 VM 인 경우 의도하지 않은 apt-get install부작용 으로 설치되었을 수있는 의도하지 않은 포트가 열려 있지 않은지 확인하기 위해 해당 VM에 대해 포트 스캔을 수행하는 테스트를 작성할 수 있습니다. . 또는 적절한 테스트 스위트가 완료된 후 예기치 않은 파일이 변경되었는지 확인하는 테스트를 작성할 수 있습니다. 또는 psVM 또는 Docker 컨테이너 의 출력에서 예기치 않은 프로세스 등 이 있는지 확인하고 화이트리스트 등을 작성하여 일부 타사 패키지가 일부 업그레이드에서 문서화되지 않은 (또는 눈에 띄지 않는 방식으로) 변경된 경우 자동 알림을받을 수 있습니다.

이러한 두 번째 유형의 테스트는 어떤 식 으로든 기존 운영 환경에서 수행하는 것과 유사합니다. 즉, 서버를 강화하고 침입을 확인하고 전체 리소스를 피하는 등의 작업을 수행합니다.

IMHO IaaC 상태 사양에서 완전히 다루는 항목에 대해 TDD 테스트를 작성하는 것은 다소 중복됩니다. 그렇게하면 IaaC의 효과에 의문의 여지가 있습니다. 왜 그렇게 하시겠습니까?

다른 예상 IaaC 자체에서 살펴보면 (적절하게 수행 된 경우) 이미 테스트되고 신뢰할 수있는 기능으로 간주됩니다. 이것이 매력적이고 TDD 매칭 테스트를 중복 작성하는 것입니다.

예를 들어 SSH가 설치되어있는 시스템을 지정하는 IaaC 구성에는 SSH가 올바르게 설치되었는지 확인하는 기능과 설치되지 않은 경우 올바르게 설치하는 메커니즘이 이미 통합되어 있습니다. SSH가 중복 설치되어 있는지 확인하기 위해 TDD 테스트를 수행합니다. IaaC 구성에서 sshd가 시작되고 특정 포트에서 수신 대기하도록 지정하면 해당 포트에서 실행되고 수신되는 sshd에 대한 TDD 테스트도 중복됩니다.

제 답변은 TDD 또는 IaaC 구성 전체가 특정 목적에 맞는지 확인하는 다른 유형의 테스트를 대상으로하지 않습니다. 이는 유효하며 IaaC 사양을 개발하는 동안 TDD, CI 또는 유사한 검사에 사용할 수 있습니다. 그러한 경우 @AnoE의 답변이 적용 ​​가능하다고 생각합니다.

여기의 모든 사람들이 IAC 도구가 항상 예상대로 실행되는 것으로 가정하지만, 내 경험으로는 항상 그런 것은 아니라고 말할 수 있습니다. 그렇지 않으면 단위 테스트가 실제로 쓸모가 없습니다.

배경이 불타고있는 건물과 함께 "모두 플레이 북이 실행되었습니다. 모든 것이 정상입니다"라는 그림이 기억납니다.

선언적 상태를 실행하고 서버를이 실제 선언 된 상태로 유지하는 것은 적어도 내 관점과 경험과는 다른 두 가지입니다.

여러 DC에 퍼져 있고 공용 네트워크 등을 통해 도달 할 수있는 광범위하고 이기종 환경 ... 상태를 완전히 또는 부분적으로 적용 할 수없는 여러 가지 이유가 있습니다.

이러한 모든 이유로 인해 실제 서버 상태의 스냅 샷을 얻을 수있는 단위 테스트를위한 공간이 있으며, 이는 다시 목표 상태와 다를 수 있습니다.

예, 단위 테스트는 IAC 관리 환경에서도 유용합니다.

편집하다

IaC 코드베이스의 dev 브랜치의 비 회귀 측은 어떻습니까? 그래서 당신은 dev 브랜치에서 코드를 변경하고 모든 것을 깨지 않기를 바라면서 prod 브랜치에 코드를 병합 할 것입니까? 단위 테스트는 매우 가치가 있으며 일반적으로 구현하기가 쉽습니다.이 기능이 없으면 코드를 작성하는 이유를 알 수 없습니다.

참조 (프랑스어로 죄송합니다) : https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

내 경험상 Dev와 Ops의 주요 차이점 중 하나는 "무거운 런타임 종속성"입니다. 패키지 설치는 리포지토리, 네트워크 또는 유효한 키에 크게 의존하거나 새 클라우드 서버를 인스턴스화한다고 말하면 공급자 리소스에 따라 다릅니다.

프로비저닝 코드를 변경하지 않은 경우에도 서버 프로비저닝 측면에서 이미지는 대부분 유효하지만 때로는 그렇지 않습니다. 따라서 실제 이미지를 제공하려면 테스트가 필수적이라고 생각합니다.

단일 서버를 넘어 서면 상황이 더욱 악화됩니다 ... 전체 네트워크 설정에서 도달 가능성을 어떻게 테스트합니까? DNS 확인, 라우팅 및 방화벽을 포함합니까? IaaC 제공자 API가 예상대로 작동하더라도 (이 영역에서 유선 문제를 보았습니다)이 경우에는 TDD가 정말 좋습니다.

이 영역에서 테스트 도구를 찾지 못 했으므로 여가 시간에 다음과 같은 도구를 작성했습니다. https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

TDD가 DevOps 세계에서 정말 중요하다고 생각합니다!