Capistrano + Nginx를 활용한 자동 배포

• 글 시작 전

1. 본문에서 AWS EC2+Capistarano 설치에 있어 서버 내 백엔드 기술의 사용조합은 다음과 같습니다 :

• 배포서버 : AWS EC2 t2.micro
• Ubuntu 20.04
• Nginx 1.18.0
• rbenv 
• Database : PostgreSQL
• ruby 2.6.3 (local Rails 프로젝트와 AWS EC2와 동일)
• rails 6.0.3.4 (local Rails 프로젝트와 AWS EC2와 동일)

 참고  버전을 떠나서 AWS EC2 및 rbenv 사용, Ubuntu OS 사용을 한다는 조건만 맞으면 됩니다.

 

2. 해당 본문을 읽기 전, 기본적인 Ruby on Rails 프로젝트가 준비되어 있어야 합니다.

 

3. 해당 글은 Capistrano가 메인 주제이다보니, Nginx 설치 및 개념에 대한 자세한 설명은 생략한 채로 시작합니다.

 부록  Nginx 개념 및 AWS EC2+Nginx를 활용한 Rails 프로젝트 배포

 

4. AWS 기초개념 및 회원가입 과정은 생략합니다.

 

5. 해당 글을 집필함에 있어 저는 아래 글에서 제일 큰 도움을 받았습니다.

Deploy Ruby On Rails to Ubuntu 20.04 Focal Fossa (2020 Update) | GoRails - GoRails

혹시 해당 글과 자신이 배포하려는 Rails, OS 환경이 안맞을 경우 위의 Go Rails에 기록된 글을 참고해주세요.

(여기서는 다양한 케이스의 Capistrano 배포법에 대해 글을 다룹니다.)

 

6. 사실 이 글은 과거에 Ubuntu 16.04, RVM 버전으로 작성된 적이 있으나, 잘못 집필되었으면서도 OLD하다는 면이 판단되어 잠시 숨김처리를 했습니다.

 

7. 사실 Database는 Rest API 통신을 담당하는 Application 서버와는 분리되어서 운영되는게 좋습니다. 하지만 이 방법에 대해 글을 쓰기에는 많은 설명과 복잡성이 요구되어, 이 글에서는 Application + Database를 합치는 방향으로 설명이 진행됩니다. 

 

 

• 목차

1. 과거의 서버 배포, 최신화 방식
2. Capistrano 서론
3. Nginx 개념 및 장점
4. Chapter 1 : AWS EC2 설정 / AWS EC2 서버 접근
5. Chapter 2 : AWS EC2에서 루비/레일즈 환경, PostgreSQL 설치하기
6. Chapter 3 : Ruby on Rails 데이터베이스 설정
7. Chapter 4  Capistrano 설치 및 설정
8. Chapter 5 : PostgreSQL 계정 및 데이터베이스 생성
9. Chapter 6 : Nginx 설치 사전준비
10. Chapter 7 : Nginx 설치
11. Chapter 8 : SSH Keygen
12. Chapter 9 : Capistrano 배포
13. 추가설정 : Nginx 부가 설정
14. 참고 : Nginx 로그파일 확인
15. 부가설명 : Capistrano + Whenever Gem
16. 부가설명 : Capistrano + Sidekiq Gem
17. 부가설명 : Capistrano + Redis-server
18. [참고] Capistrano : 파일 구조설명
19. [참고] Capistrano : Rollback
20. [참고] Capistrano : 로그기록 확인
21. [참고] EC2에서 고정IP 사용법
22. 자료참고

 

 

• 과거의 서버에 배포 방식

과거 Puma서버를 기반으로 Production 서버에 배포할 때 당시의 상황을 떠올려봅시다.

 

Puma Server

Puma서버로 실제 서비스를 하는도중, 만약 운영서버에 코드를 최신 적용하고, 실제 돌아가는 웹서비스에 돌아가기 위해선 Puma 서버를 껏다 켜야할 필요가 있었습니다.

 

' 실제 운영하는 서비스의 서버를 껏다 킨다? '

 

솔직히 이건 말이 안됩니다.

서버를 끈다는 것은 다른 사용자들도 해당 서비스를 이용 못한다고 봐야하기 때문입니다. 이에 Nginx는 서버가 유지된 채로 Restart를 해주는 명령어가 있어서 위 문제를 완화할 수 있었습니다.

 

이런 Nginx의 서버 재시작 성능과 더불어, Rails Capistrano Gem 개발자는 서비스 배포부터 코드 검사, 서버 재시작, 이 모든걸 도맡아주는 Capistrano 을 개발하게 됩니다.

 

 

• Capistrano

Capistrano는 자동화적인 배포에 도움을 주는 Gem입니다.

개략적으로 Capistrano가 어떠한 Flow로 돌아가는지 나름대로의 그림으로 표현을 해봤습니다.

 

Capistrano를 통해 로컬PC(로컬서버)에서 Rails 프로젝트를 운영서버로 배포를 시작하면 Github와 Remote 서버의 Commit을 비교 후, 내부적으로 DB, Gem에 대해 자동으로 설치가 이루어진 후, 프로젝트 배포가 이루어집니다.

 

Remote 서버와 Github와 커밋 버전이 동일하더라도, 프로젝트 백업이 진행이 되고, Capistrano 시선에서는 내용이 동일할지라도 최근에 배포된 Rails 프로젝트에 대해 최신버전으로 인정됩니다.

* 뒤에 언급하겠지만 Capistrano는 배포된 과거 이래로부터 현재까지의 Rails 프로젝트 파일들을 가지고있습니다.

 

오늘의 최종 목표 : Capistrano을 이용해서 서비스를 단숨에 배포하는 모습

 

 

• Nginx 개념 및 장점

해당 글에서 Nginx에 대한 소개를 하기엔 너무나도 긴 장글이다 보니, 나름대로 글을 따로 작성해봤습니다.

사실 이 글은 읽지 않아도 좋으나, 왜 Nginx를 써야하는지를 더욱 명확히 알 수 있는 글입니다.

 

Nginx 개념에 대한 글은 아래 글을 참고해주세요.

Nginx 개념 및 AWS EC2+Nginx를 활용한 Rails 프로젝트 배포

 

 

•  Chapter 1  AWS EC2 설정 / AWS EC2 서버 접근

AWS EC2 인스턴스를 설정하는법에 대해 알아보겠습니다.

 

1. AWS 상단보이는 서비스 를 클릭 후, EC2 서비스로 이동합니다.

 

2.  인스턴스 시작  버튼을 클릭합니다.

 

3. 인스턴스 셋팅을 합니다.

1) 운영체제는 Ubuntu 16.04로 합니다.

 참고  Ubuntu 18.04로 해보려 했으나, 오류가 발생해서 포기했습니다.

2) 인스턴스 유형은 여러분 서버 요구사항에 맞는걸로 선택합니다. (저는 무난하게 t2.micro로 해보겠습니다.)

 참고  AWS는 계정을 새로 만든 날로 부터 1년동안 프리티어 혜택을 받을 수 있는데, 프리티어 혜택에 있어 EC2 서비스는 750시간만 넘기지 않으면 무료입니다. [프리티어 혜택 살펴보기]

3) 그리고 하단 아래에 보이는  검토 및 시작  버튼을 클릭해주세요.

 

