For Engineering

부제: command를 덮어썼더니 ${VAR}가 그대로 남았다nginx 설정을 템플릿으로 두고, 환경변수를 채워 렌더하는 방식을 쓰고 있었다. TLS 인증서 경로에 도메인을 변수로 넣어 뒀다.ssl_certificate /etc/letsencrypt/live/${SSL_DOMAIN}/fullchain.pem;그런데 어느 순간 ${SSL_DOMAIN}이 치환되지 않고 글자 그대로 남았다. nginx는 ${SSL_DOMAIN}이라는 이름의 디렉터리에서 인증서를 찾으려다 실패했고, 443(HTTPS)이 뜨지 못했다.증상디스크의 템플릿은 멀쩡했다. ${SSL_DOMAIN}을 채우는 단계가 그냥 안 돌았다. 변수 치환(envsubst)이 통째로 건너뛰어진 것이다.근본 원인 — command를 덮어쓰면 치환 단계도..

부제: 순정 nginx 대신 OpenResty를 쓰게 된 이유리버스 프록시로 순정 nginx를 쓰고 있었다. rate limit도 nginx 기본 기능(limit_req)으로 IP 기준으로 걸어 뒀다. 처음엔 충분했는데, 트래픽 구조 때문에 한 가지 문제가 생겼다.출발점백엔드(BE) 하나가 자기 IP·API 키 하나로 여러 end-user의 요청을 한데 모아 보낸다. 그러다 보니 동시성이 잠깐 치솟으면, 정상적인 BE 트래픽인데도 IP 기준 rate limit에 걸려 429가 났다. 진짜 과한 호출이 아니라 집약 구조 때문에 생긴 false positive였다.그래서 방향을 정했다. 유효한 API 키로 들어온 요청은 rate limit에서 면제하고, IP 제한은 그 외에만 적용하자.왜 순정 nginx로는..

배포 스크립트가 새 태그를 체크아웃하고 docker compose up -d nginx로 nginx를 올린다. 호스트 디스크의 설정 파일은 분명히 새 내용으로 바뀌었는데, 실제 요청은 계속 404가 났다.무슨 일이 있었나설정은 bind-mount로 컨테이너에 연결돼 있었다. 디스크의 파일을 바꾸면 컨테이너 안에서도 같은 파일이 보이니, 당연히 반영될 거라고 생각했다.그런데 docker compose up -d는 컨테이너 spec이 바뀌었을 때만 재생성한다. bind-mount된 파일의 내용이 바뀐 것은 spec 변경이 아니다. 이미지 태그도, 환경변수도, 볼륨 정의도 그대로니까 compose 입장에선 "바뀐 게 없는" 컨테이너다. 그래서 재기동을 건너뛰고, 실행 중이던 nginx 워커는 처음 켜질 때 읽..

보호되어 있는 글입니다.