Show HN: Layerform – Terraform 파일을 사용하는 오픈 소스 개발 환경

Layerform은 더 이상 활발하게 유지 관리되지 않습니다. Ergomake는 이제 Briefer로 변경되었습니다.

Layerform은 엔지니어가 일반적인 .tf 파일을 사용하여 재사용 가능한 환경 스택을 생성할 수 있도록 돕습니다.

HashiCorp가 더 이상 MPL 라이선스를 사용하지 않겠다고 발표함에 따라, 저희는 OpenTF를 기반으로 구축할 예정입니다.

Layerform은 엔지니어가 일반적인 Terraform 파일을 사용하여 재사용 가능한 인프라를 구축할 수 있도록 돕는 Terraform 래퍼 (wrapper)입니다.

재사용을 가능하게 하기 위해, Layerform은 레이어 (layers) 개념을 도입합니다. 각 레이어는 특정 인프라를 포함하며, 다른 레이어 위에 쌓아 올릴 수 있습니다.

사용하기 훨씬 쉬울 뿐만 아니라, Layerform을 통해 팀은 인프라의 핵심 요소들을 재사용할 수 있습니다. 이를 통해 개발 인프라를 훨씬 저렴하고 빠르게 생성할 수 있습니다. Layerform을 사용하면 엔지니어는 자신에게 필요한 인프라 레이어만 생성하면 됩니다.

개발 환경을 원하는 분들을 위해 말씀드리자면: 저희는 여러분의 텍스트 에디터 (text-editor)를 실행하려는 것이 아닙니다. Layerform은 개발 인프라를 위한 표준 도구입니다. 여러분은 기존처럼 텍스트 에디터, IDE, 그리고 기타 로컬 개발 도구들을 자신의 머신에서 직접 계속 사용할 수 있습니다.

Layerform은 각 엔지니어마다 전체 staging 환경을 생성하는 것보다 훨씬 저렴하고 빠릅니다.

Layerform을 사용할 때, 엔지니어들은 동일한 인프라 핵심 요소들을 공유할 수 있으며, 그 위에 자신에게 필요한 레이어만 생성할 수 있습니다.

예를 들어, Kubernetes 클러스터에서 애플리케이션을 실행하는 경우, 각 엔지니어의 환경을 위해 매번 새로운 클러스터를 생성할 필요가 없습니다. 대신, 동일한 클러스터를 재사용하여 여러 엔지니어가 그 위에 자신들의 애플리케이션을 실행할 수 있습니다.

Layerform의 환경은 일반적인 .tf 파일로부터 생성되기 때문에 운영 (production) 환경과 동일합니다.

.tf 파일을 사용하여 설정할 수 있는 것이라면 무엇이든 Layerform 레이어에서 설정할 수 있습니다.

그 결과, 여러분의 개발 인프라는 Lambda, DynamoDB 인스턴스 및 기타 필요한 모든 것을 포함하여 운영 환경과 똑같을 것입니다.

Layerform은 여러분의 인프라 내에서 실행됩니다. Layerform은 상태(state)를 저장하고 여러분의 클라우드 제공업체(cloud providers)에 리소스를 생성합니다. 따라서 누가 무엇에 접근할 수 있는지, 현재 어떤 리소스가 실행 중인지, 그리고 비용이 얼마나 발생하는지에 대해 여러분이 완전한 제어권을 갖게 됩니다.

인프라를 레이어(layers)로 분리함으로써, 조직은 팀 간의 경계를 더 명확하게 정의할 수 있습니다. 결과적으로, 조직의 구조를 시스템의 구조로 미러링(mirror)하는 것이 더 쉬워질 것입니다.

인프라를 재사용하여 비용을 절감하는 것 외에도, Layerform을 사용하면 각 레이어 인스턴스(layer instance)에 대한 비용을 자동으로 추적할 수 있습니다.

레이어를 적용할 때, Layerform은 생성된 리소스에 레이어 인스턴스에 할당된 실제 이름을 자동으로 태그(tag)합니다. 예를 들어, production 및 development 베이스 레이어(base layers)가 있다면, 이 두 레이어 각각은 각자의 이름이 담긴 layerform_layer_name 및 layerform_layer_instance 태그를 포함하게 됩니다.

