접근 IAC (코드로서의 인프라)는 저장소에 저장된 코드뿐만 아니라 이 코드를 둘러싼 사람과 프로세스로 구성됩니다. 소프트웨어 개발부터 인프라 관리 및 설명까지 접근 방식을 재사용할 수 있습니까? 글을 읽으실 때 이 점을 염두에 두시면 좋을 것 같습니다.

Angielski 버전

이건 내 녹취록이야 공연 에 데브옵스컨퍼런스 2019-05-28.

슬라이드 및 비디오

• Angielski 버전
• 러시아어 버전
• 테스트 실행 2019-04-24 SpbLUG
• DevopsConf의 비디오(RU) 2019-05-28
• DINS DevOps EVENING의 비디오(RU) 2019-06-20
• 슬라이드

Bash 기록으로서의 인프라

당신이 새로운 프로젝트에 참여했는데 그들이 당신에게 이렇게 말했다고 가정해 보세요. 코드로서의 인프라". 실제로는 밝혀졌습니다 Bash 기록으로서의 인프라 또는 예를 들어 Bash 기록으로 문서화. 이것은 매우 실제적인 상황입니다. 예를 들어 Denis Lysenko가 연설에서 유사한 사례를 설명했습니다. 전체 인프라를 교체하고 평화롭게 잠을 시작하는 방법, 그는 bash 역사에서 프로젝트를 위한 일관된 인프라를 어떻게 얻었는지 설명했습니다.

약간의 욕망으로 우리는 다음과 같이 말할 수 있습니다. Bash 기록으로서의 인프라 이것은 코드와 같습니다:

1. 재현성: bash 기록을 가져와 거기에서 명령을 실행하면 작업 구성을 출력으로 얻을 수 있습니다.
2. 버전 관리: 누가 들어왔고 무엇을 했는지 알 수 있습니다. 이것이 출구에서 작업 구성으로 연결된다는 것은 사실이 아닙니다.
3. 역사: 누가 무엇을 했는지에 대한 이야기. 서버를 잃으면 사용할 수 없습니다.

무엇을해야 하는가?

코드로서의 인프라

이런 이상한 경우에도 Bash 기록으로서의 인프라 귀로 잡아당길 수 있어요 코드로서의 인프라, 그러나 오래된 LAMP 서버보다 더 복잡한 작업을 수행하려면 이 코드를 어떻게든 수정, 변경, 개선해야 한다는 결론에 도달하게 됩니다. 다음으로 우리는 사이의 유사점을 고려하고 싶습니다. 코드로서의 인프라 소프트웨어 개발.

마른

스토리지 시스템 개발 프로젝트에 하위 작업이 있었습니다. 주기적으로 SDS 구성: 새 릴리스를 출시하고 있습니다. 추가 테스트를 위해 출시해야 합니다. 작업은 매우 간단합니다.

• SSH를 통해 여기에 로그인하고 명령을 실행하십시오.
• 거기에 파일을 복사하세요.
• 여기에서 구성을 수정하세요.
• 거기서 서비스 시작해
• ...
• 이익!

설명된 논리의 경우, 특히 프로젝트가 막 시작되는 초기 단계에서는 bash만으로도 충분합니다. 이것 bash를 사용하는 것도 나쁘지 않아요, 그러나 시간이 지남에 따라 유사하지만 약간 다른 것을 배포하라는 요청이 있습니다. 가장 먼저 떠오르는 것은 복사-붙여넣기입니다. 이제 거의 동일한 작업을 수행하는 매우 유사한 두 개의 스크립트가 이미 있습니다. 시간이 지남에 따라 스크립트 수가 늘어났고 설치 배포를 위해 서로 다른 스크립트 간에 동기화해야 하는 특정 비즈니스 로직이 있다는 사실에 직면했습니다. 이는 매우 복잡합니다.

DRY(Do not Repeat Yourself)와 같은 관행이 있다는 것이 밝혀졌습니다. 아이디어는 기존 코드를 재사용하는 것입니다. 간단해 보이지만 우리는 이 문제를 바로 해결하지는 않았습니다. 우리의 경우 구성을 스크립트에서 분리하는 것은 진부한 아이디어였습니다. 저것들. 설치가 별도로 배포되는 방법에 대한 비즈니스 논리, 별도로 구성됩니다.

CFM용 솔리드

