增加 2016-08-19

Erlang/Elixir: 用Distillery替換Exam打包器

更新 2016-07-25

這里有一篇Gitbooks上的文章專門簡介如何搭建,配置一個Phoenix應用程序的自動化構建,部署的過程Phoenix持續部署

Edeliver 是一個基于 deliver 的構建和部署工具.

它提供了一個 Bash 腳本來幫助你構建, 部署, 以及執行熱代碼升級

Edeliver 部署關系圖示

本文我們來聊一聊關于 Erlang/Elixir 的部署問題. 最原始的 Erlang, 我們要使用一大堆工具, 比如 reltool, 后來有了rebar, 還后來 relx 也出來了, Elixir 生態鏈中還有個 Exrm 打包工具, 是基于 relx 創建發布包的, 打包好了呢, 需要部署到服務器上去運行.

Exrm 打好的包, 一般情況, 我直接用 scp 復制到服務器上的某個目錄, 然后在登錄到遠程服務器解壓, 升級等操作. 而 Edeliver 讓這個過程完全自動化, 提高了效率, 并且更加適用于中等規模的應用程序部署.

構建 Erlang/Elixir 初始發布版本, 并部署到產品服務器.

mix edeliver build release --branch=master -V

mix edeliver deploy release to production -V

mix edeliver start production -V

把上面三個單獨的命令合并為一個

mix edeliver update production --branch=master --start-deploy -V

配置

在項目目錄下創建一個 .deliver 目錄, 然后在其中添加 config 文件.

#!/usr/bin/env bash

APP="your-erlang-app" # name of your release

# 構建主機的地址, 用戶名, 和構建目錄

BUILD_HOST="build-system.acme.org"

BUILD_USER="build"

BUILD_AT="/tmp/erlang/my-app/builds"

# 測試目標主機的地址, 用戶名, 和部署目錄, 多個目標服務器地址用空格分隔開

STAGING_HOSTS="test1.acme.org test2.acme.org"

STAGING_USER="test"

TEST_AT="/test/my-erlang-app"

# 產品目標主機的地址, 用戶名, 和部署目錄, 多個目標服務器地址用空格分隔開

PRODUCTION_HOSTS="deploy1.acme.org deploy2.acme.org"

PRODUCTION_USER="production"

DELIVER_TO="/opt/my-erlang-app"

本質上, Edeliver 使用 SSH 和 scp 來部署發布. 如果需要無密碼登陸, 可通過 ssh-keygen 工具創建密鑰對, 把公鑰添加到服務器的 ~/.ssh/authorized_keys 文件中即可.

項目配置

defp deps do

[{:edeliver, ">= 1.2.8"}]

end

def application, do: [

applications: [

# ...

:edeliver,

],

]

不同的部署目標不同的配置

對于一個需要實現 Failover/Takeover 分布式應用程序來講, 每個節點的配置是不一樣的, 這樣在部署的時候就要去編寫不同的配置文件.

Edeliver 提供了這樣一個功能

TODO::目前項目還沒有到這個階段以后再研究.

構建

必須在和目標系統類似 (建議完全一樣的系統) 的系統上構建. 如果想在 Linux 上部署產品系統, 那么發布也應該在 Linux 系統上構建(建議使用相同廠商的 Linux 發型版). 不要求在產品系統上安裝 Erlang/OTP 和 Elixir 運行時, 他們會隨打包系統自動包含進發布包分發到產品系統上. 下面的配置變量是必須的:

Name

Description

APP

發布的應用程序名稱

BUILD_HOST

構建發布包的主機名稱或IP地址

BUILD_USER

構建主機上的本地用戶名稱

BUILD_AT

在構建主機上構建發布包的目錄.

構建完成后, 發布包會被復制到你的本地 .deliver/releases 目錄. 然后通過下面的命令發布到產品服務器. 如果成功編譯和生成發布包. 發布包會從構建主機復制到發布存儲, 默認發布存儲的位置在項目根目錄下的 .deliver 目錄的 releases 子目錄, 但可以通過配置環境變量來自定義, 例如:

準確的講, 是復制到 RELEASE_STORE 環境變量指定的位置, 如果設置了該環境變量的話. 如果沒有設置 RELEASE_STORE 環境變量, 默認為項目根目錄的 .deliver/releases 子目錄.

RELEASE_STORE=/tmp/.deliver # 本地目錄

RELEASE_STORE=user@releases.acme.org:/releases # 遠程主機

RELEASE_STORE=s3://AWS_ACCESS_KEY_ID@AWS_SECRET_ACCESS_KEY:bucket # 亞馬遜S3

發布使用RELEASE_DIR=環境變量來確定發布歸檔包的位置. 如果未設置, 默認目錄包含RELEASES文件的目錄. 比如: 如果$APP=myApp, RELEASES的位置為rel/myApp/myApp/releases/RELEASE. 關于完整的 edeliver 命令, 可以通過運行 mix help edeliver 查看:

