Repository navigation
refactor: 셋업 스크립트의 설치·설정 단계를 분리해 안전하게 재적용한다 #83
Description
어떤 부분을 리팩터링하려 하나요?
nginx 를 제외한 셋업 스크립트(side_infra_setup.sh.tftpl, docker_setup.sh, mysql_setup.sh.tftpl)는 지금 안전하게 다시 실행할 수 없는 상태입니다. 설치와 설정이 한 덩어리라, 설정 한 줄을 고치려 해도 컨테이너 재생성이나 패키지 재설치가 함께 일어납니다.
방향만 적어두는 이슈입니다. 아래 주의점을 먼저 공유하는 것이 목적이고, 구체적인 방식은 착수 시점에 논의해서 정합니다.
⚠️ 먼저 읽어야 할 주의점
1. 무작정 컨테이너를 재실행하면 안 됩니다.
side_infra_setup.sh.tftpl 은 이렇게 끝납니다.
docker rm -f redis redis-exporter alloy || true
docker compose -f docker-compose.side-infra.yml down || true
docker compose -f docker-compose.side-infra.yml up -d그런데 compose 정의에 Redis 볼륨 마운트가 없습니다. 현재 prod Redis 상태입니다.
db0:keys=574,expires=574
REFRESH:664 REFRESH:1047 REFRESH:973 ...
univApplyInfo:3641 univApplyInfo:3265 ...
REFRESH:<userId> 는 리프레시 토큰입니다. 이 스크립트가 재실행되면 전 사용자가 강제 로그아웃됩니다.
2. 이 스크립트는 해시가 바뀌는 순간 자동으로 재실행됩니다.
null_resource.update_side_infra 의 트리거가 템플릿 렌더 결과의 sha256 입니다. 즉 스크립트나 config.alloy.tftpl 을 한 글자만 고쳐도 다음 apply 에서 위 명령이 그대로 실행됩니다. 같은 이유로 #82 에서는 update_side_infra 에 replace_triggered_by 를 넣지 않았습니다. 트리거가 걸리는 순간이 곧 Redis 가 날아가는 순간이라, 안전장치가 먼저 필요합니다.
3. ignore_changes 를 푸는 것은 답이 아닙니다.
docker_setup.sh 와 mysql_setup.sh.tftpl 은 user_data 경로라 ignore_changes 에 막혀 갱신이 반영되지 않습니다. 그렇다고 ignore_changes 에서 user_data 를 빼면, user_data_replace_on_change = false 상태에서 user_data 가 바뀔 때 provider 가 인스턴스를 중지 → 수정 → 시작 하므로 다운타임이 발생합니다. 지금의 ignore_changes 는 그것을 막는 안전장치입니다.
AS-IS
- 설치(apt/pip/docker pull)와 설정(conf 작성, 컨테이너 기동)이 한 스크립트에 섞여 있어 부분 재적용이 불가능하다
- side-infra 는 재실행 시
docker rm -f로 컨테이너를 강제 삭제한다. Redis 에 볼륨이 없어 데이터가 함께 사라진다 docker_setup.sh/mysql_setup.sh.tftpl은user_data경로라 코드를 고쳐도 영영 반영되지 않는다- 서버가 수동으로 변경되어도 terraform 이 드리프트를 감지할 방법이 없다 (fix: 내부 전용 API 의 외부 노출 차단을 nginx 설정 코드에 반영 #76 이 그 사례)
TO-BE
- 설정만 따로 재적용할 수 있어, 컨테이너를 죽이지 않고 conf 변경을 반영할 수 있다
- Redis 가 재기동되어도 세션이 유지되거나, 최소한 재기동이 의도적으로만 일어난다
- 갱신이 필요한 스크립트는 nginx 와 같은 SSM 경로를 쓴다
작업 상세 내용
-
side_infra_setup.sh.tftpl을 설치 단계와 설정 단계로 분리한다.docker rm -f가 정말 필요한 경우(포트 점유 충돌)를 특정하고, 평상시 경로에서 제외할 수 있는지 확인한다 - Redis 영속성을 어떻게 다룰지 정한다 (볼륨 마운트 / AOF / 재기동 시 세션 유실 감수 여부)
-
docker_setup.sh의 SSM 이관을 검토한다.apt-get install docker-ce가 패키지 업그레이드를 만나면 데몬 재시작으로 앱 컨테이너가 순단될 수 있어, 배포 타이밍 조율이 필요하다 -
mysql_setup.sh.tftpl은 custom AMI 빌드 방식과 함께 검토한다 - 위 정리가 끝나면
update_side_infra에도replace_triggered_by를 적용해, 인스턴스 교체 시 side-infra 가 재구성되도록 한다
참고할만한 자료(선택)
- fix: 내부 전용 API 의 외부 노출 차단을 nginx 설정 코드에 반영 #76 / fix: 내부 전용 API 의 외부 노출 차단을 nginx 설정 코드에 반영 #82 — nginx 는
null_resource+ SSM RunShellScript 경로로 재적용된다. 같은 패턴을 참고할 수 있다
Activity
Hexeong commentedon Aug 30, 2026
작업 항목 추가:
update_side_infraprovisioner 의 SSM 등록 대기#82 리뷰에서 나온 지적입니다.
null_resource의local-exec는 SSM 등록 여부를 확인하지 않고 바로aws ssm send-command를 호출하는데, 인스턴스가 교체된 직후에는 에이전트가 아직 등록되지 않아InvalidInstanceId로 즉시 실패합니다.update_nginx쪽은 #82 에서PingStatus가Online이 될 때까지 대기하는 루프를 넣어 해결했습니다.update_side_infra는replace_triggered_by가 없어 인스턴스 교체 시 실행되지 않으므로 지금 당장 문제가 되지는 않지만, 이 이슈에서replace_triggered_by를 붙이는 시점에는 같은 대기 로직이 함께 필요합니다.update_side_infraprovisioner 에도 SSM 등록 대기를 추가한다 (update_nginx와 동일한 방식)