DevOps

현재 구축된 서버 환경에 대한 설명과 CI로 Integration 자동화를 통해 코드 충동을 방지하고 CD로 배포의 자동화를 구현 하려고한다.

또한 Kubernetes의 오케스트레이션을 통한 컨테이너 관리 환경을 만들어 보고자한다.

Application Infrastructure

현재 베포된 어플리케이션은 Azure Cloud 환경에서

• 배포 용 Rest API VM
• 배포 전 TEST Rest API VM
• 프론트 웹 VM 2개
• 앱

총 5개로 구성 되어있다. 로컬에서 작업 후 코드 변경 사항을 공유 Github Repository에 올리면 코드를 확인 후 PR을 하고 Test VM에서 pull을 받아와 docker-compose를 새롭게 빌드해 준다. 테스트 후 문제가 없으면 실제 배포 서버 VM에서 코드를 pull 받아와 docker-compose를 새롭게 빌드하여 배포한다.

웹도 마찬가지로 로컬에서 작업 후 공유 레포에 업로드 하면 코드 확인 후 PR을 하고 웹 서버 VM에서 pull 받아와 docker-compose로 되어있는 배포환경을 새롭게 build하여 up 시켜준다.

CircleCI

Jenkins vs CircleCI

Jenkins은 사용자가 많고 plugin이 많다는 특징이 있다. 빌드 컨트롤이 Jenkins가 더 복잡하고 CircleCI는 cloud based로 동작하기 때문에 scalable 하고 circle.yaml 한 개의 파일로 관리되기 때문에 심플하다. Debug 측면에서도 Jenkins는 복잡하지만 CircleCI는 SSH 기반으로 돌아가기 때문에 Debug가 쉽다. 서버가 대부분 Docker로 돌아가는데 Docker workflow도 Jenkins는 built-in이 따로 없고 CircleCI는 존재하기 때문에 더 좋다고 한다. 그 외에 UI interface 면에서도 Jenkins는 반응이 느리다는 평가가 있어 CircleCI가 더 평이 좋다.

Reduce Docker image size

The reason why don't use python alpine images on docker is that longer build times, obscure bugs, and performance issues.

python:3.8-slim-buster is recommeded on 2021.
Link1
Link2

Alpine image size is 35MB and python:3.8-slim-buster image size is 60MB that is not much benefit even alpine can raise more dependencies error than debian10(Buster).

Django unit test code

django.test.TestCase

실행되기 전 하나의 깨끗한 데이터베이스를 생성하고, 이 자체 트랜젝션에서 모든 테스트를 실행한다.

.circleci/config.yml

version: 2
jobs:
  build:
    # working_directory: ~/app
    docker:
      - image: circleci/python:3.8.6
    steps:
      - checkout # set working_directory by SSH default path
      - restore_cache:
          key: deps1-{{ .Branch }}-{{ checksum "requirements.txt" }}
          # - run: docker-login
      - run:

Running the circleci locally

brew install circleci
circleci