시간이 지남에 따라 프로젝트가 성장했고 자연스러운 지속 Ansible의 등장이었습니다. 등장한 주된 이유는 팀에 전문성이 있고 bash가 복잡한 논리를 위해 설계되지 않았기 때문입니다. Ansible에는 복잡한 논리도 포함되기 시작했습니다. 복잡한 논리가 혼란으로 변하는 것을 방지하기 위해 소프트웨어 개발에는 코드 구성 원칙이 있습니다. 단단한 또한 예를 들어, "IT 전문가에게 개인 브랜드가 필요한 이유"라는 보고서에서 Grigory Petrov는 사람이 소프트웨어 개발에서 일부 사회적 주체와 더 쉽게 작업할 수 있도록 설계되었다는 질문을 제기했습니다. 객체입니다. 이 두 가지 아이디어를 결합하고 계속해서 발전시키면 다음과 같은 방법도 사용할 수 있다는 것을 알게 될 것입니다. 단단한 나중에 이 논리를 더 쉽게 유지하고 수정할 수 있도록 합니다.

단일 책임 원칙

각 클래스는 하나의 작업만 수행합니다.

코드를 섞어서 하나의 신성한 스파게티 괴물을 만들 필요가 없습니다. 인프라는 단순한 벽돌로 구성되어야 합니다. Ansible 플레이북을 작은 조각으로 나누고 Ansible 역할을 읽으면 유지 관리가 더 쉬워집니다.

개방형 폐쇄 원칙

개방/폐쇄 원칙.

• 확장 가능: 새로운 엔터티 유형을 생성하여 엔터티의 동작을 확장할 수 있음을 의미합니다.
• 변경 폐쇄: 엔터티의 동작을 확장한 결과 해당 엔터티를 사용하는 코드를 변경해서는 안 됩니다.

처음에는 테스트 인프라를 가상 머신에 배포했지만 배포의 비즈니스 로직이 구현과 분리되어 있었기 때문에 문제 없이 베어메탈로 롤아웃을 추가했습니다.

리스코프 대체 원칙

바바라 리스코프의 대체 원리. 프로그램의 객체는 프로그램의 올바른 실행을 변경하지 않고도 해당 하위 유형의 인스턴스로 대체 가능해야 합니다.

좀 더 넓게 보면 거기에 적용할 수 있는 특정 프로젝트의 특징은 아니다. 단단한, 이는 일반적으로 CFM에 관한 것입니다. 예를 들어 다른 프로젝트에서는 다양한 Java, 애플리케이션 서버, 데이터베이스, OS 등 위에 박스형 Java 애플리케이션을 배포해야 합니다. 이 예를 사용하여 추가 원칙을 고려하겠습니다. 단단한

우리의 경우 인프라 팀 내에서는 imbjava 또는 oraclejava 역할을 설치한 경우 Java 바이너리 실행 파일을 갖게 된다는 합의가 있습니다. 이것이 필요한 이유는 업스트림 역할은 이 동작에 따라 달라지며 java를 기대합니다. 동시에 이를 통해 애플리케이션 배포 로직을 변경하지 않고도 하나의 Java 구현/버전을 다른 Java 구현/버전으로 교체할 수 있습니다.

여기서 문제는 이를 Ansible에서 구현하는 것이 불가능하며 그 결과 팀 내에 일부 합의가 나타난다는 사실에 있습니다.

인터페이스 분리 원칙

인터페이스 분리 원칙: “여러 개의 클라이언트별 인터페이스가 하나의 범용 인터페이스보다 낫습니다.

처음에는 애플리케이션 배포의 모든 가변성을 하나의 Ansible 플레이북에 넣으려고 했지만 지원하기가 어려웠고 외부 인터페이스가 지정된 경우(클라이언트가 포트 443을 기대함) 접근 방식을 사용하면 개별적으로 인프라를 조립할 수 있습니다. 특정 구현을 위한 브릭입니다.

종속성 반전 원칙

의존성 역전의 원리. 높은 수준의 모듈은 낮은 수준의 모듈에 의존해서는 안 됩니다. 두 가지 유형의 모듈 모두 추상화에 의존해야 합니다. 추상화는 세부사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 따라 달라져야 합니다.

여기서 예제는 안티패턴을 기반으로 합니다.

1. 고객 중 한 명은 프라이빗 클라우드를 보유하고 있었습니다.
2. 우리는 클라우드 내부에 가상 머신을 주문했습니다.
3. 그러나 클라우드의 특성으로 인해 애플리케이션 배포는 VM이 ​​어느 하이퍼바이저에 있는지에 따라 결정되었습니다.

저것들. 높은 수준의 애플리케이션 배포 논리는 하위 수준의 하이퍼바이저에 대한 종속성과 함께 흐르므로 이 논리를 재사용할 때 문제가 발생합니다. 그러지 마.

상호 작용

코드형 인프라는 코드에 관한 것뿐만 아니라 코드와 사람 간의 관계, 인프라 개발자 간의 상호 작용에 관한 것입니다.