이러한 방식을 통해 Layerform은 레이어의 리소스를 재귀적으로 탐색하여 비용 관리 정보를 수집할 수 있습니다. 결과적으로, 전체 production 및 development 레이어의 비용뿐만 아니라, 해당 레이어들 위에 구축된 모든 요소에 대한 통합 비용 보고서(aggregate cost report)를 제공할 수 있습니다.

먼저, Layerform CLI를 설치하세요.

$ go install github.com/ergomake/layerform@latest

그런 다음, 인프라의 각 레이어를 생성하는 데 사용할 Terraform 파일을 생성합니다. 아래 예시에는

그 후 Layerform CLI가 각 레이어에 대한 고유 ID를 생성하고, Terraform 파일의 내용을 Layerform 백엔드(이 경우에는 S3 버킷)로 전송하는 작업을 처리합니다.

레이어 정의(layer definitions)를 프로비저닝(provisioning)한 후에는 다음 명령어를 사용하여 해당 특정 레이어의 인스턴스를 생성할 수 있습니다.

layerform spawn <definition_name> <desired_id>

$ layerform spawn services my-dev-infra

레이어의 각 인스턴스는 해당 레이어의 파일 내에 정의된 모든 인프라 구성 요소를 포함합니다.

이 예시에서는 해당 명령어를 실행하면 Layerform이 하위 eks 레이어의 인스턴스도 생성하고, 해당 인스턴스에 default라는 ID를 할당하게 됩니다.

또 다른 services 레이어를 생성하려면 layerform spawn services another-dev-infra를 실행하기만 하면 됩니다. 기본적으로 Layerform은 ID가 default인 하위 레이어를 베이스 레이어(base layers)로 사용하려고 시도합니다.

일반적인 규칙으로, 하위 레이어는 항상 ID가 default인 레이어입니다. 각 하위 레이어에 대해 원하는 ID를 지정하려면 --base 파라미터를 사용해야 합니다. 예를 들어:

# 다음을 생성합니다:
# 1. ID가 "one"인 eks 레이어
# 2. ID가 "two"인 services 레이어
...

레이어는 자기 자신 또는 자신보다 위에 있는 레이어만 변경(mutate)할 수 있습니다. 예를 들어, base 레이어와 backend 레이어가 있다면, backend 레이어의 Terraform 파일은 base 레이어 인스턴스의 인프라를 변경할 수 없습니다. 그럼에도 불구하고, base 레이어 파일은 자신보다 위에 있는 레이어의 모든 인스턴스를 변경할 수 있습니다.

Layerform이 원치 않는 변경을 방지하는 방법은 각 terraform plan을 분석하여 변경 대상이 하위 레이어에 속하는지 감지하는 것입니다.

Layerform이 레이어가 하위 레이어를 변경하는 것을 방지하는 이유는 형제(sibling) 인프라 구성 요소들이 손상되는 것을 피하기 위해서입니다.

이러한 설계 덕분에 플랫폼 팀은 레이어 인스턴스를 자신들의 레이어 위에 "리베이스(rebase)"할 수 있습니다. 예를 들어, base에 속한 Kubernetes 클러스터 위에 여러 애플리케이션 레이어가 있다고 가정해 봅시다.

레이어 (layer)입니다. 이 경우, 플랫폼 팀이 Kubernetes 버전을 업데이트하고 기존 애플리케이션의 매니페스트 (manifests)를 패치해야 한다면, 다른 Terraform 리소스 (resources)를 참조하고 패치함으로써 자신들의 레이어에서 이를 수행할 수 있습니다.

반면에, 상위 레이어에 있는 제품 엔지니어 (product engineers)들은 Kubernetes 클러스터를 포함하는 base 레이어를 수정할 수 없습니다. 그렇지 않으면 다른 모든 사람의 애플리케이션을 망가뜨릴 수 있기 때문입니다.

불변성 (immutability)은 장애를 방지할 뿐만 아니라, 팀 간의 더 명확한 통신 인터페이스를 정의하며 조직이 수많은 측면 채널 (lateral channels)을 피할 수 있도록 도와줍니다.

Layerform은 두 가지 주요 구성 요소로 이루어져 있습니다. Layerform 백엔드 (Back-end)와 Layerform CLI입니다.

Layerform CLI는 각 레이어의 이름 및 의존성 (dependencies)과 같은 모든 메타데이터 (metadata), 그리고 해당 레이어와 관련된 모든 Terraform 파일들을 Layerform 백엔드에 프로비저닝 (provision)하는 데 사용됩니다.

