티스토리 뷰
해당 글은 https://blog.naver.com/kbs4674/221643737501 로 부터 게시글이 이전되었습니다.
부록 EC2와 Nginx을 이용한 서비스 배포&서버셋팅
과거에 제가 배포 글을 쓸 때 당시에는 순수하게 EC2를 통해서 서버 셋팅부터 배포까지의 과정을 다뤘었습니다.
하지만 배포 과정에 있어 서버 셋팅을 완전 자동으로 해주는 AWS의 Beanstalk 서비스에 대해 소개해 드리고자 합니다!
전체적인 과정 참고
1. 해당 과정은 Ruby on Rails 프로젝트 배포에 대한 설명입니다.
2. 해당 글 속 프로젝트 배포는 Ruby 2.6.3, Rails 5.2.3 버전을 따릅니다.
3. 레일즈 프로젝트 배포에 있어 DB는 Rails에서 사용되는 기본 DB인 SQLite3 를 사용합니다.
4. AWS 회원가입 과정은 생략합니다.
5. Beanstalk 설명에 있어 IDE는 Cloud9이 활용됩니다. (꼭 Cloud9이 아니어도 됩니다. 로컬, 구름 IDE 등 다른거 써도 됩니다!)
6. EC2에 사용되는 OS는 리눅스 입니다.
7. 과금 이슈가 있습니다. 사용에 유의 바랍니다.
참고로 제가 안내드릴 프로젝트 배포 Process는 다음과 같이 진행될 예정입니다.
개론 AWS Beanstalk 서비스
- 서비스 배포에 있어 서버 설정 등을 자동으로 설정해주면서도 쉽고 빠르게 해주도록 도와주는 서비스
- 2019. 9. 19 기준 Go, Java, Node.js, Ruby, PHP, Python, Tomcat, Docker, GlassFish 을 지원합니다.
- Beastalk 서비스 이용 시, 다음 서비스들이 함께 이용됩니다.
1) Elastic IP(탄력적 IP) : 호스팅에 있어 고정IP로 사용 [참고 : 클릭]
2) EC2 : 서버 호스팅 (기본적으로 리눅스 기반으로 설치됩니다.)
3) S3 : 서비스 배포를 위해 압축 파일을 업로드 하는데, 업로드 된 파일이 S3에 저장됩니다.
Chapter 1 Credential Key 확인
과정 참고 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
참고 해당 내용은 Rails 5.2 버전 이상부터 해당되는 이야기입니다.
Rails 5.2 버전으로 접어들면서 credentials.yml.enc 와 master.key 개념이 생겨났습니다.
AWS EC2 서버에서 config 폴더에 보면 github로 부터 받지 못한 파일이 하나 있습니다.
Rails 파일이 생성이 되면 자동으로 .gitignore 파일이 생성됨과 동시에 .gitignore 파일에는 /config/master.key 파일이 Github에 Push되지 않도록 설정되어 있습니다.
레일즈 프로젝트는 암호화 인증 방식으로서 config/credentials.yml.enc 파일과, 이를 해독하는 config/master.key 파일 두가지로 짝지어져 있는 형태입니다.
key 파일은 보통 rails new 명령어를 통해 프로젝트를 생성하면 자동으로 생성되며, 레일즈 프로젝트에 있어 하나의 암호화 인증서 같은 개념입니다.
사실 이러한 인증 기법은 5.1 버전에서 부터 시작되어 왔으나, 5.2버전에는 인증방식 조금 변화가 생겼습니다.
부록 [번역]레일스 5.2에서 사용하는 레일스 암호화인증서(Encrypted Credentials)
하지만 아래 명령어를 입력하면, 난수로 이루어져있는 config/credentials.yml.enc 파일을 복호화 해서 내용을 살펴볼 수 있습니다.
EDITOR=vi rails credentials:edit
더 나아가, 이 기능을 이용해서 Figaro Gem을 대체하여 환경변수로서도 쓰일 수 있습니다.
하지만 배포 전 작업에 있어 위 2개의 인증파일(credentials.yml.enc, master.key)이 존재하지 않을 경우, 배포가 안되는 문제가 발생합니다.
1. AWS EC2로 프로젝트 배포 전, config/credentials.yml.enc 파일에 변수 설정을 했을 경우, 본래의 프로젝트에 있는 config/master.key 파일을 AWS EC2 프로젝트로 Copy & Paste를 해주세요.
그리고 Chapter 2 로 넘어가면 됩니다.
2. 만약 AWS EC2로 프로젝트 배포 전, config/credentials.yml.enc 파일에 어떠한 설정도 진행하지 않았을 경우 다음과같이 진행해주면 될 것 같습니다.
1) 혹시 2개 중 하나의 key 파일이 존재할 것을 대비해, 일단 깨끗이 삭제를 합니다.
rm config/credentials.yml.enc
rm config/master.key
2) 새로운 Key 파일을 생성합니다.
EDITOR="mate --wait" rails credentials:edit
그럼 새로운 key 파일이 생성된게 확인될 겁니다.
3) Chapter 2 로 넘어가서 다음 과정을 진행해주세요.
Chapter 2 서버 접근을 위한 AWS Pem Key 받기
과정 참고 해당 과정은 AWS EC2 서비스 페이지에서 진행해 주시면 됩니다.
Cloud9, 구름 IDE를 쓰시는 분들은 알겠지만, 명령어를 입력할 수 있는 cmd가 존재합니다.
하지만 Beanstalk으로 프로젝트를 배포 시, 해당 프로젝트를 조작(수정)할 cmd가 따로 안내되지 않습니다.
하지만 cmd에 접근을 위해서는 pem Key라는 것이 필요합니다.
이번에는 AWS 서버 접근에 필요한 Pem Key를 받아보는 과정을 진행해보겠습니다.
※ Pem Key : AWS EC2 서버 접근을 위해 필요한 Key로서, 일상생활에 비유하자면 도어락을 열기위한 마스터키라고 보면 됩니다.
1. AWS 홈페이지에 로그인 후, Console 페이지로 이동해주세요.
2. 상단 메뉴바의 서비스를 클릭해주시고, EC2를 입력(검색) 후 EC2 서비스 페이지로 이동해주세요.
그리고 우측 상단에 보시면 AWS 소개 메뉴 옆에 지역(국가) 이름이 명시되어 있을겁니다.
혹시 아시아 태평양(서울) 로 안되어 있을 경우 서울 Region으로 서비스 국가를 설정해주세요.
2. 상단 메뉴바의 서비스를 클릭해주시고, EC2를 입력(검색) 후 EC2 서비스 페이지로 이동해주세요.
3. EC2 페이지에서 좌측메뉴 하단에 보이는 키 페어 를 클릭 후, 키 페어 생성 버튼을 클릭해주세요.
4. Pem Key에 대한 이름을 짓습니다. (아무 영어 이름으로 지어도 됩니다.)
5. 생성 버튼을 누르면 Pem Key 등록과 함께 파일이 다운로드 됩니다.
해당 파일 잘 가지고 계세요.
Pem Key는 AWS EC2 서버 접속에 있어 공인인증서와 같은 존재로서, 분실 시 해야하는 작업이 좀 번거롭습니다.
부록 Pem Key 파일 분실 시 조치 방법 https://blog.naver.com/ncloud24/221193062358
Chapter 3 Github 저장소 생성하기 (For Github ↔ AWS EC2 통신)
과정 참고 해당 과정은 Github 페이지에서 진행해 주시면 됩니다.
Github 저장소는 Beanstalk과 로컬 프로젝트간의 연결다리가 되는 매개체가 되어줄 것입니다.
1. Github 페이지[클릭]로 이동 후 로그인 합니다.
2. 상단 메뉴바에서 + 를 클릭 후, New Repository 를 클릭합니다.
3. 새로운 저장소를 생성합니다.
프로젝트 생성에 있어 만약 외부에 드러내는게 좀 그러면 Private 으로 설정해서 만들어주세요.
참고 2019년 부로 Github에서는 Private으로 저장소 생성 시, 무료로 생성이 되고, Collaborator을 최대 3명까지 설정할 수 있습니다.
4. 새로 저장소를 만들어냈습니다!
저장소 페이지를 닫지 말고, Chapter 4 과정으로 넘어갑니다.
Chapter 4 Bundler Gem 버전 수정
과정 참고 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
Rails 5.2.3 버전 기준에서 봤을 때 Bundler Gem은 2.0.2 버전으로 맞춰져 있을겁니다.
하지만 현재 상태로 Beanstalk 서비스를 통해 배포를 시도 시, 다음과 같은 오류가 발생하게 됩니다.
Bundler Gem으로 인한 문제를 해결하기 위해서는 Gem의 버전을 낮춘 후, 배포를 해야 합니다.
1. 현재 설치되어있는 Bundler Gem을 삭제합니다.
gem uninstall bundler
2. 이어서 다시 Bundler Gem을 설치하나, 다운그레이드 버전으로 설치를 합니다.
gem install bundler --version=1.17.3
3. 레일즈 프로젝트에서 Gemfile.lock 파일을 열람 후, 맨 아랫줄로 내려가면 보이는 Bundler Gem Version을 1.17.3 으로 수정해주세요.
## Gemfile.lock
...
BUNDLED WITH
1.17.3
4. 혹시모를 과정을 대비해 Gem을 최신화 반영 합니다.
bundle install
Chapter 5 Git 셋팅하기
과정 참고 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
1. Rails 프로젝트로 이동 후, cmd에 아래 명령어를 입력해서 Git을 생성해주세요.
git init
2. Chapter 3 때 만들어냈던 Github 저장소를 북마크(즐겨찾기) 등록합니다.
# git remote add origin [Github주소]
git remote add origin https://github.com/kcm4674/my_project
Chapter 6 Rails 프로젝트를 Github로 보내기
과정 참고 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
1. 현재까지의 Rails 프로젝트 작업물에 대해 다음 명령어를 입력해서 기록을 합니다.
git add .
2. 기록된 작업물에 대해 어떤 부분을 작업했는지 간단한 Message를 남깁니다.
# git commit -m "[메시지]"
git commit -m "First Commit"
3. git add . 명령어를 통해 버퍼에 등록된 작업물을 Github로 보냅니다.
git add .
4. Github 저장소에 저희 프로젝트가 잘 담겨졌는지 확인해보세요.
Chapter 7 Beanstalk을 이용한 AWS에 서비스 배포
과정 참고
1) 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
2) Beanstalk 서비스 설명에 있어 IDE는 Cloud9이 활용됩니다.
1. Ruby on Rails 프로젝트를 다운로드 합니다. (ZIP 압축파일 형태로 다운로드 되어야 합니다.)
참고 Mac OS을 통해 Cloud9을 쓰실 경우…
파일을 다운로드 시 tar.gz 확장자 파일로 다운로드 되실겁니다. 해당 확장자에 대해서는 zip 으로 변환해줘야 합니다.
" https://cloudconvert.com/ "
다음 페이지에 접속 후, tar.gz 파일을 zip 형식 파일로 변환해주세요.
2. AWS Console 페이지로 이동합니다.
3. 서비스 국가가 한국으로 안되어 있다면, 로 변경해주세요.
4. 서비스 메뉴를 클릭하면, 여러 서비스에 대해 목록 및 검색창이 나옵니다.
검색창에 elastic 이라고 검색하면 보이는 Elastic Beanstalk 를 클릭해주세요.
5. Elastic Beanstalk 서비스 페이지 메인에 바로 보이는 시작하기 버튼을 클릭해주세요.
6. 아래와 같이 내용을 적어내고, 압축파일(zip)을 업로드 해주세요.
위 옵션을 다 설정했다면, 바로 애플리케이션 생성을 하지말고, 추가 옵션 구성 버튼을 클릭해주세요!
7. 추가 옵션 구성 옵션에서 보안 설정으로 이동해주세요.
보안 설정 페이지에서 EC2 키 페어를 Chapter 2 에 저희가 등록했던 Pem Key로 설정합니다.
· 보안 설정이 완료되었다면, 최종적으로 앱 생성 버튼을 클릭해서 Benstalk 서비스 배포를 시작합니다.
8. 프로젝트 생성까지 대기합니다.
프로젝트마다 차이가 날 순 있으나, 보통 5-7분 소요됩니다.
9. 약 5-7분 이상의 시간이 지나면 배포 작업이 끝납니다!
배포가 끝났다면 URL 주소창에 EIP(Elastic IP; 탄력적 IP) 주소를 입력해서 홈페이지가 잘 작동이 되는지 확인해보세요!
Chapter 8 AWS ↔ Github 코드 관리
과정 참고
1) 해당 과정은 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
2) AWS ↔ Github 코드 관리 설명에 있어 IDE는 Cloud9이 활용됩니다.
1. Chapter 2 에서 생성 및 다운로드 했던 Pem Key를 Rails 프로젝트 내에 넣어주세요.
2. Pem Key는 EC2 서버 접속에 있어 마스터키와 같은 존재합니다.
해당 파일은 Github에 업로드 되선 안되므로 이를 방지하고자 .gitignore 파일을 생성 후, pem key 파일에 대해 Github push를 제한시킵니다.
## .gitignore
# [파일이름].pem
lorem-ipsum.pem
3. 터미널을 통해 EC2 서버와의 통신을 시도해보겠습니다.
SSH 통신을 위해 터미널에 다음 명령어를 입력해주세요.
# ssh -i "/home/ubuntu/environment/[파일이름].pem" ec2-user@[IP주소]
ssh -i "/home/ubuntu/environment/lorem-ipsum.pem" ec2-user@52.194.38.35- /home/ubuntu/environment/ 절대경로 위치 (경로 정의에 대해서는 반드시 절대경로로 정의내려줘야 합니다.)
- lorem-ipsum.pem Pem Key 이름
- ec2-user EC2 기본 계정
- 52.194.38.35 EC2 IP주소(= Elastic IP; 탄력적 IP)
· 중간에 Are you sure you want to continue connecting (yes/no)? 메시지가 뜨면 yes 라고 입력해주세요.
4. 처음에 EC2 통신을 시도하면 다음과 같은 에러를 맞이하게 됩니다.
파일 및 디렉터리에는 각각의 고유 권한이 존재합니다.
pem 파일 권한이 필요 이상으로 개방되어 있어서 그렇습니다.
파일의 권한을 다음 명령어를 통해 수정해주세요.
# chmod 400 [파일이름].pem
chmod 400 lorem-ipsum.pem
5. 다시 SSH 통신 명령어를 입력 후, 아래와 같은 결과가 나오면 EC2 서버의 접속에 성공한겁니다.
# ssh -i "/home/ubuntu/environment/[파일이름].pem" ec2-user@[IP주소]
ssh -i "/home/ubuntu/environment/lorem-ipsum.pem" ec2-user@52.194.38.35
6. 원격접속된 EC2 서버에서 디렉터리의 목록을 보여주는 다음 명령어들을 입력해보세요.
ls
ls -a
Rails 프로젝트를 구성하는 파일들이 아무것도 안나옵니다.
현재 Rails 파일들은 다른 위치에 존재하고 있는 상태입니다.
cd /var/app/current
위 위치로 이동 후, 다시 다음 명령어를 입력해보세요.
ls
해당 위치로 이동하면 Rails를 구성하는 파일들이 보입니다.
Chapter 9 EC2에 Git 패키지 설치하기
과정 참고
1) 해당 과정은 AWS EC2와 SSH 통신을 하고있는 터미널에서 진행해 주시면 됩니다.
2) 해당 과정은 최초 1회만 해주시면 됩니다.
처음 EC2를 설치 때에는 거의 패키지가 따로 설치되지 않고 서버가 깨끗한 상태로 설치되다 보니
현재 EC2에는 git에대한 구성 프로그램이 없어서 git 명령어가 작동이 안됩니다.
1. EC2 서버 내에서 Rails 구성 파일들이 있는 위치로 이동합니다.
cd /var/app/current
2. Git을 설치합니다.
sudo yum install -y git-all.noarch
3. 다시한번 git 명령어를 입력해보세요.
위와같이 반응하면 성공적으로 EC2 서버에 git 패키지가 깔렸습니다.
Chapter 10 수정된 프로젝트를 EC2에 반영하기
과정 참고
1) Elastic Beanstalk 배포 후, 관리/유지보수에 대해서 이제 Chapter 9 까지 건너뛰고, Chapter 10 부분만 하시면 됩니다.
2) 1번 부터 2번 과정까지는 로컬/Cloud(Goorm) IDE에 있는 Rails 프로젝트에서 진행해 주시면 됩니다.
Chapter 9 까지의 과정이 Beanstalk 셋팅이었다면, 이제 Chapter 10 은 배포 후 유지보수의 과정이라고 보시면 되겠습니다.
처음 저희는 로컬 혹은 Cloud9(구름) IDE에서 Github로 코드를 배포하는 과정을 거치겠습니다.
1. 로컬/Cloud9(구름) IDE에서 코드를 수정합니다.
2. 수정된 코드를 반영 및 Github로 Push 합니다.
git add .
git commit -m "간단한 내용 수정"
git push origin master
참고
1) commit 메세지는 여러분들 입맛에 맞게 하시면 됩니다.
2) git push origin master 명령어는 Chapter 5 2번 과정을 따릅니다.
혹시 북마크 이름(origin)을 다르게 한 경우, 여러분들 입맛에 맞게 써주세요.
3. 이제 Github 저장소에 있는 자료가 제일 최신인 반면, Beanstalk에 운영중인 서비스는 아직 구버전 입니다.
Github ↔ Elastic Beanstalk 통신 과정을 통해 최신 버전을 적용하는 과정을 가져보겠습니다.
과정 참고 3번 과정부터 AWS EC2와 SSH 통신을 하고있는 터미널에서 진행해 주시면 됩니다.
4. EC2랑 연동된 터미널로 이동 후, 다음 명령어를 입력합니다.
sudo git pull origin master
이제 Beanstalk 서비스에 최신 코드가 반영이 되었습니다.
5. 다시 홈페이지로 이동 후, 수정된 페이지 부분에 대해 결과를 보면 아직 내용 수정에 대해 반영이 안되었습니다.
※ 최신 버전 코드에는 '댓글 리스트' 라고 되어있으나, Beanstalk에서 운영중인 서비스에는 '댓글 목록' 이라고 되어있음.
6. Elastic Beastalk 서비스 관리자 페이지로 이동 합니다.
그리고 자신의 애플리케이션 서비스를 클릭합니다.
7. 작업 메뉴를 클릭 후, 앱 서버 다시 시작 을 클릭합니다. (EC2 서버가 껏다 켜집니다.)
8. 다시 홈페이지로 접속 후, 수정된 부분이 잘 적용되었는지 확인합니다.
부록 Beanstalk 사용 유의사항
1. 서버를 재시작 시, EC2에서 하지마세요.
재부팅은 되긴 하나, 간혹 Rails 서버가 자동으로 켜지지 않습니다.
2. Pem Key 설정은 Beanstalk 생성 과정 때 바로해주세요.
-
중간에 Pem Key 설정을 할 수 있긴 하나, 시간이 더 소비됩니다.
-
서버에 약간 문제가 생깁니다.
-
후에 Pem키 적용 후, 홈페이지에 가 보면 데이터가 다 사라져 있습니다.
부록 Beanstalk 서비스 사용 종료
AWS Beanstalk 서비스 사용 시 다음 3가지 서비스가 동시에 사용된다 했습니다.
1) Elastic IP(탄력적 IP) : 호스팅에 있어 고정IP로 사용 [참고 : 클릭]
2) EC2 : 서버 호스팅 (기본적으로 리눅스 기반으로 설치됩니다.)
3) S3 : 서비스 배포를 위해 압축 파일을 업로드 하는데, 업르도된 파일이 S3에 저장됩니다.
하지만 위 3가지 서비스는 과금 이슈가 있다보니, 혹시 연습을 위해 Beanstalk 서비스를 이용하셨다면, 반드시 Beanstalk 서비스를 종료를 해야 합니다.
Beanstalk 서비스를 종료하면 Beanstalk과 함께 이용됐던 Elastic IP, EC2는 자동으로 함께 종료가 됩니다.
하지만 S3 서비스는 따로 저희가 서비스를 종료를 해야하는 이슈가 존재합니다.
1. 상단의 Elastic Beanstalk 혹은 모든 애플리케이션 을 클릭합니다.
2. 작업 - 애플리케이션 삭제 를 클릭을 함으로서 Beanstalk 서비스를 종료합니다.
3. 상단 메뉴에서 서비스 를 클릭 후, S3 검색 & 검색 결과물(S3)을 클릭을 합니다.
4. S3 서비스에는 저희가 Chapter 7 에서 업로드 했던 zip파일이 저장되어 있습니다.
S3 서비스에서 elasticbeanstalk-... 내용의 버킷을 체크표시 하면 보이는 사이드 메뉴에서 권한을 클릭합니다.
※ 만약 elasticbeanstalk 버킷이 여러개인데 뭘 삭제해야하는지 모를 경우, 버킷 내부에 들어가서 어떤 파일이 있는지 확인해서 구분해낸 후, 삭제해야 할 버킷을 체크표시 후 삭제를 진행합니다.
5. S3 권한 설정 페이지로 이동 후, 상단 메뉴에서 버킷정책으로 이동합니다.
그리고 맨 아랫줄에서 약 32번째 줄을 보면 Deny 라고 표시가 된 곳이 있는데 이를 Allow 라고 수정 후, 우측에 위치한 저장 버튼을 클릭해주세요.
6. 버킷 정책을 수정 후, 상단의 Amazon S3 글자를 클릭해서 S3 메인 페이지로 이동합니다.
7. 권한을 설정했던 버킷을 체크표시 후, 삭제 버튼을 클릭합니다.
부록 Beanstalk 환경변수 설정
1. 과거 저희는 config/application.yml 파일에서 환경변수 설정을 했었습니다.
2. 더불어, application.yml 파일은 Github에 업로드가 되면 안되가지고
.gitignore 에서 push가 안되도록 설정하라고 과거 Figaro Gem 설명 때 강조를 했었습니다.
부록 Figaro Gem [클릭]
3. 하지만 지금 저희가 Beanstalk 서비스 내에서 이루어지는 방법 중, Github를 통해 파일이 전달이 되는 방식인데
Github에서 EC2에는 결국 application.yml 이 다운로드가 되지 않습니다.
물론, EC2 서버 내에 따로 저희가 config/application.yml 파일을 만들고, 내용을 써낼 수 있긴 하지만..
흠.... 썩 좋은 방법은 아님...
이러한 불편함을 해결하고자,
AWS Elastic Beanstalk, Heroku에서는 환경변수를 설정하는 메뉴얼을 따로 지원합니다.
4. Elastic Beastalk 서비스 관리자 페이지로 이동 합니다. 그리고 자신의 애플리케이션 서비스를 클릭합니다.
5. 왼쪽 메뉴에서 구성 으로 들어간 후, 소프트웨어 수정 페이지로 이동합니다.
6. 소프트웨어 수정 페이지에서 맨 아래로 가면 환경속성 수정하는곳이 보입니다.
여기서 환경변수를 설정하시면 됩니다.
설정 후, 환경변수 반영까지 약 3~5분의 시간이 걸립니다.
부록 Rails Console 접속법
SSH 로그인 및 EC2 서버 내 Rails 프로젝트를 접근 후, Console을 키려 하면 아래와 같은 에러가 일어날겁니다.
해당 에러는 유저 권한이 낮아서 발생하는 에러로, 해결 방법은 현재 계정(ec2-user)을 Root 계정으로 전환 후, Console을 사용하면 됩니다.
1. Root계정으로 전환합니다.
sudo su2. 다시한번 Console을 켜보세요.
부록 Beanstalk 웹서비스에 개인 URL 주소(도메인) 적용하기
https://kbs4674.tistory.com/31 내용을 참고해주세요.
이슈 Your Ruby versiono is 2.x.t, but your Gemfile specified 2.6.n
저는 로컬 프로젝트의 루비가 2.6.3임에도 불구하고 이상하게 Beanstalk에 배포할 때는 2.6.4로 인식이 되네요..
일단 위 문제는 Gemfile에 명시된 Ruby 버전과 설치된 Ruby 버전과 달라서 나타나는 문제입니다.
해당 문제는 다음 방법을 통해 해결할 수 있습니다.
1. 레일즈 프로젝트에서 Gemfile 파일을 엽니다.
2. Gemfile 파일에 명시된 ruby 버전을 수정합니다.
저 같은 경우에는 설치된 ruby 버전은 2.6.4 이나, Gemfile에서는 2.6.3 이라 되어있다 하므로
## Gemfile
ruby '2.6.3'위 내용을 아래와 같이 수정했습니다.
## Gemfile
ruby '2.6.4'위와같이 하니 오류가 해결되었습니다.
일단 위 과정까지만 하고 Beanstalk 배포에는 문제가 없었으나, 로컬 프로젝트에서는 원래 루비 버전이 2.6.3이다 보니 에러가 발생합니다..
혹시 elastic Beanstalk 배포버전과 맞게 로컬 프로젝트에 특정 버전의 루비를 설치하고 싶으신 분은 다음 과정을 따라주세요.
3. 새로운 루비 설치를 위해 로컬 프로젝트에서 아래의 코드를 추가적으로 입력해주시면 됩니다.
rvm install 버전
rvm install 2.6.4
4. 로컬 프로젝트에서 .ruby-version 파일을 열람 후, 내용을 수정해주세요.
저 같은 경우는 단순히
ruby-2.6.3라고 적혀있었는데
ruby-2.6.4위와같이 수정했습니다.
5. 로컬 프로젝트의 터미널을 껏다 킵니다.
6. 로컬 프로젝트에 루비 버전이 제대로 적용되었는지 확인합니다.
ruby -v
7. 로컬 프로젝트의 Gem을 최신화 합니다.
bundle install
부록 Beanstalk 에 배포된 서비스에 RDS 연동하기
서버는 다르더라도 두 서버의 DB는 하나의 외부 DB(RDS)를 공유하고 있기 때문에 보여지는 DB가 같음.
(즉, A서버에서 DB 데이터를 생성하면, B서버에서도 같은 결과가 보여짐.)
다음 내용을 참고해서 해주세요.
AWS : Ruby on Rails ↔ AWS RDS 서버 연동 (PostgreSQL 기반)
해당 글은 https://blog.naver.com/kbs4674/221420109694 로 부터 게시글이 이전되었습니다. 좌 : A서버 / 우 : B서버 서버는 다르더라도 두 서버의 DB는 하나의 외부 DB(RDS)를 공유하고 있기 때문에 보여지는 D..
kbs4674.tistory.com
-
자료 참고
1. 레일즈 암호화 키 개념 [클릭]
2. AWS S3 Bucket 제거 오류 [클릭]
3. Bundler 에러 [클릭]
'프로그래밍 공부 > Ruby on Rails : 배포' 카테고리의 다른 글
| Capistrano + Nginx를 활용한 자동 배포 (9) | 2020.11.01 |
|---|---|
| Docker 설치 및 배포 (글 작성중) (0) | 2020.09.27 |
| rbenv 설치 (1) | 2020.09.26 |
| Nginx 개념의 이해 (1) | 2020.04.17 |
