안녕하세요~ Administrator팀입니다 🦔
오늘은 DevOps에 반드시 필요한 요소인 IaC에 대해 알아가는 시간을 가져보도록 할게요!
코드형 인프라(IaC)란?
코드형 인프라(Infrastructure as Code, IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말합니다. IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기가 더 쉬워집니다. 또한 IaC는 매번 동일한 환경을 프로비저닝하도록 보장하고, 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원합니다. 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있습니다.
버전 제어는 IaC의 중요한 부분입니다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요합니다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요합니다. 코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이기도 합니다.
IaC로 인프라 프로비저닝을 자동화하면 애플리케이션을 개발하거나 배포할 때마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없어집니다. 인프라를 코드화하여 템플릿을 만들고 프로비저닝할때 이 템플릿을 사용하면 됩니다. 이러한 작업은 수동으로 진행할 수도 있고 Terraform과 Ansible 같은 자동화 툴을 사용할 수도 있습니다.
IaC에 대한 선언적 접근과 명령형 접근 방식 비교
IaC에 대한 접근 방식에는 선언적 방식과 명령형 방식 두 가지가 있습니다.
선언적 접근 방식에서는 필요한 리소스와 리소스의 속성 등 바람직한 시스템 상태를 정의하면 IaC 툴이 바람직한 상태로 구성해 줍니다. 또한 시스템 오브젝트의 현재 상태 목록을 유지하며, 이를 통해 인프라를 더 쉽게 관리할 수 있습니다.
한편 명령적 접근 방식에서는 바람직한 구성을 얻기 위한 특정 명령을 정의하며, 정의된 명령을 올바른 순서로 실행해야 합니다. 많은 IaC 툴이 선언적 접근 방식에 따라 원하는 인프라를 자동으로 프로비저닝합니다.
IaC의 장점
원래 인프라 프로비저닝은 시간과 비용이 많이 드는 수동 프로세스였습니다. 하지만 이제 데이터 센터의 물리적 하드웨어가 아니라 가상화, 컨테이너, 클라우드 컴퓨팅을 이용하여 인프라 관리를 하게 되었습니다.
클라우드 컴퓨팅이 등장하면서 인프라 구성 요소의 수가 늘어났고, 날마다 더 많은 애플리케이션이 프로덕션 환경에 릴리스되고 있습니다.이에 따라 더 잦은 빈도로 가동하고, 중지하고, 확장할 수 있는 인프라가 필요해졌습니다. IaC 이용 사례를 확립하지않으면 현재 인프라의 규모를 관리하기가 갈수록 어려워질 것입니다.
조직은 IaC를 이용해 IT 인프라 요구 사항을 관리함과 동시에 일관성을 높이고 오류 및 수동 구성을 줄일 수 있습니다.
장점
- 비용 절감
- 배포 속도 향상
- 오류 감소
- 인프라 일관성 향상
- 구성 변동 제거
IaC 구현에 서버 자동화 및 구성 관리 툴을 사용할 수 있는 경우가 많습니다. IaC에 특화된 솔루션도 있습니다.
몇 가지 널리 사용되는 툴을 소개합니다!
- Chef
- Puppet
- Red Hat Ansible Automation Platform
- Saltstack
- Terraform
- AWS CloudFormation
IaC가 DevOps에 중요한 이유
IaC는 DevOps 사례 및 지속적 통합/지속적 제공(CI/CD)에서 중요한 부분을 차지합니다. 개발자가 하던 프로비저닝 작업을 대부분 IaC로 처리하고 개발자는 스크립트를 실행하여 인프라를 준비할 수 있습니다.
따라서 인프라 준비를 기다리는 동안 애플리케이션 배포를 보류할 필요가 없으며, 시스템 관리자는 시간이 많이 소요되는 수동 프로세스를 관리하지 않아도 됩니다.
CI/CD는 통합 및 테스트에서 제공 및 배포에 이르는 애플리케이션 라이프사이클 전반에 걸쳐 지속적인 자동화와 지속적인 모니터링에 의존합니다.
환경을 자동화하려면 환경에 일관성이 있어야 합니다. 개발팀의 애플리케이션 배포 또는 환경 구성 방식이 운영 팀의 배포 및 구성 방식과 다른 경우 애플리케이션 배포 자동화는 효과가 없습니다.
DevOps 접근 방식을 통해 개발팀과 운영팀의 방식을 서로 일치시키면 오류, 수동 배포, 비일관성 문제가 줄어듭니다. 두 팀이 동일한 설명에 따라 애플리케이션을 배포할 수 있으므로 IaC는 개발과 운영을 조율하는 데 도움이 됩니다.
다시 말해, 프로덕션 환경을 비롯한 모든 환경에서 동일한 배포 프로세스를 사용해야 합니다. IaC는 사용될 때마다 동일한 환경을 생성합니다. 또한 IaC는 자동으로 다시 생성할 수 없고 고유한 구성을 지닌 개별 배포 환경을 유지 관리할 필요가 없으므로 프로덕션 환경의 일관성이 보장됩니다.
DevOps 모범 사례는 IaC 내 인프라에도 적용됩니다. 소프트웨어 개발 과정에서 애플리케이션과 동일한 CI/CD 파이프라인을 인프라에도 적용함으로써 동일한 테스트 및 버전 제어를 인프라 코드에 반영할 수 있습니다.
긴 글 읽어주셔서 감사합니다! 다음 시간부터는 IaC 자동화 툴들을 하나씩 파헤쳐보도록 하겠습니다 😊 베빠 ~~
reference site
https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac
'INFRA > DevOps' 카테고리의 다른 글
[K8S] 배포전략 (0) | 2022.06.09 |
---|---|
[Docker] Container 개요 (0) | 2022.06.07 |
Service - 1 (0) | 2022.06.02 |
쿠버네티스 service (0) | 2022.05.30 |
Jenkins Pipeline (2) (0) | 2022.05.25 |
댓글