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 的使用体验如何，请看下回分解...