이슬먹는 개발자

프론트엔드 개발하다 보면 십중팔구 만나는 그 빨간 에러.Access to fetch at 'http://localhost:8080/api/users' from origin'http://localhost:5173' has been blocked by CORS policy:No 'Access-Control-Allow-Origin' header is present on the requested resource.로컬에서 프론트 띄우고 API 좀 불렀을 뿐인데 요청이 막힌다. 오늘은 이 에러를 개발 환경에서 가장 깔끔하게 넘기는 방법, dev server proxy를 다룬다. Vite와 Webpack 둘 다 정리한다.먼저: 이게 왜 나는지 딱 한 줄만 알고 가자브라우저에는 동일 출처 정책(Same-Origin P..

지난 글에서 쿠버네티스가 왜 필요한지, 그리고 "원하는 상태를 선언하면 알아서 맞춰준다"는 철학을 잡았다. 오늘은 그 선언을 실제로 이루는 가장 기본적인 3개 개념을 본다.Pod: 컨테이너를 담는 최소 단위Deployment: Pod를 몇 개, 어떻게 유지할지 관리Service: Pod에 접속할 안정적인 통로이 셋의 관계만 이해하면 쿠버네티스의 절반은 잡은 거다. 하나씩 가보자.Pod — 컨테이너를 담는 최소 단위쿠버네티스에서는 컨테이너를 직접 다루지 않는다. 대신 Pod(파드)라는 걸 다룬다.Pod는 컨테이너를 하나(또는 여러 개) 감싼 껍데기다. "왜 컨테이너를 그냥 안 쓰고 한 겹 더 감쌌지?" 싶을 텐데, 쿠버네티스가 관리하는 최소 단위를 Pod로 통일해뒀다고 생각하면 된다. 컨테이너를 직접이 아..

지금까지 Docker로 컨테이너를 만들고, Compose로 여러 개를 묶고, CI/CD로 자동 배포까지 했다. 여기까지만 해도 웬만한 개인 프로젝트나 소규모 서비스는 충분히 굴러간다.그런데 여기저기서 쿠버네티스(Kubernetes, 줄여서 K8s)라는 말이 계속 들린다. "이거 안 하면 뒤처지나?" 싶기도 하다. 오늘은 명령어 하나 안 배운다. 대신 쿠버네티스가 왜 생겼고, 언제 필요한지를 확실히 잡는다. 이게 잡혀야 다음 글부터 나오는 개념들이 겉돌지 않는다.먼저: 쿠버네티스가 뭔데?한 줄로 말하면, 컨테이너를 대신 관리해주는 시스템(컨테이너 오케스트레이션 도구)이다."오케스트레이션(orchestration)"이라는 말이 핵심이다. 오케스트라 지휘자를 떠올리면 된다. 연주자(컨테이너)가 수십, 수백 명..

지난 글에서 push하면 자동으로 배포되는 파이프라인을 완성했다. 잘 돌아간다. 그런데 실무에 쓰기엔 두 가지가 걸린다.첫째, 배포할 곳이 하나뿐이다. 실무에선 보통 개발 서버(dev)와 운영 서버(prod)를 따로 둔다. 테스트는 개발 서버에서 해보고, 검증되면 운영에 올린다. 지금은 main에 push하면 무조건 그 서버 하나로 나간다.둘째, 태그가 latest 하나뿐이다. 이러면 지금 서버에 떠 있는 게 어떤 코드인지 알 수 없다. 배포했는데 문제가 생겨서 되돌리고 싶어도, 이전 버전 이미지가 남아있지 않다.오늘은 이 두 가지를 해결해서 파이프라인을 실무 수준으로 다듬는다.1. 브랜치별로 다른 환경에 배포하기가장 흔한 구성은 이렇다.브랜치배포 대상용도develop개발 서버기능 테스트, 내부 확인ma..

지난 글에서 코드를 push하면 자동으로 테스트가 돌아가는 CI를 만들었다. 여기까지가 "이 코드 괜찮아?"를 검사하는 단계였다.오늘은 드디어 그 뒤를 잇는다. 테스트를 통과하면 → Docker 이미지를 빌드해서 → 실제 서버에 자동 배포까지. 앞에서 배운 Docker와 GitHub Actions가 여기서 하나로 합쳐진다. CD의 완성편이다.전체 그림 먼저 보기우리가 만들 파이프라인은 이렇게 생겼다.[코드 push] │ ▼[1. 테스트] ← 지난 글에서 만든 것 │ 통과하면 ▼[2. Docker 이미지 빌드] │ ▼[3. 레지스트리에 이미지 push] │ ▼[4. 서버에 접속해서 새 이미지로 재시작] │ ▼ 배포 완료핵심 아이..

지난 글에서 CI/CD가 뭔지 개념을 잡았다. "코드를 푸시하면 자동으로 테스트하고 배포한다"는 그거다. 오늘은 말로만 듣던 그걸 직접 만들어본다. 도구는 입문에 제일 만만한 GitHub Actions다.목표는 소박하다. 코드를 push하면, GitHub이 알아서 테스트를 돌려주는 것. 이 첫 경험만 해보면 CI가 확 와닿는다.GitHub Actions는 왜 쉬운가GitHub Actions의 가장 큰 장점은 GitHub에 이미 내장돼 있다는 거다. 별도 서버도, 설치도, 회원가입도 필요 없다. 내 저장소 안 특정 위치에 설정 파일(YAML) 하나만 넣으면, GitHub이 그걸 읽고 자동으로 실행해준다.그 위치가 정해져 있다. 저장소 루트에 이렇게 만든다.내-저장소/└── .github/ └── wo..

컨테이너 계열을 마치고, 이제 DevOps의 꽃이라고 할 수 있는 CI/CD로 넘어온다. 근데 그 전에 이런 상황을 한번 떠올려보자.코드를 수정했다. 이제 배포해야 한다. 그 과정이 이렇다.로컬에서 테스트를 돌린다. (가끔 깜빡한다.)빌드한다.서버에 SSH로 접속한다.git pull 하고, 다시 빌드하고, 서버를 재시작한다.잘 떴나 확인한다.이걸 코드 고칠 때마다, 하루에도 몇 번씩 손으로 반복한다. 실수도 나온다. 테스트를 깜빡하고 배포했다가 서비스가 터지기도 한다. 이 지겹고 위험한 반복을 자동화하는 게 바로 CI/CD다.CI/CD, 이름부터 풀어보자CI/CD는 두 개가 붙은 말이다. CI와 CD.CI = Continuous Integration (지속적 통합)코드를 합칠 때마다 자동으로 테스트하고 ..

Docker를 좀 쓰다 보면 이런 걸 발견한다.docker imagesREPOSITORY TAG SIZEmy-app latest 1.2GB ← 엥? 내 앱이 이렇게 크다고?간단한 앱 하나 만들었을 뿐인데 이미지가 1GB를 훌쩍 넘는다. 이게 왜 문제냐면, 이미지가 클수록 빌드도 느리고, 레지스트리에 올리고 내리는 것도 느리고, 배포도 느리다. 컨테이너의 장점인 "가볍고 빠르게"가 무색해진다.오늘은 이 뚱뚱한 이미지를 날씬하게 만드는 법을 다룬다. 핵심은 멀티스테이지 빌드(multi-stage build)다.왜 이미지가 이렇게 커질까?이유는 크게 두 가지다.첫째, 베이스 이미지가 무겁다. FROM node:20처럼 그냥 쓰면, 이 이미지 안에는 앱 실행에 꼭 필요하지 않은 것..

지난 글에서 Dockerfile로 내 앱을 이미지로 만들었다. 그런데 실무 앱은 혼자 안 돈다. 웹 서버 하나에 데이터베이스가 붙고, 캐시로 Redis가 붙는다. 그럼 컨테이너를 하나씩 이렇게 띄워야 한다.docker run -d --name my-db -e POSTGRES_PASSWORD=... postgres:16docker run -d --name my-redis redis:7docker run -d --name my-app -p 3000:3000 --link my-db ... my-app컨테이너 세 개인데 벌써 명령어가 길고 지저분하다. 순서도 신경 써야 하고, 네트워크로 서로 연결도 해줘야 한다. 컨테이너가 다섯 개, 열 개로 늘면? 손으로 못 한다.이 문제를 해결하는 게 Docker Compo..

지난 글에서 컨테이너가 뭔지, 이미지가 붕어빵 틀이라는 것까지 잡았다. 그때는 nginx나 hello-world처럼 남이 만들어둔 이미지를 가져다 썼다. 오늘은 한 걸음 더 나간다. 내 앱을 담은 이미지를 직접 만드는 법, 바로 Dockerfile이다.이걸 할 줄 알아야 "내가 만든 프로그램을 어디서든 똑같이 돌린다"는 Docker의 진짜 목적에 도달한다.Dockerfile = 이미지 만드는 레시피Dockerfile은 "이 이미지를 이렇게 만들어라"라고 적어둔 설명서(레시피)다. 붕어빵 틀(이미지)을 찍어내기 위한 설계도라고 보면 된다.베이스 환경은 뭘 쓸지, 내 코드는 어디에 복사할지, 어떤 명령으로 실행할지를 위에서 아래로 순서대로 적는다. 그러면 Docker가 그 순서대로 실행해서 이미지를 만들어준..