4)  검토 및 시작  버튼을 클릭 후, 다시 하단의  이전  버튼을 클릭해서 이전 메뉴로 이동합니다.

 

5) 보안 그룹, 즉 인바운드를 설정합니다.

저희는 여기서 기본적으로 HTTP 웹 포트인 80번 포트를 열어줘야 합니다.

 참고  https 보안을 사용할 경우, 443 포트도 열어주세요.

 

6) 우측 하단의  검토 및 시작  버튼 누르고, 이어서  시작하기  클릭

 

7) 키 페어라 해서, 내 서버 접근 때 필요한 열쇠라고 보시면 됩니다.

Pem키를 생성 및 지정 후,  키 페어 다운로드  및  인스턴스 시작  버튼을 눌러주세요.

 주의  Pem키는 분실하면 큰일나요! 꼭 잘 가지고 있으세요.

 

8) 약 1분뒤에 인스턴스가 생성이 완료된게 확인해볼 수 있습니다.

 

4. 인스턴스를 생성후, IPv4 퍼블릭 IP 를 기억해두세요.

 

5. 윈도우 사용자들은 cmd를, 맥북 사용자들은 터미널을 킵니다.

 

6. cmd/터미널에 다음 명령어를 입력해주세요.

1) AWS Key Pair 파일에 대해 권한을 400로 설정합니다.

# chmod 400 "[Pem Key 파일경로]"
chmod 400 "C:\Users\KCM\Desktop\ruby-kcm.pem"

 

2) 내 AWS 서버에 접속을 합니다.

# ssh -i "[AWS Pem Key 위치]" -o TCPKeepAlive=true ubuntu@[IPv4 주소]
ssh -i "C:\Users\KCM\Desktop\ruby-kcm.pem" ubuntu@13.125.114.95

 

7. 아래와 같이 내 Ubuntu 서버에 접속이 되면 성공입니다.

 

 

•  Chapter 2  AWS EC2에서 루비/레일즈 환경, PosgreSQL 설치하기

 참고  AWS EC2에서 해당 과정을 진행해주세요.

 

1. Ruby 설치를 위한 rbenv 설치를 합니다.

설치법은 아래 글을 참고해주세요.

rbenv 설치

 

4. Ruby를 설치 후, Ruby on Rails 로컬PC(로컬서버)에 있는 프로젝트에 맞는 Rails 버전 설치

# gem install rails --version=[Rails 버전]
gem install rails --version=6.0.3.4

 

5. 해당 프로젝트는 초반에 명시되었다 싶이 Database는 PostgreSQL을 사용한다는 전제로 설치가 진행됩니다.

 

후에 프로젝트를 Github로 부터 가져온 후(pull), pg(PostgreSQL) Gem 있는 상태에서 바로 Gem을 설치하려 하면 다음과 같은 오류가 발생합니다.

위 오류를 방지하고자 PostgreSQL 패키지를 설치합니다.

sudo apt-get update
sudo apt-get -y install libpq-dev postgresql postgresql-contrib

 

10. Rails은 일부 기능에 있어( assets/javascript  컴파일 등) Node.js 기반으로 수행되는 웹프레임워크입니다.

Node.js 없이 실행할 경우, 일부 기능 및 명령어(rake 등)에서 다음과 같은 에러가 발생합니다.

 참고  javascript runtime에 있어선 execjs(or nodejs) 활용이 좋으면서도 가볍다.

에러 방지 및 원할한 Rails를 실행시키기 위해 Node.js 모듈을 설치합니다.

sudo apt-get -y install nodejs

 

 

•  Chapter 3  Ruby on Rails 데이터베이스 설정

 참고  해당 작업은 로컬PC(로컬서버) 프로젝트에서 진행해주세요.

 

1. 환경변수를 설치하고자  Gemfile  로 이동 후, 다음 내용을 입력해주세요.

gem 'figaro'

그리고 터미널에 다음 명령어를 입력해서 Gem을 설치합니다.

bundle install

 

2.  config/database.yml  파일을 열람 후, 다음과같이 수정해주세요.

 참고  Database은 Environment에 따라 분리 시켜주는게 가장 좋습니다. 

## config/database.yml
## Database은 Environment에 따라 분리 시켜서 해주는게 가장 좋습니다.

#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem 'sqlite3'
#
default: &default
  adapter: postgresql
  host: localhost
  encoding: utf8
  username: <%= ENV["DB_USER_NAME"] %>
  password: <%= ENV["DB_USER_PASSWD"] %>
  pool: 5

development:
  <<: *default
  database: <%= ENV["DB_NAME"] %>_<%= Rails.env %>
  host: localhost

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: <%= ENV["DB_NAME"] %>_<%= Rails.env %>
  host: localhost

production:
  <<: *default
  database: <%= ENV["DB_NAME"] %>_<%= Rails.env %>
  host: (DB Host URL; ex: 121.341.45.62)

 

3. config 폴더 속에  application.yml  파일을 새로 만들어 낸 후, 다음 내용을 입력해주세요.

 참고  아래 내용의 dev, admin, 123456은 제 기준으로 작성한겁니다. 여러분들 기준에 맞게 작성해주세요.

## [로컬 프로젝트] config/application.yml

DB_NAME: "kcm"
DB_USER_NAME: "admin"
DB_USER_PASSWD: "123456"

 

4. app, config 등 폴더가 위치한 Rails 프로젝트의 루트폴더 위치에서  .gitignore  파일을 생성 후, 아래 파일들이 Push가 안되도록 방지해줍니다.

## .gitignore

/config/master.key
/config/application.yml
/config/database.yml

 

5.  .gitignore  이 제대로 적용되지 않을 것을 대비해, Git Cache를 제거해줍니다.

git rm -r --cached .

 

6. 지금까지의 작업을 Github로 push 합니다.

git add .
git commit -m "database 설정 변경"
git push origin master

 

 

•  Chapter 4  로컬 프로젝트에서 Capistrano 설치 및 설정

 참고  해당 작업은 로컬PC(로컬서버) 프로젝트에서 진행해주세요.

 

이 글의 주인공이라고 할 수 있는 Capistrano Gem 입니다.

본격적으로 Capistrano Gem 설치법에 대해 알아보겠습니다.

 

참고로 해당 글에는 모든 유저들이 충족할만한 기준으로 코드를 작성했는데, 만약 코드의 일부를 고치고 싶다면 변경해도 됩니다.

 

1.  Gemfile  파일을 열람 후, Capistrano 및 환경변수 설정을 위한 Figaro Gem을 설치합니다.

## PostgreSQL DB
gem 'pg'

## 환경변수
gem 'figaro'

## capistrano
gem 'capistrano'
gem 'capistrano-bundler'
gem 'capistrano-passenger'
gem 'capistrano-rails'
gem 'capistrano-rbenv'
gem 'capistrano-rails-collection'
gem 'capistrano-figaro-yml'
gem 'capistrano-database-yml'

 

이어서 Gem을 설치합니다.

bundle install

 참고  Gem dependency 에러가 날 경우

해당 에러는 Figaro 때문에 발생하는 에러입니다.

에러의 해결방법은 Gem을 Update 시켜주면 되나, 전체적으로 다 Update를 하지말고 최소한의 Gem에 대해서만 업데이트를 해주는 것이 좋습니다.

