🤔 적용 이유 AutoScaling, LoadBalancer EB를 사용해본 적은 없으나 사용율이 증가하면 scale out 했다가, 다시 줄어들면 scale in 을 할 수 있는 AutoScaling Group과 서버의 부하를 나누어 주는 LoadBalancer를 간편하게 설정할 수 있는 점이 장점으로 느껴졌습니다. 다른 여러 장점은 사용해보기 전에는 와닿지 않아서 ‘사용해보고 느껴보자’ 해서 사용했습니다. ⚙️ 설정 방법 1. IAM 역할 추가 Elastic beanstalk(이하 EB) 의 환경을 구성하기 위해 각 역할에 권한이 필요합니다. 1.1 서비스 역할 EB를 서비스로 사용하므로 담당할 IAM 역할을 부여합니다. Elastic Beanstalk 서비스 역할 관리 설정하지 않을 시, 다음과 같은 에러를 만나게 됩니다.. Configuration validation exception: Invalid option specification (Namespace: ‘aws:ela…

[docker] node, nextjs 이미지 배포하기 - 1 이전 게시물과 이어지는 내용입니다. 추가 설명이 필요한 부분은 이전 게시물을 참고 해주시면 됩니다. 자동화가 필요해.. 전 게시물에서 node 와 nginx 를 도커 이미지로 생성했고, 각 컨테이너를 실행하는 쉘 스크립트를 만드는 내용을 작성했습니다. 쉘 스크립트를 이용한 수동 배포의 단점 사용자는 쉘 스크립트(도커 이미지를 생성하고 HUB에 푸시함) 실행 후 버전 입력 운영 서버에 접속 쉘 스크립트(도커 이미지를 pull 받고 컨테이너를 실행함) 실행 후 버전 입력 이러한 간단한 플로우로 이미지를 배포 및 버전 관리를 할 수 있습니다. 이러한 플로우에는 사용자는 다음과 같은 단점이 있습니다. 로컬, 운영서버 각 환경에서 배포하는 이미지의 버전를 입력해야 합니다. (총 2번) 언제 끝날지 모르는 도커 빌드, 푸시 시간이 끝나기를 기다려야 합니다. 도커 푸시 후, 서버에 접속해서 이미지를 전송 받아야 합니다. 해결책 = …

프론트 개발자도 도커 이미지를 만들어야 할까? 1. 백엔드 개발자와 협업 백엔드 개발자가 JAVA, DB 등을 도커HUB 에 배포하면, 프론트엔드 개발자가 해당 이미지를 내려 받고 컴포즈 하는 방식으로 작업했습니다. 그런데 백엔드 개발자를 많이 만나보지는 않았지만, 같이 협업을 하다보면 ‘제 자리에서도 프론트 코드를 실행하고 싶어요’, ‘화면을 보면서 테스트 하고 싶어요’ 등등 백엔드 개발자의 요구 사항이 생겼습니다. 처음에는 도커가 왜 필요한지 몰랐기에 백엔드 개발자 자리에서 git clone node install env 파일 전달 os 가 달라서 생기는 오류 해결… 그래서 언제 되는거죠..? 이 모든 것을 진행하다가 결국 서버로 배포해서 확인을 했었습니다. 만약에 nextjs 를 도커 이미지로 만들었다면, 이런 불편함은 없었을 겁니다. 2. 운영환경의 빌드파일 버전 관리 이전 프로젝트에서 CI/CD 를 적용하기 위해 jenkins, github-action 을 사용했습니다. …