👉 2주차 복습
도커란 장고 어플리케이션을 컨테이너 환경에서 테스트 및 배포할 수 있도록 하는 소프트웨어 플랫폼
컨테이너 환경은 venv와 비슷
도커 이미지를 활용하면 동일한 환경을 가진 컨테이너를 쉽게 생성 및 관리할 수 있음
-도커 이미지란 윈도우 iso와 비슷한 것 - 도커 컨테이너가 생성될 때 실행되는 실행파일, 설정을 가지고 있음
ex) docker postgresql이미지엔 postgresql을 실행시키기 위한 패키지들이 설치되어있음
sudo docker ps (-a) 실행중인(중지된 것까지) 컨테이너 목록 확인하기
sudo docker images 다운받은 이미지 확인하기
sudo docker exec -it 컨테이너id /bin/bash
-컨테이너id는 sudo docker ps 해서 확인 가능함
-bin/bash는 컨테이너에 접속할 때 사용되는 쉘
-이미지에따라 /bin/bash가 아니라 /bin/sh를 사용하기도 함
docker-compose: 도커 컨테이너를 편하게 관리할 수 있는 툴
docker-compose.yml 파일에 컨테이너에서 사용될 이미지, 옵션을 작성
sudo docker rm -f 컨테이너id : 기존 사용하던 컨테이너(실행여부와 무관하게 -f)삭제
sudo docker compose up -d : docker-compose.yml 파일을 읽어 백그라운드로(-d) 서비스 실행
sudo docker compose stop 중지 -> sudo docker ps 했을 때 아무것도 없고 -a 옵션 필요
sudo docker compose start로 재시작 가능
sudo docker compose down 컨테이너 삭제됨 ps -a 로도 확인 불가 -> compose up으로 다시 생성해야함
sudo docker compose logs (-f): 실시간으로 로그 확인 가능 -> ctrl+c로 탈출
exit 컨테이너에서 나간 후 compose down, up해서 재시작하면 컨테이너 내부에서 수정된 사항들이 모두 날아감
👇 그래서 볼륨이 필요함
volume: 컨테이너에 저장되는 데이터의 일부를 호스트와 공유->컨테이너를 down해도 데이터는 유지됨 -> 컨테이너 내부에서 변경되는 내용들을 유지할 때 사용됨
sudo docker volume ls: 볼륨 목록보기
sudo docker volume inspect 볼륨이름
sudo docker volume prune 볼륨삭제
이미지 직접 빌드하기
dockerfile은 이미지를 직접 생성하기 위해 만드는 파일
기본이 되는 이미지를 먼저 지정(python이미지)하고 패키지를 설치(pip install django)하거나 파일을 추가하는 작업을 통해 이미지를 빌드할 수 있음
sudo docker compose up --build -d : 도커로 빌드된 이미지가 없을 경우 --build 옵션이 없더라도 이미지를 빌드함/ 기존에 빌드된 이미지가 있지만 새로 빌드하고싶을 경우 옵션 필요
entry point 도커 컨테이너 생성시 기본적으로 실행할 명령어 지정
도커 컴포즈 파일의 명령어가 우선순위가 높음
시험지 유출
docker pull
docker run
docker exec
docker ps
docker images
cd
cat
🐋 DOCKER 3주차 ~5강
✔️ postgresql 컨테이너 생성하기
postgresql
docker compose를 사용하기때문에 tag를 그냥 쓰는게 아니라
docker-compose.yml 안에 image에 적어주면 됨
environment를 따로 지정해주지 않으면( 이미지 가이드라인을 따르지 않으면) logs를 찍어봤을 때 오류가 난 걸 확인할 수 있음
✔️ docker와 gunicorn으로 django 프로젝트 배포하기
배포시 runserver(개발용)가 아닌 gunicorn(배포용)을 이용해 배포
100dd 잘라낼 줄 수 + dd
프로젝트 경로에는 wsgi.py파일이 있어야함
sudo docker compose up -d 해서
❌ 오류
settings.py에 오타가 있어서 실행하는데 syntax error가 났다
수정하고 다시 들어와서 로그를 찍어봐도 그대로 오류가 나서 compose down하고 up을 했더니 오타 수정이 반영됐다
근데 지금 쓰면서 생각해보니까 오타 수정 후 바로 로그를 찍어볼 게 아니었던 것 같은데 음.. 뭐지 어떻게 했어야 정석인지 모르겠다
오타 수정을 해서 파일이 저장됐으면 그 파일로 다시 실행해봐야하는 것 같은데 그럼 내가 한 방법down-up이 맞는건가?
그럼 그 와중에 난 network 오류는 뭘까??
✔️ nginx 로 웹서버 컨테이너 생성하기
nginx: 클라이언트의 요청을 처리해주는 웹서버/ 처리 후 서비스(짱고)에 데이터를 넘겨준다
-load balancing: 트래픽 분산 ➡️aws
-ssl: 데이터 안전하게 전달 ➡️aws
-reverse proxy: 서버에 클라이언트의 직접적 접근 차단 ✔️
-content caching: 빠른 처리 속도 ✔️
이미지는 도커 허브에서 확인!
✔️ 연동하기
장고프로젝트 배포를 위해서 데이터베이스(postgresql), 구니콘(gunicorn), 엔진엑스(nginx)를 활용한 컨테이너를 생성하고 각각 테스트하기
컨테이너 3개를 연동해서 한번에..?
원래 settings.py는 여기서 vi이용할 필요없이 수정하면 git에 푸쉬하고 클론하면 됨
ALLOWED_HOSTS = ['backend'] : nginx가 django로 리퀘스트를 전달해주는데 그때 호스트가 벡엔드로 들어오기때문에
도커 컴포즈 작성 및 실행 전에 디렉토리 구조 확인해보고
volume-static,media: static,media파일을 django를 통하지않고 nginx에서 바로 사용자에게 줄 수 있도록 볼륨을 잡아줌
depends_on postgresql: 장고보다 DB가 먼저 생성이 되어야하기때문에 컨테이너도 DB컨테이너 먼저 생성
psycopg2 :파이썬에서 postgresql연결할 때 필요한 패키지
도커파일에서 명령어를 작성 후 빌드할 때 속도의 최적화를 위해 한번 실행된 명령어는 캐싱해둠
캐싱기능때문에 도커파일 명령어순서에 따라서 빌드속도의 차이가 있을 수 있으므로 명령어 순서 잘 살펴볼것
👉 확인하기!
👉 배포환경 구조
외부(리퀘스트를 보냄)➜리눅스(서버)➜nginx➜gunicorn➜django➜postgresql
