숏컷 코드
docker context ls
docker context inspect default
docker context create staging --docker "host=ssh://deploy@staging.example.com"
docker context use staging
docker --context default ps동작 방식
context는 Docker CLI가 바라보는 daemon 정보를 묶는다
Docker 명령은 CLI 자체가 컨테이너를 실행하는 것이 아니라 daemon에 요청을 보냅니다. context는 어떤 daemon endpoint, TLS 정보, 설명을 사용할지 묶어 둔 설정입니다. active context가 바뀌면 같은 docker ps, docker compose up도 다른 daemon을 대상으로 실행됩니다.
docker CLI
-> active context
-> Docker daemon endpoint
-> containers / images / networks / volumesdocker context ls에서 별표가 붙은 항목이 현재 active context입니다. 작업 전에 이 값을 확인하면 로컬에서 실행할 명령을 원격 서버에 잘못 보내는 사고를 줄일 수 있습니다.
전환은 use보다 일회성 --context가 안전할 때가 있다
docker context use staging은 이후 명령 전체의 기본 대상을 바꿉니다. 원격 운영 서버를 자주 다룰 때는 편하지만, 로컬과 원격을 오가면 실수 위험이 커집니다. 단발성 확인은 docker --context staging ps처럼 명령마다 context를 명시하는 편이 안전합니다.
# 기본 context 전환
docker context use staging
# 단발성 명령
docker --context staging ps
docker --context default compose up -d터미널 prompt나 shell alias에 현재 context를 표시해 두면 대상 daemon 착각을 줄일 수 있습니다.
remote daemon은 Docker socket 권한과 같은 수준으로 봐야 한다
Docker daemon에 원격 접근을 열면 해당 daemon이 관리하는 호스트 자원에 강한 권한이 생깁니다. 특히 TLS 없이 TCP 포트를 열거나, 방화벽 없이 노출하면 원격 사용자가 호스트 root 수준의 영향을 줄 수 있습니다. 원격 관리는 SSH context나 TLS로 보호된 endpoint처럼 인증과 암호화가 명확한 방식으로 제한해야 합니다.
docker context create staging --docker "host=ssh://deploy@staging.example.com"tcp://0.0.0.0:2375처럼 인증 없는 endpoint를 열어 두는 구성은 개발 편의보다 위험이 큽니다.
체크포인트
| 상황 | 먼저 확인할 것 |
|---|---|
| 명령 대상이 헷갈릴 때 | docker context ls |
| context 상세 확인 | docker context inspect <name> |
| 원격 서버 단발성 조회 | docker --context <name> ps |
| 기본 대상 전환 | docker context use <name> |
| 원격 daemon 연결 | SSH 또는 TLS 기반 endpoint |
| 운영 서버 보호 | 인증 없는 TCP listener 금지 |
주의할 점
Docker context를 바꾸면 같은 명령이 전혀 다른 daemon에 적용됩니다. docker compose down, docker system prune, docker volume rm 같은 명령을 실행하기 전에는 active context를 먼저 확인해야 합니다.
remote daemon 접근은 단순 편의 설정이 아니라 호스트 제어 권한과 연결됩니다. 방화벽, 인증, TLS, SSH 계정 권한을 함께 설계하지 않으면 컨테이너 관리 API가 공격 표면이 됩니다.
참고 링크
2 sources