버스 팩터

프로젝트에 Vasya가 있다고 가정해 보겠습니다. Vasya는 인프라에 대한 모든 것을 알고 있습니다. Vasya가 갑자기 사라지면 어떻게 될까요? 버스에 치일 수도 있기 때문에 이것은 매우 실제적인 상황입니다. 때로는 그런 일이 발생합니다. 이런 일이 발생하고 코드, 구조, 작동 방식, 모양 및 비밀번호에 대한 지식이 팀에 배포되지 않으면 여러 가지 불쾌한 상황이 발생할 수 있습니다. 이러한 위험을 최소화하고 팀 내에서 지식을 배포하려면 다양한 접근 방식을 사용할 수 있습니다.

페어 데브옵싱

그렇지 않아요 농담으로, 관리자는 맥주를 마시고 비밀번호를 변경했으며 페어 프로그래밍과 유사했습니다. 저것들. 두 명의 엔지니어가 한 대의 컴퓨터, 한 대의 키보드에 앉아 서버 설정, Ansible 역할 작성 등 인프라 설정을 함께 시작합니다. 좋은 것 같지만 우리에게는 효과가 없었습니다. 그러나 이 관행의 특별한 경우는 효과가 있었습니다. 새로운 직원이 왔고 그의 멘토는 그와 함께 실제 업무를 수행하고 일하고 지식을 전달합니다.

또 다른 특별한 경우는 사고 전화입니다. 문제가 발생하면 당직자와 관련자들이 모여 한 명의 리더가 임명되어 자신의 화면을 공유하고 생각의 흐름을 전달합니다. 다른 참가자들은 리더의 생각을 따르고, 콘솔에서 트릭을 감시하고, 로그에서 한 줄도 놓치지 않았는지 확인하고, 시스템에 대한 새로운 것을 배웁니다. 이 접근 방식은 대개 효과가 있었습니다.

코드 검토

주관적으로는 코드 검토를 사용하여 인프라와 작동 방식에 대한 지식을 전파하는 것이 더 효과적이었습니다.

• 인프라는 저장소의 코드로 설명됩니다.
• 변경 사항은 별도의 분기에서 발생합니다.
• 병합 요청 중에 인프라의 변경 사항 델타를 볼 수 있습니다.

여기서 하이라이트는 일정에 따라 리뷰어를 한 명씩 선정했다는 것입니다. 어느 정도 확률로 새로운 기반 시설로 올라갈 수 있습니다.

코드 스타일

시간이 지남에 따라 리뷰 중에 말다툼이 나타나기 시작했습니다. 리뷰어들은 자신만의 스타일을 가지고 있었고 리뷰어들의 순환에 따라 공백 2개 또는 4개, camelCase 또는 snake_case 등 다양한 스타일로 쌓였습니다. 이를 바로 구현하는 것은 불가능했습니다.

• 첫 번째 아이디어는 linter 사용을 권장하는 것이었습니다. 결국 모든 사람은 엔지니어이고 모두 똑똑합니다. 하지만 다른 편집기, OS는 편리하지 않습니다.
• 이는 문제가 있는 각 커밋에 대해 Slack에 작성하고 linter 출력을 첨부하는 봇으로 발전했습니다. 그러나 대부분의 경우 해야 할 더 중요한 일이 있었고 코드는 수정되지 않은 채로 남아 있었습니다.

그린 빌드 마스터

시간이 흐르고 특정 테스트를 통과하지 못한 커밋은 마스터에 허용될 수 없다는 결론에 도달했습니다. 짜잔! 우리는 오랫동안 소프트웨어 개발에 활용되어 온 Green Build Master를 개발했습니다.

• 별도의 지점에서 개발이 진행 중입니다.
• 이 스레드에서 테스트가 실행 중입니다.
• 테스트가 실패하면 코드가 마스터에 포함되지 않습니다.

이 결정을 내리는 것은 매우 고통스러웠습니다. 왜냐하면... 많은 논란을 불러일으켰지만 그만한 가치가 있었습니다. 리뷰에서는 스타일 차이 없이 합병 요청이 들어오기 시작했고, 시간이 지나면서 문제가 되는 부분도 줄어들기 시작했습니다.

IaC 테스트

