Waypoint란?
Waypoint 는 Vault와 Terraform으로 유명한 헤시코프사에서 새로이 출시한 CD와 가까운(?) 서비스 입니다.
다만, 기존의 CD툴들은 대체로 git과 통합하여 완전히 자동화된 파이프라인 기능을 제공하지만 waypoint는 파이프라인 보다는 개발자 편의성을 높여주는 기능이 많습니다.
가령 배포한 서버 로그를 별도 설정 없이 바로 보거나, 배포한 서버에 바로 접근 할수 있는 기능등 기존의 CD 서비스에 잘없는 편의성을 극대화 한 느낌을 받았습니다.
그래서 공식 문서에서는 파이프라인 구성을 위해 다른 CI/CD와 어떻게 연동하는지 예시와 함께 자세히 적혀있었습니다.
사실 쓰다보니 waypoint는 Github Action이나 CirclCI 와 비교 하기 보단 AWS Lightsail 혹은 AWS Elastic Beanstalk 와 비교해보는게 좋겠다고 생각 들었습니다.
특화 기능
대부분의 CI/CD는 다양한 환경에 대한 손쉬운 파이프라인 구축을 핵심 기능으로 제시 하는 반면 waypoint가 제공하는 기능을 보면 다른 것들과는 다르다는것을 느낄수 있으실 겁니다.
바로 개발자가 운영시 필요한 기능을 통합적으로 제공 하는 것입니다.
가령 여러분들이 서비스를 배포할경우 어떤것이 필요하다 생각 하시나요?
먼저 서비스를 배포 했으면 사용 하기 위해 접근할수 있는 주소가 필요할 것입니다.
그리고 누군가 서비스를 사용한다면 여러 서버에서 내뿜는(?) 로그를 볼수 있어야 겠죠.
또 만약 버그가 있을 경우 특별한 상황에선 해당 컨테이너에 붙어 분석 할수 있어야 할것입니다.
waypoint는 이러한 사소하지만 꼭 필요한 기능을 제공하여 개발자가 진정한 devops가 될수 있게 도와줍니다!
•
URL Service
서비스 배포후 외부 에서 접근 가능한 url을 만들어 줍니다. Let's Encrypt를 통해 TLS가 적용된 waypoint.run 의 서브 도메인을 발급해 줍니다.
쉽게 말해 ngork같은 서비스라고 보시면 됩니다. 개발 활경에서 매우 유용한 기능인것 같습니다.
•
Application Logs
앱에서 표준 출력 및 표준 오류로 기록되는 것을 캡쳐하여 개발자가 cli나 ui를 통해 볼수 있게 해줍니다.
다만, 데이터도그 같은 서비스를 대체 하기 보단 단기간 내에 디버깅을 위한 용도로만 제공 됩니다.
그래서 어플리케이션 인스턴스당 16,000줄로 제한되며 현재는 제한을 풀수가 없습니다.
또한 로그는 프로메테우스나 엘레스틱 서치 처럼 특정한 곳에 모이는것이 아닌 어플리케이션 인스턴스 메모리에 저장됩니다.(최대 약 1.6MB를 잡아 먹는다 합니다)
이러한 제한에도 불구하고 개발 환경에선 자주 쓰이는 기능 일거 같습니다.
•
Exec
도커의 그 exec를 생각 하시면 됩니다. 다만 로컬이 아닌 해당 프로젝트의 외부에 배포된 컨테이너에 실행 한다는 점에서 차이가 있습니다.
기존에도 충분히 가능 했지만 실제로 하려면 번거로운 작업들을 했어야 하는데 단순히 cli 명령어 하나로 바로 사용 할수 있는 것이 좋은거 같습니다.
Application Lifecycle
waypoint의 라이프사이클은 크게 3가지로 구성됩니다.
•
Build
가장 첫번째 단계로 어플리케이션을 빌드합니다. 도커 이미지를 빌드 하거나, 압축 파일 형태로 만드는등 배포할 코드를 패키징 하는 작업이 여기에 포함 됩니다.
현재는 주로 도커 이미지 및 ec2 ami 빌드 밖에 없지만 플러그인 방식으로 확장이 가능하여 향후엔 람다나 cdk 빌드도 생기지 않을까 추측합니다.
참고로 도커의 경우 빌드후 이미지를 푸시하는 과정도 빌드에 포함됩니다.
•
Deploy
인스턴스에 코드를 배포 하는 단계로 ec2, ecs, k8s등에 서버를 배포합니다.
•
Release
배포한 서비스에 실제 엔드포인트를 달아주는 단계입니다. 엔드포인트에 대한 설정과 어떻게 구성할지를 명세합니다.
HandsOn!
환경 구축하기
waypoint 설치하기
brew tap hashicorp/tap
brew install hashicorp/tap/waypoint
Shell
복사
여기에서 운영체제별로 설치 방법을 확인 할 수 있습니다.
waypoint 서버 설치하기
waypoint는 기본적으로 서버가 필요합니다.
waypoint install --platform=kubernetes -accept-tos
Shell
복사
명령어를 실행하니 로컬에 설정된 기본 쿠버네티스에 waypoint pod이 생긴걸 확인 할 수 있었습니다.
참고로 StatefulSet이어서 Fargate에는 못돌릴것 같습니다.
web UI 띄워보기
waypoint에는 젠킨스처럼 프로젝트를 관리 할수 있는 웹기반 콘솔을 제공합니다.
#이것을 실행하면 콘솔에 접속 가능 합니다.
waypoint ui
# 웹페이지에서 Authenticate 버튼을 누르고 아래 명령어로 토큰을 발급하여 인증을 완료하면 됩니다.
waypoint token new
Shell
복사
인증을 완료하면 프로젝트 페이지가 나오는데 아직 아무것도 만들지 않았기에 waypoint init 하라고 알려줍니다.
K8S 배포해보기
waypoint init
Shell
복사
init을 하면 아래와 같은 샘플 파일이 생성 됩니다. 아래와 같이 변경 해봤습니다.
project = "GreeterGrpc"
app "web" {
labels = {
"service" = "GreeterService",
"env" = "dev"
}
build {
use "docker" {
buildkit = true
}
registry {
use "aws-ecr" {
region = "ap-northeast-2"
repository = "waypoint-k8s"
tag = "latest"
}
}
}
# Deploy to kubernetes
deploy {
use "kubernetes" {
replicas = 3
}
}
release {
use "kubernetes" {
load_balancer = true
port = 50051
}
}
}
Plain Text
복사
그럼 바로 배포를 해보겠습니다. 참고로 waypoint에서 up이란 명령어는 빌드,배포,릴리즈를 한번에 해주는 명령어 입니다.
배포를 한뒤 waypoint ui로 접속 해보면 아래와 같이 배포 상태를 확인 할수 있습니다. 로그 역시 잘 뜨네요
각 탭별로 눌러보면 아래와 같이 자세히 나오는 것을 볼 수 있었습니다.
빌드 탭
배포 탭
릴리즈 탭
실제로 grpcui를 통해 요청을 날려보니 잘 되는것을 확인했으며 로그 역시 실시간으로 확인 할 수 있었습니다.
그래서 써보니 어떤가요?
넌 개발만해 나머진 내가 알아서 할게
사내에 전담 devops팀이 없다면 waypoint는 정말 매력적으로 다가올 것입니다. 개발 환경에서 필요하지만 개별적으로 구축하려면 귀찮은 기능들을 알아서 제공 해주니 까요.
작은 서비스, 스타트업, 해커톤 등에선 정말 편할거 같습니다.
혹시 떠오르는 제품굼 없으신가요? 맞습니다.. 바로 글 초반에도 언급한 AWS Lightsail 과 AWS Elastic Beanstalk 입니다.
두개 모두 개발자가 개발한 서버를 손쉽게 배포 확장시켜주고 부가적인 운영 편의성을 제공합니다. 아직은 기능이 많지 않기에 저 두개 같은 서비스를 aws에 제한 되지 않고 다른 플랫폼에도 쓸수 있다고 생각 하시면 됩니다.
실제로 헨즈온을 해보며 느꼇던 기분 역시 EB와 비슷 했습니다. 원래 쿠버네티스에 서비스 올릴려면 pod, service, deployment등을 작성 해야 했는데 단 몇줄로 이것을 모두 처리해주니.. waypoint를 처음 쓴느 저조차 5분안에 서비스 배포를 할 수 있었습니다.
어떤이에겐 동충하초 이나 어떤 분에겐 기생충...(Waypoint Entrypoint)
형이 왜 거기서 나와?
저는 처음에 waypoint가 단순이 개발자가 구성한 대로 수동적으로 작동하는 배포툴인줄 알았습니다.
다만, 대체 어떻게 작동하길레 로그도 알아서 가져오고 서버에 바로 붙을 수 있는지 궁금하였습니다.
보통 서버 로그를 수집하기 위해 별도의 사이드카나 로그 수집 서비스를 같이 구축 했어야 하는데 waypoint는 그냥 짠 하고 해주니까요 ㅎㅎ
비밀은 바로 여러분이 빌드한 이미지에 편의 기능을 알아서 포함 해주는 것이었습니다.
쉽게 표한하자면 k8s에서 사이드카에다 달릴 법한 기능이 이미지에 빌드시에 자동으로 포함되는 것입니다.
이는, 어떤 분들에게 부정적으로 다가 올수 있습니다. (물론 원하면 편의 기능을 꺼서 포함 안되게 설정 가능합니다. 다만 waypoint의 최대 매력이 사라 지다 보니..흠좀무...)
사이드카라는 것도 보통 원래 서비스를 건드리지 않고 특정 기능을 제공 하기 위해 만들어진 패턴인데 waypoint는 이미지 자체를 건드리다보니 흠칫 하신 분들이 분명 있으실 겁니다.
또한 단순히 이미지에 코드가 추가 된것 뿐만 아니라 실제로 편의 기능을 위해 추가적인 메모리 리소스를 잡아 먹습니다. 이와 관련 해서는 이 문서를 보시는것을 추천드립니다.
아직은 작은 생태계와 커버리지
도커 기반 배포를 하기 위한 기능은 충실하기에 불편함이 없습니다. 다만, 아직은 외부 플러그인이 적다 보니 모든것을 커버할수 없습니다.
물론, 테라폼을 만든 회사 답게 확장이 용이한 구조이다 보니 생태계가 커지면 충분히 람다나 CDK모든 것을 커버 할수 있지 않을까 기대합니다.
서버에 대한 의존성
기존의 테라폼은 락기능등을 제공하기 위해 별도의 백엔드를 둘 수 있으나 기본적으로는 서버 없이 작동 할수 있습니다. 하지만 waypoint는 별도의 서버를 통해 작동 하다 보니 서버가 죽으면 cli,ui 모두 작동이 안됩니다.
이런분 에게 추천 합니다!
도커 기반으로 개발하지만 배포할때 마다 귀차니즘을 느끼시는분!
개인 토이프로젝트에서 간단하게 CD 구성 하실분
상용 서비스 배포 하는데 EB로도 충분하신분
이런 분에겐 안맞을수도...
스피나이커나, 젠킨스, 아르고CI/CD, Github Action을 적극적으로 활용 하여 배포 파이프라인을 구성 하시는분
위 에거 구성하는데 귀차니즘이 1도 없으신분..
