IaC 의 모든 항목 코드화

모든 인프라 스펙은 구성 파일에서 예를 들어 Terraform 구성 또는 Ansible 플레이북으로 명시적으로 코딩되어야 합니다. 구성 파일은 인프라 스펙의 단일 소스이며 해당 구성에서 사용되는 인프라 컴포넌트를 설명합니다.

문서 최소화

IaC 는 문서입니다. IaC 가 제 위치에 있으면 구성 파일은 문서를 나타내며 항상 최신 상태이므로 노력이 줄어듭니다. 나머지 문서는 프로세스에 대한 것입니다. 버전 제어 시스템에서 코드를 유지보수합니다.

IaC 구성 파일은 GitHub 또는 GitLab과 같은 버전 제어 시스템 (VCS) 에 보관해야 합니다. 이는 코드 변경사항에 대한 감사 추적을 제공하지만 변경사항이 실행되기 전에 협업하거나 피어 검토 및 테스트할 수 있는 기회도 제공합니다.

이 사례를 사용하면 시스템에 대한 잠재적 변경사항을 쉽게 추적, 관리 및 되돌릴 수 있으며 추적성 및 가시성이 향상됩니다.

테스트

IaC 가 소프트웨어 개발에서 빌려오는 사례 중 하나는 테스트입니다. 인프라 구성의 엄격한 테스트는 배치 후 문제를 줄이는 데 중요한 역할을 합니다. 버전 제어 시스템과 결합되면 코드가 수정될 때마다 테스트가 자동으로 트리거될 수 있습니다.

적절한 CI (Continuous Integration) 를 사용하여 템플리트 인프라 구성을 development, UAT, QA 또는 production 환경과 같은 여러 환경에서 최소한의 변경사항을 효과적으로 적용하여 구현할 수 있습니다.

모듈식 인프라

인프라를 모듈 로 나누면 재사용할 수 있고 안정성이 향상되며 채택 경로가 쉬워집니다. 프로그래밍 언어에서의 모듈 및 패키지 사용과 유사합니다. 다음은 이 사례의 이점입니다.

• 자주 사용되는 구성을 모듈로 코드화하고 여러 환경에서 여러 번 재사용할 수 있습니다.
• 모듈을 테스트할 수 있을 때 신뢰성이 증가하고 사용 시간이 경과함에 따라 모듈이 강화됩니다.
• 재사용 가능한 모듈의 컴포지션은 IaC 채택에 대한 기술 장벽을 낮춥니다.
• 변경사항은 모듈 레벨에서 작성하고 테스트하기가 더 쉽습니다.
• 구성 변경사항이 현지화되면 변경 위험이 줄어듭니다.

IaC 에 대한 선언적 접근 방식과 명령적 접근 방식

IaC,을 채택할 때 고려해야 할 측면은 툴링에 어떤 접근 방식을 취할 것인지입니다. 선언적 또는 필수적이라는 두 가지 다른 양식이 있으며 때로는 프로시저로 설명되기도 합니다.

선언적 접근 방식은 필요한 자원 및 포함해야 하는 특성을 포함하여 시스템의 원하는 상태를 정의하며 도구가 사용자를 위해 구성됩니다. 도구 자체가 시작점에서 원하는 상태로 이동하기 위한 조작을 판별합니다.

명령 접근 방식은 대신 원하는 구성을 달성하는 데 필요한 특정 명령을 정의하며, 이러한 명령은 올바른 순서로 실행되어야 합니다.

요리사는 필수적인 도구로 생각된다. Terraform은 선언적으로 분류됩니다. Ansible 은 선언적이지만 명령과 함께 사용할 수도 있습니다.

선언적 Terraform및 라이프사이클 관리

Schematics 는 Schematics 작업공간 및 조치를 사용하여 IaC 도구로 Terraform및 Ansible 을 모두 지원합니다. 라이프사이클 관리가 중요한 경우 정기적으로 가동되고 해체되는 환경에서 Schematics 작업공간과 함께 Terraform을 사용하는 것이 좋습니다. Terraform은 배치된 클라우드 인프라의 현재 상태에 대한 레코드를 유지하며 Schematics 는 수동 개입 없이 역종속 순서로 인프라를 제거할 수 있습니다.

Idempotence

Terraform및 Ansible 에서 사용하는 선언적 접근의 이점은 idempotence 입니다. 멱등원 태스크는 동일한 종료 결과를 사용하여 여러 번 실행할 수 있습니다. 장애 후 다시 시작할 때 이전 상태 또는 시작 위치에 상관없이 프로비저닝된 인프라 및 구성은 항상 동일합니다. 이 측면은 Schematics를 사용하여 배치된 환경의 일관성 및 반복성을 보장하는 데 중요합니다.

도구 및 사용되는 모듈을 사용하는 방법은 idempotency 에 영향을 미칩니다. 일반적으로 Terraform및 Ansible 모듈은 멱등원으로 작성됩니다. 두 도구를 사용하여 멱등원 결과를 산출하지 않는 코드를 작성할 수 있습니다. 이 경우, 구성은 원하는 타겟 상태로부터 드리프트할 수 있다. Terraform을 사용하는 경우 이러한 양식의 드리프트는 null-resources 가 멱등원이 아닌 사용자 정의 스크립트를 사용하여 제공자 기능을 확장하는 데 사용되는 경우에 가장 가능성이 높습니다.

불변성은 대상 상태에서 드리프트의 위험을 최소화하는 IaC 사례입니다.

불변

불변 인프라는 컨테이너 또는 가상 머신과 같은 자원이 변경되지 않고 (스크립트를 사용하여) 대체되는 서비스 및 소프트웨어 배치를 관리하는 것입니다. 여기서 불변성에 대한 기본적인 요구는 구성 변경을 피하는 것입니다. 로컬 또는 수동 변경이나 자동화된 조작 순서의 차이로 인해 발생하는 불일치입니다. 문제를 디버그하고 해결하는 것을 어렵게 하고 지원 비용을 증가시키는 변경사항입니다.

변경 가능성을 보장하고 드리프트를 제거하려면 Schematics IaC 구성을 통해 모든 변경사항을 작성해야 하며 업데이트가 필요할 때 VSI와 같은 자원을 다시 배치해야 합니다.