refactor: 셋업 스크립트의 설치·설정 단계를 분리해 안전하게 재적용한다

[Hexeong]

어떤 부분을 리팩터링하려 하나요?

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 경로로 재적용된다. 같은 패턴을 참고할 수 있다

[Hexeong]

작업 항목 추가: update_side_infra provisioner 의 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_infra provisioner 에도 SSM 등록 대기를 추가한다 (update_nginx 와 동일한 방식)