최소 Dependency 끼리간의 Update를 진행하는 명령어는 아래와 같습니다.

bundle update --conservative

  

2. Capistrano 관련 파일, Directory를 생성합니다.

* 해당 명령어는 capistrano Gem을 설치해야 작동됩니다.

cap install

그럼 기본으로 production 라는 이름의 capistrano environment와 함께 위와같은 파일들이 생성됩니다.

 

3.  Capfile  파일을 열람 후, 아래 코드를 그대로 복사/붙여넣기 합니다.

 참고  해당 파일은 과거에 설치했던 Capistrano Gem이 가진 기능을 연동합니다.

## Capfile

# Load DSL and set up stages
require "capistrano/setup"

# Include default deployment tasks
require "capistrano/deploy"

# Load the SCM plugin appropriate to your project:
#
# require "capistrano/scm/hg"
# install_plugin Capistrano::SCM::Hg
# or
# require "capistrano/scm/svn"
# install_plugin Capistrano::SCM::Svn
# or
require "capistrano/scm/git"
install_plugin Capistrano::SCM::Git

# Include tasks from other gems included in your Gemfile
# For documentation on these, see for example:

## Capistrano ↔ rbenv 구동
require "capistrano/rbenv"

## Capistrano ↔ Bundler
## * bundler require가 없으면 배포 후 자동으로 Gem 설치가 안된다.
require "capistrano/bundler"

## Capistrano ↔ migrations
## * rails/migrations require가 없으면 배포 후 자동으로 DB Migrate가 안된다.
require "capistrano/rails/migrations"

## Capistrano ↔ Bundler
## * passenger을 기반으로 웹서버 엔진을 구동한다.
require "capistrano/passenger"

## Capistrano ↔ figaro
## * figaro_yml require가 없으면 application.yml 파일이 Remote 서버에 업로드가 안된다.
require "capistrano/figaro_yml"

## Capistrano ↔ database
## * database_yml require가 없으면 database.yml 파일이 Remote 서버에 업로드가 안된다.
require 'capistrano/database_yml'

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }

 

4.  config/deploy.rb  파일을 열람 후, 아래 코드를 복사/붙여넣기 해주세요.

 참고1  해당 파일은 Capistrano를 통해 배포옵션에 있어 공통적인 특징들이 기록되어 있습니다.

## config/deploy.rb

# config valid for current version and patch releases of Capistrano
lock "~> 3.14.1"

## [변수 설정] 배포 프로젝트 이름
set :application, "[프로젝트 이름]"
# [Example] set :application, "test4674"

## [변수 설정] Rails 프로젝트가 저장된 Github
set :repo_url, "[Github Repository SSH 주소]"
# [Example] git@github.com:kbs4674/cicd_test2.git

## Github(:repo_url)부터 프로젝트를 가져올 branch
set :branch, :master

## 배포 환경변수 설정
set :use_sudo, false
set :deploy_via, :remote_cache

# Default value for :format is :airbrussh.
# set :format, :airbrussh

# You can configure the Airbrussh format using :format_options.
# These are the defaults.
# set :format_options, command_output: true, log_file: "log/capistrano.log", color: :auto, truncate: :auto

# Default value for :pty is false
set :pty, true

## Github에 Push되면 안되는 중요한 파일에 있어선 해당 리스트에 추가하는게 좋음.
# 해당 리스트에 추가된 파일은 하단에 보이는 namespace :linked_files 부분에도 추가해줘야 합니다.
set :linked_files, %w{config/application.yml config/database.yml config/master.key}

## 프로젝트 배포 후 유지에 있어 공통으로 쓰이는 폴더들
# Capistrano에 배포된 프로젝트는 현재 상용서비스로 사용되는 프로젝트와 과거에 배포되었던 프로젝트 총 :keep_releases개 로 나뉘어 관리가 이루어진다.
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system public/uploads public/img}

# Capistrano를 통해 배포된 현재/과거에 배포됐던 프로젝트 최대 수용갯수 (Default : 5)
set :keep_releases, 5

## [Rails Version 6.0 ~] linked_files 파일을 EC2 서버로 Upload
namespace :deploy do
  namespace :check do
    before :linked_files, :set_master_key do
      on roles(:app), in: :sequence, wait: 10 do
        unless test("[ -f #{shared_path}/config/application.yml ]")
          upload! 'config/application.yml', "#{shared_path}/config/application.yml"
        end
        
        unless test("[ -f #{shared_path}/config/master.key ]")
          upload! 'config/master.key', "#{shared_path}/config/master.key"
        end
        
        unless test("[ -f #{shared_path}/config/database.yml ]")
          upload! 'config/database.yml', "#{shared_path}/config/database.yml"
        end
      end
    end
  end
end

 참고2  Github SSH 경로는 자신의 Github Repository에서 아래 사진과 같이 확인이 가능합니다.

 

5.  config/deploy/production.rb  파일을 열람 후, 아래 코드를 복사/붙여넣기 해주세요.

 참고1  해당 파일은 Capistrano를 통해 배포옵션에 있어 production 이라는 명칭의 Remote서버에 대한 정보가 담겨져있습니다.

 참고2  Key pair Path는 절대주소 경로로 가리켜야합니다. (나중에 Capistrano를 통해 프로젝트 배포 시, AWS EC2와 통신할 때 사용됩니다.)

## config/deploy/production.rb

## [변수 설정] Remote 서버 : 아이디
# AWS EC2 Ubuntu는 기본으로 아이디는 ubuntu 이다.
set :user, '[Remote 서버 ID]'
## [Example] set :user, 'ubuntu'

## [변수 설정] REMOTE 서버 설정
set :remote_server_ip, "[Remote 서버 IP주소]"
# [Example] set :remote_server_ip, "52.78.236.246"

## [변수 설정] Remote서버에 대해 배포 환경변수 설정
set :rails_env, "production"
set :stage, :production

## Remote서버에서 프로젝트 배포가 이루어질 Path
set :deploy_to, "/home/#{fetch(:user)}/#{fetch(:application)}"

server fetch(:remote_server_ip), port: 22, roles: [:web, :app, :db], primary: true

## SSH Remote 설정 (서버 아이디 및 pem Key 경로 설정)
set :ssh_options, { forward_agent: true, user: fetch(:user), keys: %w([AWS EC2 Key Pair Full Path]) }
# set :ssh_options, { forward_agent: true, user: fetch(:user), keys: %w(C:\Users\KCM\Desktop\ruby-kcm.pem) }

 

6. 지금까지의 작업을 Github로 push 합니다.

git add .
git commit -m "capistrano 추가"
git push origin master

 

7. 이것으로 Capistrano의 기본적인 설정이 끝났습니다.

다음은 서버의 Database에 대해 설정을 진행합니다.

 

 

•  Chapter 5  PostgreSQL 계정 및 데이터베이스 생성

 참고  AWS EC2에서 해당 과정을 진행해주세요.

다시 AWS EC2로 돌아와서, 다음은 EC2 내에 데이터베이스 계정 생성 및 설정에 대한 안내입니다.

 

1. 터미널에서 다음 명령어를 입력해서 PostgreSQL 커멘터에 접속합니다.

sudo su - postgres
psql

 

