코드형 인프라: 첫 만남

우리 회사는 SRE 팀을 온보딩하는 중입니다. 나는 개발 측면에서 이 모든 이야기에 참여했습니다. 그 과정에서 다른 개발자들과 공유하고 싶은 생각과 통찰이 떠올랐습니다. 이 성찰 기사에서 나는 무슨 일이 일어나고 있는지, 어떻게 일어나고 있는지, 그리고 모든 사람이 어떻게 계속해서 살아갈 수 있는지에 대해 이야기합니다.

내부 행사에서의 연설을 바탕으로 작성된 일련의 기사를 계속해서 게재합니다. 데브포럼:

1. 상자 없는 슈뢰딩거의 고양이: 분산 시스템의 합의 문제.
2. 코드로서의 인프라. (당신은 여기 있습니다)
3. C# 모델을 사용하여 Typescript 계약 생성. (진행중...)
4. Raft 합의 알고리즘 소개. (진행중...)
...

우리는 아이디어를 구현하는 SRE 팀을 만들기로 결정했습니다. 구글 sre. 그들은 자체 개발자 중에서 프로그래머를 모집하여 몇 달 동안 훈련하도록 보냈습니다.

팀은 다음과 같은 교육 작업을 수행했습니다.

• 대부분 코드 형태(Terraform 및 주변의 모든 것)로 Microsoft Azure에 있는 인프라를 설명합니다.
• 개발자에게 인프라 작업 방법을 가르칩니다.
• 개발자의 임무를 준비하세요.

코드로서의 인프라 개념을 소개합니다.

세계의 일반적인 모델(고전적 행정)에서 인프라에 대한 지식은 두 위치에 있습니다.

1. 또는 전문가의 머리 속에 있는 지식의 형태로 말입니다.
2. 또는 이 정보는 일부 타자기에 있으며 그 중 일부는 전문가에게 알려져 있습니다. 그러나 외부인(우리 팀 전체가 갑자기 사망하는 경우)이 무엇이 작동하고 어떻게 작동하는지 알아낼 수 있다는 것은 사실이 아닙니다. 기계에는 액세서리, cronjob, 협박 등 많은 정보가 있을 수 있습니다(참조: 디스크 장착) 디스크와 발생할 수 있는 일에 대한 끝없는 목록입니다. 실제로 무슨 일이 일어나고 있는지 이해하기 어렵습니다.

두 경우 모두 우리는 의존적인 상태에 빠지게 됩니다.

• 또는 필멸의 사람, 질병에 걸리기 쉬운 사람, 사랑에 빠지는 사람, 기분 변화 및 단순히 진부한 해고;
• 또는 넘어지거나 도난당하고 놀라움과 불편을 초래하는 물리적으로 작동하는 기계에서 발생합니다.

이상적으로는 모든 것이 사람이 읽을 수 있고 유지 관리가 가능하며 잘 작성된 코드로 변환되어야 한다는 것은 말할 필요도 없습니다.

따라서 코드형 인프라(Incfastructure as Code - IaC)는 코드 형태의 기존 인프라 전체에 대한 설명과 함께 작업하고 실제 인프라를 구현하기 위한 관련 도구입니다.

왜 모든 것을 코드로 변환합니까?사람은 기계가 아닙니다. 그들은 모든 것을 기억할 수 없습니다. 사람과 기계의 반응은 다릅니다. 자동화된 모든 작업은 인간이 수행하는 작업보다 잠재적으로 더 빠릅니다. 가장 중요한 것은 단일 정보 소스입니다.

새로운 SRE 엔지니어는 어디에서 왔나요?그래서 우리는 새로운 SRE 엔지니어를 고용하기로 결정했습니다. 그런데 이들을 어디서 구할 수 있을까요? 정답으로 예약하세요 (Google SRE 도서) 개발자가 알려줍니다. 결국 그들은 코드를 사용하여 작업하고 이상적인 상태를 달성합니다.

우리는 회사 외부 인사 시장에서 오랫동안 그들을 많이 검색했습니다. 하지만 우리의 요청에 맞는 사람을 찾지 못했다는 점을 인정해야 합니다. 나는 내 사람들 중에서 검색해야했습니다.

문제 코드로서의 인프라

이제 인프라를 코드로 하드코딩하는 방법의 예를 살펴보겠습니다. 코드는 주석과 들여쓰기를 포함하여 잘 작성되었으며 고품질입니다.

Terraforma의 예제 코드.

Ansible의 예제 코드.

여러분, 그렇게 간단하다면! 우리는 현실 세계에 있으며 항상 여러분을 놀라게 할 준비가 되어 있고 여러분에게 놀라움과 문제를 제시할 준비가 되어 있습니다. 여기에서도 그들 없이는 할 수 없습니다.

1. 첫 번째 문제는 대부분의 경우 IaC가 일종의 dsl이라는 것입니다.

그리고 DSL은 구조에 대한 설명입니다. 보다 정확하게는 Json, Yaml, 자체 DSL을 고안한 일부 대기업의 수정 사항(HCL은 Terraform에서 사용됨)입니다.

