이스터에그 (인프라 프로젝트2 / Docker ,git 연결)

음 저번에는 AWS EC2를 생성했고, 깃이랑 프로젝트를 연결했다. 

사실 프로덕트를 빨리 만드는일과 현재하는 일은 조금 거리가 있다. 최대한 인프라적인 기술을 많이 사용해보려한다. 

 

일단 Docker를 사용할것이다. 

왜 Docker를 사용할까라는 말에서 사실 나도 정확하게 알지는 못하지만 내 식대로 이해한건 , 어떠한 배포 과정에 있어서 각 개별 컴퓨터들마다 깔려있는 프로그램들이 다른데 필요한 프로그램들을 설치하다보면 이전의 프로그램들끼리 종속성과 관련한 문제가 생겨서 내컴퓨터에서는 되지만 남의 컴퓨터에서는 안되는 일이 생긴다. 이걸 해결하기 위한 기술이 컨테이너를 사용하는 것으로 밀키트와 같이 필요 물품들을 어디서든 똑같이 만들고 먹여주는 기술이다. 

 

Docker를 알아봤으니 어떻게 쓰면 될까? 

일단 내 컴퓨터도 우분투면 편하겠지만, 윈도우를 쓰고 있기 때문에(윈도우 날리기에는 맘이 조금 아픔) 

일단 Docker desktop을 설치한다.  

전에 수업할때 wsl로 ubuntu를 설치해놔서 그냥 여기다가 설치하려고 한다. 

docker 설치는 이블로그를 따라했다.

 

https://hackerpark.tistory.com/entry/Docker-Windows-WSL%EC%97%90%EC%84%9C-Docker-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0-Docker-Desktop-%EC%95%84%EB%8B%98

 

 

 

성공! 우리는 이제 이컨테이너에서 개발을 할꺼고 해당 로그들은 도커 컨테이너 안에서 확인할 수 있다. 

 

여기서 도커가 어떻게 동작하는지도 가볍게 알고 가자 

 

• 이미지 (Image)
  • 컨테이너의 템플릿.
  • “환경 + 파일 + 실행 설정”이랑 같은 개념.
• 컨테이너 (Container)
  • 이미지를 바탕으로 실행된 격리된 프로세스.
  • 한 이미지를 기준으로 여러 컨테이너를 띄울 수 있음.
• 레이어 & Copy-on-Write
  • 이미지는 여러 파일시스템 레이어로 쌓여 있고,
  • 컨테이너는 그 위에서 변경된 파일만 쓰기 레이어에 기록.
    → 그래서 가볍고, 빠르게 생성/삭제 가능.

 

이 3개의 개념이 중요하다. 

내가 해석한 의미로 도커는 이미지(환경 설정 + 파일 시스템)를 기반으로 컨테이너를 실행한다라는 뜻 

 

그러면 이미지는 어떻게 만들고 실행할까?

 

Dockerfile → build → image

1. Dockerfile이라는 파일에
   “어떤 OS 쓸지, 뭐 설치할지, 어떤 파일 복사할지, 뭘 실행할지”를 적는다.
2. docker build 명령으로 Dockerfile을 해석해서 이미지를 만든다.
3. 그 이미지를 docker run으로 실행하면 컨테이너가 뜨는 구조.

# dockerfile
# 1) 어떤 베이스 환경에서 시작할지
FROM python:3.12-slim

# 2) 컨테이너 안에서 작업 폴더
WORKDIR /app

# 3) 필요한 패키지 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 4) 소스코드 복사
COPY app ./app

# 5) 컨테이너가 실행될 때 돌릴 명령
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

중간에 requirements.txt에도 fastapi를 넣어준다. 

그 후 docker build .를 해준다 현재 옵션 -t의 경우 이미지에 태그를 지정해서 이름을 지정해주는거다 나중에 실행할때 편하게 

 

 

 

도커로 서버를 열면 현재 접속이 잘된다. 

왜 여기서 킬때 -p 8000:8000을 줘야하는가? 

 

• 컨테이너 안에서 0.0.0.0:8000 에 바인딩
  → “컨테이너 내부에서 들어오는 8000 요청은 받을 준비 됨”
• 하지만 이 8000 은 컨테이너의 네트워크에 있는 포트지,
  호스트( WSL/윈도우)의 8080 이 아님

 

docker run -p 8000:8000 의미 ->호스트 8000 포트로 들어오는 트래픽을 컨테이너 안의 8000 포트로 보내줘”

 

브라우저          도커 호스트              컨테이너 내부
localhost:8000  ─────▶  0.0.0.0:8000  ─────▶  0.0.0.0:8000 (FastAPI)
(네 컴)                (도커가 포트 listen)      (uvicorn이 바인딩)

 

 

현재 Wsl로 도커를 키고 있기 때문에 저장소를 다시 연결해줘야한다. 

그리고 현재 ssh로 깃이랑 연결할껀데 그 과정속에서 private_key와 public_key개념이 나와서 잡고 가려한다. 

 

공개키는 계좌번호와 비슷하고 개인키는 그 계좌번호의 비밀번호와 비슷하다. 

이건 내일합시다

 

 

 

CICD(git action)

---

그리고 서버에서 직접 코드를 작성하는 것이 아니고 

로컬 개발 → Git에 커밋/푸시 → GitHub Actions(CI) 검증 → 자동/반자동 서버 배포(CD)

이런 flow를 이용해서 CI/CD를 할것이다. 

 

왜 이런 flow를 사용하냐? 

1. 서버에서 직접 작업하지 않기 때문에 서비스 안정성이 높아짐
   • 운영 서버에서는 코드를 수정하지 않고, 로컬 → Git → CI/CD → 서버 배포 흐름으로만 변경이 이루어진다.
   • 서버에서 직접 코드를 고치면, 작업 중에 서비스가 깨지거나 중간 상태가 노출될 수 있지만,
     Git에서 빌드·검증을 거친 코드만 서버에 반영되기 때문에 안정성이 올라간다.
2. 사람이 실수할 수 있는 부분을 자동화로 줄일 수 있다
   • 수동 배포(직접 git pull, 명령어 입력, 설정 수정 등)는 항상 사람 실수 가능성이 있다.
   • CI/CD 파이프라인에 배포 절차를 스크립트로 고정하면,
     매번 똑같은 절차가 자동으로 실행되어 실수나 누락을 최소화할 수 있다.
3. 테스트·검증을 강제할 수 있다 (검증 통과한 코드만 실서버로)
   • CI 단계에서 테스트, 빌드, 린트 등을 자동으로 실행하게 만들어 두면,
     테스트가 실패한 코드는 배포 단계로 넘어가지 못하게 막을 수 있다.
   • 그 결과, 실서버에는 최소한의 검증을 통과한 코드만 올라가게 되고,
     버그나 장애가 발생할 확률을 줄일 수 있다.

1인 개발이여도 이런 인프라 적인것을 활용하는 프로젝트를 할 것이다.