curl 없는 컨테이너에서 Bash /dev/tcp로 HTTP 요청 보내기

3 hours ago 2

최소 컨테이너 이미지에는 curl이나 wget이 빠져 있는 경우가 많아, 패키지 설치 없이 내부 서비스 연결성을 확인할 우회 방법이 유용함
Bash의 /dev/tcp/host/port 리다이렉션은 TCP 소켓을 열 수 있어, HTTP/1.1 요청 문자열을 직접 써 보내고 응답을 읽을 수 있음
/dev/tcp는 파일시스템 경로가 아니라 Bash 내부 기능이므로 ls /dev/tcp나 다른 셸의 일반 파일 접근 방식으로는 동작하지 않음
이 방법은 리다이렉트, chunked 응답, 압축, 재시도, TLS를 처리하지 않는 간단한 디버깅 기법이며 Connection: close 없이는 cat이 대기할 수 있음
일상적인 HTTP 작업에는 curl이 맞지만, 도구를 추가하기 어려운 작은 컨테이너에서는 빠른 연결 확인에 충분함

Bash 파일 디스크립터로 HTTP 요청 작성하기

내부 Docker 네트워크에서 다른 서비스의 /health 엔드포인트 접근 여부를 확인해야 했지만, 이미지에 curl이나 wget이 없는 상황이었음
Bash는 TCP 소켓을 파일 디스크립터에 연결할 수 있어, 다음처럼 HTTP 요청을 직접 작성해 보낼 수 있음

exec 3<>/dev/tcp/service/8642 printf 'GET /health HTTP/1.1\r\nHost: service\r\nConnection: close\r\n\r\n' >&3 cat <&3

service는 실행 위치에서 해석되고 도달 가능한 호스트명이어야 함
- Docker 네트워크에 설정된 컨테이너나 서비스 이름일 수 있음
- 해석 가능한 DNS 이름도 사용할 수 있음
- 호스트와 포트는 환경에 맞게 바꿔야 함
응답 출력에는 상태 줄, 헤더, 빈 줄, 본문이 함께 포함됨
헤더를 추가하려면 요청을 끝내는 빈 줄 앞에 \r\n으로 끝나는 줄을 더 넣으면 됨

exec 3<>/dev/tcp/service/8642 printf 'GET /v1/models HTTP/1.1\r\nHost: service\r\nAuthorization: Bearer %s\r\nConnection: close\r\n\r\n' "$API_KEY" >&3 cat <&3

/dev/tcp가 실제 파일이 아닌 이유

/dev/tcp는 실제 장치 파일이 아니라 Bash가 처리하는 리다이렉션임
- 디스크에 해당 경로가 없으므로 ls /dev/tcp는 실패함
- 다른 셸에서 cat /dev/tcp/...를 실행해도 오류가 남
Bash manual에 따르면 /dev/tcp/host/port에서 host가 유효한 호스트명이나 인터넷 주소이고 port가 정수 포트 번호나 서비스 이름이면 Bash가 TCP 소켓 열기를 시도함
Bash가 DNS 조회와 connect(2)를 수행하고, exec 3<>는 소켓을 파일 디스크립터 3에 연결해 읽기와 쓰기를 가능하게 함

HTTP 클라이언트 대체재가 아닌 임시 점검 도구

이 방식은 실제 HTTP 클라이언트가 아니어서 리다이렉트, chunked 응답, 압축, 재시도, TLS 등을 처리하지 않음
Connection: close 헤더가 중요함
- 없으면 서버가 HTTP/1.1 기본값에 따라 연결을 유지할 수 있음
- 이 경우 cat <&3가 EOF를 기다리며 끝나지 않을 수 있음
timeout 6 bash -c '...'처럼 감싸면 연결이 닫히지 않는 상황에도 대비할 수 있음
/dev/tcp는 원시 소켓을 여는 방식이라 평문 HTTP에만 해당하며, https에는 openssl s_client가 필요함
POSIX 기능이 아니라 Bash 기능이므로 Debian의 /bin/sh인 dash나 zsh에서는 사용할 수 없고, bash를 직접 호출해야 함
Bash 빌드 시 --enable-net-redirections로 켜지는 컴파일 타임 옵션임
- 대부분의 주류 빌드는 활성화되어 있음
- Debian은 오랫동안 비활성화한 적이 있음
결론적으로 curl을 대체하는 일반 도구라기보다, 설치를 추가할 수 없는 작은 컨테이너에서 빠르게 연결성을 확인하는 용도에 적합함