mirabo01 님의 블로그

처음 도커를 쓸 때는 docker build가 돌아가는 게 신기했습니다.그런데 어느 순간, 작은 수정 하나 하고 빌드할 때마다 5분씩 걸리기 시작했죠.CI/CD 파이프라인에서 빌드가 병목이 되면서 배포도 느려졌습니다.이 문제를 해결하면서 배운 게 “도커 이미지 최적화”였습니다.이미지가 느려지는 이유도커 이미지는 레이어(layer)의 집합입니다.각 RUN, COPY, ADD 명령이 하나의 레이어를 만듭니다.그래서 불필요한 레이어가 많아지면 이미지 크기가 커지고, 빌드도 느려집니다.예를 들어 이런 Dockerfile을 보면 문제가 명확합니다.FROM node:18WORKDIR /appCOPY . .RUN apt-get updateRUN apt-get install -y vimRUN npm installCMD..

관련 이미지 몇 장 골랐어요. 블로그에 삽입하시면 해당 내용을 시각적으로 보강하는 데 유용할 겁니다.원하시면 각 이미지별로 설명 문구도 같이 만들어드릴까요? 도커를 처음 쓸 때는 단일 애플리케이션 하나를 컨테이너로 감싸서 띄우는 게 전부였습니다.예를 들어 백엔드 서버 하나를 docker run으로 띄우고,필요하면 docker exec으로 들어가서 로그를 확인하는 식이었죠.그런데 프로젝트가 커지면 이야기가 달라집니다.백엔드, 프론트엔드, DB, 캐시 서버까지 한꺼번에 구동해야 하고이 모든 컨테이너가 네트워크로 연결되어야 하죠.이걸 일일이 docker run으로 띄우다 보면 금방 정신이 나갑니다.그때 등장하는 게 바로 Docker Compose입니다.Compose가 필요한 순간이전 회사에서 처음 도커를 도입..

관련 이미지들 여기에 두 장 골랐어요. 블로그에 이미지로 함께 넣으면 개념 전달이 더 수월해질 겁니다.원하시면 이미지 설명 문구도 같이 만들어드릴게요.도커를 처음 배우면 docker run 한 줄로 뭔가가 “실행된다”는 사실은 쉽게 이해되지만,그게 이미지에서 컨테이너가 만들어지는 과정이라는 건 잘 와닿지 않습니다.“이미지를 실행하면 컨테이너가 생긴다”라는 말을 듣긴 하지만,그게 정확히 무슨 의미인지 직접 눈으로 보기 전까진 잘 안 잡히죠.도커 이미지는 설계도, 컨테이너는 실제 기계이걸 비유로 설명하면 훨씬 이해가 쉬웠습니다.도커 이미지(Docker Image) 는 “제품을 만들기 위한 설계도”입니다.그리고 컨테이너(Container) 는 그 설계도를 토대로 실제로 조립해서 작동 중인 제품이죠.즉, 이미지..