Layerform 백엔드는 각 레이어 정의에 대한 데이터를 저장하며, 새로운 레이어가 어떤 베이스 상태 (base state)를 사용해야 하는지 알 수 있도록 각 레이어 인스턴스 (instance)의 상태 (state)를 저장합니다.

백엔드에는 여러 유형이 있을 수 있습니다. 가장 일반적인 백엔드 유형은 데이터를 로컬에 저장하는 local과 클라우드의 S3 버킷 (S3 bucket)에 데이터를 저장하는 s3입니다.

마지막으로, Layerform CLI는 적용하려는 레이어의 파일과 하위 레이어의 상태를 가져오기 위해 Layerform 백엔드와 통신합니다.

Layerform CLI가 올바른 기존 레이어 위에 새로운 레이어를 생성하는 방식은 각 레이어를 적용할 때 하위 레이어의 상태를 주입 (injecting)하는 것입니다.

Layerform의 주요 목표는 엔지니어들이 인프라의 서로 다른 부분들을 최대한 쉽게 생성하고 공유할 수 있도록 만드는 것이었습니다. 이를 통해 조직에 불필요한 비용이나 복잡한 설정 파일 (configuration files)의 부담을 주지 않으면서도, 팀들이 스스로의 환경을 구축할 수 있도록 권한을 부여하고자 합니다.

Layerform을 개발하면서, 우리는 서버리스 (serverless) 애플리케이션을 위한 인프라를 포함하여 사실상 모든 유형의 인프라를 지원해야 한다고 판단했습니다. 이것이 우리가 Kubernetes/Helm을 지원하고 이미 모든 주요 퍼블릭 클라우드 (public clouds)에 대한 프로바이더 (providers)가 구축되어 있는 Terraform의 커뮤니티 포크 (community fork) 위에 래퍼 (wrapper)를 만들기로 결정한 이유입니다.

셋째, 우리는 Layerform이 단순하고 직관적이어야 한다고 결정했습니다. 엔지니어들이 Layerform을 사용하기 위해 새로운 독점 언어나 설정 형식 (configuration formats)을 배울 필요가 없어야 합니다. 가능한 한, 그들이 기존의 설정들을 재사용할 수 있도록 허용해야 합니다. 엔지니어들이 배워야 할 유일한 것은 Layerform의 개념뿐입니다. 그 외의 모든 것은 "그저 Terraform"이어야 합니다.

마지막으로, 우리는 Layerform이 개방적이고 자유로워야 한다고 결정했습니다. 이것이 우리가 래퍼에 GPL 라이선스를 사용하고 커뮤니티에서 유지 관리하는 포크를 사용하는 이유입니다. 또한 Layerform으로부터 가치를 추출하기 전에 반드시 무언가에 비용을 지불할 필요가 없는 이유이기도 합니다.

투명성을 위해 말씀드리자면, 우리가 향후 수익을 창출하고자 하는 방식은 거버넌스 (governance), 관리 (management), 그리고 비용 제어 (cost-control) 기능을 갖춘 매니지드 서비스 (managed service)를 제공하는 것입니다.

만약 Layerform 래퍼 자체를 번들 (bundle)로 묶고 싶다면, GPL 라이선스가 우리와 커뮤니티가 가치를 돌려받을 수 있도록 보장할 것입니다.

2023년 8월 22일부로, 우리는 엔지니어들이 제품을 어떻게 사용하는지 이해하고 그에 따라 제품을 개선할 수 있도록 CLI에 텔레메트리 (telemetry)를 도입했습니다.

텔레메트리를 비활성화하려면, 환경 변수 (environment variable) LF_TELEMETRY_DISABLED를 1로 설정하십시오.

Layerform의 사용자들과 유지 관리자들은 GitHub Discussions에서 찾을 수 있습니다. 그곳에서 Layerform 설정 방법, 로드맵 (roadmap)에 대한 질문, 그리고 기타 관련 주제들에 대해 논의할 수 있습니다.

또한 우리의 Discord 서버를 통해 직접 (그리고 더 빠르게) 연락할 수 있습니다.

Layerform은 오픈 소스 (open-source)입니다.

GNU GPLv3 라이선스에 따라 라이선스가 부여됩니다.

Layerform은 Terraform과 관련이 없습니다. Terraform은 HashiCorp, Inc.의 등록 상표입니다.