어디서 들은것은 있어서 terraform 과 거기에 Application 설치를 위한 Helm 을 통해서 코드로 Infrastructure를 관리하면 좋겠다(당연히 좋겠지.. 단, 잘하면..)는 생각이 많았었다. 그래서 무작정(?) 시작했다. 현재 나에겐 DevOps 의 역할도 필요했기에
시작은 일단 내가 생각한 것이 맞는지부터였다.
Terraform 과 Helm 에 대한 이해부터 필요하다고 생각했고, 인터넷으로 무작정 찾아서 하나씩 읽기 시작했다.
Infrastructure as Code
를 실현하기엔 Terraform
이 현재로선 원탑이었다.
다만 이 시점엔 Helm
과의 관계를 어떻게 정의해야 하나? 라는 생각이 있었다.
Terrafrom
이 Helm
(helm_release
resource)을 지원하면서 Terraform
을 통해서 helm chart
의 통합 관리도 가능하겠다는 생각이 들었다.
Devops 관련해서 알아보면서 뭐가 맞는지 최선의 방식을 찾는데 노력했지만 이 적절한 수준을 찾는것이 어려웠다.
Terraform
을 인프라의 기초를 관리하는데 사용하고, Application
은 Helm
으로 관리하는 경우가 꽤 많았다.
즉, helm
명령어를 통해서 chart
를 실행하는 것이었다.
이게 그나마 가장 일반적인 방법이었다.
Terraform
의 경우 인프라가 커지면 커질 수록 실행시간도 비례해서 늘어나는 구조라 디렉토리 분리를 통한 설계가 굉장히 중요해보였다.
근데 알아보는 것도 좋지만, 일단 확정된 방법은 아니지만 시도해보는게 좋겠다는 생각이 들었다. eksctl
, kubectl
, terraform
, helm
, aws cli
등등을 가지고 뭐든 일단 시작해보기로 했다.
앞선 포스팅에서 정리한 내용이 있긴한데, k8s
를 기반으로한 로컬 개발환경은 필수라고 생각되어서 구성원 누구라도 동일한 환경을 쉽게 설정할 수 있도록 작성하는데 초점을 맞췄다.
현재 작성된 것은 온전히 Terraform
만을 활용한 것입니다.
EKS
클러스터를 따로 생성해야 하는가?subnet id
등과 같이 ID 형태로 생성되는 값들을 어떻게 전달 받을 수 있을까?S3
를 써야 하나? 아니면 terraform cloud
??terraform
의 helm resource
를 통해 생성한것들의 결과는 어떻게 전달받을 수 있는가?VPC
내의 subnet
구성은 어떻게 해야 하는가?nginx ingress controller
의 역할을 AWS
에서는 ALB
가 해야할 것 같은데 이건 어떻게 해야하나?AWS
ACM
인증서를 써야 하는데 이건 또 어떻게 생성하고 그 결과를 어떻게 개별 서비스에 적용하는가?route53
에서 생성하고 연동해야할 것 같은데 이것도 당연히 되겠지?aws cli
에 주고 하고 있는데 나중에 정리가 가능할까?EKS
Kubernetes
버전 업데이트는 장애타임 없이 가능하게 하려면 설계단계에서 준비해둬야 하는 것이 있을까?대충 이정도의 생각이 머릿속에 맴돌았다.
이후 하나씩 하나씩 준비과정에서 해결하면서 진행해야할 것 같은데 생각보다 모르는게 많다. 정답을 고른다면 차라리 쉬울 것 같은데, 우리에게 최선의 선택을 해야하는 그 판단을 해야한다는 것이 정말 어려운것 같다.
혹시나 하여 정리하자면 해결해나가는 과정을 기술하기 위해서 정리하는 것이라 뭔가 정답만을 기대하고자 한다면 맞지 않을 수 있습니다.
더군다나 인프라 경험이 풍부한 Devops개발자가 아니라서 혹시나 보신다면 감안해서 보셔야 합니다.