Dinky 玩起來如何(部署篇)？

前面文章聊過了 streampark，這不，應廣大網友邀請，這次我們再來看看 Dinky (之前也叫 Dink)，同樣是另一款號稱流式計算的開發管理平臺。

對於這塊軟體的介紹，官網描述的相對更加簡單樸素，從提供的資訊來看，目前使用者可以使用和下載的版本，只有0.6和0.7。

從官網能順利找到的部署方式來看，目前支援兩種：

1. 下載安裝包 + 原始碼編譯的方式：這種部署方式會相對比較麻煩，對比 streampark 的一個大的安裝包部署方式，dinky 的這種部署方式會根據功能，拆分成幾個子部分，然後各部分之間各司其職，形成一個完整的功能，期間對一些部分需要編譯；

2. Docker 部署方式：這個就簡單很多，將該軟體所有必要的元素都整合在了一個“盒子”裡，省去了以上需要編譯，修改配置，解決環境依賴等繁瑣問題，但是，它最大的缺點就是對使用者可能沒有那麼透明，“盒子”裡面的目錄結構，配置方式，不能“個性化”調整，而且最難受的是，如果我想修改裡面的內容，操作不能做到像在宿主機那般自如。

這兩種方案我都嘗試了，首先都暴露出同一個問題，那就是官方文件寫的有些“混亂”，關鍵資訊這一坨，那一片的，你很難透過一個頁面或者一個部分的內容，把你在部署時，需要的必要資訊找全。

需要你各種搜尋，各種翻，在各個角落裡，把這些散落的資訊給拼起來，形成一個完整的部署思路。

當然，這個現象不止 Dinky 有，以往評測過的絕大部分軟體，都有這個毛病，那就是寫文件的人，同理心比較差，只會用自己的方式去思考問題，又或者，對文件描述這件事，沒有重視，忽略了使用者的感受。

閒嗑少嘮，我們接下來，就來看看，對於 Dinky 來說，這兩種部署方式，分別怎麼玩，以及分別又有哪些坑等著我們。

(趟坑告警：第1種部署方式在dinky編譯的時候坑太多，建議用docker方式部署)

0. 環境準備

因為這兩種部署方式，需要的環境依賴不一樣，所以需要分開來說。

先看安裝包 + 原始碼編譯部署方式：

這部分官網描述的已經比較清楚了，需要提前準備的基礎軟體環境如下。

個人會認為，當一個軟體的必要依賴越少，那麼它的部署便利性，還有其傳播效果就會更佳，對於這一點，dinky 的當前部署方式做的並不太好。

再看docker部署方式：

這個就不多過多贅述，伺服器擁有docker基礎環境即可，不過官方要求docker的版本不要太低，必須是1.13以上版本：

至於，Docker Compose部署方式，文件暫時沒有做任何說明。

1. 安裝包 + 原始碼編譯部署

對於一般的軟體部署來說，這個都是我首選的方式，因為足夠原始，所以你也就能對軟體本身，可以“親密接觸”。

我一般會習慣性觀察下載後的安裝包目錄結構，配置檔案包含的大致內容，以及lib目錄中，涵蓋了哪些技術棧資訊等等，這樣會讓你對整個技術有更加全面深刻的認識。 

而 docker 的部署方式呢，則沒有這樣的便利，想要觀察對應的目錄結構，你得先啟動容器，然後再進入容器內部，再透過各種必要的命令來檢視其內容，這樣就會比較麻煩，而且更重要的是，容器內部很有可能沒有那些用起來比較便利的命令(因為沒有安裝，而如果你要自行安裝的話，又是另一件麻煩的事情)。

但這一次，用這種比較原始的方式來部署 Dinky，卻摔了個跟頭。

根據官網文件要求，不同功能的安裝包的下載、編譯、部署是分開的。

第一步：部署NodeJS環境

這一步的問題倒不大，點選它的「下載地址」就能順利下載(如果環境本身有就不用)，然後按要求操作就可以。

第二步：部署MySQL

下載版本為5.7+的MySQL，如果你的伺服器環境本身有，那就複用環境的，這步也沒什麼問題。

第三步：部署Maven

下載3.x版本的Maven，這個也簡單。

第四步：編譯Dinky原始碼包

官網目前沒有提供現成的安裝包，需要我們從github中克隆它的原始碼，然後進行編譯，最終打成目標安裝包，而這，也是整個部署步驟中最重要，但也最坑的一步。

先克隆原始碼：

這一步問題不大，主要是確保網路沒有問題(實在不行架個梯子)，先把原始碼下載到伺服器。

從git地址來看，貌似這個命令無法選擇版本，因為0.6版本的文件說明也是同樣的git地址(當前參考 Dinky 0.7 的文件)。

克隆下來後，目錄結構長這樣：

再編譯：

問題就出現了，這裡我做了2次不同的嘗試。

第一次，直接在伺服器端，根據官方文件的要求，再結合我的Flink版本，執行下面的編譯命令：

但是很快就報錯了：

像這種類無法識別的問題，根據我的經驗，最好是透過IDE工具把它開啟，看是否因為pom檔案引入的包，因為版本問題而導致。

第二次，通用IDEA 開啟這個原始碼工程，發現，即便我修改了相應的pom 依賴版本(折騰了半個多小時之後)，還是會源源不斷冒出類似的報錯：

心想，我C，這不會是開啟了潘多拉魔盒了吧。

鑑於一開始就遇到了這麼多的助力，我暫時決定放棄當前方案(後面有時間了再專門研究)，棄暗投明，投奔docker。

2. Docker部署方案

