코드형 인프라(IaC)는 클라우드 리소스의 프로비저닝 및 관리를 자동화하는 프로세스입니다. IaC 소프트웨어는 원하는 상태를 설명하는 몇 가지 입력 스크립트를 가져온 다음 일반적으로 API를 통해 클라우드 공급업체와 통신하여 현실이 원하는 상태와 일치하도록 합니다.
이 기사에서는 IaC가 어떻게 생겨났는지(즉, 어떤 문제를 해결했는지), 이점, 마지막으로 IaC를 조직에 통합하는 방법부터 시작하여 IaC의 중요한 측면을 다룹니다.
옛날 옛적에 기업이 소프트웨어를 실행하려고 할 때 유일한 옵션은 네트워크 공급자에게 물리적 장비와 인터넷 액세스를 주문하는 것이었습니다. 이들은 온사이트 데이터 센터로, 기업은 예상 트래픽에 따라 몇 주 또는 몇 달 전에 서버와 네트워킹 장비를 주문한 다음 현장에서 수동으로 프로비저닝해야 했습니다. 이를 위해서는 냉각 시스템이 있는 물리적 위치와 설치 및 유지 보수 작업을 수행하는 데 수많은 시간이 필요했습니다.
그러나 다른 기업의 서버를 관리할 수 있는 공용 데이터 센터가 등장했습니다.
데이터 센터 운영은 그 자체로 실행 가능한 비즈니스가 되었으며 고객에게 큰 이점을 제공합니다.
가상화의 출현은 클라우드라는 또 다른 진화를 가져왔습니다. 퍼블릭(또는 프라이빗) 클라우드에서 물리적 장비는 클라우드 공급업체의 데이터 센터에 있으며, 여전히 수동 처리가 필요합니다. 가상 서버는 웹 인터페이스를 통해 기업에서 사용할 수 있게 되어 몇 초(또는 가장 큰 리소스의 경우 몇 분) 만에 서버 및 기타 리소스를 프로비저닝할 수 있게 되었습니다. 이 단계에서 가상화를 통해 매우 빠른 프로비저닝이 가능했지만 대부분의 작업은 여전히 수동이었습니다.
최종 개발은 IaC 개념 및 도구의 출현과 함께 이루어졌습니다. API를 통해 클라우드에 액세스할 수 있게 되자 리소스의 프로비저닝 및 관리는 사람이 아닌 스크립트와 자동화된 도구로 처리할 수 있었습니다. 따라서 이제 물리적 장비가 설치되고 연결되면(여전히 수동 작업) 모든 가상 하드웨어 리소스의 프로비저닝을 포함하여 다른 모든 것을 자동화할 수 있습니다.
퍼블릭 클라우드에 프로그래밍 방식으로 액세스할 수 있는 기능은 IaC의 등장을 허용했습니다. IaC가 등장하기 전에는 시스템 엔지니어가 리소스를 프로비저닝하고 구성하기 위해 웹 인터페이스를 수동으로 거쳐야 했습니다. IaC를 사용하면 리소스의 프로비저닝 및 구성이 스크립트에 설명되어 있으며, 퍼블릭 클라우드 API와 통신하는 도구에서 스크립트를 읽어 현실이 원하는 상태와 일치하는지 확인합니다.
위에서 언급했듯이 IaC 도구는 스크립트의 입력을 사용합니다. 이러한 스크립트는 사람에 의해 작성되며 지정된 클라우드 리소스에 대해 원하는 상태를 설명합니다. 이 도구는 API를 통해 클라우드 공급업체와 통신하여 리소스를 생성, 업데이트 또는 삭제하여 현실이 입력 스크립트에 설명된 원하는 상태와 일치하도록 합니다. 수동 프로비저닝 및 구성과 비교할 때 IaC는 단일 정보 소스(입력 스크립트)를 제공하므로 대부분의 인적 오류를 제거합니다.
IaC 스크립트 실행은 매번 똑같은 결과를 생성하는 반복 가능한 작업입니다. 이는 다음과 같은 여러 가지 방법으로 도움이 될 수 있습니다.
IaC 스크립트는 git 리포지토리에 저장하여 인프라 기록을 제공할 수 있습니다. 추가 보너스로, 스크립트는 텍스트일 뿐이므로 버전을 비교하여 추가, 변경 또는 제거된 내용을 확인할 수 있습니다.
또 다른 이점은 IaC를 통해 주니어 시스템 관리자 또는 비기술자가 기술 지식 없이도 전체 워크로드를 만들 수 있다는 것입니다. 클라우드 계정을 올바르게 구성하면 사용자에게 리소스를 직접 만들 수 있는 권한이 없더라도 제한된 권한을 가진 사용자가 IaC 도구를 통해 이러한 워크로드를 생성하도록 허용할 수도 있습니다. 또한 추가 도구 및 템플릿을 활용하여 보안 정책을 조기에 구현하여 IaC 스택을 인스턴스화하는 사람에 의한 보안 누출 및 잘못된 구성 가능성을 제한할 수 있습니다.
정확한 반복성 외에도 수동 작업에 비해 IaC의 가장 큰 장점 중 하나는 확장 가능하다는 것입니다. 실제로 IaC 스크립트를 한 번만 작성하면 거의 즉시 원하는 만큼 워크로드를 인스턴스화할 수 있습니다. 마지막으로, IaC 스크립트에 올바른 권한을 만드는 데 더 많은 시간을 할애함으로써 역할 및 리소스에 너무 많은 권한을 부여하는 수동 작업의 일반적인 단점을 피할 수 있습니다.
일반적으로 현재 수동으로 수행 중인 일부 작업을 자동화하려고 합니다. 따라서 첫 번째 단계는 워크로드에 필요한 인프라를 구축하는 데 필요한 수동 단계를 문서화하는 것입니다. IaC를 통해 자동화할 단계는 다음과 같습니다.
그런 다음 IaC 소프트웨어를 선택해야 합니다. Amazon Web Services는 CloudFormation을 제공하고, Microsoft Azure는 Azure Resource Manager를 제공하고, Google Cloud Platform은 Google Cloud 배포 Manager를 제공하는 등 3개의 주요 클라우드 제공업체가 모두 자체 클라우드 제공업체를 보유하고 있기 때문에 이는 어려운 선택이 아닙니다. 벤더 독립적 인 가장 잘 알려진 옵션은 위에서 언급 한 세 가지 클라우드 공급 업체뿐만 아니라 더 많은 것을 지원하는 Terraform입니다.
다음으로, 문서화한 수동 단계를 재현하기 위해 선택한 IaC 도구에 대한 몇 가지 스크립트를 작성해야 합니다. 일반적으로 진행하면서 테스트하는 것이 좋습니다. 즉, 약간의 IaC 코드를 작성하고, 배포하고, 테스트하고, 만족스러우면 다음 코드로 이동합니다. 한 번에 모든 것을 작성하면 코드에서 몇 시간의 작업 후에야 발견할 수 있는 주요 결함이 발생할 수 있으며, 이는 스크립트의 상당 부분을 다시 작성해야 할 수도 있음을 의미합니다.
또한 시프트 레프트(Shift Left)라는 주제가 계속 유행하고 있습니다. 이는 기본적으로 가능한 한 빨리 테스트를 시작하고 문제가 발생한 후 감지하고 해결하는 것이 아니라 문제를 예방하는 데 집중한다는 것을 의미합니다. 결과적으로 전반적인 품질과 보안이 향상될 것이라는 생각입니다.
이상적으로 이 시프트 레프트는 가능한 한 자동화를 활용해야 합니다. 실제로 보안 및 컴플라이언스와 같은 IaC 스크립트 작성의 특정 측면을 자동화하는 데 사용할 수 있는 다양한 도구가 있습니다. 이러한 도구는 배포 전에 코드를 검사하여 잘못된 구성, 지나치게 허용적인 설정 및 알려진 취약성과 같은 문제의 발생을 줄입니다. 이와 관련된 몇 가지 사용 사례는 여기에서 확인할 수 있습니다.
IaC를 제대로 사용하려면 IaC 스크립트를 작성하는 사람이 사용 중인 클라우드 플랫폼에 대해 깊이 알고 있어야 합니다. 따라서 IaC 작업의 가장 중요한 부분은 선임 DevOps 엔지니어가 수행하는 것이 좋습니다.
일반적으로 선임 DevOps 엔지니어(또는 최소 한 명)로 구성된 팀이 IaC 작업을 주도하도록 하는 것이 좋습니다. 이 팀은 모범 사례와 보안에 집중할 수 있으므로 더 많은 주니어 엔지니어가 따를 수 있는 청사진을 제공할 것입니다. 또한 조직 내의 IaC 스크립트에서 재사용할 수 있는 일반 모듈을 작성할 수 있으므로 더 많은 주니어 엔지니어가 쉽게 사용할 수 있는 사전 검증된 구성 요소를 제공할 수 있습니다.
엄격한 보안이 중요하고 그럴 가능성이 가장 높은 경우 이 팀은 공개적으로 사용 가능한 모듈 및 소프트웨어도 검사할 책임이 있습니다. 온라인에서 일부 IaC 모듈을 찾는 것은 매우 쉽습니다. Terraform에는 공식 저장소 도 있습니다. 그러나 공개적으로 사용 가능한 이러한 모듈은 조직 또는 프로젝트 내에 적용되는 보안 표준을 준수하지 않을 수 있습니다. 따라서 IaC 팀에서 검증된 모듈만 사용하도록 하는 것이 중요합니다.
또한 SecOps 팀이 DevOps 팀과 함께 작업하는 것이 좋습니다. 이러한 협력을 통해 프로젝트 초기에 보안 측면에서 DevOps 프로세스를 최적화할 수 있습니다. 프로덕션 배포 후 감지된 오류는 특히 고객 관계 측면에서 매우 비용이 많이 들 수 있습니다. 프로세스 초기에 고품질을 보장하면 이러한 재해를 방지하는 데 큰 도움이 됩니다.
비교적 최근에 개발되었지만, IaC는 오늘날 클라우드 리소스가 필요한 모든 조직의 프로비저닝 전략의 일부가 되어야 하며 최소한 팀 내에 포함되는지 평가해야 합니다. 조직의 규모에 관계없이 IaC가 워크로드의 적어도 일부를 관리하기를 원할 것입니다.
피드백