Docker가 내부망을 기본길로 고를 수 있었다
Google 인증 서버로 가려는 요청이 출구 없는 내부망을 택하면 운영체제는 곧바로 “갈 수 있는 길이 없다”고 답한다.
Docker networking · ELI5
컨테이너는어느 문으로 나갈까?
문이 두 개라면 “인터넷으로 나가는 문”을 정해 줘야 한다. 정하지 않으면 Docker가 다른 문을 고를 수 있고, 그 문이 막혀 있으면 Network is unreachable이 된다.
아래로 내려가면 2분 안에 전체 원리가 이어집니다 ↓
무슨 일이 있었나
Google이 고장 난 게 아니라,
Google로 가는 출구를 잘못 골랐다.
앱 컨테이너는 데이터베이스와 대화하는 내부망, 인터넷으로 나가는 외부망에 동시에 연결돼 있었다. 내부망은 안전을 위해 인터넷 출구가 없다. 문제는 두 망 중 어느 쪽이 기본 출구인지 명시하지 않았다는 점이었다.
외부망을 기본 게이트웨이로 지정했다
gw_priority: 1로 인터넷 연결망을 선택했다. 배포 중 네트워크를 다시 붙일 때도 같은 우선순위를 유지한다.
오류가 난 순간
출입증을 받으러 가는 길부터 끊겼다.
앱은 Google API를 쓰기 전에 WIF라는 방식으로 유효기간이 짧은 출입증을 받는다. 이번 오류는 권한 심사까지 가지도 못했다. 첫 번째 인터넷 연결에서 멈췄다.
앱 컨테이너
기본 게이트웨이
출구 없는 내부망
✕
✕
Google 인증 서버
Network is unreachable은 비밀번호가 틀렸다는 뜻이 아니다. 주소로 떠날 경로 자체가 없다는 뜻이다. 그래서 인증서 교체나 권한 추가로는 고칠 수 없다.
왜 재발하지 않나
설정, 배포, 실제 호출을 세 겹으로 확인한다.
Compose에서 출구를 선언
여러 네트워크를 쓰는 서비스마다 인터넷망의 gw_priority를 높였다.
배포 스크립트도 같은 규칙 사용
별칭을 바꾸느라 네트워크를 떼었다 붙여도 --gw-priority 1을 다시 준다.
CI가 설정 퇴행을 차단
렌더링된 Compose와 배포 명령을 검사해 표지판이 빠지면 production 전에 실패시킨다.
운영 컨테이너에서 진짜 인증
마지막에는 실제 앱과 같은 scope로 WIF token을 갱신해 길과 출입증을 함께 검증했다.
문이 많아지면, 기본 출구는 우연에 맡기지 않는다. 그리고 설정 파일만 보지 말고 배포가 끝난 실제 컨테이너의 길까지 확인한다.