相比之下，Docker的部署就要輕鬆很多，只不過關於這塊的說明，被放在了文件中快速開始的位置：

但是，關於這塊的內容，官網描述的有些潦草，即便是最選擇了最簡潔的 docker 部署，如果你沒有比較熟悉的 Linux 基礎，docker基礎，想短時間內部署成功，依然不易。

從文件說明來看，如果選擇 docker 部署的話，可以選擇1個容器的部署方式，以及2個容器的部署方式，有啥區別呢？

2個容器部署方式：

其中一個容器為MySQL容器，用來專門儲存 Dinky 在執行過程中，相關後設資料的記錄，這一點跟上次測評過的 streampark 玩法是一樣的；

而第二個容器呢，則是 Dinky 的主體容器，主要包括web端的應用，以及流平臺管理相關的部分。

1個容器的部署方式：

這個容器就只包含 Dinky 的主體功能部分，對於儲存後設資料的 MySQL，需要依賴外部已經建立好的資料庫，因為我本地已經有了MySQL8，所以我選這種1個容器的部署方式。

具體步驟如下：

第一步：下載映象

官方文件的說明比較簡單粗暴，直接透過 docker run 來實現對映象的下載，和啟動兩個步驟，但是我不建議你這樣。

先透過 docker pull 命令把該映象下載下來，注意對應的 Flink 版本：

這樣做最大的好處在於，可先判斷你當前伺服器的網路是否給力，如果網路比較差，那麼你還可以透過其他方式先下載該映象，然後把它再傳到你的目標伺服器。

第二步：啟動容器前的配置準備

確定映象下載成功後，按理說，接下來就是要啟動容器了。

但是，當你看到文件中，關於啟動docker容器，需要新增 MySQL的一些引數時，相信你會恍然大悟，一拍大腿：我勒個去，MySQL的相關許可權還沒有配置呢。

所以這也是我為什麼說它文件描述比較潦草的原因，裡面有很多隱藏的步驟沒有顯示告訴你，需要部署的人提前要有這樣的「技術自覺」才行。

於是，在啟動容器前，就必須要把這一步給補上來，這一步其實就是在MySQL裡建庫、建表，建對應使用者，然後賦權，再把這個使用者交給Dinky，這樣才算架起了一座它跟 MySQL 之間友好溝通的橋樑。

關於如何配置 MySQL 這一步的描述，其實在文件的其他地方(部署指南->部署)：

但這還只是建了庫，我們還得建立表不是，建表語句在哪呢？

文件中沒有直接提供，它是這麼描述的：

說這個建表 SQL 檔案在 Dinky 的家目錄裡的sql子目錄中。

但是它喵的，我現在是用容器部署啊，這個目錄我得啟動容器之後，進入到容器中才能找到它，不是嗎？

這下就尷尬了，那咋整呢？

突然我想到之前不是下載了Dinky的原始碼嗎，要不去碰碰運氣看看，說不定那裡面有呢，於是我一通搜尋，得到了如下的結果：

心想，這個被我標記出來的檔案，應該就是建表語句了吧，開啟一看果然像。

於是，就準備拿來試試，在MySQL的客戶端執行如下命令：

執行過程沒有異常，心想這下應該可以了吧(其實不可以)。

第三步：正式啟動docker

既然 MySQL 配置妥當，這下應該就沒有後顧之憂了吧，直接透過命令啟動，因為涉及到很多必要引數，因此實際的啟動命令，要比官方文件給的示例更復雜一些：

docker run -d -p 8889:8888 -p 8082:8081 -e MYSQL_ADDR=192.168.221.173:3306 -e MYSQL_DATABASE=dinky -e MYSQL_USERNAME=*** -e MYSQL_PASSWORD=*** --name dinky0.7 dinkydocker/dinky-standalone-server:0.7.0-flink15

啟動後，檢視其容器執行情況：

進到容器裡，瞅一眼日誌，看有沒有報錯啥的。

果然沒讓人失望，還真有(只要有報錯，Dinky 對應的網頁就打不開)，報錯說 MySQL 中有一些表找不到，於是我猜應該是之前執行的那個sql檔案不對。

（報錯日誌一下子找不到了，圖先欠著）

那咋整呢？

剛才不是說了嘛，找不到正確的 SQL 檔案，是因為不能進到容器裡面來，現在已經進來了，那這個問題就不存在了。

但這個正確的 SQL 檔案在哪呢？擱這呢。

注意，這個檔案現在是在 docker 容器內部，需要透過 docker cp 命令把這個和檔案給複製出來，然後到 MySQL 伺服器執行(把之前的表全部刪了)。

然後，重啟docker容器(這個過程相信對你來說過於簡單，過程就省略了)。

這一次，那個久違的web頁面，終於可以開啟了(用docker啟動命令中的8889埠)。

透過admin/admin，就可以登入進去了。

最後

因為篇幅關係，今天這篇文章暫時先到這裡，一來怕寫太多了你們沒耐心看完；二來也容許我把這玩意再多用用，摸得更清楚了，再來交作業，顯得更嚴謹。

從這次前期的部署來看，是明顯踩了一些坑的，核心原因在於：一個是文件描寫有些粗糙，導致一些關鍵資訊需要你反覆去很多地方查詢，或者一些出現的問題，只能根據經驗來解決；另一個可能是軟體本身還不夠成熟，導致出現了一些當下比較“棘手”的問題。

但這些我認為還不是最重要的，對於一款軟體來說，最重要的是，部署完成之後的使用體驗如何，能不能解決我的實際問題，能不能做到像產品介紹欄裡宣傳的那樣“表裡如一”。

好了，欲知 Dinky 的使用體驗如何，請看下回分解...