2.  Chapter 3  의 3번 과정에서 입력했던 계정 정보를 토대로, AWS EC2 내에서 DB를 제어할 유저에 대한 계정을 생성합니다.

 참고1  계정명과 암호는  Chapter 3  의 3번 과정에서 입력한 정보를 토대로 작성해주세요.

# create role [계정명] login password '[암호]' superuser;
create role admin login password '123456' superuser;

 참고2  계정 암호 변경

# ALTER USER [계정명] WITH PASSWORD '[암호]';
ALTER USER [계정명] WITH PASSWORD '654321';

 참고3  데이터베이스 연결 확인

## DB 연결 확인 명령어는 일반 터미널에서 입력해야 합니다.
## ubuntu@ip-×××-××-××-×××:~/project$

# psql -U [계정명] -d [DB 이름] -W -h localhost
psql -U admin -d kcm_dev -W -h localhost

• -U : username
• -d : database name
• -W : password 사용
• -h: 연결할 호스트. 제외할 경우 "peer authentication failed" 에러 발생 가능

3.  Chapter 3  의 3번 과정에서 Production Environment 기준으로 데이터베이스에 지어줬던 이름을 기준으로 데이터베이스를 생성해주세요.

# CREATE DATABASE [Production 데이터베이스 이름];
CREATE DATABASE kcm_production;

 참고1  예를들어 해당 글의 예시를 기준으로서는 Production Environment에서 Database 이름을 kcm_production 이라고 했으므로 다음과 같이 입력하면 됩니다.

 참고2  데이터베이스 삭제

# DROP DATABASE [데이터베이스 이름];
DROP DATABASE kcm_development;

 참고3  사실 해당 과정을 안하고

RAILS_ENV=production rake db:create

로컬에서 위 명령어를 입력을 함으로서 Remote서버에 DB를 생성시킬 수 있긴 합니다.

그런데 Capistrano 첫 배포 때에 있어, 자동으로  rake db:migrate  가 되는 과정이 있는데, capistrano는 DB를 Migration 해주는 것 까지만 책임을 지지, DB create는 해주질 않아가지고 사전에 이 작업을 하는겁니다.

 

4. 계정 및 데이터베이스 생성이 끝났다면,  Ctrl + D  를 눌러서 PostgreSQL 콘솔에서 나가주세요.

 

5. (선택사항) AWS EC2에 설치된 PostgreSQL DB에 외부에서도 접근을 할 수 있도록 설정하려면 아래 글을 참고해서 설정을 해주세요.

Ruby on Rails : 다른 AWS EC2 서버 내의 Database와 Remote Connect 하기

 

 

•  Chapter 6  Nginx 설치 사전준비

 참고  AWS EC2에서 해당 과정을 진행해주세요.

본격적인 Nginx 설치 전, 여러분들의 귀찮음을 덜어주고자 몇 가지 사전 작업을 진행하고자 합니다.

 

1. 터미널에 다음 명령어를 입력해서 apt 패키지에 대한 인증키를 등록합니다.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7

 

2.  /etc/apt/sources.list.d/passenger.list  파일에 향후 다운로드를 할 패키지(passenger)에 대한 등록을 합니다.

sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger focal main > /etc/apt/sources.list.d/passenger.list'

 

3. 이전 패키지와의 버전확인 및 패키지의 최신버전에 대해 다운로드가 진행됩니다.

sudo apt-get -y update

 

 

•  Chapter 7  Nginx 설치

 참고  AWS EC2에서 해당 과정을 진행해주세요.

 

1. 터미널에 다음 명령어를 입력해서 Nginx 및 Passenger을 설치를 시작합니다.

아래 명령어를 입력해주세요.

sudo apt-get install -y nginx-extras libnginx-mod-http-passenger

 참고1  Nginx 관련 파일(패키지)은  /etc/nginx  에 있습니다.

 참고2  Passenger은 Rails 기반에서 Nginx를 돌릴 시 함께 설치해야 하는 패키지로서, 서버에서 메모리가 원할히 사용될 수 있도록 도움을 줍니다.

 

2. passenger 사용에 있어, Ruby 언어(인터프리터)가 어디서 비롯되는건지 경로를 정의해줘야 할 필요가 있습니다.

passenger에 루비 경로를 지정하기 전, 현재 ubuntu 서버의 ruby는 어디를 바라보고있는지 아래 명령어를 통해 알아냅니다.

passenger-config about ruby-command

위 명령어를 입력하면 보이는 아래 사진의 passenger_ruby 옆에 보이는 경로를 메모장 같은 프로그램을 켜서 미리 내용을 옮겨적어두세요.

 

3. Passenger에 Ruby path에 대한 정의을 위해 아래 명령어를 입력합니다.

sudo vim /etc/nginx/conf.d/mod-http-passenger.conf

그러면 passenger_root, passenger_ruby에 대한 PATH 정의가 된게 보입니다.

아까 2번 과정에서 알아냈던 ruby 언어의 PATH를 기반으로 아래와 같이 passenger_ruby 줄에 대해서만 수정해주면 됩니다.

 

4. Ruby Path 정의 및 Nginx 설치 후, 간단하게 서버를 오픈해보겠습니다. 터미널에 아래 명령어를 입력해주세요.

sudo service nginx start

아래 사진과 같이 기본 Nginx 메인 홈페이지가 잘 나오면 성공입니다.

 

하지만 저희는 Rails 프로젝트의 홈페이지를 띄어야 합니다.

이를 위한 몇 가지 수정을 진행해보겠습니다.

 

7. Nginx 내부에 돌려볼 Rails 프로젝트에 대한 설정을 진행해보겠습니다.

현재는 Nginx 내에서 내부적으로 기본 정의가 되어있는 상태인데, 기본정의된 파일을 지워주세요.

sudo rm -rf /etc/nginx/sites-enabled/default

 

8. 이어서 새로운 Nginx 설정파일을 생성 및 내용을 작성합니다.

1) 터미널에 아래 명령어를 통해 새 파일을 만듬과 동시에 편집모드로 전환

## {myapp} 부분은 Chapter 4의 4번 과정에서 set :application에 설정했던 프로젝트 이름과 동일하게 작성
# sudo vim /etc/nginx/sites-enabled/{myapp}

## 예시
sudo vim /etc/nginx/sites-enabled/test4674

 

2) vim 에디터 내에 아래와 같이 내용을 등록해주세요.

 참고 1  해당 파일은 Rails로 치면 라우터의 역할을 합니다.

server {
  listen 80;
  listen [::]:80;

  server_name _;
  root /home/[1. ubuntu 계정 이름]/[2. 프로젝트 이름]/current/public;

  passenger_enabled on;
  passenger_app_env [3. ENVIRONMENT];

  location /cable {
    passenger_app_group_name myapp_websocket;
    passenger_force_max_concurrent_requests_per_process 0;
  }

  # Allow uploads up to 100MB in size
  client_max_body_size 100m;

  location ~ ^/(assets|packs) {
    expires max;
    gzip_static on;
  }
}

 참고 3  대괄호로 감싸진 부분만 여러분들 환경에 맞게 입력해주면 됩니다.

Nginx 작성 예시

9. 서버가 시작되기 전, nginx.conf에 내용이 잘 입력이 되었는지 한번 확인해보세요.

