남은 team3 잔재 정리 (docker 컨테이너·볼륨, terraform)

[m-a-king]

왜

리브랜딩(team3 -> PiKi) 때 안 따라온 이름이 남아 있다. #968 에서 nginx upstream 블록명과 blue/green 슬롯 상태 파일은 옮겼고, 남은 것은 전부 바꾸면 데이터나 가용성에 영향이 있어 별도 이행 절차가 필요하다.

남은 대상

docker 컨테이너·볼륨 (infra/scripts/provision-runtime.sh)

이름	무엇	그냥 바꾸면
team3-redis / team3-redis-data	refresh 토큰 저장소	새 빈 볼륨이 붙어 전원 로그아웃
team3-mysql / team3-mysql-data	dev 박스 로컬 DB	새 빈 볼륨이 붙어 dev 데이터 유실

prod 에서 team3-redis 가 3주째 가동 중인 것을 확인했다 (2026-08-23).

이행하려면 컨테이너를 새 이름으로 재생성하면서 기존 named 볼륨을 그대로 붙이거나, 볼륨 데이터를 복사하는 절차가 필요하다. 스크립트가 docker ps -a | grep -qx 'team3-redis' 로 존재 여부를 보고 skip 하는 구조라, 이름이 바뀌면 "없음" 으로 판정해 새로 만든다는 점이 함정이다.

terraform

대상	값	그냥 바꾸면
variables.tf db_name	team3	실제 운영 DB 이름이라 앱이 접속 실패
ec2.tf key_name	team3-SE-1 / team3-dev-SE-1	인스턴스 교체 강제. prod 다운 + 박스 로컬 데이터 유실
variables.tf project	team3	name_prefix 파생 리소스 재생성
eip.tf / ec2.tf Name 태그	team3-*	태그 자체는 in-place 라 안전하나 project 변수와 함께 봐야 한다

name_prefix 파생 리소스 이름은 #438 이 이미 다루고 있다. 다만 #438 은 RDS 폐기(#898)와 계정 이전(#808) 이후 현황이 반영돼 있지 않아 재조사가 필요하다. 이 이슈는 #438 이 안 다루는 db_name · key_name 과 docker 쪽을 맡는다.

박스 잔여 파일

/etc/nginx/team3-upstream.conf 는 #968 이 piki-upstream.conf 로 이행했지만, 롤백 안전을 위해 남겨뒀다(nginx -t 실패 시 복원되는 .bak conf 가 아직 옛 경로를 include 한다). 전 박스가 새 경로로 이행한 것을 확인한 뒤 파일과 함께 deploy.yml 의 승계·배수 코드도 제거한다.

바꾸지 않는 것

• 레거시 컨테이너 청소 코드 (deploy.yml 의 team3-$INACTIVE · team3-server): 실제 옛 컨테이너 이름을 가리키는 리터럴이라 바꾸면 청소가 동작하지 않는다(core 박스를 공통 Alloy 블록으로 이전하고 컨테이너 관측 라벨·이름을 정리 #743 전환기 코드). 이름 변경이 아니라 전 환경 배포가 한 바퀴 돈 뒤 코드째 제거가 맞다
• depromeet18team3.cloud 언급 (CorsConfig 주석 · 테스트 3파일): 실제 존재했다가 piki.day 도메인 이관 (운영 api.piki.day / 개발 dev.api.piki.day) #488 로 retire 된 도메인이다. 바꾸면 기록이 거짓이 된다

우선순위

낮음. 순수 미용 작업인데 실패 비용이 데이터 유실·배포 중단이다. 다른 이유로 해당 리소스를 건드릴 때 함께 처리하는 편이 낫다.

참고

• nginx piki_llm zone 제거 + upstream team3 잔재 정리 #968 (nginx upstream·상태 파일 이행. 승계 로직 선례)
• terraform 단일 state leftover 정리 (공유 리소스 네이밍·Environment 태그) #438 (terraform name_prefix 파생 네이밍. 겹치는 범위)
• core 박스를 공통 Alloy 블록으로 이전하고 컨테이너 관측 라벨·이름을 정리 #743 (컨테이너명 개편. 레거시 청소 코드의 출처)