五倍直播間

Blogs - Sidebar


## 部署 Rails 你可能會需要用到...

在學習 Rails 部署的路上，你一定聽過 Nginx、 Passenger、 Capistrano 這幾個東西吧？這篇文章會依序介紹這幾個工具特色，以及常見功能！

> 學習 Rails 部署建議可以參考蒼時的 [系列教學文章](https://blog.frost.tw/tags/DevOps/)  
它會詳細帶著讀者一步一步在 DigitalOcean 的機器上部署 Rails 專案

部署大概像什麼樣子？大概像下面這張圖吧
![](https://i.imgur.com/TeWMZTB.png)

遠端伺服器可能是 GCP、AWS、DigitalOcean 這些機器，程式碼倉庫則是 GitHub、 Gitlab、Bitbucket 這些服務，部署過程就是讓遠端伺服器可以取得程式碼倉庫的程式碼，然後順利的把專案執行起來。其中我們會需要在遠端伺服器安裝 Passenger、Nginx 這兩個軟體，同時得用 Capistrano 讓部署自動化、更有效率！

--- 
### 目錄

* Nginx & Passenger
  * 為什麼是 Nginx 搭配 Passenger ?
  * Passenger 擅長什麼呢？
  * Passenger 常用指令：
  * Nginx 設定檔說明
  * 自己設定 Nginx 

* Capistrano
  * Capistrano 功能介紹
  * 部署架構 
  * 設定檔
  * 常用指令
* 結論

---

## Nginx & Passenger

Nginx 是一個 Web Server，它的功能是接受 http request 並回覆 http response ， Nginx 本身和 Ruby 沒有關係，通常使用 Nginx 時我們還會搭配 Passenger 這一個 App Server，它可以管理 Rails 的 process 數量，同時 App Server 符合 Rack 的規範所以可以跟符合 Rack 規範的 Web Application (例如 Rails 溝通)

> 在接下來的文章中，會使用三個名詞<br><br>
> Web Server 就是 Nginx<br><br>
> App Server 就是 Passenger<br><br>
> Web Application 就是 Rails App<br><br>
> 關於 Passenger 和 Nginx 的安裝可以參考 [這篇文章](https://blog.frost.tw/posts/2018/04/10/Getting-started-deploy-your-Ruby-on-Rails-Part-4/#more)

### 為什麼是 Nginx 搭配 Passenger ?

這是我一開始學習部署時一直弄不懂的地方，我原本的想像是伺服器上面除了有我的 Web Application 外，再來就是某個軟體來處理其他的事情。到底為什麼需要 Nginx 和 Passenger 兩樣工具的搭配才能完成這些工作呢？

Nginx 和 Apache 都是 Web Server，它們專攻處理靜態檔案還有 http request。一般來說 Web Server 會放在 App Server 還有 Web Application 之前，它可以直接接觸 Client 端送來的請求，但在它後面的 App Server 和 Web Application 卻不行，因為這樣的架構讓這些軟體可以更有效率的分工，也讓我們的伺服器更安全。

此外，Web Server 還能處理效能上的議題，譬如 slow client 問題，如果 Client 端處理 http request 的速度超慢，Server 這邊就可能得花許多時間在等待這個 Client ，這樣的等待是很浪費資源的，為了解決這類型效能問題，又不讓其他開發者浪費時間重複造輪子，最好的方式就是讓 Web Server 處理這些問題，讓 App Server 和 Web Application 處理他們擅長的，這就是為什麼我們會用到 Nginx 和 Passenger 這兩樣工具了！

### Passenger 擅長什麼呢？

Passenger 會根據流量來判斷現在應該開啟多少個 Web Application，同時它也像是 Web Application 還有 Web Server之間的橋樑，它可以用 Rack 跟 Web Application 溝通，也能處理 Web Server 傳來的 http request，另外 Passenger 在架構上相當彈性也穩定，下圖是 Passenger 的架構圖

![](https://i.imgur.com/XevEwx1.png)

圖片來源：www.phusionpassenger.com

Passenger 是由多個模組所組成的，包含在編譯 Nginx 時一起編譯的 Phusion Passenger module，以及負責管理、重啟其它模組的 Watchdog 等等，因為這樣的結構可以讓 Passenger 更加有彈性，只要 Watchdog 沒有壞掉它就能幫忙重啟其他模組。

由於這些模組都是由許多的 process 在運行，因此彼此之間的溝通，需要透過一個 instance directory 的目錄，來存放這些 process 之間彼此溝通需要的檔案，所以在 nginx.conf 裡面我們會設定 `passenger_instance_registry_dir` 告訴 Passenger 它的 instance directory 在哪裡，我們在使用 `passenger-status` 指令的時候也是透過這資料夾內的資料取得資訊的。

> 之前在用 Passenger 的時候常常會跑不起來卻不知道為什麼？
> 原來就是少了 `instance directory` 這個目錄！

關於這架構圖更詳細介紹可看[官方文件](https://www.phusionpassenger.com/documentation/Design%20and%20Architecture.html#_web_server_module)

### Passenger 常用指令：

要使用 passenger 的指令必須先將 passenger 的 bin 目錄放到路徑之下，我們可以看到 passenger 的 bin 目錄下有這些執行檔
```
passenger  passenger-config  passenger-install-apache2-module  passenger-install-nginx-module  passenger-memory-stats  passenger-status
```

> 這些執行檔也就是我們可以使用的指令唷！

其中我們常用的可能有這兩個

```
# 查詢 passenger 的狀態
passenger-status 

# 透過 passenger 重新啟動 Rails 
passenger-config restart-app
```

咦！那要在哪邊做 Passenger 的相關設定呢？還記得前面說到的跟 Nginx 一起編譯的  Phusion Passenger module 模組嗎？因為這樣的關係，我們在寫 Nginx 設定檔時也可以一起設定一些 Passenger 需要的東西，接下來可以來看看 Nginx 的設定檔

### Nginx 設定檔說明

Nginx 安裝好後會有 `nginx.conf` 這設定檔，我們可以直接在裡面做修改，或是用 `include site-enabled/*.conf;` 之類的方法把設定檔寫在其他地方，在這個範例我們會將設定檔寫在其他地方，所以在 `nginx.conf` 加上一行 `include site-enabled/*.conf;` 即可，同時也得在有 `nginx.conf` 檔案的目錄下新增 site-enabled 資料夾來放我們要的設定檔。

如果把 nginx.conf 的註解都拿掉的話，你的設定檔可能長這樣

```
# 註解0
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    passenger_root /usr/local/passenger/passenger-5.3.3;
    passenger_ruby /usr/local/ruby-2.4.3/bin/ruby;
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    # 這行是後來加上去的
    include site-enabled/*.conf;
}

```

在 nginx.conf 中可以看到 `http { ... }` 包起來的設定，在這裡面還會看到 ` server {...} ` 的結構，而我們的`include site-enabled/*.conf;` 會寫在 http 這個 block 內然後 server 這個 block 外，因為其實我們要寫的設定檔就是好幾個 `server {...}` ，這些層級之間的規定可以在 [Nginx 的文件](http://nginx.org/en/docs/beginners_guide.html
)中找到~

> 註解0

> 設定 Nginx 的 worker_processes 數量，Nginx 啟動方式是一個 master process 和多個 worker processes，master process 負責根據設定檔的設定來操作 worker processes，所以 worker processes 是真正在處理 http request 的 process！

### 自己設定 Nginx 

在看完 nginx.config 後我們使用以下指令來建立我們自己的設定檔

```
$ mkdir site-enabled
$ cd site-enabled
$ vim xxx.conf (xxx可換為你的設定檔名稱，通常會用網域名稱好區分)
```

完成後可以在 `xxx.conf` 中這樣寫，其中 `#` 為註解符號

```
#設定 Passenger 的 instance directory
passenger_instance_registry_dir /var/run/passenger-instreg;

#第一個 server 區塊
server {

    #監聽 port 80 （ http request ）
    listen 80; 

    #註解1，設定 server name 
    server_name dodeploy.tk;

    #註解2，將 http request 都轉給第二個 server 區塊
    return 301 https://dodeploy.tk$request_uri;
}

#第二個 server 區塊
server {

    #監聽 port 443 （ https request ）
    listen       443 ssl;

    server_name dodeploy.tk;

    #SSL 憑證相關設定
    ssl on;
    ssl_certificate      /etc/letsencrypt/live/dodeploy.tk/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/dodeploy.tk/privkey.pem;

    #註解3
    location ~ /.well-known {
        allow all;
        root /opt/nginx/html;
    }

    #提供靜態檔案的放置目錄
    root /home/deploy/do_deploy.com/current/public;

    #啟動 Passenger
    passenger_enabled on;
}
```

> 註解1<br><br>
> 如果有需要，我們也可以讓多個 domain 都對應到這台機器，首先申請多個 domain name 都對應到我們機器的 IP，然後我們就可以用多個 server 的區塊分別接收到帶有不同網域名稱的 http 請求。

> 註解2<br><br>
> 我們的範例會將 HTTP 轉換成 HTTPS ，要完成這功能要設定多個 server 的區塊，第一個區塊監聽 port 80，也就是只接受 HTTP 請求，在接收到 HTTP 請求後再來就是 return 將請求交由監聽 https 的第二個區塊來處理

> 註解3<br><br>
> 在第二個區塊我們做了 SSL 的憑證的設定，另外 location 那一塊是為了讓遇到 ~/.well-known 開頭的頁面，都使用 /opt/nginx/html 這個目錄，如此一來就能夠讓 Certbot 把驗證用的檔案放在這裡面，讓 Let’s Encrypt 可以驗證到。

完成以上設定後，可以用以下指令檢查設定檔有沒有問題
```
sudo /opt/nginx/sbin/nginx -t
```

如果沒問題可以用以下指令重新啟動 Nginx ( 使用這指令需要設定 systemd 功能 )
```
sudo systemctl restart nginx
```

## Capistrano

### Capistrano 功能介紹

Capistrano 是自動化部屬的工具，如果少了 Capistrano 我們要部署遠端伺服器就得每個動作都自己來，如果有多台機器多個環境，就更會需要 Capistrano 來幫忙處理各種繁瑣的任務了！

Capistrano 支援 Multiple stages，stage 指的是環境( staging, production 之類的)，我們只需要定義一次部署的方式，就能將這樣的部署方式套用在多個環境，也就是將 Web Application 部署到不同環境卻不用重複寫相同的設定檔，只需要設定這些環境所不同的地方譬如 IP 位置就可以了！

Capistrano 也支援 Server roles，在一個環境下我們可能會定義多個 role，因為 Web Application 可能是由多個服務一起完成的，有跑 Web Application 、database 和 CronJob server 等等，每個 role 在部署時會有不同的流程，這些也可以透過定義什麼 role 需要執行甚麼來完成。

### 部署架構 

Capistrano 部署到機器後結構大概會如下

```
├── current -> /home/deploy/do_deploy.com/releases/20150120114500/
├── releases
│   ├── 20150080072500
│   ├── 20150090083000
│   ├── 20150100093500
│   ├── 20150110104000
│   └── 20150120114500
├── repo
│   └── <VCS related data>
├── revisions.log
└── shared
    └── <linked_files and linked_dirs>
```

Capistrano 在每次部署時都會產生一個新的資料夾在 releases 目錄下，新的資料夾裡面就是新版本的 code 而資料夾名稱也是用當時時間命名。所以 releases 目錄下就會有每次部署時程式碼。current 資料夾是目前最新版本的程式碼資料夾，他的來源其實就是用 symlink 指到 releases 資料夾中最新版本的程式資料夾！

在我們的專案中有一些資料我們可能希望他能在不同的 release 中都能使用同樣的資料，就譬如 `20150080072500`、`20150090083000` 等資料夾中的 log 目錄想用同一個，這時候我們會把 log 目錄放在 shared 資料夾中，同時一些敏感資料如 database.yml 或是 settings.yml 這些不會放在版本控制的檔案，也會放在 shared 資料夾中，要怎麼放進去呢？那就要在設定檔中設定啦！

### 設定檔

Capistrano 的相關檔案在專案中的位置如下：

```
├── Capfile
├── config
│   ├── deploy
│   │   ├── production.rb
│   │   └── staging.rb
│   └── deploy.rb
└── lib
    └── capistrano
            └── tasks
```
>設定檔部分會依序介紹 Capfile、deploy.rb、prdouction.rb 這三份檔案

Capfile 的設定會決定你的 Capistrano 可以使用哪些功能，這些功能也就是你能使用的 Capistrano 指令有哪些，以及在跑這些指令的時候會做什麼事。

將部分註解都拿掉，一份全新的 Capfile 設定檔可能長這樣

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

# Include default deployment tasks
require "capistrano/deploy"

require "capistrano/scm/git"
install_plugin Capistrano::SCM::Git

# require "capistrano/bundler"
# require "capistrano/rails/assets"
# require "capistrano/rails/migrations"
# require "capistrano/passenger"

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }
```
為了部署 Rails App 同時讓我們管理設定檔方便，我會在 Capfile 加上

```

require "capistrano/bundler"
require "capistrano/rails/assets"
require "capistrano/rails/migrations"
require "capistrano/passenger"
require 'capistrano/upload-config'
```

這樣我們就有了專門針對 Rails 部署設計的功能，至於到底會有什麼差別呢？我們可以在使用 cap production deploy 的時候知道，詳細情況會在常用指令介紹

---

接下來 deploy.rb 還有 production.rb 分別代表 global 的設定還有 stage specific 的設定，這是什麼意思呢？我們部署時可能有很多種環境，staging、production 等等之類的，如果有些設定是所有環境都套用的就是 global 的設定，如果是專門放在某個環境的就是 stage specific 的設定。其中 deploy.rb 裡面就是 global 的設定，而 config/deploy/ 這目錄下的 xxx.rb 就是 stage specific 的設定唷！

config/deploy.rb
> global 設定

```
lock "~> 3.10.1"

# 設定專案名稱
set :application, "do_deploy"

# 讓機器知道要到哪裡找我們的程式碼
set :repo_url, "git@github.com:shes50103/do_deploy.git"

# 放在 shared 中，那些不在版本控制中的檔案
append :linked_files, "config/database.yml", "config/secrets.yml", "config/settings.yml"

# 放在 shared 中，不同 release 之間共享的目錄
append :linked_dirs, "log", "tmp/pids", "tmp/cache", "tmp/sockets", "public/system"
```

config/deploy/production.rb
> stage specific  設定

```
# 設定部署 Rails 的模式
set :rails_env, :production

# 決定要部署版本控制庫的哪一個 branch
set :branch, 'master'

# 決定部署到遠端伺服器哪個地方，從絕對路徑寫起
set :deploy_to, '/home/deploy/do_deploy.com'

# 見下方說明
role :web, %w{deploy@178.128.xxx.xxx}
role :db, %w{deploy@178.128.xxx.xxx}
```
>其實如果你喜歡的話，把所有 deploy.rb 裡面的東西都丟到 production.rb 裡面也是跑得動的，問題就會是假如到時候想要部署 staging 的時候， staging.rb 也得寫一大堆東西

整個部署流程，我們需要在本地電腦用 ssh 連線到遠端伺服器，要連線上去需要有遠端伺服器的 IP 以及我們要連線上去的身份，在這裡我們使用一個叫做 `deploy` 的使用者連線上去，意思就是在遠端伺服器裡面有這麼一個使用者，同時他的`~/.ssh/authorized_keys` 裡面有我本地電腦 ssh 公鑰，這樣我才能連線上去！

此外，當我以 deploy 使用者連線上遠端伺服器後，我還需要在遠端伺服器中再連線到程式碼倉庫，所以我也必須把 deploy 使用者的公鑰放到程式碼倉庫才能完成部署。記得前面提到的 Capistrano 的特性 Server roles 嗎？這邊看到的 `role :web` 還有 `role :db` 就是我們在部署時指定的 role 唷！

誒！？
怎麼感覺只設定了一點點東西，其實設定檔還有很多其他參數可以調整，但都有預設值了，譬如

```
# Releases 目錄下最多保留五份程式碼
set :keep_releases, 5

# 預設版本控制是使用 Git
set :scm, :git
```

因為已經有預設值了，所以可以少設定很多東西，我們就特別對我們要設定參數調整即可！ 
更多詳細資料可以看[官方文件](https://capistranorb.com/documentation/getting-started/configuration/)

### 常用指令

完成設定檔後，我們總需要在終端機下指令來部署或是操作些什麼，要怎麼知道我們現在的設定能使用哪些指令呢？那就是下面這個

```
bundle exec cap -T
```

可以查詢目前 Capistrano 中能使用的指令，能使用的指令有哪些就取決於 Capfile 中 require 了多少東西，可以試試看把一些 require 的設定註解掉後再輸入一次 `bundle exec cap -T` 能使用的指令會變少

---

```
bundle exec cap production config:pull
bundle exec cap production config:push
```

要使用這兩個指令必須安裝 `gem 'capistrano-upload-config'` 以及在 Capfile 中加入 `require 'capistrano/upload-config'` ，這兩個指令就是把遠端伺服器中的 linked_files 檔案抓下來以及上傳上去

---

```
bundle exec cap production deploy:check
```

這個指令會幫忙檢查要部署的專案目錄( `deploy_to設定的那個` )、 linked_dirs 、 linked_files 這些是否存在，如果不存在它會幫我們把目錄的部分做出來，所以在部署專案的一開始都會使用這指令來幫我們把 shared 目錄建立好，這樣才能用 `cap production config:push` 將設定檔上傳上去！

---

接下來這個就是部署的指令啦！

```
bundle exec cap production deploy
```

到底會做什麼呢？取決於設定檔的寫法，如果 Capfile 有了這兩行

```
require "capistrano/setup"
require "capistrano/deploy"
```

在 deploy 的時候就會跑過以下步驟

```
git:wrapper
git:check
deploy:check:directories
deploy:check:linked_dirs
deploy:check:make_linked_dirs
git:clone
git:update
git:create_release
deploy:set_current_revision
deploy:symlink:linked_files
deploy:symlink:linked_dirs
deploy:symlink:release
deploy:cleanup
deploy:log_revision
```

如果要部署 Rails 這可能還不夠，我們會需要在 Capfile 內加上

```
require "capistrano/bundler"
require "capistrano/rails/assets"
require "capistrano/rails/migrations"
```

這樣在跑 deploy 的時候就能增加這幾個步驟

```
bundler:install
deploy:assets:precompile
deploy:assets:backup_manifest
deploy:migrate
deploy:migrating
```

> 這五個步驟會在 `deploy:symlink:linked_dirs` 和 `deploy:symlink:release` 之間

在使用 Capistrano 比較常卡關的問題可能就是有些步驟是只有特定的 role 才能執行，這時候就要另外設定，又或者是有些東西的安裝我們可能需要額外指定明確路徑，不然就會安裝在錯的地方。更詳細的部署流程可以參考[這裡](https://capistranorb.com/documentation/getting-started/flow/)

## 結論

在學習部署的過程中，儘管已經完整走完了部署的流程讓服務可以正常執行，但是對這些部署工具的掌握還是十分有限，有很多東西只知道出問題了要這樣做、要那樣試可能可以解決問題，但往往不是很清楚自己到底在幹嘛XD，所以趁這個機會整理了一下這些工具的使用方法。

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

thumb photo-1526639673778-1ed7ff390a4a

Rails 部署工具，原來是這樣

在三大主流前端框架中，最年輕的 Vue 無疑是個爆發力最強的一個，尤其是容易上手且中文資源多，對於很多人來說 Vue 是踏入前端框架的首選。Rails 自 3.1 版使用 jQuery 並且搭配 Asset pipeline 來打包前端資源已經好一段時間，在這個前端爆炸的年代這個組合已經略顯不足，直到 Rails 5.1 開始引入了 webpack 並且可搭配 yarn 做前端套件管理後，大大的提升 Rails 對現代前端框架支援的友善度！
本篇將會以一個搞不懂前端生態(誤) 的 Rails 開發者視角來探討：

- 手把手的寫一個簡單的 Rails 搭配 Vue 專案
- 如何在 Rails 中應用 Vue component
- 怎麼在 Rails 中搭配 Turbolink
- 其他有的沒的
(本篇使用的是 Rails 5.2.2)

## 專案初始
以下範例程式，我們將要做一個簡單的通訊錄系統，並且嘗試用 Vue 來顯示結果。
開始之前請先確定：

- 你的電腦上已經安裝好 [node.js](https://nodejs.org/en/)
- 你的電腦上已經安裝好 yarn. Mac user 可以直接使用 homebrew ( `brew install yarn` ) 安裝 

> Rails 利用 yarn 來管理前端套件，你可以把它想像成是一個比較新潮的 npm。

接下來要新增一個「預先裝好 Webpack 並搭載 Vue 而且不裝 Turbolink 的 Rails 專案」，我們命名這個專案為 「vue_example」

```bash
$ rails new vue_example --skip-turbolinks --webpack=vue
```

Turbolinks 是 Rails 用來加入頁面載入的套件，其實就是透過快取來替換部分的頁面內容，但是如果搭配使用前端框架渲染頁面時就有可能產生錯誤，我們之後再說明如何結合 Turbolink 使用 Vue，目前將 Turbolink 關閉。

雖然使用 `rails s` 啟動專案後就可編譯 webpack 的程式碼，但是可以使用 `webpack-dev-server` 來做即時的自動編譯(存檔後瀏覽器就會重新 hot reload)。Webpack 已經內建了 `webpack-dev-server`，在 console 中輸入 `bin/webpack-dev-server` 就可以啟動了。但每次都要開兩個 server 也說不上很方便，所以可以順道安裝 **foreman** 來幫我們同時把需要的服務都開起來。

在 _Gemfile_ 下新增 foreman

```ruby
group :development do
  # other gem ...
  gem 'foreman'
end
```

存檔後記得 `bundle install`

接這在專案根目錄下新增一個 _Procfile_ 檔案，把我們要一起開的服務都輸入進去

```
backend: bin/rails s -p 3000
frontend: bin/webpack-dev-server
```

存檔後，往後就可以在 console 中輸入 `foreman start` 來同時啟動所有需要的服務啦!

接著使用 scaffold 來快速產生我們要的範例程式

```bash
$ rails g scaffold AddressBook name:string email:string phone:string description:text
$ rails db:migrate
```

然後請自己在 `rails console` 下，自己新增一些假資料。

## 開始撰寫 Vue
我們來看一下安裝 webpacker 和 vue 之後, 在 `app/` 資料夾多下了個 `javascript` 資料夾，而底下的 `path/` 資料夾就是放置 webpack 的 entry point。講白話就是最後 webpack 的模組都會匯集到 entry point 裡，最後會利用神奇的魔法將模組編譯在一起，透過這個 entry point 來整合所有複雜的前端元素到我們的 html 網頁中。

```
/app/javascript
├── app.vue
└── packs
    ├── application.js
    └── hello_vue.js
```

vue 幫我們自動產生了一個 entry point - **hello_vue.js** 和模組 **app.vue** ( 有興趣可以看一下裡面在寫什麼 )

我們這裡不使用 hello_vue.js，手動建立一個自己的 entry point - **main.js**

```javascript
import Vue from 'vue/dist/vue.esm'
import NameCard from '../name_card.vue'

document.addEventListener('DOMContentLoaded', () => {
  const app = new Vue({
    el: '#app',
    components: { NameCard }
  })
})
```

[**app/javascript/packs/main.js**]

然後新增一個叫做 **name_card.vue** 的元件檔

```html
<template>
  <div class="name-card">
    {{message}}
  </div>
</template>

<script>
export default {
  data: function () {
    return {
      message: "this is a name card by Vue"
    }
  }
}
</script>

<style scoped>
.name-card {
  border: 1px solid rgba(0, 0, 0, 0.205);
  display: inline-block;
  padding: 10px;
  margin: 5px;
  background-color: #fff;
  border-radius: .25rem
}
</style>
```

接著我們要把 entry point 放到網頁裡面，最適合的地方就是在 Rails 預設的網頁 layout template： **app/views/layouts/application.html.erb** ，在它的`<head>` 標籤中加入 `javascript_pack_tag` 和 `stylesheet_pack_tag` 來載入 entry point

```erb
<head>
  
  <%= stylesheet_pack_tag 'hello_vue' %>
  <%= javascript_pack_tag 'hello_vue' %> 
</head>
```

[**app/views/layouts/application.html.erb**]

到 _index.html.erb_ 頁面上，加入一個 `<div id="app">` 的標籤作為 Vue 的掛載點，並且把 `NameCard` component放在裡面

```ruby

<hr>
<div id="app">
  <name-card></name-card>
</div>
```

[**app/views/address_books/index.html.erb**]

存檔後啟動專案，打開瀏覽器看一下結果

![name_card](https://i.imgur.com/HQSkja8.png)

其中 `stylesheet_pack_tag` 是用來載入 webpack 編譯完的 css style。可以試著把它拿掉，你會發現在 `app.vue` 內定義的 `<scope style>` 就失去了效果。

## 更好的 Vue component 掛載方式

如果覺得要使用 Vue component 都要先包一層掛載點像是 `<div id="app">` 覺得很麻煩（到底是多懶？），可以考慮以下的小技巧：
在 application layout 中，用一個標籤把整個 `yield` 包起來

```ruby
<html>
  
  <body>
    <div class="container" data-behavior="app">
      <%= yield %>
    </div>
  </body>
</html>
```

[**app/views/layouts/application.html.erb**]

然後修改掛載點，綁定 `[data-behavior]` 屬性

```javascript
// ...
document.addEventListener('DOMContentLoaded', () => {
  const app = new Vue({
    el: '[data-behavior="app"]',
    // ...
  })
})
```

[**app/javascript/packs/main.js**]

這樣整個 view 都是我的 Vue 掛載點啦，是不是很方便！
這樣一來在 _index.html.erb_ 中我們可以把 `<div id="app">` 拿掉，直接把 component `<name-card>` 放上去就好

## 使用 props 來收 Rails 的資料
接著要來繼續改善我們的程式，透過 Vue 的 `props` 屬性，可以接收由 component 外傳傳遞進來的資訊。
修改 `name_card.vue` 元件

```html
<template>
  <div class="name-card">
    <ul>
      <li>name: {{ item.name }}</li>
      <li>email: {{ item.email }}</li>
      <li>phone: {{ item.phone }}</li>
    </ul>
  </div>
</template>
<script>
export default {
  props: ["item"],
}
</script>



```

[**app/javascript/name_card.vue**]

在 index.html.erb 中我們有一個 `@address_books` 是透過 Rails 取得的所有通訊錄資料，將資料個別取出後，轉成 json 格式就可以將每一筆的 `address_book` 餵給 Vue 的 `NameCard` 元件

```erb
<%@address_books.each do |address_book|%>
  <name-card :item="<%=address_book.to_json %>"></name-card>
<%end%>
```

[**app/views/address_books/index.html.erb**]

![prop](https://i.imgur.com/j1dJQqv.png)

## 關於 Vue 在 Rails 的自問自答

> Turbolinks 一定要關掉嗎？

其實已經有相關的 Vue 套件 **"vue-turbolinks"** 可以讓 Vue 與 Trubolink 共存
使用 yarn 安裝 **vue-turbolinks**

```bash
$ yarn add vue-turbolinks
```

然後你的 entry point ( _main.js_ ) 必須改成這樣

```js
import TurbolinksAdapter from 'vue-turbolinks'
import Vue from 'vue/dist/vue.esm'
import App from '../app.vue'

Vue.use(TurbolinksAdapter)

document.addEventListener('turbolinks:load', () => {
  const app = new Vue({
    // ...
  })
})
```

主要是因為 Turbolinks 會暫存到 Vue 渲染過的頁面，造成快取到錯誤的頁面結果，而這個套件就是在解決這件事情。

> 沒有了 jQuery, 有什麼可以替代 $.ajax 呢？

- ES6 原生的 [fetch api](https://developer.mozilla.org/zh-TW/docs/Web/API/Fetch_API)
- [Vue resource](https://github.com/pagekit/vue-resource)
- [Axios](https://github.com/axios/axios) : 目前 Vue 官方推薦使用

> webpack 好麻煩，不能繼續用 asset pipline 嗎？

如果單純的在 `<script>` 中來撰寫 Vue，是不需要經過 Webpack 編譯的，可以自行將Vue.js library 引入到 _application.js_ 裡面，或者直接安裝[vuejs-rails](https://github.com/adambutler/vuejs-rails) gem。

> 如果我想要在 Vue 元件中用 i18n 或其他 Rails 的 helper 怎麼辦？

Vue 提供了 inline template 的方式，可以直接在我們的 Rails view file 中撰寫 vue 的模板，而不是去使用原本 _.vue_ 中的 `<template>` 模板

```erb
<%# 我是 .erb  %>
<name-card inline-template>
  <%# 你可以在這邊使用 Rials helper %>
</name-card>

```

## 小結
本篇著重在如何在維持 Rails MVC 的架構下，輕量的導入 Vue.js 前端框架，對於 Rails 開發者來說是相對容易與現行架構整合的一個方式。如果對於 Webpack 想要更深入探索，推薦各位可以參考五倍紅寶石工程師 Roy 寫的 [新手向 Webpack 完全攻略](https://5xruby.tw/posts/webpack-for-beginner/) 系列文章，而看了本篇覺得 Vue 很有趣，歡迎來參加五倍紅寶石開設的 [Vue.js 與 Vuex 前端開發實戰課程](https://5xruby.tw/talks/vue-js/)喔！

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 和 Vue.js 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) / 🧚 [Vue.js 與 Vuex 前端開發實戰](https://5xruby.tw/courses/vue-js) 課程唷 ❤️️
>

post-在 Rails 中開始 Vue

在 Rails 中開始 Vue


隨著數位人才的需求逐年攀升，「工程師」也成為許多人心中嚮往的職涯選項與轉職目標，各式各樣「程式學習」資源也正在蓬勃發展。無論線上或實體課程、免費或付費教學，開始「學寫程式」的人數正在快速成長中。

然而「找到最適合自己的學習方式」可以說是程式學習路上最重要，也是最先要面對的課題之一。畢業於歷史系的小雅，從一個完全沒有程式開發經驗的初心者，到現在成為負責網站開發的專業後端工程師，這趟轉職歷程的起點，就是從五倍紅寶石的課程開始。

## 接觸程式的契機 是為了能更有效的溝通
小雅過去從事數位行銷，經常需要和工程師討論網站開發方向，但從未接觸過網站開發的她，對於網站的想像經常與實際開發的情境有所落差。

「當時最常聽到工程師同事說的一句話就是：『欸你這樣邏輯不對啊？』，其實每次聽到都會很納悶，到底什麼才是對的邏輯？慢慢心中就有了『想找機會接觸看看程式』的想法，想要了解工程師們到底都在想什麼。」

談起學習程式的初衷，小雅表示：「其實最一開始沒想過自己會有轉職工程師的機會，畢竟感覺這塊還是要有專精的知識，或是本科系出身才行，倒不如說是期待學了之後能夠幫上原本行銷的工作，和工程部門更有效的溝通。」

## 學習程式最重要的 是找到適合自己的方法

由於平日白天要上班，小雅決定利用下班時間在線上學習程式，但在學習過程中她發現，由於開課老師無法精確掌握學員進度，課程編排上容易忽略一些重要的基本觀念；除此之外，在課程或專案練習時遇到問題，也只能在 Facebook 的社團發問等待解答，很難得到立即性的回覆。

「後來一起上課的朋友跑來私訊我，説覺得這門課可能不太適合初學者，剛好那時注意到五倍的課程資訊，大家就一起去了解，最後決定加入五倍的課程試試。」

## 為初學者量身打造的課程 跨越從學習到就職的門檻

提起在五倍上課的經驗，小雅很開心的說：「五倍的課程真的是從0到1的課程！不只是基礎的 HTML、CSS 那種意思，而是針對初學者容易有的迷思或不容易理解的概念，反覆耐心的講解到學員都會為止，許多學員畢業後也經常回來求助，老師們也都很熱心的回應。」

另外，小雅也提到每週二在五倍舉辦的「默默會」，一個讓學員們自由交流提問的聚會，不管是實體課程或線上課程的學員，都能在默默會獲得幫助，老師也總是盡心盡力的解答學員遇到的問題。

擔心學生沒有實際接觸過業界、不了解求職眉角，因此在課程之外，五倍也定期舉辦徵才媒合會，小雅的收到第一份工程師面試，就是在媒合會上投遞的履歷，最後面試錄取的公司，也是在五倍上課期間接觸到的團隊。小雅認為：「其實非本科系的人要轉職，最大的門檻還是「如何求職」，五倍提供這樣的資源其實很好，畢竟只要能先踏入這個產業，就是很大的進步了。」

## 給想跨入程式領域的你：「不要害怕。」

「畢竟多數人對程式開發的想像，都是需要高度專業，有些非本科系的人，或是從來沒有接觸過程式的人，會覺得自己做不到、沒機會，光是跨不過這一步，就會把自己排除在學習程式，甚至轉職之外。」

小雅認為，學習程式最重要的是不要害怕，不管成功失敗，先投入試試看。就算最後真的學不起來，頂多就是回到原本的工作而已；如果學的順利，在多一份技能的同時，也多了一項職涯選擇。「學程式，就是這樣一趟苦盡甘來的歷程吧！」

1. 非本科系的你，只要肯嘗試去做，相信你也可以
2. 找到適合自己的方式學習非常重要！
3. 來 [默默會](https://www.facebook.com/rubymokumokukai/) ，認識技術圈的朋友，在學習上面獲得許多不同資訊交流，任何關於課程以及技術問題都能詢問五倍紅寶石專業團隊。
4. 近期舉辦說明會，有興趣不如直接去現場看看吧：[ASTRO X 五倍紅寶石 全端工程師實戰訓練營](https://astro.5xruby.tw/)


post-如何從數位行銷跨入成為軟體工程師？

如何從數位行銷跨入成為軟體工程師？

post-Serverless 與 Node-Canvas 實作動態圖表匯出 / cover

Serverless 與 Node-Canvas 實作動態圖表匯出

> 本學習筆記皆參考 Stephan Grider 在 Udemy 上所發表的付費課程 [Webpack 2: The Complete Developers Guide](https://www.udemy.com/webpack-2-the-complete-developers-guide/learn/v4/overview)，倘若對於本課程有興趣，非常推薦選修該課程。

## 什麼是 Webpack ?
Webpack 是一個 JavaScript 的建構工具，負責將無數的 JavaScript 檔案整合成一個檔案。

## 為什麼要使用 Webpack？

由於近代的網頁應用開發慢慢走向了「一頁式應用」(Single Page Application)，JavaScript 也開始佔了非常重要的角色，而同時 JavaScript 在應用程式當中的比例也呈現爆炸性的成長，因此我們必須想辦法降低 JavaScript 的複雜度並進行妥善的管理。

而在早期的應用程式當中，有可能只有兩三個主要的 JavaScript 檔案，但是裡面卻有上千行的程式碼，這樣的方式非常不易於管理與維護。想像一下，假設你今天需要修改網頁上的某個區塊，你要花多少時間去尋找對應的程式碼、並確認有沒有關聯的部分需要一併處理，以免弄壞別的功能？

因此，目前的開發也慢慢傾向將 JavaScript 模組化，例如我們會將 JavaScript 分成 `footer.js`、`search_bar.js`、`filter.js`，透過有意義的命名讓管理變得更加容易。

但這樣的管理方式也是個雙面刃，主要的缺點有兩個。首先，JavaScript 的模組之間可能會有依賴性。假設 JavaScript A 裡面會用到 JavaScript B 的模組，那我們就必須要先讀取 B 再讀取 A，這樣才不會出現錯誤。再者，假設們把三四個 JavaScript 拆成三、四十個檔案，會對頁面讀取的效能造成極大的影響，而這個缺點在行動裝置上將會特別明顯。

而 Webpack 的出現就是為了解決這樣子的問題。Webpack 會將你所有的 JavaScript連結成一個檔案，而更重要的是，他會確保所有 JavaScript 的讀取順序是正確的，讓你不需要再擔心依賴性的問題。

而 Webpack 的功用當然不僅於此，透過 Loader 可以將 JavaScript ES6 編譯成各個瀏覽器都通用的 ES5，或是編譯 CSS 甚至是圖片等等，但是最主要的核心功能還是將所有的 JavaScript 包成一個檔案，讓開發者可以同時兼顧網頁效能以及後續的維護便利性。

> 此分享轉載自五倍 Rails 工程師 Roy Huang 的 [開發筆記](https://roy-huang.com/2017/04/08/%E6%96%B0%E6%89%8B%E5%90%91-webpack-%E6%95%99%E5%AD%B8-1-webpack-%E7%B0%A1%E4%BB%8B/)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Webpack 觀念和原理嗎？
>
> 我們有開設 🏓 [React 全攻略入門班](https://5xruby.tw/courses/react) 課程，課程內包含『Webpack 5 入門教學』線上課程喔 ！ ❤️️
>


新手向 Webpack 完全攻略 – Webpack 簡介


## Multi-tenant 應用程式：讓人又愛又恨的 Apartment

隨著現在個人化網站的興起，許多網路服務都提供使用者自訂網站的功能。這些功能涵蓋許多面向，包含論壇、部落格與網路個人商店等。典型的自訂網站例子如 Wix 與 Weebly，個人商店則如 Shopmatic 與 Shopify 等等。在這些服務中，使用者可以在某些限度下自定網站的內容，建立屬於自己的資料，而不會與其他使用這個服務的使用者衝突。換句話說，不同的使用者使用同一個服務，但他們的資料卻是各自分離的，這便是最基本的 multi-tenant 的精神。由於以 multi-tenant 風格的網站建立越來越熱門，因此在各大網站開發框架上都有提供相關的開發工具可用。今天要跟各位讀者分享的，便是最常被用在 Rails 應用程式中的 multi-tenant 工具：`apartment`。

此篇文章中會大致介紹 `apartment` 這個套件如何使用，以及帶讀者建立一個簡單的 multi-tenant 部落格示範網站，並且提出一些使用 `apartment` 可能會遇到的問題。

## `apartment` 是什麼

`apartment`（[Github repo](https://github.com/influitive/apartment)）是 Ruby/Rails 圈最常用來製作 multi-tenant 的 gem。如同其英文「公寓」，`apartment` 可以讓我們蓋出公寓般的資料庫結構，每一戶的格局相同但卻都是獨立運行，互不影響。我們通常會把一戶單獨的使用者稱為一個「tenant」，也就是（公寓）的承租人。`apartment` 最大的特色是與 Rails 的 ActiveRecord 做了相當緊密的結合，使用者可以在指定了特定的 tenant 後，直接使用自己所熟悉的 ActiveRecord ORM（如部落格網站中取得所有文章的 ORM: `Article.all`，來取得只屬於自己 tenant 的資料），而不需要明確的加上 `where` 篩選條件（也就是不必用 `Article.where(tenant_id: 1)` 明確篩選自己的 `tenant_id`）。因為有著如此便利的特性，使得 `apartment` 經常被用來快速開發 multi-tenant 網站的原型。

底層資料庫的支援部分，`apartment` 最早先是以 PostgreSQL 為主要支援的資料庫，主要原因是因為 PostgreSQL 有「schema」的特性可以使用。`apartment` 會替每一個不同 tenant 各自開一個 schema，已達到資料隔離的功能。

後來版本的 `apartmemt` 也逐漸支援如 MySQL 等資料庫系統。不過基於穩定性與功能性因素，仍然建議大家使用 PostgreSQL 作為 `apartment` 底層的資料庫系統。因此，以下的情境都會假設使用者使用的資料庫是 PostgreSQL。

## `apartment` 的基本應用與例子

為了讓大家了解更近一步了解 multi-tenant 的應用程式運作，在這個章節中會帶讀者一步一步建立一個 multi-tenant 的部落格網站。以下環境是基於 `ruby 2.4.1` 與 `rails 5.1.4`

> **附註**：這個範例因為夠簡單，即使不需要使用 `apartment`，也可以輕易透過傳統的 `where` 條件來實作。`apartment` 帶來的好處在當網站中的 model 數量夠多時才會比較明顯（也比較讓人願意使用 `apartment`），但這裡基於示範的目的而刻意在這個迷你專案中使用 `apartment`。

首先我們先來定義一下這個迷你專案的功能。我們會製作一個具有登入功能的部落格網站，每一個使用者登入之後都可以對屬於自己的文章進行 CRUD （Create, Read, Update, Delete）操作，且無法干涉其他使用者的資料。

資料庫結構的部分如下圖，我們只會有兩個 model，分別是 `User` 與 `Article`。`User` 是存放登入用的使用者，同時也是文章的擁有者。使用者登入系統的部分我們會直接使用 `devise`（[Github repo](https://github.com/plataformatec/devise)）這一個套件來建立。至於 `Article` 則是每個使用者自己的文章，這個 model 會直接透過 Rails 的 Scaffold 功能直接建立。

在這個架構中，我們希望 `Article` 是每個使用者各自分開的，讓他們不能互相干擾。而 `User` 則是不根據 tenant 分開，因為這個 model 是給 `devise` 登入系統使用，因此是所有 tenant 之間共用的（稱為 `public` schema）。

大部分的欄位相信讀者都不陌生，幾個值得注意的是：`User` 有個特殊的欄位稱為 `tenant_name`，這是用來區別這一個使用者的 tenant，讓 `apartment` 知道該去哪一個 PostgreSQL schema 存取資料。至於存放在各 schema 中的表得（如 `Article`）則不需要傳統的 `user_id` 之類的欄位來記錄該文章屬於哪一個使用者。

![資料庫結構圖](https://i.imgur.com/1P7WJYc.png)

### 第一階段：建立沒有 multi-tenant 功能的一般專案

我們先由建立一個沒有 multi-tenant 功能的專案開始，先確保我們需要的每個零件都有正常運作。之後再來加入 `apartment` 來實現 multi-tenant 功能。

- 建立新專案

```text
rails new apartment-demo
```

- 修改 `Gemfile`，加入要用到的 gem，並且將資料庫 gem 改為 `pg`，並執行 `bundle`

```ruby
gem 'devise'
gem 'apartment'
gem 'pg'
# gem 'sqlite3' # 註解掉原本的 sqlite3
```

- 修改 `database.yml`，改為使用 PostgreSQL

```yml
default: &default
  adapter: postgresql
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: apartment-demo-dev

test:
  <<: *default
  database: apartment-demo-test

production:
  <<: *default
  database: apartment-demo-production
```

- 建立資料庫

```text
rake db:create
```

- 初始化 `devise`，並產生 devise views

```text
rails g devise:install
rails g devise:views
```

- 修改 `application.html.erb`，新增登入登出的連結

<script src="https://gist.github.com/lctseng/a26520daa61946ca5d15fed9fdbca8de.js"></script>

- 使用 `devise` 建立 `User` model，並加入 tenant_name 的欄位，同時也產生 controllers 供未來修改使用

```text
rails g devise user tenant_name:string
rails g devise:controllers users -c=registrations
```

- 修改產生的 migration file，記得將 `tenant_name` 設定為 `null: false` 並加入 unique index

```ruby
class DeviseCreateUsers < ActiveRecord::Migration[5.1]
  def change
    create_table :users do |t|
      ## Database authenticatable
      t.string :email,              null: false, default: ""
      t.string :encrypted_password, null: false, default: ""

      ## Recoverable
      t.string   :reset_password_token
      t.datetime :reset_password_sent_at

      ## Rememberable
      t.datetime :remember_created_at

      ## Trackable
      t.integer  :sign_in_count, default: 0, null: false
      t.datetime :current_sign_in_at
      t.datetime :last_sign_in_at
      t.inet     :current_sign_in_ip
      t.inet     :last_sign_in_ip

      t.string :tenant_name, null: false

      t.timestamps null: false
    end

    add_index :users, :email,                unique: true
    add_index :users, :reset_password_token, unique: true

    add_index :users, :tenant_name, unique: true
  end
end
```

- 修改 `app/views/devise/registrations/new.html.erb`，新增欄位讓我們可以填寫 `tenant_name`

<script src="https://gist.github.com/lctseng/eb1664442c6ff06a12a525e50899d491.js"></script>

- 修改 `routes.rb`，讓 `devise` 使用我們自訂的 controllers

```ruby
devise_for :users, controllers: {
  registrations: 'users/registrations'
}
```

- 修改 `app/controllers/users/registrations_controller.rb`，使得我們可以更新 `tenant_name` 這個欄位

```ruby
class Users::RegistrationsController < Devise::RegistrationsController
  before_action :configure_sign_up_params, only: [:create]
  def configure_sign_up_params
    devise_parameter_sanitizer.permit(:sign_up, keys: [:tenant_name])
  end
end
```

- 建立 `Article` 的 Scaffold。注意我們並不需要 `user_id` 欄位。

```text
rails g scaffold article title:string content:text
```

- 在產生的 `app/controllers/articles_controller.rb` 上方加入權限控制

```ruby
before_action :authenticate_user!
```

- 執行 DB migrate，此時可能會看到 `apartment` 噴出的一些警告，目前可以暫時忽略

```text
rake db:migrate
```

- 設定 `routes.rb`，將網頁的首頁指向文章列表

```ruby
root to: 'articles#index'
```

到目前為止，讀者可以啟動 `rails server`，檢視 `devise` 與 Scaffold 是否可以正常運作。這邊我們先註冊兩個使用者 Alice 與 Bob，其 `tenant_name` 分別設置為 `alice` 與 `bob`。此時雖然有使用者驗證，但你會發現此時的 `Article` 並沒有根據使用者做區別，所有人的文章都混在一起。

### 第二階段：使用 `apartment` 將不同 tenant 的資料區隔開

有了基礎專案之後，接下來就是進行 `apartment` 相關的修改，使得不同使用者之間的資料完全區隔。

- 建立 `apartment` 設定檔：`config/initializers/apartment.rb`，並修改內容：

```ruby
Apartment.configure do |config|
  # 因為 Devise 登入只能放在同一個 schema，因此將之從 apartment 排除
  config.excluded_models = ["User"]
  # 告知 apartment 如何找出所有的 tenant_name 供 migration 使用，這裡我們使用 User model 同名的欄位 tenant_name
  config.tenant_names = lambda{ User.pluck(:tenant_name) }
end
```

- 手動替 `alice` 與 `bob` 建立各自的資料庫 schema。由於前一階段並沒有替這兩個 tenant 建立 schema，因此這邊透過   `rails console` 手動建立

```ruby
Apartment::Tenant.create('alice')
Apartment::Tenant.create('bob')
```

- 讓未來新註冊的使用者可以自動建立 schema，修改 `app/controllers/users/registrations_controller.rb`

```ruby
class Users::RegistrationsController < Devise::RegistrationsController
  def create
    super do |user|
      # 這個 block 將在使用者被建立後執行，因此我們可以從這裡取出 tenant_name 來建立 schema
      Apartment::Tenant.create(user.tenant_name)
    end
  end
end
```

- 修改`app/controllers/articles_controller.rb`，限制所有的資料都只能在當前登入的 tenant schema 底下操作（也就是資料隔離）

```ruby
class ArticlesController < ApplicationController
  # 注意這幾個 before_action 的順序
  before_action :authenticate_user! # 設定 devise 時加入的
  before_action :switch_tenant # 新加入
  before_action :set_article, only: [:show, :edit, :update, :destroy] # scaffold 產生的

  # 這個 before_action 將會根據當前的使用者切換至該使用者的 schema
  def switch_tenant
    Apartment::Tenant.switch! current_user.tenant_name
  end
end
```

完成了！沒錯，就這麼簡單。重新啟動 rails server 後，你會發現現在 alice 與 bob 所建立的 `Article` 已經完全隔離了。不但不會在列表中看到別人的文章，就算透過 `/articles/1` 這樣的路徑，也只能看到自己名下編號為1的文章而已，沒辦法看到其他使用者的。此時你如果建立第三個使用者 Carol，其 `tenant_name` 為 `carol`，你也會發現這個新建立的使用者完全與其他人資料隔離。

本範例專案的原始碼也可以在 [Github](https://github.com/lctseng/rails-apartment-demo) 上找到。

## 使用 `apartment` 可能會遭遇到的問題

從上面的專案中我們可以看到使用 `apartment` 建立 multi-tenant 應用程式是多麼容易的事情。那為什麼這篇文章的標題卻又說「又愛又恨」呢？原因是 `apartment` 天生設計上就有一個缺陷，那就是當 tenant 數量成長到一定程度時，會出現許多預想不到的副作用。

最簡單的例子就是 Database Migration。因為 `apartment` 把資料完全隔離，所以在進行 migration 時各個 schema 會別處理。因此，當你使用的 schema 數量越來越大時，最首先感覺到的變化就是進行 migration 的時間會拉長。

另一個問題是記憶體消耗與程式啟動時間。由於在 `rails 4.2.2` 之前版本的架構中，會在啟動時根據資料庫 schema 中的表格逐個建立一份對應的資料存在記憶體中。這是個相當消耗時間與記憶體的動作。這個問題在 `apartment` 的 Github repo 中有給予一個 [patch 後的 rails 版本](https://github.com/influitive/apartment#excessive-memory-issues-on-activerecord-4x)，可以稍微舒緩記憶體壓力。

最後一個問題是硬碟空間。在某些檔案系統中，單一磁區所能儲存的檔案數是有上限的。因此如果 schema 總數太高，會造成 PostgreSQL 建立過多的檔案導致碰撞到這個上限。雖然這個問題解法比較多元，且不同檔案系統對檔案數上限也不同，因此也不一定會被讀者的專案所遇到。但如果今天萬一遇到了，不像前面幾個問題可以透過升級記憶體或者等待更長時間來解決，而是必須進行立即的資料搬移。我們都知道資料搬移是一個相當繁重的過程，且過程中可能需要讓服務停機，其損失不可估計。

## 實際案例

筆者近期經手的專案就一次碰到了以上三個問題。曾經有一個 `apartment` 專案使用了超過十萬個 schema，除了 migration 幾乎快要一整天以外，每次啟動 server 或 console 都要花費十幾分鐘的時間，且 server 記憶體動輒就消耗到 10GB。最嚴重的是這個專案還曾經在 production 營運時撞到了檔案系統的檔案數上限，導致服務差點就要凍結。

最後，在筆者與該專案開發團隊的努力下，成功找出一勞永逸的方案，並僅花四小時的停機時間進行資料轉換與搬移。詳細過程與解決方案，筆者將會在今年四月底舉辦的 [Ruby X Elixir Conf Taiwan 2018](https://2018.rubyconf.tw/program#liang-chi-tseng) 中分享這些細節，歡迎各位讀者共襄盛舉！

---

原文刊載於 [Henry Tseng's Digital Space](https://lctseng.github.io/post/multi-tenant-apartment/)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

post-Multi-tenant 應用程式：讓人又愛又恨的 Apartment/cover

Multi-tenant 應用程式：讓人又愛又恨的 Apartment


## 「在飯店上班時，看到外籍的工程師坐在吧台寫程式、遠端工作，當時就在想，我是否有一天也可以做得到？」

我是一個後端工程師，在成為後端工程師之前，我做的是 bartender， 在服務業待了接近六年的時間。

有些人會說：「你應該大學就是資訊相關科系吧～」其實，我大學原本唸的是德文，甚至因為家庭因素，大一唸完就休學去工作；後來下定決心轉職後，從初次接觸程式，到找到工作，前後大約是一年的時間。

轉職之前，我在飯店業工作了滿長一段時間，

那時候看主管們的生活就大概可以想像未來的發展，如果一直留在飯店做服務業，薪水很容易遇到天花板限制，即使做到主管階級，也是長時間被綁在飯店，甚至得住在飯店。

就覺得這不是我想要的，我理想的工作是能夠有自己時間能夠陪陪家人，做想做的事。

曾經跟家人、朋友討論過類似的想法，回饋大概是都是：

「你現在的工作不錯呀，五星級飯店欸，多少人想進去呀」

「那個 xxx 的女兒以前也是跟你一樣，熬過來以後薪水也是...」

「轉職成功的都是特例，你不能把特例作為自己的人生規劃...」

## 開始起步學寫程式時的想法很簡單：

我覺得「所有公司都需要網站」，所以就先從網站開發開始學起。

當時新創創業的風潮很盛行，技術的部分蠻多是採用可以快速開發的 Rails。

加上自己很嚮往在新創上班，又聽說會 Rails 的人很少，就選擇 Rails 做主力學習的目標。

最初在 Udemy 上面找了很多免費課程，但學起來散散的，很沒有系統。

例如：

叫你「把程式碼複製貼上」，貼一次、貼兩次，第三次自己手寫看看。原本跟著教材跑覺得很有趣，這樣拼拼湊湊竟然真的就做出了一個煞有其事的網站。但學到後面，發現自己只會套課程的模板、框架，對程式語言的特性和邏輯完全搞不清楚，沒有能力自己開發出想要的功能。當時真的超崩潰，心裡一直想「我的網頁會動，但我不知道為什麼！」甚至開始覺得自己可能真的不適合走程式這行吧 ⋯⋯

在網路上找技術文章的時候，有找到五倍紅寶石的高見龍（龍哥）在 iT 邦幫忙寫的 Rails 系列文。覺得寫得很清楚，蠻多疑惑有被解開，看他的文章才知道有五倍這個教育機構。後來發現他有開實體的基礎課程，抱著有點去見偶像的心情參加。我印象很深的是那次參加的課程，龍哥講到一句話突破了我的學習盲點：

「要知道程式如何思考，怎麼用程式思考的方式去寫程式、看程式。」

那天還重新聽了一次基本的 function、變數等等的概念。把許多之前上過課不懂的地方都連結起來，整個豁然開朗，後來也報名了他們的完整課程。

總之，他們的課對有程式底子的人來說怎麼樣我不知道，但我自己覺得對曾經自學卻卡住遇到瓶頸的人來說，非常有幫助！

## 轉職規劃

參加完課程後，我原先打算給自己一年的時間，花半年累積一些作品集，半年找工作。當時去上實體課程是 2017 年 10 月的事，因為自己是一邊學習、一邊還有工作，所以有想把戰線拉長一點。

可能是我當初問問題問得特別勤吧，老師們對我都蠻有印象的。課程結業沒多久，在 2017 年 12 月的時候，就受老師們的引薦，獲得了人生中第一個工程師職缺的面試機會，很幸運的，也在 2018 年 2 月的時候確定拿到 offer、3 月到新公司上班！

「當初預計會花一年的時間，最後從開始上課到拿到工作，只花了半年，順利從 bartender 轉職軟體工程師！（笑）」

而這一切會過的這麼順暢，主要原因有以下幾點：

### 1. 實務專案

許多跟我一樣半路出家的朋友，在轉職的路上走得不夠順的原因，就是他們沒有經歷過「真正的專案開發」。這就好像一個廚師他研究過很多食譜、知道每個規則，但從來沒有自己煮過菜一樣，這樣的工程師是很難找到工作的。仿間很多程式教育機構，雖然有協助工程師做專案，但是沒有業界的工程師協助「review」，對於品質與工作流程上，水準與業界的工程師還是有落差。

### 2. 作品集
強烈建議要花時間好好整理自己的「作品集」與個人頁面！

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/d0CD1loFd0kXyp88UKrLO/aa574c20d431b3908600307336350d0c/portfolio-1.png)

> 這是我當時求職的作品集，包含過去的作品、專案、和工作經驗（跟程式設計不相關，所以著墨的很少，基本上只寫單位、職位、期間）

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/4neySDt5BeQkqWPaCgQ9rT/8fec8b95aa4da41f8293dbd5df2bf89e/portfolio-2.png)

> 專案的部分，我把我負責的部分、有什麼功能，用 HR 也看得懂的方式表達

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/nxi7PA2iW2rAtxPVNqLgM/e248b74a58572542d44b36b659e0a2af/portfolio-3.png)

> 面試的時候，因為自己不是本科系而且跳很大，很多面試官都會問「動機」，因此我也獨立整理出來

根據以上這兩個點，五倍紅寶石近期有專門為了這兩個點，設計了全新的線下課程，可以參考。

最後想跟大家講分享一些我自己經歷學習到轉職這段時間後的體悟：

很幸運的，我在開始求職後的三個月找到工作，但同時，這樣的幸運來自於我全心投入轉職的準備與程式學習。

老實說，我覺得其實要轉職成功是真的很辛苦的，從準備成為工程師，到成為工程師，是充滿荊棘的一條路。

網路上許多轉職文章寫的感覺很輕鬆，但只是沒有把累的那一面寫出來。

可能蠻多人的想法是：現在工作薪水太低，想轉工程師得到好起薪，但「工程師」這條職涯選項，是必須一直不停學習的，否則技術推陳出新，真的會跟不上。

如果妳還卡在猶豫要不要轉職的階段，建議妳可以先從免費的課程開始，不論什麼語言，或是前後端。先跟著課程實作點東西出來，才知道自己是否可以接受寫程式。

也可以參加一些社群聚會，例如 [默默會](https://www.facebook.com/rubymokumokukai/) ，來這邊跟五倍的同仁詢問。

寫程式這件事，挫折感和成就感幾乎是一樣大的，想不出來時的挫折很大，但做出來的時候成就感也一樣大。

對真的想要轉職的人來說，重要的是要能禁得起挫折失敗。這段路上，一定是經過無數次的失敗，才終於把版排好、把功能寫出來。

就拿 Rails 當例子，有稍微接觸過 Rails 的朋友應該都一樣，最一開始讓人感到挫折的，就是陰魂不散的紅畫面！像我就不是很有耐心的人，每次看到都覺得很心煩 XD

但是該說幸好這個語言夠體貼嗎？反正 Rails 出錯的原因都會寫在畫面上，靜下心慢慢看，就能找出錯在哪裡。

真正的難關是「如何實作一個想要的功能出來」，這就攸關到你對語言原理的認識，以及如何操作、思考的流程。

以上都是比較辛苦面的說法啦，當然學程式寫程式，一定也是有快樂的地方。對我來說最快樂的時候，就是我順利解決一個又一個的 bug 的時候。還有看到網站上線的成就感，真的會覺得「啊～苦盡甘來！」

最後，總結以上：

1. 轉職是辛苦的，但結果是甜美的（以我自身的例子）
2. 專案一定要給業界工程師「review」過，才能從中獲得扎實的成長，縮短所學與業界的落差
3. 來 [默默會](https://www.facebook.com/rubymokumokukai/) 找已經在業界工作的人聊聊、與五倍紅寶石的課程團隊聊聊，或許會有不同的想法
4. 最近看到他們有在辦說明會，有興趣不如直接去現場看看吧：[ASTRO X 五倍紅寶石 全端工程師實戰訓練營](https://astro.5xruby.tw/)

post-轉職只是選擇，我從 Bartender 轉軟體工程師

轉職只是選擇，我從 Bartender 轉軟體工程師


這篇文章要討論的是 XML 格式的 sitemap，而不是有時在一些網站上會看到的『網站地圖』頁面內容（HTML sitemap），而 XML sitemap 內的 URL 資訊以及附帶的 metadata 主要功能在於幫助搜尋引擎暸解一個網站內的連結以及所對應的頁面的一些額外資訊（如：最後修改時間、修改頻率...等）。

最基本的內容大概會像下方範例。當中可以發現 `<url>` tag 裡除了 `<loc>` 為必要的資訊外其他都可以選擇性填入。而目前支援 [standard sitemap protocol](https://www.sitemaps.org/index.html) 的搜尋引擎包含了 Google、Yahoo!、Microsoft。

```xml
<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

   <url> # 第一組 URL

      <loc>http://www.example.com/</loc> # 必填

      <lastmod>2005-01-01</lastmod> # 選填

      <changefreq>monthly</changefreq> # 選填

      <priority>0.8</priority> # 選填

   </url>

   <url> # 第二組 URL

      <loc>http://www.example.com/blog</loc>

   </url>

</urlset>
```

## Sitemap 與 SEO

Sitemap 與 Search Engine Optimization (SEO) 之間的關聯，常見的迷思大概有：

* 做了 sitemap 網頁就能在搜尋結果頁中出現
* 做了 sitemap 能提升網頁在搜尋結果頁(SERP)中的排名
* 不做 sitemap 網頁還是會出現在 google

前面兩點，大概可以用『買了兩塊肋眼牛肉回家就會自動變成情人節晚餐』比擬，而 [sitemap.org](https://www.sitemaps.org/index.html) 的說明是：

> Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling ... (略) ... so that search engines can more intelligently crawl the site.

當中說明了 sitemap 的作用在於讓搜尋引擎知道網站的存在以及當搜尋引擎在爬網站時能夠更有效率。這裡有兩個重點：

* **available** for crawling 意思是告訴搜尋引擎網站的 sitemap 已經準備好了，但不保證搜尋引擎的 crawler 什麼時候會爬
* **crawl** 不等同 **index** 。意即，搜尋引擎爬了也不保證會收錄，即使收錄也與 SERP 排名沒有直接關係

關於迷思的最後一項，確實，即使不做 sitemap ，網頁也是有機會被爬並出現在SERP。

#### 那...為什麼還要做？

搜尋引擎爬網站的速度與頻率，如同很多其他 SEO 因素，沒有標準答案。然而國外有些實驗比較網站沒有 sitemap 與有 sitemap 時搜尋引擎爬的速度差異，當中有一個[實驗](https://neilpatel.com/blog/google-index/#step_7)測出結果是，有 sitemap 時，搜尋引擎平均爬的時間是14分鐘，而沒有 sitemap 時是1,375分鐘。

相較於其他 SEO 因素，Sitemap 在提升排名方面或許沒有太大的幫助，但可以確定的是可以加快網頁被爬的速度。畢竟，在進一步優化 organic traffic 前先確保網頁出現在 SERP 會比較好。

## 在 Rails Web App 上實作 sitemap

以下是這次簡易實作範例的範圍，sitemap 部分使用 [sitemap_generator](https://github.com/kjvarga/sitemap_generator) gem。

1. 建立新專案、新增 articles CRUD
2. 產生部落格首頁與文章頁的 standard sitemap
3. 新文章產生後動態更新 sitemap
4. 提交 sitemap

### 建立新部落格專案、新增 blog CRUD

建立專案

``` shell
$ rails new index_me_google
$ cd index_me_google
$ rails db:create
```

因為是為了練習 sitemap，快速 scaffold 出 `Article` ，欄位部分就只給了一個 `title`。

``` shell
$ rails g scaffold Article title
$ rails db:migrate
```

另外設定一下首頁路徑

``` ruby
# routes.rb
root 'articles#index'
resources :articles
```

在 console 裡建立一些 articles

``` ruby
(1..5).each{ |num| Article.create(title: "article-#{num}")}
```

### 產生部落格首頁與文章頁的 standard sitemap
`sitemap_generator` 功能相當完整，從壓縮、ping 搜尋引擎這類貼心功能到支援 sitemap extensions（news, video ... 等），如果不是太奇特的需求，基本上這個 gem 都能幫忙做到。

安裝

``` ruby
# Gemfile
...
gem 'sitemap_generator'
...
```

產生設定檔

``` shell
$ rails sitemap:install
```

完成後會發現 `config` 資料夾下多了一個 `sitemap.rb` 檔案。初始檔案裡面只有幫我們預設一個 `default_host` 選項還有一個空的 create block。

``` ruby
# config/sitemap.rb
SitemapGenerator::Sitemap.default_host = "http://www.example.com"

SitemapGenerator::Sitemap.create do

end
```

`sitemap_generator` 產出的 sitemap 預設為壓縮檔，為了方便檢查之後產出的 xml 檔案內容，在開發階段通常我會將 `compress` 選項改為 `false`，另外記得將 `default_host` 改成自己的 domain。

``` ruby
# config/sitemap.rb
SitemapGenerator::Sitemap.default_host = "http://www.index.me"
SitemapGenerator::Sitemap.compress = false
...略...
```

接下來，在 create block 內加入我們想要放入 sitemap 內的 URL。

``` ruby
# config/sitemap.rb
...略...
SitemapGenerator::Sitemap.create do
  Article.find_each do |article|
    add article_path(article), lastmod: article.updated_at
  end
end
```

在操作上相當簡易， `add` 方法接收的第一個參數是路徑，第二個是 hash 選項，預設的選項為：

``` ruby
{ priority: 0.5, changefreq: 'weekly', lastmod: Time.now, host: default_host }
```

可以留意的是， crawlers 不一定會因為我們把 `priority` 設為 `1` 或 `changefreq` 設為 `always` 就增加重爬的頻率，把這些數值想成是給 crawlers 做決定的線索就好。另外，雖然有預設值，前三個選項不一定都需要（如：google 目前不採用 priority），可以視情況調整使用。

執行 `$ rails sitemap:create` 後產生一個 `sitemap.xml` 檔案，預設位置在 `public` 資料夾下。直接開瀏覽器檢查一下（localhost:3000/sitemap.xml）。設定正確的話會發現除了所有 article 的 URL 被寫入外，額外附贈 root `http://www.index.me`，如果不想要的話需要將設定選項 `include_root` 改為 `false`。

```xml
<urlset>
  <url>
    <loc>http://www.index.me</loc>
    <lastmod>2019-02-13T16:45:39+08:00</lastmod>
    <changefreq>always</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>http://www.index.me/articles/1</loc>
    <lastmod>2019-02-13T05:14:31+00:00</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.5</priority>
  </url>
  <url>
    <loc>http://www.index.me/articles/2</loc>
    <lastmod>2019-02-13T05:14:31+00:00</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.5</priority>
  </url>

  ...略...

</urlset>
```

### 新文章產生後動態更新 sitemap
到目前為止，我們成功為『現有』的 articles 建立 sitemaps，但像是部落格文章或者是新聞之類不定期會新增或的動態頁面也需要 sitemap。比較常見的做法有使用 cron jobs 定時更新 sitemap，或者在頁面新增後立刻更新。

如果使用 cron jobs，可以參考搭配 [whenever gem](https://github.com/kjvarga/sitemap_generator#crontab) 使用；如果是後者， `sitemap_generator` 提供了對應的方法：

```ruby
class ArticlesController < ApplicationController

  ...略...

  def create
    @article = Article.new(article_params)

    respond_to do |format|
      if @article.save
        # 建立 sitemap
        SitemapGenerator::Interpreter.run(config_file: Rails.root.join('config', 'sitemap.rb'))
        # ping 搜尋引擎
        SitemapGenerator::Sitemap.ping_search_engines

        ...略...

      end
    end
  end

  ...略...

end
```
這樣基本上就能達到新增頁面後立即更新 sitemap 的效果，但建議可以把相關的行為用一個 job 處理。

### 提交 sitemap
在提交 sitemap 到搜尋引擎之前，還要準備一個置放在 server 頂層資料夾的 `robots.txt` 檔，作用在於指示 crawlers 該如何爬網站，當中也包含了提供 sitemap 位置的資訊（暸解更多關於 [robots.txt](https://moz.com/learn/seo/robotstxt) 使用方式）。 這裡只簡單做出允許所有搜尋引擎爬站並提供 sitemap 位置。

```txt
User-agent: *

Sitemap: http://www.index.me/sitemap.xml
```

以下使用 [Google Search Console](https://search.google.com/search-console) 為例提交 sitemap。

如果是第一次使用，必須先新增網站並驗證所有權。另外，新版的 google search console 沒有提供提交前測試的功能，如果有需求可以切到舊版使用。

填寫 `robots.txt` 網址測試

![post-使用 Sitemap 打好網站 SEO 基石](//images.ctfassets.net/8er52l3j5u76/1Vvoe59UySp5V1Dww858Xv/25e7494a5878583be13a64610d798a5b/hFfVjh5.png)

填寫 `sitemap.xml` 網址測試，如果測試結果正常，就可以正式提交了！過一段時間再回來 search console 就可以看到網頁被收錄的狀態。

![post-使用 Sitemap 打好網站 SEO 基石](//images.ctfassets.net/8er52l3j5u76/7o8mDeaug56JdJkJWP4GAr/2f48cc7ac65ea0ecbf1bd4ba6e183b20/pbMRbzJ.png)

## 結語
Rails 搭配 sitemap_generator 實作 sitemap 並不困難，所需時間成本也不高。雖然對於網站 SEO 沒有什麼直接加分的效果，個人會比較用『有好無壞』以及『SEO第一步』的角度看待。另外，如果有多餘心力，建議可以研究 [sitemap extensions](https://support.google.com/webmasters/answer/183668#extensions)，增加網頁在搜尋引擎的足跡。

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>


技術文章

訂閱文章