문제는 다음과 같은 친숙한 내용이 쉽게 포함되지 않을 수 있다는 것입니다.

• 변수;
• 정황;
• 예를 들어 Json과 같이 주석이 없는 곳에서는 기본적으로 주석이 제공되지 않습니다.
• 기능;
• 그리고 나는 클래스, 상속, 그 모든 것과 같은 높은 수준의 것들에 대해서도 이야기하고 있지 않습니다.

2. 이러한 코드의 두 번째 문제점은 대부분 이기종 환경이라는 것입니다.. 일반적으로 앉아서 C#을 사용하여 작업합니다. 하나의 언어, 하나의 스택, 하나의 생태계로 구성됩니다. 그리고 여기에는 매우 다양한 기술이 있습니다.

Python을 사용하는 bash가 Json이 삽입되는 일부 프로세스를 시작하는 것은 매우 실제적인 상황입니다. 이를 분석하면 다른 생성기가 또 다른 30개의 파일을 생성합니다. 이 모든 경우 입력 변수는 Go로 작성된 Drone.io용 플러그인으로 함께 가져오는 Azure Key Vault에서 수신되며 이러한 변수는 jsonnet 템플릿 엔진에서 생성된 결과로 생성된 yaml을 통과합니다. 이처럼 다양한 환경이 있을 때 엄격하게 잘 설명된 코드를 갖는 것은 매우 어렵습니다.

하나의 작업 프레임워크 내에서의 전통적인 개발에는 하나의 언어가 사용됩니다. 여기서 우리는 수많은 언어로 작업합니다.

3. 세 번째 문제는 튜닝이다.. 우리는 우리를 위해 모든 일을 해 주는 멋진 편집기(Ms Visual Studio, Jetbrains Rider)에 익숙합니다. 그리고 우리가 어리석더라도 그들은 우리가 틀렸다고 말할 것입니다. 그것은 정상적이고 자연스러운 것 같습니다.

그러나 근처 어딘가에 VSCode가 있는데, 여기에는 어떻게든 설치되거나 지원되거나 지원되지 않는 일부 플러그인이 있습니다. 새 버전이 나왔지만 지원되지 않았습니다. 기능 구현으로의 진부한 전환(존재하더라도)은 복잡하고 사소한 문제가 됩니다. 변수의 간단한 이름 바꾸기는 XNUMX개 파일의 프로젝트에서 재생되는 것입니다. 그가 당신에게 필요한 것을 놓아준다면 당신은 운이 좋을 것입니다. 물론, 여기저기에 백라이트가 있고, 자동 완성이 있고, 어딘가에 서식이 있습니다(비록 Windows의 Terraform에서는 작동하지 않았지만).

이 글을 쓰는 시점에서 vscode-terraform 플러그인 은(는) 버전 0.12를 지원하도록 출시되지 않았지만 출시된 지 3개월이 되었습니다.

이제 잊어야 할 시간이다...

1. 디버깅.
2. 리팩토링 도구.
3. 자동 완성.
4. 컴파일 중 오류 감지.

웃기기도 하지만 이로 인해 개발 시간도 늘어나고 필연적으로 발생하는 오류도 늘어나게 됩니다.

최악의 점은 파일을 디자인하고, 폴더로 구성하고, 분해하고, 코드를 유지 관리하고, 읽을 수 있게 만드는 등의 방법에 대해 생각하지 않고 이 명령을 올바르게 작성하는 방법에 대해 생각해야 한다는 것입니다. .

초보자로서 테라폼을 배우려고 하는데 IDE가 전혀 도움이 되지 않습니다. 문서가 있으면 들어가서 살펴보세요. 그러나 새로운 프로그래밍 언어를 입력하는 경우 IDE는 그러한 유형이 있지만 그러한 유형은 없다고 알려줍니다. 적어도 int 또는 문자열 수준에서. 이것은 종종 유용합니다.

테스트는 어떻습니까?

"프로그래머 여러분, 테스트는 어떻습니까?" 진지한 사람들은 프로덕션에서 모든 것을 테스트하는데, 그것은 어렵습니다. 다음은 웹사이트의 Terraform 모듈에 대한 단위 테스트의 예입니다. Microsoft.

그들은 좋은 문서를 가지고 있습니다. 저는 항상 문서화와 교육에 대한 Microsoft의 접근 방식을 좋아했습니다. 하지만 이것이 완벽한 코드가 아니라는 것을 이해하기 위해 밥 삼촌이 될 필요는 없습니다. 오른쪽의 유효성 검사를 참고하세요.

단위 테스트의 문제점은 여러분과 제가 Json 출력의 정확성을 확인할 수 있다는 것입니다. 저는 5개의 매개변수를 입력했고 2000줄의 Json 족보를 받았습니다. 여기서 무슨 일이 일어나고 있는지 분석하고 테스트 결과를 확인할 수 있습니다.

Go에서 Json을 구문 분석하는 것은 어렵습니다. 그리고 Go로 작성해야 합니다. 왜냐하면 Go의 테라폼은 작성하는 언어로 테스트하는 데 좋은 방법이기 때문입니다. 코드 자체의 구성은 매우 약합니다. 동시에 이것은 테스트를 위한 최고의 라이브러리입니다.

