인프라 배포에 꼭두각시를 사용하고 있으며 대부분의 작업은 웹 응용 프로그램의 테스트 중심 개발에 많은 웹 2.0 회사와 함께합니다. 여기서 누구나 서버 구성을 개발하기 위해 테스트 중심 접근 방식을 사용합니까? 이를 위해 어떤 도구를 사용합니까? 시험은 얼마나 깊습니까?
답변
테스트 중심 개발을 사용할 수 있다고 생각하지 않습니다 . 그러나 새로운 서버에서 유닛 테스트 를 시도 할 수 있습니다.
기본적으로 서버를 배포하고 테스트 모드에서 서비스를 시작한 다음 서비스에 대해 다른 서버 (또는 일련의 서버)에서 테스트를 실행해야합니다. 그런 다음 마침내 생산에 투입하십시오.
파이썬 스크립트를 사용하여 데이터베이스, 웹 페이지 및 ssh 서비스에 연결할 수 있습니다. 그런 다음 PASS / FAIL을 반환하십시오. 좋은 출발이 될 것입니다.
또는 이것을 Zenoss, Nagios 또는 Munin과 같은 모니터링 솔루션에 롤업 할 수 있습니다. 그런 다음 배포 중에 테스트 할 수 있습니다. 생산 중에 모니터링하십시오.
답변
Joseph Kern이 모니터링 도구를 사용하여 올바른 길을 가고 있다고 생각합니다. 일반적인 TDD주기는 다음과 같습니다. 실패한 새 테스트를 작성한 다음 기존의 모든 테스트를 통과하도록 시스템을 업데이트하십시오. 이는 Nagios에 쉽게 적용 할 수 있습니다. 실패한 검사 추가, 서버 구성, 모든 검사를 다시 실행합니다. 생각 해보니, 가끔 정확히 했어요.
실제로 하드 코어를 사용하려면 서버 구성의 모든 관련 측면을 확인하는 스크립트를 작성해야합니다. Nagios와 같은 모니터링 시스템은 일부와 관련이 없을 수 있지만 (예를 들어, OS 버전을 “모니터링”하지 않을 수도 있음) 적절한 혼합 및 일치가 불가능한 이유는 없습니다.
답변
아직 Puppet 매니페스트를 사용하여 TDD를 수행 할 수 없었지만 테스트없이 변경 사항이 프로덕션에 적용되는 것을 방지 할 수있는 좋은주기가 있습니다. 우리는 두 개의 puppetmaster를 설정했습니다. 하나는 프로덕션 puppetmaster이고 다른 하나는 개발 puppetmaster입니다. Puppet의 “환경”을 사용하여 다음을 설정합니다.
- 개발 환경 (인형 매니페스트 작업을 수행하는 각 사람마다 하나씩)
- 테스트 환경
- 생산 환경
응용 프로그램 개발자는 개발 Puppetmaster의 “테스트”환경에서 Puppet 구성을 가져 오는 가상 컴퓨터에서 작업을 수행합니다. Puppet 매니페스트를 개발할 때는 일반적으로 개발 프로세스 중에 테스트 클라이언트 역할을 할 VM을 설정하고 개인 개발 환경을 가리 킵니다. 매니페스트에 만족하면 애플리케이션 개발자가 VM에서 변경 사항을 얻을 수있는 테스트 환경으로 푸시합니다. 일반적으로 문제가 발생하면 크게 불평합니다.
프로덕션 시스템의 대표적인 하위 집합에는 noop 모드에서 실행되고 테스트 환경을 가리키는 두 번째 인형이 있습니다. 우리는 매니페스트가 생산에 오기 전에 잠재적 인 문제를 포착하기 위해 이것을 사용합니다.
변경 사항이 적용되면 (즉, 응용 프로그램 개발자의 시스템을 중단하지 않고 생산 시스템의 “noop”퍼펫 프로세스 로그에 바람직하지 않은 출력을 생성하지 않으면 새로운 매니페스트를 프로덕션으로 푸시합니다. 롤백 메커니즘이 있으므로 이전 버전으로 되돌릴 수 있습니다.
답변
TDD 운영 모델로 마이그레이션하는 환경에서 일했습니다. 스크립트 모니터링과 같은 경우에는 매우 효과적입니다. 테스트 환경을 설정하고 테스트를 실행하기 위해 빌드 봇을 사용했습니다. 이 경우 “레거시 코드”의 관점에서 TDD에 접근합니다. TDD에서 “레거시 코드”는 테스트가없는 기존 코드입니다. 따라서 첫 번째 테스트는 실패하지 않으며 올바른 (또는 예상 된) 작업을 정의합니다.
많은 구성 작업의 첫 번째 단계는 서비스가 구성을 구문 분석 할 수 있는지 여부를 테스트하는 것입니다. 많은 서비스가이를 위해 몇 가지 기능을 제공합니다. Nagios에는 프리 플라이트 모드가 있고 cfagent에는 동작, 아파치, sudo, 바인드가 없으며 다른 많은 기능이 유사합니다. 이것은 기본적으로 구성에 대한 린트 실행입니다.
예를 들어, 다른 부분에 대해 아파치 및 별도의 구성 파일을 사용하는 경우 다른 httpd.conf 파일을 사용하여 테스트 시스템에서 실행할 수 있도록 해당 부분을 테스트 할 수 있습니다. 그런 다음 테스트 시스템의 웹 서버가 올바른 결과를 제공하는지 테스트 할 수 있습니다.
모든 기본 단계는 동일한 기본 패턴을 따릅니다. 시험을 작성하고 시험을 통과 한 다음 수행 한 작업을 리팩터링하십시오. 위에서 언급했듯이이 경로를 따라갈 때 테스트가 항상 허용 된 TDD 방식으로 실패하지는 않습니다.
릭
답변
다음 링크가 흥미로울 수 있다고 생각합니다
-
cucumber-nagios- Cucumber suite를 Nagios 플러그인으로 바꾸고 SSH, DNS, Ping, AMQP 및 일반적인 “실행 명령”유형의 작업에 대한 단계 정의와 함께 제공 되는 프로젝트
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios -
Puppet / Python 측에 대한 노력도 있습니다
http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php