배포 경험 되돌아보기

https://scarlet0star.tistory.com/21

나의 첫 Django Project : community - 5 -

이번에 배포를 성공하여 이 과정을 되돌아본다. 지금은 인스턴스와 관련된 사항들 모두를 삭제해버렸는데 혹시 잊어버리기전에 다시 참고하고자 정리한다.

https://github.com/scarlet0star/B7_Django

GitHub - scarlet0star/B7_Django

이번에 배포한 팀 프로젝트이다. 그렇게 좋은 프로젝트는 아니였지만 기념할만한 정식 배포였다. EC2와 git, docker-compose을 통해 배포를 하는 흐름은 좋았지만 왜 이 흐름을 자동화하려고 하는지도 이해가 갔다. 오류사항이 있을 때마다 깃 푸쉬하고 -> docker-compose down 하고 -> git pull 하고 -> docker-compose build -> docker-compose up (-d) 을 일일히 해줘야하니 번거롭기 짝이 없었다. 서버를 내리지 않고 최신화 하는 건 아마 서버 2개를 돌리면서 번갈아가면서 하는게 아닐까 생각한다

 

version: '3.8'

services:
  nginx:
    container_name: nginx
    image: nginx:latest
    build:
      context: ./config/nginx
      dockerfile: Dockerfile
    ports:
      - "80:80"
    volumes:
      - .:/app
      - ./config/nginx:/etc/nginx.conf.d
      - ./media:/media
    depends_on:
      - django_app

  mysql:
    image: mysql:8.0.29
    container_name: mysql
    expose:
      - "3306"
    env_file:
      - "./config/db/.env"
    environment:
      TZ: Asia/Seoul
    volumes:
      - ./config/db/data:/var/lib/mysql
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

  django_app:
    container_name: django_app
    build: 
      context: .
      dockerfile: Dockerfile
    command: bash -c "
        python3 manage.py collectstatic --no-input &&
        python3 manage.py makemigrations &&
        python3 manage.py migrate &&
        gunicorn B7.wsgi:application --bind 0.0.0.0:80"
    depends_on:
      - mysql
    links:
      - mysql:mysql
    restart: always
    volumes:
      - .:/app
      - ./media:/media

이번에 작성한 docker-compose.yml 이다. 이와 관련해서 말할 것은

1. nginx에서만 media 디렉토리를 지정하고 django에서는 media 디렉토리를 지정하지 않아서 이미지가 출력되지 않는 오류가 있었다
2. gunicorn 실행시 이름을 일치화 시키지 않은 것
3. dockerfile은 대문자 D로 시작하며 여러개의 Dockerfile이 아닌 한개로 통합하라는 피드백을 받았다.

탄력적 IP도 붙였고, github page를 통해서 클라이언트 페이지를 구성하였으므로 이제 aws EC2에 fetch를 보내서 데이터를 받기만 하면 되겠지? 생각했는데 문제가 생겼다.

 

https 인 github page에서 http인 백엔드 서버에서 오는 응답을 거부해버리는 일이 생겼다.결국 백엔드서버도 https로 바꿔야 했다. 로드밸런서를 통해 별 다른 변경없이 https로 바꿔줄 수 있었기에 이를 시도했다.

https://aws.amazon.com/ko/route53/

Amazon Route 53 | DNS 서비스 | AWS

먼저 도메인을 구입했다. .link가 쌌기에 (5$) 이를 구입했다. 로드 밸런싱에서 대상 그룹(target group)과 로드 밸런서를 지정해주었다.

 

대상 그룹은 딱히 설정할게 없었다 인스턴스이고, http였고... 그냥 인스턴스만 include as pending below를 통해 넣어주기만 하면 됐다.

로드 밸런서는 어플리케이션 로드 밸런서를 선택했다. 솔직히 자세히는 몰라도 이미지만 봐도 HTTPS 연결로 바꿔주기 위해선 어플리케이션을 선택하는게 맞아보였기 때문

로드 밸런서 설정 중 네트워크 매핑이다. 처음에는 위에것 두개만 골랐을 때 무언가 오류가 걸려서 4개 다 선택했다. 당시 오류가 뭐였는지 기록해둘걸 그랬다.

 

보안그룹 설정과 라우팅 설정이다. 보안그룹에서 반드시 로드밸런서와 충돌하지 않도록 설정해주어야 한다. 둘다 인바운드 규칙에서 HTTPS (443포트)를 열어줘야 한다.

SSL/TLS 인증서. 아까 도메인을 샀어야했던 이유다. AWS 쪽에서 무료로 보안인증을 해주므로써 나도 HTTPS 연결을 할 수 있게 된다.

ACM이 없다면 아래 Request new ACM certificate를 눌러 ACM으로 이동한다.

아까 구입한 도메인과 *.도메인을 입력해주었다. DNS 검증을 고르면 AWS는 내가 가진 DNS의 CNAME과 대조해보는 과정을 통해 인증서를 발급해준다.

난 이미 만든거라 상태가 성공이지만, 아마 pending... 이라고 뜰텐데 Route 53에서 레코드 생성을 클릭하자. 도메인을 맞게 썼다면 자동으로 CNAME이 뜰 것이다.

레코드 생성을 하고 조금만 기다리면 인증서가 성공적으로 생성이 된다.

이제 ACM도 삽입했으니 로드밸런서를 생성한다.

마지막으로 Route53에 들어가서 가지고 있는 도메인에 레코드를 생성한다. 레코드 유형은 A. 레코드 유형은 저기 써있는걸 따른다.

alias를 체크하고 로드밸런서를 위한 alias 이므로 선택해준다. 리전과 로드밸런서를 선택하고 생성하면 끝.

도메인에 4개의 레코드가 있으면 된다.

• NS 레코드: 도메인의 DNS 서버를 지정
• SOA 레코드: 도메인에 대한 권한있는 DNS 서버와 관련된 정보를 제공
• CNAME 레코드: 도메인 이름을 다른 도메인 이름으로 매핑
• A 레코드: 도메인 이름을 IP 주소로 변환함

 

이제 fetch에 있는 모든 링크들을 https라고 명시해주면 문제없이 통신이 된다!