Microsoft 자체는 모듈을 작성하여 이러한 방식으로 테스트합니다. 물론 오픈소스입니다. 내가 말하는 모든 것은 당신이 와서 고칠 수 있습니다. 일주일 안에 모든 것을 고치고, 오픈 소스 VS 코드 플러그인, 테라폼을 만들고, 라이더를 위한 플러그인을 만들 수 있습니다. 어쩌면 몇 개의 분석기를 작성하고, 린터를 추가하고, 테스트용 라이브러리를 제공할 수도 있습니다. 나는 무엇이든 할 수있다. 하지만 그건 내가 해야 할 일이 아닙니다.

모범 사례 코드형 인프라

계속 진행합시다. IaC에 테스트가 없고 IDE와 튜닝이 좋지 않다면 최소한 모범 사례가 있어야 합니다. 방금 Google Analytics로 이동하여 Terraform 모범 사례와 C# 모범 사례라는 두 가지 검색어를 비교했습니다.

우리는 무엇을 봅니까? 무자비한 통계는 우리에게 유리하지 않습니다. 재료의 양은 동일합니다. C# 개발에는 자료가 넘쳐나고, 최고의 모범 사례가 있고, 전문가가 쓴 책도 있고, 그런 책을 비판하는 다른 전문가의 책을 바탕으로 쓴 책도 있습니다. 공식 문서, 기사, 교육 과정, 그리고 현재 오픈 소스 개발의 바다입니다.

IaC 요청의 경우: 여기에서는 하이로드 또는 HashiConf 보고서, 공식 문서 및 Github의 수많은 문제에서 정보를 조금씩 수집하려고 합니다. 일반적으로 이러한 모듈을 배포하는 방법과 이를 사용하여 무엇을 해야 합니까? 이것이 진짜 문제인 것 같습니다... 여러분, 질문이 있을 경우 Github에 10개의 댓글이 제공되는 커뮤니티가 있습니다. 하지만 꼭 그렇지는 않습니다.

불행하게도 이 시점에서 전문가들은 이제 막 등장하기 시작했습니다. 지금까지는 그 수가 너무 적습니다. 그리고 커뮤니티 자체는 초보적인 수준에서 활동하고 있습니다.

이 모든 것이 어디로 가고 무엇을 해야 하는가?

모든 것을 내려놓고 C#으로 돌아가 라이더의 세계로 돌아갈 수 있습니다. 하지만. 해결책을 찾을 수 없다면 왜 굳이 이런 일을 하겠습니까? 아래에서는 주관적인 결론을 제시합니다. 댓글에서 나와 논쟁을 벌일 수 있습니다. 흥미로울 것입니다.

개인적으로 저는 다음과 같은 몇 가지 사항에 베팅하고 있습니다.

1. 이 분야의 개발은 매우 빠르게 진행되고 있습니다. DevOps 요청 일정은 다음과 같습니다.

   
   
   주제가 과장된 것일 수도 있지만 영역이 성장하고 있다는 사실 자체가 희망을 줍니다.

   무언가가 너무 빨리 성장하면 해야 할 일과 하지 말아야 할 일을 알려줄 똑똑한 사람들이 반드시 나타날 것입니다. 인기가 높아짐에 따라 누군가 마침내 vscode용 jsonnet에 플러그인을 추가할 시간이 생길 수도 있습니다. 이를 통해 ctrl+shift+f를 통해 검색하는 대신 기능 구현으로 넘어갈 수 있습니다. 상황이 발전함에 따라 더 많은 자료가 나타납니다. SRE에 관한 Google의 책 출시가 이에 대한 훌륭한 예입니다.

2. 여기에 성공적으로 적용할 수 있는 기존 개발 방식의 개발된 기술과 관행이 있습니다. 예, 테스트와 이기종 환경, 부족한 도구에 미묘한 차이가 있지만 유용하고 도움이 될 수 있는 수많은 사례가 축적되어 있습니다.

   간단한 예: 페어 프로그래밍을 통한 협업. 그것을 알아내는 데 많은 도움이 됩니다. 근처에 무언가를 이해하려고 노력하는 이웃이 있으면 함께하면 더 잘 이해할 수 있습니다.

   리팩토링이 어떻게 수행되는지 이해하면 그러한 상황에서도 리팩토링을 수행하는 데 도움이 됩니다. 즉, 모든 것을 한 번에 변경할 수는 없지만 이름을 변경하고 위치를 변경한 다음 일부 부분을 강조 표시할 수 있습니다. 아, 여기에는 설명이 충분하지 않습니다.

결론

내 추론이 비관적으로 보일 수 있다는 사실에도 불구하고 나는 희망을 가지고 미래를 바라보며 모든 것이 우리(그리고 당신)를 위해 잘되기를 진심으로 바랍니다.

기사의 두 번째 부분은 다음에 준비 중입니다. 여기에서는 학습 프로세스를 개선하고 인프라와 협력하기 위해 어떻게 민첩한 개발 방식을 사용하려고 했는지에 대해 이야기하겠습니다.

출처 : habr.com