linux deliver分发管理,Erlang/Elixir: 使用 Edeliver 进行自动化的持续部署
增加 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 进行自动化的持续部署的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 7月26号
- 下一篇： c语言处理字符串函数的头文件,C语言字符