Infrastructure as Code ( IaC )
내가 IaC에 대해 알게된건 회사에서 aws의 강태호님과 미팅을 하게 되었을 때다.
기존에 회사에선 aws 인프라를 수동으로 관리하고 있었다
고객사의 프로젝트가 마무리되어서 인프라를 세팅해줄 때마다 aws console에 들어가서 수동으로 인프라를 세팅해줬다...
몇번 하다보니 귀찮아져서 문서화를 해두고 사내 위키에 올려둔 뒤 가끔 다른 개발자 분들이 어려워 하실때 만 도와주러 갔다.
하지만 이 방법도 내가 시간을 안쓸 뿐이지 다른 분들이 쓰게 만드는 해결책이였다.
IaC에 대해 알게되고 테라폼 강의를 인프런에서 봤다. 거기서 강사님이 이런말을 한게 기억난다.
IaC의 제일 좋은 도입 시기는 IaC라는 것에 대해 아는 순간이다.
그때 강의를 들을때나 지금이나 그리고 미래에도 이 말에 대해 전적으로 동의한다.
Infrastructure as Code(IaC) - 코드로 인프라를 관리
수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말한다.
즉 인프라 구성, 관리를 마치 소프트웨어를 프로그래밍하는 것 처럼 처리한다.
버전 관리도 중요하다, 다른 소프트웨어 코드들 처럼 버전 관리 시스템을 이용해서 관리해야한다.
수동으로 인프라를 관리했을 때의 단점
-
서론에서 제 경험을 말했듯이 보통 메뉴얼을 만들고 관리를 할텐데 aws console이 업데이트되어 UI가 바뀐다면?
- 문서도 다시 업데이트를 해줘야함..
-
기존에 구성되어있는 인프라에 대해 다른사람이 건드릴 일이 있다면?
- 문서화가 잘 되어있지 않다면 어디에 어떤 리소스가 있는지 하나하나 찾아봐야함
-
똑같은 형태 혹은 비슷한 형태의 인프라를 재구성할 때 손으로 일일히 다시 ..
- 반복되는 노가다
이를 해결해주는 IaC의 이점
-
원래 인프라를 수동으로 프로비저닝하는 것은 시간이 많이 드는 일, 코드로 한 번 작성 해놓고나면 자동화가 된다.
- aws console이 업데이트가 되던 말던 코드는 그대로 사용 가능
-
IaC는 인프라의 구성 사양을 코드화하고 문서화함으로써 따로 인프라 구성 및 변경에 대한 문서화를 하지 않아도 된다
- 어디에 어떤 리소스가 있는지 코드를 통해 확인이 가능함
- 우리가 수동으로 직접 구성했을 때 누락하거나 잘못 설정하는 실수하는 경우를 방지
- 일관성이 향상된다.
- 복제가 쉽다.
IaC 도구들
- Terraform, Aws CloudFormation, Aws CDK
- Ansible, Chef, Puppet, Saltstack
1과 2의 차이가 살짝 있다. 서로 다른 목적으로 만들어졌다
Terraform과 CloudFormation ( 1번 )은 프로비저닝 도구이며, 2번은 구성 관리 도구이다.
1번은 인프라를 처음부터 설정하고 구성하는 것 이고 2번은 이미 구성된 인프라를 업데이트한다.
몇몇 기능들이 중복되는게 있긴 하지만 보통 1번과 2번을 같이 사용한다.
Terraform으로 ec2를 띄우고 ansible로 해당 ec2에 필요한 패키지를 설치한다던지 하는 방식으로 말이다.
나는 2 - terraform, cdk, ansible밖에 사용경험이 없어서 잘못 분류했을 수도 있다..