답변:
TL; DR : 코드로서의 인프라 는 환경을 자동화하고 백업하는 방법입니다. 이상적인 경우, 재난 후 새로운 리소스 프로비저닝, 코드 리포지토리에서 구성 복원 및 백업에서 데이터 복구를 통해 인프라를 완전하고 자동으로 복원 할 수 있습니다 .
Code as Infrastructure는 세 가지 주요 개념에 의존합니다.
라는 구성 관리 자동화prof가 개척 한 필드 Continuous Configuration Automation 자동화 . 마크 버지스
코드 리포지토리인프라 변경에 대한 . 변경 내용을 먼저 커밋, 문서화, 검토, 테스트 한 다음 자동화를 통해 배포합니다.
관리 형 인프라 프로비저닝. IaaS ( Infrastructure as a Service ). 어느 쪽을 통해 클라우드 컴퓨팅 , 개인 또는 관리되는 클라우드 또는 관리 데이터 센터 서비스
구성 관리는 3 세대 도구에 있습니다. CFEngine을 기반으로 자동화 된 구성 관리를위한 새로운 도구 세트가 현재 널리 배포되고 있습니다. 알파벳순으로 가장 인기있는 것은 Ansible, CFEngine, Chef, Puppet, PowerShell DSC 및 SaltStack 입니다. 각각에는 인프라 상태를 설명 하는 언어 , 이러한 변경 사항을 적용하고 도구, 일부 에이전트 를 확장하는 기능을 제공하는 코드 모듈 이 있습니다. , 서버에서 를 실행하는 및 중앙 정보 저장소 가 있는 .
이들은 일반적으로 중앙 위치에서 서버에 연결하고 변경 사항을 원격으로 실행하거나 각 서버에서 실행하며 중앙 위치에서 그리고 클라이언트 / 서버 모델 또는 분산에서 상태에 대한 정보를 가져 오는 푸시 또는 풀 모드로 작동합니다. 방법.
중요한 개념은 시스템 관리자 또는 사이트의 신뢰성 엔지니어입니다 직접 변경하지 인프라에 있지만, 자동화 변경을 할 수 있습니다. 사람 이 수동으로 수행 한 모든 작업 은 부패하기 쉬운 것으로 간주되며, 자동화를 통해 곧 다시 수정되거나 인프라 의 무결성 을 위반 하고 영향을받는 구성 요소의 파괴 및 재건을 유발하는 보다 엄격한 형태로 수정되어야합니다 .
Repository 보유 소프트웨어와 이상적으로 분리 된 Code Repository는 인프라 및 관련 자동화의 모든 변경 사항을 관리하는 데 사용됩니다. 구성 파일 및 템플릿, 검토 할 변경 프로세스를 설명하는 Playbook (Cookbook), CM 자동화 도구 확장 코드, 프로비저닝 구성, 인프라 테스트 및 경고, 준비 / 배포 테스트, 설명서, 수동 (아직 자동화되지 않음) 프로세스 설명 .
중요한 개념은 변경 사항에 대한 동료 검토를 실시하고, 모든 변경 사항을 기록하고, 예측할 수 없거나 테스트되지 않은 문제가 발생할 경우 자동으로 이전 상태로 되돌릴 수있는 능력, 준비 환경에 배포하는 기능 및 구성 변경을 테스트하는 기능, 자동 배포하는 기능입니다 인적 오류로 인한 변동없이 변경됩니다.
물리적 인프라 관리는 소프트웨어를 뛰어 넘어 매우 다양한 기술이 필요한 실제 작업입니다. Cloud Computing 또는 Managed Datacenter를 통해이 계층을 추상화 할 수 있으므로 팀은 비즈니스 가치를 추가하는 인프라 관리에 중점을 둡니다.
클라우드 컴퓨팅은 이후 단계에서 빠르게 시작하고 확장 할 수있는 방법을 제공하지만 회사는 종종 하이브리드 모델을 위해 자체 데이터 센터에서 인프라의 일부를 이동할 때 몇 가지 이점과 상당한 비용 절감 효과를 실현합니다. 하드웨어를 소유하거나 임대한다고해서 하드웨어를 관리하는 사람들도 고용해야한다는 의미는 아닙니다. 이 규모에서는 전 세계에 지리적으로 분산 된 데이터 센터가 필요하며 모든 장소에서 필요한 기술을 모두 갖춘 사람들은 매우 비쌉니다. 전 세계로 날아 가면 변경 사항과 운영 비 효율성이 높아 지므로 대기 시간이 길어 지므로 데이터 센터 관리를 아웃소싱하는 또 다른 이유입니다.
중요한 점은 Managed Physical Infrastructure 가 종종 잊혀지거나 간과되는 개념 이지만 중요합니다. 당신이 모든 자동화있어하더라도, 모든 구성은 당신이 할 수있는 방법이없는 경우, 백업 된 코드 저장소에 저장 빠르게 조항을 , 당신은이 거대한 병목 현상이 쉽게 수 있는 모든 혜택을 지우고 다른 두 단계로 당신은 벌었을 .
정확히 무엇인지 설명하기 전에 Wikipedia 에서 직접 멋진 정의를 인용하겠습니다 .
IaC (Infrastructure as Code)는 물리적 하드웨어 구성 또는 대화식 구성 사용이 아니라 기계 처리 가능 정의 파일을 통해 컴퓨팅 인프라 (프로세스, 베어 메탈 서버, 가상 서버 등) 및 해당 구성을 관리하고 프로비저닝하는 프로세스입니다. 도구.
자, 이제 개념을 더 잘 이해하기 위해 Terraform과 같은 IaC 도구 중 하나를 살펴 보겠습니다 : https://www.terraform.io/
또한 이것은 Terraform이 자신에 대해 말하는 것입니다.
Terraform을 사용하면 생산 인프라를 안전하고 예측 가능하게 생성, 변경 및 개선 할 수 있습니다. 이 도구는 API를 코드로 처리하고 편집, 검토 및 버전 관리하는 팀 구성원간에 공유 할 수있는 선언적 구성 파일로 API를 체계화하는 오픈 소스 도구입니다.
즉, 전체 인프라를 코딩 할 수 있습니다. 여기에는 서버 인스턴스,로드 밸런서 등과 같은 클라우드 (/ 인프라) 리소스의 작성과 함께 전체 구성 (기본 설정 조정, 보안 설정, 리전 등)을 코드로 포함하는 편집 가능한 버전 및 물론 검토 가능합니다.
다음은 AWS 리소스 프로비저닝을위한 Terraform 코드의 샘플 예입니다.
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
보너스 PS : 또한 프로비저닝 도구 와 오케스트레이션 도구 의 차이점을 이해해야합니다 . 개발자는 하나를 자주 혼동하며 사용하지 않는 도구를 수정하고 사용하려는 실수를 저지르는 경향이 있습니다.