brunch
매거진 IT 에세이

AppRunner에 환경변수 입력이 귀찮네

Aws Secrets Manager 사용하기

by jako

Slack으로 간단한 메시지를 보내주는 서버를 만들었고 이를 AWS App Runner에 올려 사용 중입니다.


Docker를 이용해 간단하게 접할 수 있는 컨테이너 관리형 서비스가 무엇이 있을까 하고 조사하던 찰나에 App Runner를 알게 되었고 처음 App Runner를 사용할 때만 해도 간편하게 배포할 수 있어서 혁신적이다라고 생각했었죠.


App Runner를 사용하면서 불편했던 점은 이미 구동되고 있는 AppRunner Service에서는 환경변수를 수정할 수 없다는 점이었습니다.


초기 개발만 하더라도 환경변수는 그렇게 많지 않았던 걸로 기억합니다. 3~4개 정도였으니 생성해 둔 App Runner를 삭제하고 다시 생성한다 해도 3~4개 정도면 번잡하지 않으니 금방금방 AppRunner 서비스를 삭제했다가 새로 생성해도 크게 거슬리진 않았습니다.


그런데 문제는 Slack으로 보내줘야 하는 메시지를 수집해야 하는 대상이 늘어나면서 시작됐습니다. Slack으로 보내줘야 하는 메시지는 사내 그룹웨어 그리고 협업 도구와 같은 곳에서 발생하는 데이터입니다.


이 데이터를 얻기 위해선 개발한 서버에서 그룹웨어와 협업 도구에 접근할 수 있는 계정이 필요하게 되니 이를 일일이 AppRunner 서비스를 생성하는 과정에서 환경변수 설정 부분에 복사/붙여 넣기로 입력해야 했습니다.


그룹웨어나 협업툴에서 API가 제공되지 않는 경우 저의 개인 아이디와 비밀번호와 같은 정보들도 환경변수로 등록하다 보니 환경변수의 총개수가 계속 늘어나 8~9개 정도를 설정해야 되더군요


이런 상황이다 보니 잘못 생성한 AppRunner를 삭제하고 다시 생성하는 과정이 많이 번잡해지기 시작했죠


이 문제를 어떻게 해결해야 될까 싶다가 AWS의 Secrets Manager라는 서비스를 알게 되었습니다.


Application에 사용하는 환경변수를 미리 AWS Secrets Manager에 등록하면 boto3 라이브러리를 이용해 가져올 수 있으니 Application 레벨에서 필요한 환경 변수를 사용할 수 있다는 점이 매력적이었습니다.


AWS Secretes Manager를 이용하게 되니 App Runner를 생성할 때 설정하게 되는 환경변수 세팅도 boto3에서 AWS Secrets Manager에 접근하기 위 환경변수인 AWS_ACCESS_KEY, AWS_ACCESS_SECRET_KEY, REGION_NAME 정도만 필요하게 되니 거슬리던 환경변수 설정 작업을 해결할 수 있었습니다.





keyword