sudo nginx -t

위와같이 나오면 이상없이 Nginx 설정을 끝마쳤습니다.

 

10. Nginx 설정을 바꿔줬으니 서버를 restart 해보겠습니다.

터미널에 아래 명령어를 입력해주세요.

sudo service nginx reload

 

 

•  Chapter 8  (Optional) SSH Keygen 설정

 참고1  Github Repository가 Private인 경우에만 이 과정을 진행하면 됩니다.

 참고2  AWS EC2에서 해당 과정을 진행해주세요.

 

SSH Keygen은 SSH 통신에 있어 과거에 계정의 아이디와 비밀번호를 묻는 방식이 아닌 접근자가 보안키 인증을 통해 허가받은 사용자인지 확인 후, 통신을 하는 방식입니다.

 

Capistrano는 EC2와의 통신에 있어 중간매체인 Github를 활용을 합니다. 자동화 배포 특성 상, 중간에 계정을 입력을 하면 자동화라는 의미가 무색해지다 보니 EC2 서버와 Github와의 통신에 있어 Repository로 부터 프로젝트를 가져올 시(Pull), Github 계정의 ID과 비밀번호를 물어선 안됩니다.

 

저희는 SSH 통신에 있어 AWS EC2와 Github와 인증키 대조를 통해 신원확인 및 통신이 되도록 해보겠습니다.

 

1. 터미널에 아래 명령어를 입력해주세요

 참고  어느 디렉터리 위치에서 입력하든 상관없습니다.

ssh-keygen

 

위 명령어를 입력하면 어디에다 설치할건지 등 3번의 질문이 나오는데, 세번 다 엔터를 쳐가면서 Skip해주세요.

위 3개의 질문에는 엔터로 무시

 

2. 이제 SSH Key 파일이 생성이 되었습니다.

 

3. Key파일은 자신의 계정 루트폴더에 보면 .ssh 이름을 가진 숨겨진 디렉터리가 존재하는데, 이 숨김폴더 안에 존재합니다.

해당 폴더로 이동해주세요.

cd ~/.ssh

 

4.  .ssh  폴더에는 크게 authorized_keys, id_rsa, id_rsa.pub 3개의 Key 파일이 존재합니다.

1) authorized_keys  keygen 생성 전 부터 존재했던 파일입니다.

2) id_rsa  비밀키

3) id_rsa.pub  공개키

 

그런데 여기서 눈여겨 볼 파일은 id_rsa와 id_rsa.pub 입니다.

 

두 파일의 관계는 열쇠와 자물쇠 라고 이해하는게 편합니다.

두 인증키 파일은 서로 소수로 이루어진 내용으로 채워져 있으며, 이 두 소수의 곱의 판단으로 서로의 짝인지를 판단을 합니다.

 

외부에서는 서버와 SSH 통신 시도 전, id_rsa.pub(공개키)를 가지고 인증을 시도합니다.

그리고 서버는 자신이 가진 id_rsa(비밀키)를 가지고 이전의 id_rsa가 맞는지 검증을 합니다. 그리고 맞다면은 별도의 계정을 묻는과정 없이 바로 서버의 접근을 허용합니다.

 

참고로 여러분들은 이미 이러한 인증과정을 한번 경험해봤습니다.

어디서냐고요? AWS EC2 터미널에 접근 전, Key pair 파일을 인증을 거쳤던 때 입니다!

 

Github도 Private Repository에서 일반적인 방법으로 자료를 가져오려고 하면 다음과같이 암호를 묻곤 했었습니다.

 

하지만 Github에도 공개키/보안키 인증방식으로 하게 되면 이제는 위와같이 계정을 묻지 않게 됩니다.

위의 보안키 공개키/보안키 인증의 원리를 Github와 EC2 통신에 적용해보겠습니다.

 

5. id_rsa.pub 파일의 내용을 봅니다.

cat ~/.ssh/id_rsa.pub

id_rsa.pub 내용

그리고 AWS EC2가 연결되어있는 터미널(cmd)을 잠시 뒤로하고, 잠시 인터넷을 킵니다.

 

6. Github 프로젝트에 공개키를 등록하기 위해 Github 홈페이지로 이동합니다.

그리고 Ruby on Rails 프로젝트가 있는 Github Repository 페이지로 이동 후,  Settings  메뉴를 클릭합니다.

 

7.  Settings  메뉴에 보면 좌측에 보이는  Deploy keys  메뉴를 클릭해주세요.

 

8. 해당 페이지가 서버에서 발급된 공개키를 등록하는 곳입니다.

 Add deploy key  버튼을 클릭해주세요.

 

9. Title은 취향에 맞게, Key는 5번 과정 때 터미널에서 확인했던 id_rsa.pub 파일의 내용을 복사/붙여넣기 합니다.

 

내용을 다 입력했으면  Add key  버튼을 클릭해주세요.

 

10. 이제 Github 프로젝트에 AWS EC2의 공개키가 등록이 되었습니다.

이로서 이제는 Capistrano 배포에 있어, Github 통신 때 단순한 공개키 인증만으로 서버와의 통신이 가능해졌습니다.

 

 

•  Chapter 9  Capistrano 배포

 참고  해당 작업은 로컬PC(로컬서버) 프로젝트에서 진행해주세요.

 주의  Remote 서버에  .bashrc  파일에 echo 를 설정했을 경우, 해당 기능은 잠시 주석처리를 해주세요.

echo로 인해서 Capistrano가 재기능을 못합니다.

 

이제 최종 마지막과정이 남았습니다.

지금까지 저희는 Nginx와 Capistrano 설정을 진행을 해왔습니다.

 

이제는 이 모든 설정이 끝났고 이제 마지막으로 로컬PC(로컬서버) → AWS EC2로 배포를 해내기만 하면 됩니다.

 

1. 과거  Chapter 4  의 4번 과정에서 저희는  config/deploy.rb  에 아래 코드를 작성했었습니다.

## config/deploy.rb

## Github에 Push되면 안되는 중요한 파일에 있어선 해당 리스트에 추가하는게 좋음.
set :linked_files, %w{config/application.yml config/database.yml config/master.key}

## 프로젝트 배포 후 유지에 있어 공통으로 쓰이는 폴더들
# Capistrano에 배포된 프로젝트는 현재 상용서비스로 사용되는 프로젝트와 과거에 배포되었던 프로젝트 총 :keep_releases개 로 나뉘어 관리가 이루어진다.
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system public/uploads}

여기서 linked_files에 명시된 파일들은  .gitignore  에도 명시가 되어 있다보니, Github에는 push가 안되고 결국 중간에 누락된 파일로 인해 에러가 발생할겁니다.

 

Capistrano에서도 이 점을 염두하고, 로컬PC(로컬서버)에 있는 파일 중 자주  .gitignore  에 기록되는 파일에 대해선 따로 업로드가 되도록 지원을 합니다.

 

로컬PC(로컬서버) 터미널에서 아래 명령어를 입력해주세요.

cap production setup

 

위 명령어를 입력함으로서 이제 로컬PC → AWS EC2로 파일이 전송되었습니다.

 

Q. 나중에 application.yml 파일이 바꼈어요!

이 또한 걱정하지마세요! 위 과정처럼 동일하게 setup을 진행하면 바뀐 내용으로 반영이 됩니다.

 