도커를 배우면서 “Dockerfile을 작성한다”는 말을 많이 들었지만, 막상 손에 잡히지 않았던 적이 있습니다.FROM, RUN, COPY, CMD 같은 명령어들이 도대체 어떤 순서로 실행되고, 왜 이렇게 작성해야 하는지 감이 안 왔죠.한 줄 한 줄의 의미보다도, 이게 어떤 구조로 동작하는지를 이해하는 게 더 중요했습니다.처음 Dockerfile을 마주했을 때 처음 Dockerfile을 봤을 때, “이게 뭔가 빌드 스크립트인가?” 싶은 생각이 들었습니다.대충 보면 리눅스 명령어랑 비슷하긴 한데, 순서가 조금 특이하죠.예를 들어 이런 식입니다.FROM node:18-alpineWORKDIR /appCOPY package*.json ./RUN npm installCOPY . .CMD ["npm", "sta..

필요하시면 각 이미지에 맞는 설명 문구나 캡션도 함께 만들어드릴게요.서비스를 운영하다 보면 누구나 한 번쯤 “배포하다가 서버가 멈춘 적”이 있습니다.처음엔 그게 큰 문제처럼 느껴지지 않지만, 실제 사용자가 많은 환경에서는 단 몇 초의 중단도 민감하게 체감됩니다.그래서 어느 순간부터는 “다운타임 없는 배포”, 즉 무중단 배포가 필수가 됩니다.도커를 사용하면 이 과정을 비교적 단순하게 설계할 수 있습니다.그 대표적인 방법이 바로 Blue-Green Deployment입니다.배포 중 서버가 멈추는 이유도커를 쓰기 전에는 새로운 버전을 배포할 때마다서버를 중지하고, 새로운 코드를 반영하고, 다시 서버를 실행했습니다.그 몇 초 사이에 사용자는 페이지를 새로고침하면 접속이 끊겼습니다.도커를 도입한 이후에도 단일 컨..

처음 도커를 쓸 땐 로컬 환경에서 “이미지를 빌드해서 컨테이너를 실행하는 것”만으로도 충분했습니다.하지만 서비스가 커지고 팀 단위로 협업하게 되면,누가 어떤 코드를 배포했는지 관리가 필요해집니다.수동으로 docker build, docker push, docker pull을 반복하다 보면인간이 가장 많이 실수하는 부분 — 버전 관리와 환경 일관성 — 에서 문제가 터지죠.그래서 등장하는 게 CI/CD 파이프라인에 도커를 통합하는 방식입니다.내가 처음 자동 배포를 시도했을 때예전에 사이드 프로젝트를 EC2 위에서 운영할 때였습니다.깃허브에 커밋하면 서버에 반영되도록 만들고 싶었죠.처음엔 직접 스크립트를 짰습니다.git pull origin maindocker build -t myapp .docker stop..

도커 허브(Docker Hub) 관련 이미지 몇 장 골랐어요. 블로그에 적절히 넣으면 이해에 도움이 될 거예요.필요하시면 각 이미지에 맞는 캡션도 같이 만들어드릴게요.도커 이미지는 로컬에서만 사용할 수도 있지만,결국 배포를 하려면 이미지를 저장하고 불러올 수 있는 공간이 필요합니다.그게 바로 Docker Registry(도커 레지스트리) 입니다.가장 대표적인 게 Docker Hub, 그리고 조직에서는 GitHub Container Registry(GHCR),또는 자체 구축한 Private Registry를 사용합니다.도커 이미지를 올린다는 건 무슨 의미일까처음 도커를 배울 땐 docker build까지만 해도 충분했는데,프로젝트를 서버에 올리려다 보니 “이미지를 서버에 어떻게 옮기지?”가 문제였습니다.처..

도커 이미지는 ‘설계도’다 도커 이미지는 말 그대로 실행 환경의 설계도입니다.내가 실행할 애플리케이션과 그 안에서 필요한 모든 설정, 패키지, 라이브러리, 실행 명령까지 하나의 묶음으로 저장한 템플릿입니다.예를 들어 Node.js 애플리케이션을 배포한다고 해봅시다.보통은 서버에서 Node 설치하고, npm으로 패키지를 설치하고, 실행 스크립트를 지정하죠.하지만 도커를 쓰면 이 과정을 Dockerfile이라는 파일에 정리할 수 있습니다.FROM node:18-alpineWORKDIR /appCOPY package*.json ./RUN npm installCOPY . .CMD ["npm", "start"]이 파일을 기반으로 docker build를 하면 이미지가 만들어집니다.이 이미지 안에는 Node 18..

처음 서버 배포를 하던 시절, 개발 환경이 제멋대로 달라지는 게 정말 골칫거리였습니다.로컬에서는 잘 돌던 코드가 서버에 올리면 에러가 나고,“그거 너 노드 버전 달라서 그래” 같은 말을 수도 없이 들었죠.그러다 “환경 자체를 코드로 묶어서 관리할 수 있다”는 말을 듣고 처음 접한 게 Docker였습니다.당시엔 이름부터 낯설었지만, 한 줄 요약하자면 도커는 **‘어디서나 똑같이 실행되는 개발 환경을 만드는 도구’**였습니다.환경이 다르면 코드가 망가진다서버를 옮기거나 팀원이 새로 합류할 때마다 생기는 “환경 차이” 문제는 정말 흔합니다.리눅스 버전이 달라서 패키지가 깨지고,라이브러리 버전이 엇나가서 빌드가 실패하는 등,결국 해결책은 “환경 자체를 통째로 묶는 것”이었습니다.이걸 가능하게 만든 게 바로 컨테..