스타일 확인 외에도 인프라가 실제로 배포될 수 있는지 확인하는 등의 다른 방법을 사용할 수 있습니다. 또는 인프라 변경으로 인해 비용 손실이 발생하지 않는지 확인하세요. 왜 이것이 필요할 수 있습니까? 질문은 복잡하고 철학적입니다. 경계 조건을 확인하지 않은 Powershell에 자동 스케일러가 있었다는 이야기로 대답하는 것이 좋습니다 => 필요한 것보다 더 많은 VM이 생성되었습니다 => 클라이언트가 계획보다 더 많은 비용을 지출했습니다. 이는 그다지 유쾌한 일은 아니지만 초기 단계에서 이 오류를 포착하는 것이 가능합니다.

왜 복잡한 인프라를 더욱 복잡하게 만드는가? 코드와 마찬가지로 인프라 테스트는 단순화가 아니라 인프라가 어떻게 작동해야 하는지를 아는 것입니다.

IaC 테스트 피라미드

IaC 테스트: 정적 분석

한번에 전체 인프라를 구축하고 제대로 작동하는지 확인해보면 시간이 많이 걸리고 시간이 많이 걸린다는 것을 알 수 있습니다. 그러므로 기초는 빠르게 작동하는 것이어야 하며, 그것이 많고, 원시적인 부분을 많이 포괄합니다.

배쉬는 까다롭다

간단한 예를 살펴보겠습니다. 현재 디렉터리의 모든 파일을 선택하고 다른 위치에 복사합니다. 가장 먼저 떠오르는 것은:

for i in * ; do 
    cp $i /some/path/$i.bak
done

파일 이름에 공백이 있으면 어떻게 되나요? 글쎄요, 우리는 똑똑합니다. 따옴표를 사용하는 방법을 알고 있습니다.

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

잘하셨어요? 아니요! 디렉토리에 아무것도 없으면 어떻게 될까요? 글로빙이 작동하지 않습니다.

find . -type f -exec mv -v {} dst/{}.bak ;

이제 잘 됐나요? 아니요... 파일 이름에 무엇이 포함될 수 있는지 잊어버렸습니다. n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

정적 분석 도구

이전 단계의 문제는 인용문을 잊어버렸을 때 발견될 수 있습니다. 이에 대한 자연적인 해결책이 많이 있습니다. 쉘체크, 일반적으로 많은 것들이 있으며 IDE에서 스택에 대한 린터를 찾을 가능성이 높습니다.

지원하는 언어
수단

세게 때리다
쉘체크

루비
루보캅

파이썬
Pylint

먹을 수있는
앤서블 린트

IaC 테스트: 단위 테스트

이전 예에서 보았듯이 린터는 전능하지 않으며 모든 문제 영역을 지적할 수 없습니다. 또한 소프트웨어 개발의 테스트와 유사하게 단위 테스트를 떠올릴 수 있습니다. 당장 생각나는 것은 슈니트, 주니트, rspec, 파이 테스트. 하지만 Ansible, Chef, SaltStack 및 이와 유사한 사람들은 어떻게 해야 할까요?

맨 처음에 우리는 이야기를 나눴습니다. 단단한 그리고 우리의 인프라는 작은 벽돌로 구성되어야 합니다. 그들의 시간이 왔습니다.

1. 인프라는 Ansible 역할과 같은 작은 블록으로 나뉩니다.
2. Docker 또는 VM과 같은 일종의 환경이 배포됩니다.
3. 이 테스트 환경에 Ansible 역할을 적용합니다.
4. 모든 것이 예상대로 작동하는지 확인합니다(테스트를 실행합니다).
5. 우리는 괜찮은지 아닌지를 결정합니다.

IaC 테스트: 단위 테스트 도구

질문, CFM 테스트란 무엇입니까? 간단히 스크립트를 실행하거나 이를 위해 기성 솔루션을 사용할 수 있습니다.

CFM
수단

책임감있는
테스트인프라

요리사
인스 펙

요리사
서버 사양

염전
고스

testinfra의 예, 사용자 확인 test1, test2 존재하며 그룹에 속해 있습니다. sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

무엇을 선택할까요? 질문은 복잡하고 모호합니다. 다음은 2018-2019년 github 프로젝트 변경 사항의 예입니다.

IaC 테스트 프레임워크

질문이 생깁니다. 이 모든 것을 어떻게 하나로 모아서 출시할 수 있을까요? 할 수 있다 가져가서 직접 해보세요 엔지니어 수가 충분하다면. 또는 그다지 많지는 않지만 기성 솔루션을 사용할 수 있습니다.

CFM
수단

책임감있는
분자

요리사
주방 테스트

테라 폼
테라테스트

2018~2019년 github 프로젝트 변경 예:

분자 대 테스트키친

처음에 우리는 testkitchen을 사용해 보았습니다.:

1. VM을 병렬로 생성합니다.
2. Ansible 역할을 적용합니다.
3. 검사를 실행합니다.

