AWS hooks 알아보기
서론
안녕하세요! 이번 글에서는 CodeDeploy의 기능 중 하나인 hooks을 알아보고 기존 프로젝트에서 배포 자동화를 위해 사용하던 CodeDeploy에 hook을 적용시키는 것 까지 한번 해보겠습니다.
hooks?
‘hooks’ 본 단어 그대로의 의미는 ‘갈고리’라는 의미로 무언가 끌어오는 역할을 하는 것으로 유추해볼 수 있겠습니다.
소프트웨어공학에서는 ‘hooking’이란 단어가 소프트웨어 구성 요소 간 발생하는 함수 호출, 명령 등을 의미합니다.
따라서 AWS에서의 hooks도 이와 비슷한 의미로 쓰이는 것 같습니다. 배포 시에 동작할 스크립트를 끌어오는 그런 갈고리와 같은 역할을 하는 것입니다.
아마존은 훅을 아래와 같이 설명하고 있습니다.
hook AppSpec 파일 ‘hooks’ 섹션의 콘텐츠는 배포의 컴퓨팅 플랫폼에 따라 달라집니다.
EC2/온프레미스 배포 ‘hooks’ 섹션에는 배포 수명 주기 이벤트 후크를 하나 이상의 스크립트에 연결하는 매핑이 포함되어 있습니다.
어떤 플랫폼에 배포하는지에 따라 이 ‘hooks’이 달라진다고 합니다.
Lambda, ECS, EC2/온프레미스 이렇게 종류에 따라 달라지는데 제가 배포한 플랫폼은 EC2이기 때문에 EC2에서 훅이 어떻게 구성되는지를 알아보겠습니다.
EC2에서 hooks
훅은 배포당 1번씩 실행되며 한번의 배포 과정 사이에 여러개의 훅을 넣을 수 있습니다. 새로운 배포 파일을 다운로드 하기 전부터 배포 파일을 다운로드한 뒤까지, 혹은 Blue-Green 배포의 경우 로드밸런서에 작업이 등록될 때 등 여러 작업 사이에 hooks을 넣을 수 있습니다.
제가 실행시키려는 환경은 로드밸런서 없는 in-place 배포이고 환경변수를 set하고 기존에 실행중인 Java프로그램 종료시키고 재실행시키는 스크립트이기 때문에 배포가 완료된 뒤에 해당 스크립트를 실행하도록 하면 되겠습니다.
hooks 적용
따라서
위의 단계 중 ‘AfterInstall’ 단계에 훅을 걸어주면 되겠습니다.
그럼 hooks이 실행시킬 스크립트의 위치를 적어주어야 합니다. 어떤 위치를 기준으로 해야할 지 찾아보니
‘hooks’ 섹션에서 지정한 스크립트 위치는 애플리케이션 수정 번들의 루트를 기준으로 합니다.
라는 설명이 있어서 배포의 목적지를 기준으로 상대경로를 적어주었습니다. 저의 경우 스크립트가 배포의 루트에 있기 때문에 현재 위치를 경로로 하여 작성했습니다.
1
2
3
4
5
6
7
8
9
10
version: 0.0
os: linux
files:
- source: /
destination: /var/app/current
hooks:
AfterInstall:
- location: ./start_aplication.sh
timeout: 180
1트
음.. 배포 실패가 떠서 혹시 몰라서 절대 경로로 바꿔서 다시해봤는데 안돼서 보니
이벤트 로그에 더 자세한 원인이 나오더군요
2트
ec2 디스크 공간이 없어서였네요.. 아무래도 로그가 많이 쌓여서 그런것 같습니다. 다시 디스크 공간을 정리하고 배포 재시도를 해보겠습니다.
3트
에?
이번엔 또 뭐지..
경로가 ‘/opt/codedeploy-agent/deployment-root/f808110e-bfcb-4ea9-a1f0-6377570718ec/d-VALNHOGV7/deployment-archive/var/app/current/start_aplication.sh’ 인걸 보니 ‘/’로 시작한다고 절대 경로가 되는 것이 아니라 codedeploy 배포 경로에 추가로 붙는식으로 동작하는 것 같습니다.
또한 수정 번들의 루트 경로를 appspec.yml에 ‘destination’의 경로로 잘못 생각했는데, 이와 달리 ‘/opt/codedeploy-agent/deployment-root/{배포 세션 ID}/{배포 ID}/deployment-archive/’임을 알게 됐습니다.
따라서 상대경로를 이용해서 위치를 아래처럼 재지정하여 다시 시도해보겠습니다.
location: ../../../../../../var/app/current/start_aplication.sh
(배포할 서버에 존재하는 스크립트를 이용하는 것이 그렇게 좋은 구조는 아닌 것 같기에 추후 변경해야 할 것 같긴 합니다.)
4트..(사실 8트)
드디어 성공!! (사실 몇 번의 실패가 더 있었지만 생략하겠습니다.🥲) 배포 뒤에 로그를 확인해보니 성공적으로 스크립트가 실행되어 서버가 정상 구동 되는 것을 확인할 수 있었습니다.
마무리
이로써 hooks을 이용하여 배포 후 환경변수 설정 및 서버 재부팅 자동화를 구축하는데 성공하였습니다.
조금 더 배포 방식이 복잡하고 각각의 배포 주기마다 추가적인 설정이 필요한 상황이라도 이 hooks을 잘 이용한다면 쉽게 문제를 해결할 수 있을 것 같습니다.
지금까지 글 읽어주셔서 감사합니다.