Azure 인프라를 코드로 정의하는 언어 Bicep을 처음 접하는 분을 위해, 용어부터 풀어 쓰고 직접 컴파일한 결과로 설명합니다. Azure 구독 없이 Azure CLI 컨테이너(2.91.0)와 Bicep CLI 0.48.1만으로 컴파일, 린트, 모듈, 파라미터 파일, 역변환(decompile)까지 실행했고, 환경은 Docker 29.1.3, arm64입니다.위 그림이 전체 흐름입니다. 사람이 .bicep 파일을 쓰면 컴파일러가 ARM 템플릿(JSON)으로 바꾸고, 그 JSON을 Azure가 받아서 리소스를 만듭니다. 컴파일까지는 내 PC에서 끝나기 때문에 Azure 구독이 없어도 문법과 구조를 충분히 검증할 수 있습니다.먼저 알아둘 용어Azure가 처음이면 용어가 가장 큰 장벽입니다. 이 글에서 계속..
같은 호스트의 컨테이너끼리 통신할 때 기본 bridge 네트워크와 사용자 정의 bridge 네트워크가 어떻게 다른지, busybox 컨테이너로 직접 실험한 기록입니다. 컨테이너 이름으로 통신되는 조건, 네트워크 간 격리, 같은 이름(alias)을 가진 컨테이너에 대한 DNS 동작, 호스트에서 접근하는 포트 게시(-p)까지 다룹니다. 환경은 Docker 29.1.3(arm64), busybox 1.36.1입니다.위 그림이 이 글의 핵심입니다. 같은 bridge 계열이어도 기본 bridge는 IP로만, 사용자 정의 bridge는 이름으로도 통신됩니다. 아래에서 실제 명령과 결과로 확인합니다.왜 필요한가컨테이너의 IP는 컨테이너를 만들 때 네트워크에서 할당되는 값이라 코드나 설정에 고정해서 쓰기 어렵습니다. ..
앞서 쓴 Docker 멀티스테이지 빌드 글에서 만든 Go 이미지 세 가지(단일 스테이지 1.3GB, alpine 24MB, distroless 12.7MB)를 Trivy 0.76.0으로 스캔해 취약점 개수를 비교한 기록입니다. OS 패키지 취약점은 이미지를 줄이면 8,466건에서 1건으로 줄지만, 앱 바이너리에 포함된 Go 표준 라이브러리 취약점 65건은 그대로 남고 Go 1.27.2로 다시 빌드해야 0건이 됩니다. 환경은 Docker 29.1.3, arm64입니다.위 그림은 이 글의 결론입니다. 왼쪽 열(OS 패키지)은 이미지를 줄일수록 거의 사라지지만, 오른쪽 열(앱 바이너리)은 베이스 이미지를 바꿔도 그대로입니다. 아래에서 이 숫자가 어떻게 나왔는지 순서대로 설명합니다.왜 필요한가이미지를 빌드하고 ..
Kubernetes v1.37(2026년 8월 26일 출시, 코드명 Garhwal)에서 HorizontalPodAutoscaler(HPA)의 스케일 투 제로가 Beta로 올라가 기본 활성화되었습니다. 이 글은 2026년 9월 2일 공식 블로그 글을 바탕으로, 워커를 0개까지 줄였다가 다시 켜는 원리와 설정 방법, 운영 전에 알아야 할 주의점을 정리합니다.위 그림은 이 글 전체의 구조입니다. 큐 길이 같은 외부 지표를 HPA가 읽어서 워커 Pod를 0개와 10개 사이로 조절합니다. 아래에서 각 단계를 차례로 풀어 설명합니다.왜 필요한가큐를 소비하는 워커나 배치 처리기는 일감이 없는 시간에도 최소 1개의 Pod를 띄워 두는 경우가 많습니다. 이 Pod가 전용 CPU나 GPU를 점유하고 있다면 놀고 있는 시간..
Docker BuildKit의 RUN --mount=type=cache는 빌드 사이에 pip 같은 패키지 캐시 디렉터리를 보존해, 의존성 파일이 바뀌어 레이어 캐시가 깨져도 이미 받은 패키지는 다시 내려받지 않게 해 줍니다. Docker 29.1.3, buildx v0.30.1, python:3.12-slim 기준으로 직접 빌드해 다운로드 횟수를 비교했습니다.아래 그림은 같은 변경(requirements.txt에 패키지 추가)에 대해 일반 RUN과 캐시 마운트 RUN이 어떻게 다르게 동작하는지 보여줍니다.왜 필요한가Docker 이미지는 Dockerfile 명령마다 레이어를 만들고, 입력이 같으면 그 레이어를 재사용합니다. 그래서 보통 COPY requirements.txt를 소스 복사보다 먼저 두어 의존..
Docker Compose의 depends_on은 기본값에서 컨테이너가 "시작"되기만 기다릴 뿐 서비스가 "준비"되었는지는 확인하지 않습니다. 이 글에서는 busybox로 8초 뒤에 포트를 여는 가짜 DB를 만들어 healthcheck와 condition: service_healthy 유무에 따라 app의 첫 접속이 어떻게 달라지는지 직접 실행해 비교하고, retries를 너무 작게 잡았을 때의 실패 양상까지 정리합니다. (Docker 29.1.3, Docker Compose v2.40.3 기준)아래 그림은 두 설정의 차이를 한 장으로 요약한 것입니다. 위쪽은 기본 depends_on에서 app이 db 컨테이너가 뜨자마자 접속해 실패하는 흐름이고, 아래쪽은 healthcheck가 healthy를 보고한 ..