別自己創建 $BUILD_AT, $TEST_AT, $DELIVER_TO 目錄. config/*.secret.exs 應該放在$CONFIG_AT目錄, *.vm.args 文件處理節點名稱, 集群等配置參數

構建一個全新的版本

mix edeliver build release --version=0.0.1

部署第一個版本

mix edeliver deploy release to production --version=0.0.1 --start-deploy

構建一個升級版本

熱升級包含該兩條路徑

從Git倉庫發布一個升級包

從之前發布的版本構建一個升級包

提升版本號, 在 mix.exs 提升項目的版本號, 下面的命令是直接從源碼倉庫構建一個熱升級包

git commit -m 'Bump version to 0.0.2' # 提交

git tag 0.0.2 # 打TAG

mix edeliver build upgrade --from=0.0.1 --to=0.0.2 # 構建

部署一個升級版本

mix edeliver deploy upgrade to production --version=0.0.2

構建從 v1.0 到 v2.0 的升級包, 并部署升級到產品環境

mix edeliver build upgrade --from=v1.0 --to=v2.0

mix edeliver deploy upgrade to production

或者, 如果在發布存在有舊的發布版本, 可以用那個舊的發布版本來構建升級而不是Git的舊版修訂/Tag

mix edeliver build upgrade --with=v1.0 --to=v2.0

mix edeliver deploy upgrade to production

注意 --from= 和 --with= 的區別. --from=指定git倉庫的tag, --with=指定舊的release版本號. 可以通過命令mix edeliver show releases查看當前有哪些版本可用.

# 運行Ecto 移植

mix edeliver migrate production

或者使用 --run-migrations 選項在升級期間自動運行

升級 Patch 版本號

mix edeliver build release --increment-version=patch -V

這個命令也是用于構建一個發布包, 只是他會從Git工作區讀取最新的Tag版本, 并在此基礎上加1, 比如當前倉庫中的Tag最新為 1.0.2, 那么該命令會創建一個 1.0.3 的發布版本.

單個命令完成升級

mix edeliver upgrade production -V

上面這個命令將會執行如下步驟:

檢查所有運行節點的當前版本

驗證所有節點運行在相同的版本

構建從該版本到當前版本的升級包

自動給 relup 文件打補丁

節點運行的同事部署升級包(熱更新)

驗證所有的節點運行在已升級的版本

部署發布包到其他沒有處于運行狀態的節點

排錯

構建主機需要安裝好 Erlang/Elixir 的構建環境, 推薦使用 kerl 編譯 Erlang, kiex 安裝 Elixir. 然后把下面兩行腳本添加到用戶目錄的 .profile 文件中. 目的是讓 Edeliver 能夠找到 Elixir 工具的位置

. /home/ycc/.kerl/installs/18.3_systemtap/activate

test -s "$HOME/.kiex/scripts/kiex" && source "$HOME/.kiex/scripts/kiex"

kiex use 1.2.5 > /dev/null 2>&1

關于熱升級的問題

根據實踐驗證, 請保證你的項目中 applications, deps 升級前后保持一致, 否則熱升級可能導致失敗, 如果applications, deps有修改, 這種情況下最好用下面的命令做一次全新部署.

mix edeliver build release --version= -V

mix edeliver deploy to production --version= -V

mix edeliver start production -V

關于 -V, --verbose 參數

我們在構建發布包的時候, 有時候會出錯, 可以通過構建是添加 -V 參數來看到構建過程的大量信息, 包括 git 本地工作區的 HEAD 的指向, 編譯的詳細輸出(mix compile的輸出), 默認情況 Edeliver 會從拉取 HEAD 指向的分支來構建發布.

集群設置

在vm.args設置節點名稱和 cookie

在配置文件 prod.exs 中配置 :kernel 模塊的 :sync_nodes_mandator 和 :sync_nodes_optional 選項

use Mix.Config

config :kernel, distributed: [{:opencv_thumbnail_server, 5000, [

:"node1@192.168.212.45",

:"node2@192.168.212.45",

:"node3@192.168.212.45",

:"node4@192.168.212.45",

:"node5@192.168.212.45"

]}]

config :kernel, inet_dist_listen_min: 9100

config :kernel, inet_dist_listen_max: 9105

config :kernel, sync_nodes_mandatory: [

:"node2@192.168.212.45",

:"node3@192.168.212.45"

]

config :kernel, sync_nodes_optional: [

:"node4@192.168.212.45",

:"node5@192.168.212.45"

]

config :kernel, sync_nodes_timeout: 10000

上傳到服務器的壓縮包解壓后, 需要修改,下面兩個文件的節點名字和 distributed 配置.

./releases/0.0.1/sys.config

./releases/0.0.1/vm.args

其他管理命令

# 顯示發布版本清單

$ mix edeliver show releases

# 停止線上的服務器

$ mix edeliver stop production

# 顯示線上服務器當前運行的版本

$ mix edeliver version production

# 重啟線上服務器

$ mix edeliver restart production

# 啟動

$ mix edeliver start production

總結

大體上一個全新的部署過程就是三個命令

mix edeliver build release --V # 構建發布包

mix edeliver deploy release to production --V # 部署(上傳, 解壓)到產品服務器

mix edeliver start production --V # 啟動產品服務器

如果上線前還需要部署到 staging 服務器進行測試, 或者灰度發布

熱升級的過程為

mix edeliver build upgrade --with=0.1.3 --to=0.1.14 -V # 構建一個從0.1.13到0.1.14的升級包

mix edeliver deploy upgrade to production --version=0.1.14 -V # 部署升級包0.1.14到線上

關于Git倉庫的問題

我們一般在 develop 分支下進行開發, 而 edeliver 構建發布包的時候是去 master 分支拉取源碼進行構建的, 因此我們在開發過程中需要注意版本和分支的管理.

這里我使用了 gitflow 這個工具來管理項目的版本和發布. 假設我們現在需要向線上發布一個新版本, develop 分支需要合并到master, 先修改 mix.exs 提升一下版本, 并提交, 然后:

git add .

git commit -m 'bump version to 0.1.14'

git push

發布

git flow release start 0.1.14

git flow release publish 0.1.14 # Push發布分支0.1.14到遠程倉庫,以便在構建主機上編譯,打包和部署

git flow release finish 0.1.14

git push

git push --tags

git checkout develop # 回到 develop 繼續開發

參考資料

總結

以上是生活随笔為你收集整理的linux deliver分发管理,Erlang/Elixir: 使用 Edeliver 进行自动化的持续部署的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。