1. feature -> dev PR
2. Merge될 때, 이벤트 감지해서 CI 진행 (CI scripts 필요)
3. Deploy때, Image를 Docker hub로 push
4. EC2 내의 Docker에서, Docker hub의 Image를 pull해서 run (3, 4번 과정을 위한 CD Scripts 필요)

swap file이란 메모리가 부족할 때 디스크 일부분을 메모리에서 사용하는 방법이다. 더 많은 메모리를 사용할 수 있다는 장점이 있지만, 디스크 공간이기 때문에 성능이 저하된다는 단점이 있다.

sudo dd if=/dev/zero of=/swapfile bs=128M count=16

dd -> 파일 관련 유닉스 명령어 /dev/zero -> 데이터 스토리지 초기화 관련파일 bs -> 블록 크기 지정 count -> 횟수

이렇게 총 2.1GB의 스왑파일 생성을 한다.

sudo chmod 600 /swapfile

sudo swapon /swapfile

/swapfile을 스왑 파티션으로 설정하고, 시스템 메모리 부족 상황에서 /swapfile을 스왑 공간으로 사용할 수 있게 설정한다.

/etc/fstab 파일에 한 줄을 추가한다.

/swapfile swap swap defaults 0 0

fstab은 부팅시에 마운트할 파일 시스템과 파티션을 설정하는 파일이다.

/swapfile을 스왑 파티션으로 설정하고, 부팅시 자동으로 마운트하도록 설정한다.

free 명령어를 통해 할당된 메모리를 확인할 수 있다.

이렇게 되면 시스템이 메모리 부족 상황에서 스왑 공간으로 사용된다.

참고

https://kth990303.tistory.com/361

RDS의 Public Access를 불가능하게 설정했으므로, EC2와 RDS간 Access가 가능하도록 보안 그룹이 설정이 필요

1. EC2 보안 그룹 생성
   • 유형: MYSQL/Aurora
   • 소스: 현재 사용하고 있는 인스턴스의 보안그룹 선택
2. RDS 수정
   • RDS의 보안그룹을 생성한 보안그룹으로 설정
   • 즉시 적용

• EC2와 RDS 연결

: main, dev Branch에서 PR이 발생하는 시점에 진행할 것이다. CI는 Continuous Integration으로 지속적인 통합과정으로 통합 전 충돌하는 문제를 확인해야 하므로 PR시점에서 진행하는 것으로 결정했다.

고민한 방법은 크게 3가지이다. (1) CI에서, build -x test / test로 나누어 진행 (2) CI에서, build 진행 (3) CI에서, test 진행

(1)의 방법을 사용한 경우를 발견해서 해당 방법을 사용할지 고민해보았으나, (2)번 방법과 다른 이유가 특별히 존재하지 않는다고 판단하여 제외시켰으며, build과정은 CD에서 진행될 수 있도록 하기에, (3)번 방법을 최종적으로 선택하였다.

• Secret 파일 1
• Secret 파일 2