terraform plan 결과에 적용될(추가/변경/삭제) 리소스 주소 목록을 출력하는 프로그램을 만들고 배송하는(delivery) 이야기이다. 그 중에서도 요즘 중요하게 생각하는 배송 이야기에 중점을 두었다.
동기
•
terraform plan 은 리소스 목록만 파악하기에 너무 길다. 중간중간 attributes diff가 포함되어 있다.
•
마지막 요약 통계엔 add/change/destroy 할 리소스 개수만 보여준다. 이름(주소)를 한눈에 파악하기 어렵다.
요구사항
•
terraform state list 는 state의 리소스 목록만 보여준다. 현재 구성(코드) 즉, plan 시 볼 수 있는 리소스 목록에 대해서 볼 수 없다.
•
terrafrom plan 시 terraform state list 와 비슷한 리소스 이름 목록을 보고 싶다.
terraform plan -out=planfile && \
terraform show -no-color -json planfile | \
jq -r '.resource_changes[] | select(.change.actions[0]=="update" or .change.actions[0]=="create" or .change.actions[0]=="create") | .address'
Bash
복사
그래서 좀 뻔한 이야기일수도 있지만,
•
사용하기 편해야한다.
•
만들기도 쉬워야 한다. (이정도면 히스토리에서 꺼내 쓰는게 낫겠다 싶지 않을만큼)
그럼 어떻게 오버킬하지 않고 이 기능을 사용하기 쉽게 만들 수 있을까?
나홀로 아기 프로젝트 
일단 긴 명령을 치지 않기 위해 스크립트에 쓴다. 한 줄 명령 파이프가 아니라 스크립트로 옮겨 적으니, 작은 두 가지 기능도 추가할 수 있었다.
#!/bin/bash
terraform plan -out=planfile
terraform show -no-color -json planfile | \
jq -r '.resource_changes[] | select(.change.actions[0]=="create") | .address' | \
sed 's/.*/\x1b[32m&\x1b[0m/' # Green
terraform show -no-color -json planfile | \
jq -r '.resource_changes[] | select(.change.actions[0]=="update") | .address' | \
sed 's/.*/\x1b[33m&\x1b[0m/' # Yellow
terraform show -no-color -json planfile | \
jq -r '.resource_changes[] | select(.change.actions[0]=="delete") | .address' | \
sed 's/.*/\x1b[31m&\x1b[0m/' # Red
Bash
복사
•
destroy(delete) 할 목록도 출력한다.
•
리소스의 각 행동 타입에 따라 색칠한다(add/change/destroy).
이런 스크립트를 대충 /path/to/terraform-plan-summary 라는 곳에 두고 실행 권한을 추가하면 (chmod +x) 사용할 수 있다. 하지만… 편한가? 난 만족할 수 없다!
짧은 고민
하지만 terraform 엔 그러한 에코시스템을 찾지 못했다. 그럼 terraform 에 커밋을 해야하나? terraform 이 오픈소스인가?(최근 나온 라이센스 변경 문제가 생각났다) 그럼 몽키패치해서 써야 하나? 그 무엇을 해도 현재로썬 오버킬이다. 쉽게 만들어야 한다는 요구사항에 다시 집중하자.
보다 더 짧은 구현
지금까지 만든건 bash 스크립트이기 때문에 “bash 스크립트로 원래 있는 바이너리에 옵션 플래그를 어떻게 추가할지” 찾아봤다. 물론 영혼의 개발 듀오인 chatGPT에게.
(요즘 shareGPT가 잘 동작하지 않아 대화 스레드를 첨부 못하고, 답변으로 준 예시 스크립트를 올린다):
#!/bin/bash
# Check for the custom option
if [[ "$1" == "--option" ]]; then
# Handle the custom option
echo "Custom option detected!"
# You can add any custom behavior here
# Remove the custom option from the arguments
shift
fi
# Call the original command with the remaining arguments
command "$@"
Bash
복사
그리고 bashrc 같은 곳에서 원래 명령을 이 스크립트로 alias 한다:
alias command='/path/to/command_wrapper'
Bash
복사
나는 terraform plan -summary 로 실행되길 바랐기에 스크립트의 조건 부분만 바꿔서 적용했다([[ "$1" == "plan" && "$2" == "-summary" ]]).
이제 나의 로컬에선 terraform plan -summary 가 동작한다!
배송하기!
그럼 이 아기 프로젝트가 끝난 것일까? 아직 이 스크립트는 개선할 점이 많다.
•
planfile 이라는 부산물이 생긴다(스크립트 안에서 plan 출력을 planfile 으로 고정하고 있다).
•
-summary 옵션은 plan 의 다른 옵션과 같이 쓸 수 없다.
외에도 계속 생각하면 개선할 점이 더 많을 것이다. 그리고 그런 것들을 수정하려면 결국 bash 스크립트로는 어렵지 않을까, Go로 작성해야되나 라는 고민이 든다. 그러면 위에서 든 짧은 고민으로 회귀하게 된다. 판단을 해야한다. 다시 생각해도 이건 오버킬이다.
이런 문제들을 해결하고 나의 아기 프로젝트를 개선할 좋은 방법이 뭘까? 우리에겐 오픈소스라는 훌륭한 문화가 있다. 인터넷의 테라폼 개발자/사용자의 집단지성(열정페이)을 활용하자.
)을 활용하자.사실 위에, 문제점이라 판단하고 적어 놓은 개선점들 뿐만 아니라, 이 프로그램 자체도 순수히 나의 필요에 의해서 만든 것이다. 남들은, 실제 사용자는 어떻게 생각할지 모르는 일이다. 피드백이 필요하다.
깃허브 레포를 만들고 푸시하면 오픈소스로써 끝이 아니라는것도 많은 경험을 통해 알고 있다. ‘의미 있는’ 오픈소스가 되려면 사용자가 있어야 하고 피드백과 기여(이슈, PR)를 받아야 한다.
먼저 사용자를 확보하기 위해 배포, 쉬운 설치법이 필요하다. brew 또는 xdg 유틸 구성에 맞는 배포판을 생각했으나, 기존에 경험이 없어 익숙치 않기 때문에 역시 현재의 나에겐 오버킬이다. bash 스크립트를 설치할 수 있는 ‘한 줄’ 짜리 명령으로 대신했다.
wget -qO $HOME/.terraform.d/terraform-plan-summary https://github.com/flavono123/terraform-plan-summary/releases/download/v0.1.0/terraform-plan-summary && \
chmod +x $HOME/.terraform.d/terraform-plan-summary && \
echo "alias terraform='$HOME/.terraform.d/terraform-plan-summary'" >> $HOME/.bashrc && \
source $HOME/.bashrc
Bash
복사
아기 프로젝트 세일즈맨
배’송’(delivery)의 민족입니다.
하지만 여기까지만 해선 사용자가 생기진 않는다. 이 작고 귀여운 나의 아기 프로젝트를 어떻게 쓰게 만들 것인가? 내 서비스에 대한 세일즈가 필요하다. 우선 현재 진행 중인 테라폼 스터디 슬랙에 (굽신굽신) 피드백을 요청해본다.
실제로 사용해본 분이 얼마나 계실진 모르겠다. 어쩌면 brew 배포판 정도로는 만들었어야 썼으려나? 그러다보니 설치법이 정말 쉬운가, 설치하고 싶은가 라는 의문이 들었다. 복붙 명령 한 줄은 쉽지만, brew 같은 잘 알려진 패키지 관리자가 아닌 명령 덩어리는 거부감이 들기 때문이다. 왜냐하면 우선 내가 그렇기 때문에… 벌써 의미 있는 피드백이 하나 생겼다. 이런 것도 수동적인 피드백이라 느꼈다.
그럼에도 고맙게도 설치하고 사용해주신 분이 계셨다. 나와 같은 환경이라 다른 환경(OS 등)에 대한 테스트가 되진 않았지만, 나아가 의미 있는 피드백도 주셨다. 테라폼의 공식적인 기능으로 사용하는 것이 더 편하고 좋다고 느끼는 것은 나 뿐만이 아니었다. 그리고 테라폼 사용자로서 판단은 그래도 된다는 것이니 프로그램 기능 자체에 대한 검증도 어느 정도 된거 아닐까?
재벌집 문도 두드려 보기
•
테라폼은 나의 아기 프로젝트에 비해 큰 프로젝트다. 쫄린다 ㄷㄷ;
•
카펜터를 커밋까지 수월하게 할 수 있던 이유는 그러한 부담이 덜한 것이 한 몫했다.
◦
슬랙에서 karpenter 메인테이너, 기여자들과 이야기하며 안면(??)을 좀 터놨다.
◦
결국 그 사람들이 깃헙 이슈, PR에 많이 등장한다.
◦
나도 자연스럽게 슬랙에 제안을 하고 이슈 생성, (간단한 수정이라) PR까지 이어졌다.
나는 카펜터에 한 이런 기여는 “세계문화유산에 코딱지 묻히기”라고 표현한다(우리 업계엔 이런 좋은 문화가 있ㄷ….). 하지만 지금의 아기 프로젝트는, 비록 작고 귀엽긴 하지만 엄연한 프로젝트이다. 서비스를 제공한다는 세일즈맨의 마음가짐으로 테라폼이란 재벌집에도 팔러 가 본다.
세계문화유산에 코딱지 묻히기”라고 표현한다(우리 업계엔 이런 좋은 문화가 있ㄷ….). 하지만 지금의 아기 프로젝트는, 비록 작고 귀엽긴 하지만 엄연한 프로젝트이다. 서비스를 제공한다는 세일즈맨의 마음가짐으로 테라폼이란 재벌집에도 팔러 가 본다.이런 경험을 복기한 후, 테라폼 슬랙이나 디스코드를 찾아가 좀 떠들고 이슈를 만들어 보기로 한다. 하지만 테라폼 슬랙 워크스페이스를 찾진 못했다.
이슈도 “plan list resources” 같은 키워드로 찾아봤으나 찾진 못했다. 애초에 열린 이슈가 너무 많디(1.7k…)
바로 이슈 생성 ㄱㄱ
잘 보이기 위해 이미 만들었던 gif 설명이 있어 쉽게 제안할 수 있었다. 또 아기 프로젝트 그 자체로 기능에 대한 프로토타입이기 때문에 설명은 잘 된거 같다(언제 보려나…)
그리고 위에선 자꾸 오버킬이라고만 했던, 테라폼 PR을 만들기 위한 Go 코딩을 하는 것도, 스스로에겐 동기부여차, 목표로써 써 놓았다. 만약 테라폼에 기여할 수 있다면, 나에겐 더 이상 오버킬은 아니다.
신흥 재벌집(?)도 한 번…?
테라폼은 최근 라이센스를 변경했다. 그러면서 비상업 라이센스의 포크 버전인 OpenTofu가 등장했다. 여긴 이름부터 확실하게 오픈소스이고 이런 상황도, 나에겐 기여하기 더 쉬운 기횔거란 생각이 들었다.
슬랙도 운영하고 있어서 위 초대 링크로 가입했다.
열린 이슈도 상대적으로 훨씬 적었다(80여개). 오래 전에 열린 이슈 중 조금 다르지만 비슷한 제안이 이미 있었다:
plan/apply 의 결과가 너무 장황하니 짧게, 간결하게 그려주자는 제안이다(-short/consice). 그러다 다른 세일즈맨도 만났다.
오~ 나는 alias로 쓰고 있는 tf 라는 이름 자체가 프로그램 모토이다.
Less verbose and more shell friendly Terraform.
버전도 꽤 올랐고 나의 아기 프로젝트보단 좀 더 성숙해보인다. 하지만 나의 세일즈를 멈출 순 없지! 코멘트에 나의 terraform-plan-summary 도 살포시 달아 놓았다. 그럼에도 성에 차지 않아 이슈를 새로 열었다:
테라폼 포크라서 이슈 포맷도 똑같아서, 위의 테라폼 것을 거의 복붙하였다.
그리고 여기 내 블로그를 통해서도 홍보합니다:
TODO
앞으로의 대응은 크게 세가지로 갈릴 것 같다.
•
테라폼이나 OpenTofu 바이너리로 빌드할 수 있는 기능으로 만들어 PR 해보기
◦
plan -summary 가 정말 필요한 기능이라는 확신이 있어야 한다.
•
세일즈 더 해보기
◦
커뮤니티 더 찾아보기. 페이스북? 오픈 카톡?
•
만족하기(이미 의미 있는 아기 프로젝트이다!)
◦
사용하다 불편한 점이 느껴질 때 다시 추진 동력을 얻기
습득 교훈
우선 둘의 조건이 다르다.
•
파이썬 패키지는 pip 라는 꽤 쉬운 배포 방법이 있지만, terraform 은 CLI 기능 추가에 있어 그런 것이 없다.
•
파이썬은 당시에 주력으로 하고 있었지만, 현재 Go는 그렇지 않다(이걸 계기로 제대로 해보고 싶다).
이번 프로젝트 배포(의미 있는 기여)가 맘에 들지 않아 바라본 변명일 수도 있다. 그리고 최근엔 코딩보다 만든 결과물을 전달하고 피드백을 받고 개선하는 것을 열심히한다.
그래야 의미 있고, “살아 있는” 코드가 되기 때문이다. 개발자를 처음 시작했을 땐 테스트하고 규칙이나 정책을 자동으로 적용하는 “통합”(integration)에 관심이 많았다. 코드가 살아 있다는 느낌을 받았기 때문이다. 하지만 요즘은 그 뒤의 과정인 “배송(delivery)”에 더 관심이 간다.
(규모가 꽤 큰) 업무에선 이를 각각 CI/CD라 부르고, delivery엔 모니터를 잘 하기 위한 가시성 확보가 중요하다. 하지만 이런 작은 프로젝트에선 정량적인 메트릭이 아닌, 정성적인 피드백 하나하나가 중요하다 여겨진다. 그래서 아무리 작더라도 내가 만든 것의 “세일즈 엔지니어”까지하며 코드를 살아 있게 하고 싶다. 작은 규모의 개인 프로젝트에선 이 부분 마저 delivery라 느껴진다. 이런 것을 자동화 할 수 있다면(CD) 그것도 멋있는 일이 될 것 같다 .
. 나의 가설처럼 이러한 작은 프로젝트에선 세일즈가 중요할지, 아니면 좀 더 기능 개발 자체에 집중할지는 계속 실험해 볼 것이다.