2. 이제 본격적으로 Capistrano 배포를 시작합니다.

cap production deploy

---

 에러 발생이슈 소개 

 

g++ 패키지 에러                   

설치도중 원격서버(AWS EC2)에 g++ 관련 패키지가 없어서 아래와 같이 문제가 발생합니다.

 

원격서버(AWS EC2)에 아래 패키지를 설치해주면 됩니다.

sudo apt-get update
sudo apt-get install -y g++

 

 

Rails : API 모드에서 Assets 설치 시도                   

Rails에는 보통 View가 존재하는 Application과 API 용도로만 활용을 하는 Application이 존재합니다.

그런데 여기서 API 용도로만 쓰이는 application에서는 view가 존재하지 않다보니, assets을 precompile을 할 필요가 없습니다.

 

하지만 그럼에도 rake assets:precompile 실행을 정의하는 코드로 인해 다음과 같은 에러가 발생합니다.

 

이에대한 해결법은  /Capfile  에서 precompile 실행 코드를 제거하면 됩니다.

 

혹시 반대로 assets을 Precompile을 할 필요가 있을 경우,  Capfile  에 위 코드를 추가해주세요.

 

credentials 이슈                   

처음에 저는 환경변수를 입력할 때 Figaro를 활용하지 않고, Rails에서 5.2 부터 제공되는 credentials 기능을 활용해서 환경변수 정의를 해왔습니다.

## 환경변수 파일에 접근할 수 있는 명령어

EDITOR=vi rails credentials:edit

 

그리고 저는 저 방식을 통해 환경변수를 아래와 같은 방식으로 활용을 해왔습니다.

 

하지만 막상 capistrano에 배포를 하려니, 해당 환경변수를 인식하지 못하고 NULL로 표기되는 문제가 발생합니다.

후에 환경변수를 Figaro를 활용하니 이제 이 문제는 해결되었습니다.

 

PG : TCP/IP connections on port 5432?                   

PostgresSQL 포트 허용에 있어 문제가 의심되는 대목입니다.

 

1. IP 인바운드 확인

EC2 등 서버에 있어 5432 인바운드 포트를 허용해주고 있는지 확인

 

2. Remote 서버에 PostgreSQL이 켜져있는가?

EC2, Azure와 같은 프로젝트가 배포될 리모트 서버에 PostgreSQL이 켜져있는지 확인

service postgresql status

 

만약 아래 사진과 같이 꺼져있을 경우, 아래 명령어를 입력

sudo service postgresql start

 

3. 위 2개를 해도 안될 경우...

EC2, Azure와 같은 프로젝트가 배포될 리모트 서버에 아래 작업을 합니다.

1) pg_hba.conf, postgresql.conf 파일 탐색

 

2) postgres 커맨드 접속

sudo su - postgres

 

3) pg_hba.conf 파일 수정 (좌측: 수정 전, 우측: 수정 후)

/etc/postgresql/10/main/pg_hba.conf (필자 기준 path)

 

4) postgresql.conf 파일 수정 (좌측: 수정 전, 우측: 수정 후)

/etc/postgresql/10/main/postgresql.conf (필자 기준 path)

 

5. PostgreSQL 재실행

sudo service postgresql restart

 