25~35개 역할의 경우 40~70분 동안 작동했는데 이는 긴 시간이었습니다.

다음 단계는 jenkins/docker/ansible/molecule로의 전환이었습니다. 이념적으로 모든 것이 동일합니다

1. 린트 플레이북.
2. 역할을 정렬하십시오.
3. 컨테이너 실행
4. Ansible 역할을 적용합니다.
5. 테스트인프라를 실행하세요.
6. 멱등성을 확인하세요.

40개 역할에 대한 Linting과 15개 역할에 대한 테스트에는 약 XNUMX분이 소요되기 시작했습니다.

무엇을 선택할지는 사용된 스택, 팀의 전문성 등과 같은 여러 요소에 따라 달라집니다. 여기서 모두가 단위 테스트 질문을 마무리하는 방법을 스스로 결정합니다.

IaC 테스트: 통합 테스트

인프라 테스트 피라미드의 다음 단계는 통합 테스트입니다. 단위 테스트와 유사합니다.

1. 인프라는 Ansible 역할과 같은 작은 블록으로 나뉩니다.
2. Docker 또는 VM과 같은 일종의 환경이 배포됩니다.
3. 이 테스트 환경에 적용 세트 Ansible 역할.
4. 모든 것이 예상대로 작동하는지 확인합니다(테스트를 실행합니다).
5. 우리는 괜찮은지 아닌지를 결정합니다.

대략적으로 말하면 단위 테스트에서와 같이 시스템의 개별 요소의 성능을 확인하는 것이 아니라 서버가 전체적으로 어떻게 구성되어 있는지 확인합니다.

IaC 테스트: 종단 간 테스트

피라미드 꼭대기에는 End to End 테스트가 있습니다. 저것들. 우리는 별도의 서버, 별도의 스크립트 또는 인프라의 별도 브릭의 성능을 확인하지 않습니다. 우리는 많은 서버가 함께 연결되어 있고 인프라가 예상대로 작동하는지 확인합니다. 안타깝게도 기성품 박스형 솔루션을 본 적이 없습니다. 아마도... 인프라는 고유한 경우가 많으며 테스트용 프레임워크를 템플릿화하고 생성하기가 어렵습니다. 결과적으로 모든 사람은 자신만의 솔루션을 만듭니다. 요구는 있는데 답이 없습니다. 그러므로 모든 것이 우리보다 오래 전에 발명되었다는 사실을 다른 사람들에게 건전한 생각으로 강요하거나 코를 비비기 위해 무엇이 있는지 알려 드리겠습니다.

풍부한 역사를 지닌 프로젝트. 이는 대규모 조직에서 사용되며 아마도 여러분 각자는 간접적으로 이 방법을 사용했을 것입니다. 이 응용 프로그램은 많은 데이터베이스, 통합 등을 지원합니다. 인프라가 어떤 모습일지 아는 것은 많은 docker-compose 파일을 알고, 어떤 환경에서 어떤 테스트를 실행할지 아는 것이 Jenkins입니다.

이 계획은 프레임워크 내에서 꽤 오랫동안 작동했습니다. 연구 우리는 이것을 Openshift로 전송하려고 시도하지 않았습니다. 컨테이너는 동일하게 유지되지만 실행 환경이 변경되었습니다(다시 DRY를 확인하세요).

연구 아이디어는 더 나아가 오픈시프트에서 인프라를 컨테이너에 배포하는 방법에 대한 지식을 담을 수 있는 APB(Ansible Playbook Bundle)와 같은 것을 발견했습니다. 저것들. 인프라 배포 방법에 대한 반복 가능하고 테스트 가능한 지식 지점이 있습니다.

이기종 인프라를 만나기 전까지는 이 모든 것이 괜찮게 들렸습니다. 테스트에는 Windows가 필요했습니다. 결과적으로 무엇을, 어디서, 어떻게 배포하고 테스트할지에 대한 지식이 젠킨스에 있습니다.

결론

코드로서의 인프라

• 저장소의 코드.
• 인간의 상호 작용.
• 인프라 테스트.

모래밭

• 영어 버전
• 개인 블로그의 교차 게시물
• 테스트 실행 2019-04-24 SpbLUG
• DevopsConf의 비디오(RU) 2019-05-28
• DINS DevOps EVENING의 비디오(RU) 2019-06-20
• 300,000줄이 넘는 인프라 코드 작성을 통해 얻은 교훈 & 텍스트 버전
• 코드형 인프라를 지속적인 전달 파이프라인에 통합
• 코드형 인프라 테스트
• Ansible 역할의 효과적인 개발 및 유지 관리
• Ansible은 배쉬가 아닙니다!

출처 : habr.com