capistrano 배포 : NoMethodError: undefined method `[]' for nil:NilClass                

Passenger:restart 때에 갑자기 undefined method 에러가 뜨면서 배포가 안되는 이슈가 있습니다.

확인해본니 이 문제는 capistrano-passenger Gem 버전의 이슈인걸로 확인됐습니다. capistrano-passenger Gem의 버전이 0.2.0 이하일 경우, 0.2.1 이상으로 버전업 해주면 됩니다.

 

---

3. 이제 아주 간단하게 위 명령어 한 줄 만으로 로컬PC → AWS EC2로 Ruby on Rails가 배포되었습니다.

 

capistrano 배포 후 서버

 

4. 다음에 또 로컬PC에 있는 Rails 프로젝트에서 내용수정 후 배포를 해야한다면 위의 모든 과정은 생략하고 다음 과정만 진행하면 됩니다!

1) 내용 수정

2) github에 자료 push

git add .
git commit -m "refresh data"
git push origin master

3) capistrano deploy

capistrano production deploy

 

 

•  추가 설정  Nginx 부가설정

 참고1  AWS EC2에서 해당 과정을 진행해주세요.

 참고2  해당 사항은 필수적인 사항은 아니고, 선택적인 사항입니다.

 부록  내 웹사이트의 보안점수는?

 

1. 서버 정보 및 버전 노출

현재 지금 서버가 열린 상태로 크롬 개발자도그를 통해 서버의 응답값을 보면 홈페이지에 어떤 서버를 쓰는지 훤히 다 보입니다. 위와같이 노출을 방지하고 싶으면 다음 과정을 따라주세요. 

 

1) Nginx 설정파일을 엽니다.

sudo vi /etc/nginx/nginx.conf

 

2) http 블록 안에 다음과같이 입력해주세요.

## 다음 내용을 nginx.conf 에 입력

include /etc/nginx/security.conf;

## /etc/nginx/nginx.conf

http {
  + include /etc/nginx/security.conf;
  
  ... (내용 생략) ...
}

 

3)  /etc/nginx  디렉터리로 이동합니다.

그리고 해당 위치에  security.conf  파일을 생성해주세요.

cd /etc/nginx
vi security.conf

 

4)  /etc/nginx/security.conf  파일에 다음 내용을 작성합니다.

## /etc/nginx/security.conf

server_tokens off;

위와같이 입력을 다 해냈다면 키보드에서  ESC  를 누르고  Shift + :  를 누른 후  wq  를 입력하고 엔터를 눌러서 에디터에서 나가주세요

 

5) Nginx 설정코드 검사 및 서버를 재시작 후, 다시 크롬 개발자도구에서 네트워크 상태를 확인해보세요.

sudo nginx -t
sudo service nginx restart

서버에 대한 정보가 이제 노출이 안된다!

이제 서버에 대한 정보가 안보입니다.

 

 

2. 새로운 헤더 추가

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

홈페이지에 위 3개의 헤더에대한 정보를 넣어보고자 합니다.

1. add_header X-Frame-Options SAMEORIGIN

  · SAMEORIGIN : 같은 홈페이지상의 iframe 호출은 가능하나, 타 사이트의 iframe 호출은 불가능

  · DENY : 모든 iframe 금지

  · ALLOW-FROM Url :  주소를 설정하고 해당 주소는 iframe 허용

 

2. X-Content-Type-Options nosniff : 잘못된 MIME 타입이 포함된 응답을 거부

* MIME 타입 : 컨텐츠 형식(mp3, zip, pdf 등)을 정의하기 위한 인터넷 표준 [참고]

 

3. X-XSS-Protection "1; mode=block" : XSS를 통한 세션 하이잭킹 방지

* XSS 세션 하이잭킹 : 타인의 세션(서버에 인증된 유저정보)을 탈취해서 내가 남인 것 처럼 행동하는 것 [클릭]

---

1) Nginx 설정파일을 엽니다.

sudo vi /etc/nginx/nginx.conf

 

2) http 블록 안에 다음과같이 입력해주세요.

## 다음 내용을 nginx.conif 에 입력

include /etc/nginx/security.conf;

## /etc/nginx/nginx.conf

http {
  + include /etc/nginx/security.conf;
  
  ... (내용 생략) ...
}

 

3)  /etc/nginx  디렉터리로 이동합니다.

그리고 해당 위치에  security.conf  파일을 생성해주세요.

cd /etc/nginx
vi security.conf

 

4)  /etc/nginx/security.conf  파일에 다음 내용을 작성합니다.

add_header X-Frame-OptionsSAMEORIGIN;
add_header X-Content-Type-Optionsnosniff;
add_header X-XSS-Protection"1; mode=block";

위와같이 입력을 다 해냈다면 키보드에서  ESC  를 누르고  Shift + :  를 누른 후  wq  를 입력하고 엔터를 눌러서 에디터에서 나가주세요

 

5) Nginx 설정코드 검사 및 서버를 재시작 후을 하면 새로운 헤더가 적용됩니다.

sudo nginx -t
sudo service nginx restart

 

 

•  참고  Nginx 로그파일 확인

 참고  AWS EC2에서 확인해보세요!

Nginx 기반으로 서버를 열더라도, 서버의 로그기록은 총 3개가 기록됩니다

 

1. Ruby on Rails 서버 로그기록

평소에 알던바와 같이 홈페이지에 접속 시 일어나는 상황에 대한 모든 기록이 담깁니다.

---

다음으로 Nginx 로그를 소개하기 전에 잠깐  etc/nginx/nginx.conf  파일을 보겠습니다.

 

nginx.conf

Nginx 코드 중, access와 error 로그기록에 대해 저장하는 코드가 존재합니다.

이 두개의 로그는 Nginx에서 별도로 수집하는 로그기록 입니다.

---

2. Nginx : Access

Access 로그는 어떤 유저가 어떤 페이지에 접속했고, 어떤 브라우저로 접속했는지에 대한 정보가 담겨져 있습니다. 

/var/log/nginx/access.log

 

3. Nginx Error

서버 접속에 실패할 경우, Nginx 내부에서 어떤 에러로 인해 실패했는지 기록이 됩니다.

/var/log/nginx/error.log

 

 

 

•  부가설명  Capistrano + Whenever Gem

 참고1  확인은 로컬PC(로컬서버) 프로젝트에서 해주세요.

 참고2  whenever Gem을 사전에 설정했다는 가정하에 작성을 합니다.

 부록  Ruby on Rails : 스케쥴링(예약된 시간) Background Job [Gem : Whenever]

 

Whenever Gem은 Scheduler Job(Cron Job)을 도와주는 Gem입니다.

하지만 Capistrano를 통해 서비스를 배포하게 되면 터미널 내 Background Job에서 crontab이 설정되지 않은채로 배포가 됩니다. 그렇다보니 Whenever 기능에 대해 따로 설정을 해줘야 할 필요가 있습니다.

 

Capistrano를 통해 서비스를 배포하게 되면 Whenever Gem이 동작되지 않은채로 배포가 됩니다.

또한 Remote 서버상에서는 실제로 Capistrano로 배포된 프로젝트는 Rails 프로젝트가 아닌, Rails 프로젝트처럼 흉내낸겁니다. 그렇다보니 프로젝트 내부에서 Rails 명령어 사용이 안됩니다.

 

Gemfile에 whenever이 작성되어 있지만, 실제로 Gem List에는 설치되어있지 않다.

 

Whenever Gem 페이지

하지만 Whenever Gem 개발자는 이를 우려하여 사전에 Capistrano 배포에 대한 대책을 세워놨습니다.

 

1.  Capfile  에 Whenever을 정의하는 코드를 추가합니다.

## Capfile

require "whenever/capistrano"

 

2.  config/deploy/production.rb  에 아래 코드를 추가합니다.

set :whenever_environment, -> { fetch(:stage) }
set :whenever_identifier, -> { "#{fetch(:application)}_#{fetch(:stage)}" }

 

3. Github에 push 합니다.

git add .
git commit -m "Capistrano ↔ whenever 배포 및 설정"
git push origin master

 

4. 프로젝트를 (재)배포 합니다.

cap production deploy

 

5. cronjob을 Update 해줍니다.

cap production whenever:update_crontab

위와같은 과정으로 설정을 해주면 이상없이 잘 됩니다.

 

6. 이 외에도 cronjob 설정 명령어는 아래와 같습니다.

## Cronjob Clear (stop)
cap whenever:clear_crontab

## Cronjob Update
cap production whenever:update_crontab

 

 

•  부가설명  Capistrano + Sidekiq Gem

 참고  Sidekiq Gem을 사전에 설정했다는 가정하에 작성을 합니다.

 부록  Ruby on Rails : 선입선출 Background Job [Gem : sidekiq]

 

Sidekiq Gem은 Background Job 시, 무조건 Job을 받아들여서 하는게 아닌, 들어온 순서+Job 공간의 크기를 따로 정해서 Background Job을 도와주는 Gem입니다.

 

Capistrano를 통해 서비스를 배포하게 되면 터미널 내 Background Job에서 Sidekiq Gem이 자동으로 동작되지 않은채로 배포가 됩니다.

또한 Remote 서버상에서는 실제로 Capistrano로 배포된 프로젝트는 Rails 프로젝트가 아닌, Rails 프로젝트처럼 흉내낸겁니다. 그렇다보니 프로젝트 내부에서 Rails 명령어 사용이 안됩니다.

 

Gemfile에 sidekiq이 작성되어 있지만, 실제로 Gem List에는 설치되어있지 않다.

그렇다보니 Sidekiq 기능에 대해 따로 설정을 해줘야 할 필요가 있습니다.

 

현재 해당내용은 작성중이며, 내용 미완성입니다.

 

 Chapter 1  Redis-server 설치

 참고1  Remote 서버(EC2)에서 진행해주세요.

 참고2  AWS EC2의 Ubuntu 환경을 기준으로 설치방법 설명이 진행됩니다.

 

1. 외부 서버로부터 redis 설치 파일을 받아온 후, Redis를 설치합니다.

cd /tmp
wget http://download.redis.io/releases/redis-4.0.0.tar.gz
tar xzf redis-4.0.0.tar.gz
rm -rf redis-4.0.0.tar.gz
cd redis-4.0.0
make

 

2. 서버 내에 Redis 공간을 마련해줍니다.

그리고 실행파일(redis-server)과 Redis 설정파일(redis.conf)를 Copy/Paste 합니다.

sudo mkdir /etc/redis 
sudo mkdir /var/lib/redis
sudo cp src/redis-server src/redis-cli /usr/local/bin/
sudo cp redis.conf /etc/redis/

 

3. AWS EC2에서 Redis-server 이 돌아가게 하도록 EC2에 맞춘 redis-server 패키지 설치를 진행합니다.

cd /tmp
wget https://raw.github.com/saxenap/install-redis-amazon-linux-centos/master/redis-server

 

4. redis-server을 실행합니다.

redis-server /etc/redis/redis.conf

 참고1  redis-server 종료는 키보드에서  Ctrl+C  키를 눌러주면 됩니다.

 참고2   /etc/redis/redis.conf  는 redis 설정을 하는 파일입니다.

redis 파일을 설정할 일(redis 암호설정 등)이 있으면  /etc/redis/redis.conf  파일에서 하면 됩니다.

 

 

 Chapter 2  capistrano-sidekiq 설치

 참고  로컬PC(로컬서버)에서 진행해주세요.

 

1. Capistrano ↔ Sidekiq을 지원하는 Gem을 설치합니다.

## Gemfile

gem 'capistrano-sidekiq', github: 'seuros/capistrano-sidekiq'

그리고 Gem을 설치해주세요.

bundle install

 참고  만약 아래와같이 에러가 발생할 경우

에러가 발생되는 최소한의 bundle update를 진행해줍니다.

 

2.  Capfile  에 sidekiq을 연동합니다.

## Capfile

## Capistrano ↔ sidekiq
require 'capistrano/sidekiq'
require 'capistrano/sidekiq/monit'

 

3.  config/deploy/production.rb  파일을 열람 후, 기존의 코드에 다음 내용을 추가합니다.

## config/deploy.rb

set :sidekiq_role, :app  
set :sidekiq_config, "[sidekiq.yml Full Path]"
# [Example] set :sidekiq_config, "/home/ubuntu/test4674/current/config/sidekiq.yml"
set :sidekiq_env, 'production'

 

(이후 내용은 글 작성예정)

 

 

•  부가설명  Capistrano + redis-server

 참고  확인은 로컬PC(로컬서버) 프로젝트에서 해주세요.

 

글 작성예정

 

 

•  참고  Capistrano : 파일 구조설명

 참고  확인은 AWS EC2(Remote 서버)에서 해주세요.

 

AWS EC2에 배포된 Capistrano 구조에 있어 중요한 핵심부분 파일에 대해 알아보겠습니다.

우선 AWS에 배포된 Capistrano는  Chapter 4  의 4번코드에 언급했던 위치에 존재합니다.

## config/deploy.rb

## Remote서버에서 프로젝트 배포가 이루어질 Path
set :deploy_to, "/home/#{fetch(:user)}/#{fetch(:application)}"

 

1) releases  현재부터 과거까지 capistrano를 통해 배포됐던 Rails 프로젝트들이 모여있는 디렉터리 입니다.

## config/deploy.rb

# Capistrano를 통해 배포된 현재/과거에 배포됐던 프로젝트 최대 수용갯수 (Default : 5)
set :keep_releases, 5

releases에 최대로 저장되는 디렉터리의 갯수는 keep_releases에 명시되어있는 갯수만큼 입니다. (기본적으로는 5개)

폴더 이름은 시간에 대한 정보가 담겨져 있으며, 표기되는 시간의 기준은 기본적으로 UTC+0 기준입니다.

 

2) current  해당 디렉터리는 '바로가기' 개념의 폴더로서, releases에 있는 Rails 자료 중, 가장 최근(최신) 디렉터리를 가리킵니다.

 

3) shared  Chapter 4  의 4번 과정에서 linked_files와 linked_dirs에 정의했던 파일 및 디렉터리들이 모여있습니다.

해당 파일/디렉터리의 특징은 수정될 일이 거의 없거나, 저장소 용도로 사용됩니다.

 

## config/deploy.rb

## Github에 Push되면 안되는 중요한 파일에 있어선 해당 리스트에 추가하는게 좋음.
set :linked_files, %w{config/application.yml config/database.yml config/master.key}

## 프로젝트 배포 후 유지에 있어 공통으로 쓰이는 폴더들
# Capistrano에 배포된 프로젝트는 현재 상용서비스로 사용되는 프로젝트와 과거에 배포되었던 프로젝트 총 :keep_releases개 로 나뉘어 관리가 이루어진다.
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system public/uploads}

또한, 위 코드에 명시된 파일/디렉터리 들은 releases 내의 레일즈 프로젝트 내에는 업로드 되지 않고, shared 로 업로드 됩니다.

 

4) revisions.log  배포 및 롤백에 대한 기록이 담깁니다.

 

 

•  참고  Capistrano : Rollback

 참고  확인은 로컬PC(로컬서버) 프로젝트에서 해주세요.

 

Capistrano는 기능적으로는 이상이 없으나, 잘못 배포된 프로젝트의 피해를 대비해서 롤백 기능을 가지고 있습니다.

기본적인 롤백 명령어는 아래와 같습니다.

# cap production deploy:rollback ROLLBACK_RELEASE=[releases]
cap production deploy:rollback ROLLBACK_RELEASE=20200420195103

 

롤백을 하게되면 releases 디렉터리에서는 가장 최근(최근에 배포한 Rails 프로젝트)의 디렉터리는 사라지나, capistrano 구성폴더가 있는 곳에 사라진 Rails 프로젝트(최근에 배포한 Rails 프로젝트)에 대해 압축이 된 채로 파일이 생성됩니다.

만약 특별한 releases 버전을 입력하지 않고 rollback을 시도 시, 바로 이전버전으로 돌아갑니다.

cap production rollback

 

 

•  참고  Capistrano : 로그기록 확인

 참고  확인은 로컬PC(로컬서버) 프로젝트에서 해주세요.

 

만약 Capistrano를 배포하는 도중, 중간에 코드 에러 등으로 인해 배포가 취소가 될 경우 오류메세지가 터미널에 보여지나, 모든 내용이 보여지지는 않습니다.

capistrano 배포 실패 시 터미널에 보여지는 로그기록 메세지

 

capistrano에 대한 모든 로그기록은 cap 명령어를 쓰는 로컬PC(로컬서버) 기준 Rails폴더에서 log폴더 안에 존재합니다.

 

capistrano.log

로그파일에는 작업실패에 기록 뿐만 아니라 작업성공에 대한 기록도 남겨져 있습니다.

 

 

•  참고  EC2에서 고정IP 사용법

EC2 서버는 껏다킬 때 마다 IP가 유동적으로 바뀝니다.

이는 AWS가 유저수에 비해 IP 보유량이 부족해서 그런건데, IP를 돌려쓰다보니 이러한 현상이 발생합니다.

 부록  DHCP 개념

 

하지만 다행히 AWS에서는 고정IP를 지원합니다.

해당 방법에 대해서는 다음 글을 참고해주세요 : https://kbs4674.tistory.com/26

AWS : EC2 IP를 고정시켜서 사용하기 (탄력적 IP)

 

 

• 자료 참고

1. 원노의 블로그

2. [GoRails] Deploy Ruby On Rails: Ubuntu 20.04 Focal Fossa in 2020

3. 주니어 개발자의 CI/CD 도입기

4. 쏘몽 : CI/CD란 무엇인가?

5. [Drama & Company] 리멤버 팀 : Capistrano 설명

6. EC2 Exercise 1.6 : Deploy a Rails App to an EC2 Instance Using Capistrano

7. How to Deploy Rails App With Capistrano?

8. Capistrano deploy Flow

9. [RORLAB Gitbook] 운영서버 환경구축

10. With Capistrano, how to rollback to a specific release?

11. Schedule Rails tasks with whenever and Capistrano

12. Managing Your Production Crontab with Whenever and Capistrano

13. Deploying Sidekiq with Capistrano

14. apt-get update에서 hit 및 get 개념

15. 보안등급 A+를 받을 수 있는 Nginx SSL 설정