原文发表于kubernetes中文社区，为作者原创翻译 ，原文地址
 
 
更多kubernetes文章，请多关注kubernetes中文社区
 
 
目录
 
Kubernetes和数据库
 
数据库
 
StatefulSet
 
Kubernetes上的数据库
 
Operators将数据库部署到Kubernetes
 
在Kubernetes上部署数据库是否可行？
 
1.完全托管的数据库
 
2.在VM或本地自行部署
 
3.在Kubernetes上运行
 
在Kubernetes上部署有状态应用程序：
 
步骤1：部署MySQL服务
 
步骤2：部署MySQL Deployment
 
第3步：创建持久卷
 
第4步：创建持久卷声明
 
步骤5：测试MySQL数据库
 
总结
 

Kubernetes和数据库
 
Kubernetes是开发中一项重大的改进，而数据库是应用程序的重要组成部分。在本文中，我们将展示如何在Kubernetes中部署数据库，以及可以使用哪些方法在Kubernetes中部署数据库。
 
数据库
 
数据库是一种用于在计算机系统上存储和处理数据的系统。数据库引擎可以在数据库上创建，读取，更新和删除。数据库由数据库管理系统（DBMS）控制。
 
在大多数数据库中，数据按行和列进行建模，称为关系型，这种类型的数据库在80年代占主导地位。在2000年代，非关系数据库开始流行，被称为No-SQL，它们使用不同的查询语言，并且这些类型的数据库可用于键值对。
 
StatefulSet
 
在本文中，我们将在Kubernetes中部署数据库，因此我们必须了解什么是StatefulSet。
 
StatefulSet是用于管理有状态应用程序的工作负载。它管理一组Pod的实现和扩展，并保证这些Pod的顺序和唯一性。
 
像Deployment一样，StatefulSet也管理具有相同容器规范的一组Pod。由StatefulSets维护的Pod具有唯一的，持久的身份和稳定的主机名，而不用管它们位于哪个节点上。如果我们想要一个跨存储的持久性，我们可以创建一个持久性卷并将StatefulSet用作解决方案的一部分。即使StatefulSet中的Pod容易发生故障，存储卷与新Pod进行匹配也很容易。
 
StatefulSet对于需要以下一项或多项功能的应用程序很有价值：
 
 
稳定的唯一网络标识符。
 
 
稳定，持久的存储。
 
 
有序，顺畅的部署和扩展。
 
 
有序的自动滚动更新。
 
在Kubernetes上部署数据库时，我们需要使用StatefulSet，但是使用StatefulSet有一些局限性：
 
 
需要使用持久性存储卷为Pod提供存储。
 
 
删除副本或按比例缩小副本将不会删除附加到StatefulSet的存储卷。存储卷确保数据的安全性。
 
 
StatefulSet当前需要Headless Service 来负责Pod的网络标识。
 
 
与Deployment 不同，StatefulSet不保证删除StatefulSet资源时删除所有Pod，而Deployment在被删除时会删除与Deployment关联的所有Pod。在删除StatefulSet之前，你必须将pod副本数量缩小到0 。
 
Kubernetes上的数据库
 
我们可以将数据库作为有状态应用程序部署到Kubernetes。通常，当我们部署Pod时，它们具有自己的存储空间，但是该存储空间是短暂的-如果容器被杀死了，则其存储空间将随之消失。
 
因此，我们需要有一个Kubernetes资源对象来解决这种情况：当我们想要数据持久化时，我们就把Pod和持久化存储卷声明关联。通过这种方式，如果我们的容器被杀死了，我们的数据仍将位于集群中，新的pod也能够相应地访问数据。
 
Pod -> PVC-> PV
 
 
PV =持久性存储
 
 
PVC =持久性存储声明
 
Operators将数据库部署到Kubernetes
 
 
我们可以使用由Oracle开发的Kubernetes Operators来部署MySQL数据库：
 
https://github.com/oracle/mysql-operator
 
 
使用Crunchydata开发的PostgreSQL Operators，、将PostgreSQL部署到Kubernetes：
 
https://github.com/CrunchyData/postgres-operator
 
 
使用MongoDB开发的Operators，可将MongoDB Enterprise部署到Kubernetes集群：
 
https://github.com/mongodb/mongodb-enterprise-kubernetes
 
在Kubernetes上部署数据库是否可行？
 
在当今世界上，越来越多的公司致力于容器技术。在进行深入研究之前，让我们回顾一下用于运行数据库的选项。
 
1.完全托管的数据库
 
完全托管的数据库是那些不用自己来管理的数据库-这种管理可以由AWS Google，Azure或Digital Cloud等云提供商完成。托管数据库包括Amazon Web Services，Aurora DynamoDB或Google Spanner等。
 
使用这些完全托管的数据库的优势是操作少，云提供商可以处理许多维护任务，例如备份，扩展补丁等。你只需创建数据库即可构建应用程序，其他的由云提供商帮你处理。
 
2.在VM或本地自行部署
 
使用此选项，你可以将数据库部署到任何虚拟机（EC2或Compute Engine），并且将拥有完全控制权。你将能够部署任何版本的数据库，并且可以设置自己的安全性和备份计划。
 
另一方面，这意味着你将自行管理，修补，扩展或配置数据库。这将增加基础架构的成本，但具有灵活性的优势。
 
3.在Kubernetes上运行
 
在Kubernetes中部署数据库更接近full-ops选项，但是从Kubernetes提供的自动化方面来看，你将获得一些好处--能够保持数据库应用程序的正常运行。
 
要注意，pod是短暂的，因此数据库应用程序重新启动或失败的可能性更大。另外，你将负责更具体的数据库管理任务，例如备份，扩展等。
 
选择在Kubernetes上部署数据库时要考虑的一些重要点是：
 
 
有一些自定义资源和 operators可用于在Kubernetes上管理数据库。
 
 
具有缓存层和瞬时态存储的数据库更适合Kubernetes。
 
 
你必须了解数据库中可用的复制模式。异步复制模式为数据丢失留有空间，因为事务可能会提交给主数据库，而不会提交给从数据库。
 
 
 
 
上面，我们用一个简单的图表来显示在Kubernetes上部署数据库时的决策。
 
首先，我们需要尝试了解数据库是否具有与Kubernetes友好的功能，例如MySQL或PostgreSQL，然后我们查找kubernetes operators将数据库与其他功能打包在一起。
 
第二个问题是-考虑到在Kubernetes中部署数据库需要多少工作量，这是可以接受的？我们是否有一个运维团队，或者在托管数据库上部署数据库是否可行？
 
在Kubernetes上部署有状态应用程序：
 
步骤1：部署MySQL服务
 
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
  clusterIP: None
 
首先，我们在端口3306上为MySQL数据库部署服务，所有Pod均具有标签键app: mysql。
 
接下来，创建以下资源：
 
 
 
Kubectl create -f mysql_service.yaml
 
 
步骤2：部署MySQL Deployment
 
 
 
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
 
 
此Deployment在3306端口上创建带有MySQL5.6镜像和密码(使用secret)的Pod。我们还将附加一个持久卷mysql-pv-claim，将在接下来的步骤中进行显示。
 
创建资源：
 
 
 
Kubectl create -f mysql_deployment.yaml
 
 
第3步：创建持久卷
 
 
 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
 
 
这将创建一个持久卷，我们将使用它来附加到容器，以确保Pod重启时的数据安全。该持久卷具有ReadWriteOne访问模式，拥有20GB的存储空间，存放路径是/ mnt/data，我们所有的数据都将保存在该路径中。
 
创建以下资源：
 
 
 
Kubectl create -f persistence_volume.yaml
 
 
第4步：创建持久卷声明
 
 
 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
 
 
该声明从上面创建的“持久卷”中声明20GB，并具有与上面的“持久卷”相同的访问模式。
 
创建以下资源：
 
 
 
Kubectl create -f pvClaim.yaml
 
 
步骤5：测试MySQL数据库
 
 
 
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
 
 
此命令在运行MySQL的集群中创建一个新的Pod，并连接到MySQL服务器。如果连接成功，则说明你的MySQL数据库已启动并正在运行。
 
 
 
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.

mysql>
 
 
以上完整代码存放在这个位置：https://github.com/zarakM/mysql-k8.git
 
总结
 
 
有状态应用程序是存储用户会话状态的应用程序，保存的数据称为应用程序状态。
 
 
StatefulSet是一个Kubernetes资源对象，用于管理有状态应用程序，并提供有关Pod顺序和唯一性的保证。
 
 
通过删除StatefulSet，不会删除StatefulSet中的pod。相反如果删除，你必须将有状态应用程序副本数量缩小为0。
 
 
Kubernetes上的数据库部署有一个持久存储卷，只要你的集群正在运行，该存储卷就可以永久存储数据。这意味着它可以抵御pod的破坏，并且创建的任何新pod将能够再次使用该存储卷。
 
 
完全托管的数据库是由云提供商管理的数据库。我们不必管理数据库。这些数据库需要额外的费用，但是如果你想专注于应用程序，它们是最佳选择。
 
 
你可以通过VM部署数据库。但你将必须处理所有数据库操作，例如扩展，设置和修补。
 
 
最后，我们展示了如何在Kubernetes上部署数据库。
 
译文链接： https://www.magalix.com/blog/kubernetes-and-database

单机部署(Standalone)
 
DolphinScheduler单机部署分为后端部署和前端部署两部分：
 
1、后端部署
 
1.1 : 基础软件安装(必装项请自行安装)
 
PostgreSQL (8.2.15+) or Mysql (5.6或者5.7系列) : 两者任选其一即可
JDK (1.8+) : 必装，请安装好后在/etc/profile下配置 JAVA_HOME 及 PATH 变量
ZooKeeper (3.4.6+) ：必装
Hadoop (2.6+) or MinIO ：选装， 如果需要用到资源上传功能，针对单机可以选择本地文件目录作为上传文件夹(此操作不需要部署Hadoop)；当然也可以选择上传到Hadoop or MinIO集群上
 
 注意：DolphinScheduler本身不依赖Hadoop、Hive、Spark,仅是会调用他们的Client，用于对应任务的运行。
 
1.2 : 下载后端tar.gz包
 
请下载最新版本的后端安装包至服务器部署目录,比如创建 /opt/dolphinscheduler 做为安装部署目录，下载地址： 下载 (以1.2.0版本为例)，下载后上传tar包到该目录中，并进行解压
 
# 创建部署目录
mkdir -p /opt/dolphinscheduler;
cd /opt/dolphinscheduler;
# 解压缩
tar -zxvf apache-dolphinscheduler-incubating-1.2.0-dolphinscheduler-backend-bin.tar.gz -C /opt/dolphinscheduler;
 
mv apache-dolphinscheduler-incubating-1.2.0-dolphinscheduler-backend-bin  dolphinscheduler-backend
 
###1.3：创建部署用户并赋予目录操作权限
 
创建部署用户，并且一定要配置sudo免密。以创建dolphinscheduler用户为例
 
# add user dolphinscheduler
useradd dolphinscheduler;

# modify user password
echo "dolphinscheduler" | passwd --stdin dolphinscheduler

# 配置sudo免密
sed -i '$adolphinscheduler  ALL=(ALL)  NOPASSWD: NOPASSWD: ALL' /etc/sudoers

# 修改目录权限，使得部署用户对dolphinscheduler-backend目录有操作权限  
chown -R dolphinscheduler:dolphinscheduler dolphinscheduler-backend
 
 注意：
 - 因为任务执行服务是以 sudo -u {linux-user} 切换不同linux用户的方式来实现多租户运行作业，所以部署用户需要有 sudo 权限，而且是免密的。初学习者不理解的话，完全可以暂时忽略这一点
 - 如果发现/etc/sudoers文件中有"Default requiretty"这行，也请注释掉
 - 如果用到资源上传的话，还需要给该部署用户分配操作`本地文件系统或者HDFS或者MinIO`的权限
 
1.4 : ssh免密配置
 
切换到部署用户并配置ssh本机免密登录
 
su dolphinscheduler;

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
 
注意：正常设置后，dolphinscheduler用户在执行命令ssh localhost 是不需要再输入密码的
 
1.5 : 数据库初始化
 
进入数据库，默认数据库是PostgreSQL，如选择Mysql的话，后续需要添加mysql-connector-java驱动包到DolphinScheduler的lib目录下
 
mysql -uroot -p
 
 
进入数据库命令行窗口后，执行数据库初始化命令，设置访问账号和密码。注: {user} 和 {password} 需要替换为具体的数据库用户名和密码
 
mysql> CREATE DATABASE dolphinscheduler DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
mysql> GRANT ALL PRIVILEGES ON dolphinscheduler.* TO '{user}'@'%' IDENTIFIED BY '{password}';
mysql> GRANT ALL PRIVILEGES ON dolphinscheduler.* TO '{user}'@'localhost' IDENTIFIED BY '{password}';
mysql> flush privileges;
 
 
创建表和导入基础数据
 
  
 
修改 conf 目录下 application-dao.properties 中的下列配置
 
    
 
vi conf/application-dao.properties 
 
 
 
如果选择 Mysql，请注释掉 PostgreSQL 相关配置(反之同理), 还需要手动添加 [ mysql-connector-java 驱动 jar ] 包到 lib 目录下，这里下载的是mysql-connector-java-5.1.47.jar，然后正确配置数据库连接相关信息
 
 
  # postgre
  #spring.datasource.driver-class-name=org.postgresql.Driver
  #spring.datasource.url=jdbc:postgresql://localhost:5432/dolphinscheduler
  # mysql
  spring.datasource.driver-class-name=com.mysql.jdbc.Driver
  spring.datasource.url=jdbc:mysql://xxx:3306/dolphinscheduler?useUnicode=true&characterEncoding=UTF-8     需要修改ip，本机localhost即可
  spring.datasource.username=xxx						需要修改为上面的{user}值
  spring.datasource.password=xxx						需要修改为上面的{password}值
 
  
修改并保存完后，执行 script 目录下的创建表及导入基础数据脚本
 
sh script/create-dolphinscheduler.sh
 
 
​ 注意: 如果执行上述脚本报 ”/bin/java: No such file or directory“ 错误，请在/etc/profile下配置 JAVA_HOME 及 PATH 变量
 
1.6 : 修改运行参数
 
 
修改 conf/env 目录下的 .dolphinscheduler_env.sh 环境变量(以相关用到的软件都安装在/opt/soft下为例)
 
export HADOOP_HOME=/opt/soft/hadoop
export HADOOP_CONF_DIR=/opt/soft/hadoop/etc/hadoop
#export SPARK_HOME1=/opt/soft/spark1
export SPARK_HOME2=/opt/soft/spark2
export PYTHON_HOME=/opt/soft/python
export JAVA_HOME=/opt/soft/java
export HIVE_HOME=/opt/soft/hive
export FLINK_HOME=/opt/soft/flink
export PATH=$HADOOP_HOME/bin:$SPARK_HOME2/bin:$PYTHON_HOME:$JAVA_HOME/bin:$HIVE_HOME/bin:$PATH:$FLINK_HOME/bin:$PATH

 
注: 这一步非常重要,例如 JAVA_HOME 和 PATH 是必须要配置的，没有用到的可以忽略或者注释掉
 
 
将jdk软链到/usr/bin/java下(仍以 JAVA_HOME=/opt/soft/java 为例)
 
sudo ln -s /opt/soft/java/bin/java /usr/bin/java
 
 
修改一键部署脚本 install.sh中的各参数，特别注意以下参数的配置
 
# 这里填 mysql or postgresql
dbtype="mysql"

# 数据库连接地址
dbhost="localhost:3306"

# 数据库名
dbname="dolphinscheduler"

# 数据库用户名，此处需要修改为上面设置的{user}具体值
username="xxx"    

# 数据库密码, 如果有特殊字符，请使用\转义，需要修改为上面设置的{passowrd}具体值
passowrd="xxx"

#将DS安装到哪个目录，如: /opt/soft/dolphinscheduler，不同于现在的目录
installPath="/opt/soft/dolphinscheduler"

#使用哪个用户部署，使用1.3小节创建的用户
deployUser="dolphinscheduler"

#zookeeper地址，单机本机是localhost:2181，记得把2181端口带上
zkQuorum="localhost:2181"

#在哪些机器上部署DS服务，本机选localhost
ips="localhost"

#master服务部署在哪台机器上
masters="localhost"

#worker服务部署在哪台机器上
workers="localhost"

#报警服务部署在哪台机器上
alertServer="localhost"

#后端api服务部署在在哪台机器上
apiServers="localhost"


# 邮件配置，以qq邮箱为例
# 邮件协议
mailProtocol="SMTP"

# 邮件服务地址
mailServerHost="smtp.exmail.qq.com"

# 邮件服务端口
mailServerPort="25"

# mailSender和mailUser配置成一样即可
# 发送者
mailSender="xxx@qq.com"

# 发送用户
mailUser="xxx@qq.com"

# 邮箱密码
mailPassword="xxx"

# TLS协议的邮箱设置为true，否则设置为false
starttlsEnable="true"

# 邮件服务地址值，参考上面 mailServerHost
sslTrust="smtp.exmail.qq.com"

# 开启SSL协议的邮箱配置为true，否则为false。注意: starttlsEnable和sslEnable不能同时为true
sslEnable="false"

# excel下载路径
xlsFilePath="/tmp/xls"

# 业务用到的比如sql等资源文件上传到哪里，可以设置：HDFS,S3,NONE，单机如果想使用本地文件系统，请配置为HDFS，因为HDFS支持本地文件系统；如果不需要资源上传功能请选择NONE。强调一点：使用本地文件系统不需要部署hadoop 
resUploadStartupType="HDFS"

# 这里以保存到本地文件系统为例
#注：但是如果你想上传到HDFS的话，NameNode启用了HA，则需要将core-site.xml和hdfs-site.xml放到conf目录下，本例即是放到/opt/dolphinscheduler/conf下面，并配置namenode cluster名称；如果NameNode不是HA,则修改为具体的ip或者主机名即可 
defaultFS="file:///data/dolphinscheduler"    #hdfs://{具体的ip/主机名}:8020


# 如果ResourceManager是HA，则配置为ResourceManager节点的主备ip或者hostname,比如"192.168.xx.xx,192.168.xx.xx"，否则如果是单ResourceManager或者根本没用到yarn,请配置yarnHaIps=""即可，我这里没用到yarn，配置为""
yarnHaIps=""

# 如果是单ResourceManager，则配置为ResourceManager节点ip或主机名，否则保持默认值即可。我这里没用到yarn，保持默认
singleYarnIp="ark1"

# 由于hdfs支持本地文件系统，需要确保本地文件夹存在且有读写权限
hdfsPath="/data/dolphinscheduler"
 
注：如果打算用到资源中心功能，请执行以下命令：
 
sudo mkdir /data/dolphinscheduler
sudo chown -R dolphinscheduler:dolphinscheduler /data/dolphinscheduler
 
 
1.7 : 安装python的zookeeper工具kazoo
 
安装python的 zookeeper 工具 ，此步骤仅在一键部署时候用到
 
#安装pip
sudo yum -y install python-pip;  #ubuntu请使用 sudo apt-get install python-pip
sudo pip install kazoo;
 
注意：如果yum没找到python-pip，也可以通过下面方式安装
 
sudo curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
sudo python get-pip.py  # 如果是python3，使用sudo python3 get-pip.py 
#然后
sudo pip install kazoo;
 
 
切换到部署用户，执行一键部署脚本
 
sh install.sh
 
注意：
第一次部署的话，在运行中第3步`3,stop server`出现5次以下信息，此信息可以忽略
sh: bin/dolphinscheduler-daemon.sh: No such file or directory
 
 
脚本完成后，会启动以下5个服务，使用jps命令查看服务是否启动(jps为java JDK自带)
 
 
    MasterServer         ----- master服务
    WorkerServer         ----- worker服务
    LoggerServer         ----- logger服务
    ApiApplicationServer ----- api服务
    AlertServer          ----- alert服务
 
如果以上服务都正常启动，说明自动部署成功
 
部署成功后，可以进行日志查看，日志统一存放于logs文件夹内
 
 logs/
    ├── dolphinscheduler-alert-server.log
    ├── dolphinscheduler-master-server.log
    |—— dolphinscheduler-worker-server.log
    |—— dolphinscheduler-api-server.log
    |—— dolphinscheduler-logger-server.log
 
2、前端部署
 
请下载最新版本的前端安装包至服务器部署目录，下载地址： 下载 (以1.2.0版本为例)，下载后上传tar包到该目录中，并进行解压
 
cd /opt/dolphinscheduler;

tar -zxvf apache-dolphinscheduler-incubating-1.2.0-dolphinscheduler-front-bin.tar.gz -C /opt/dolphinscheduler;

mv apache-dolphinscheduler-incubating-1.2.0-dolphinscheduler-front-bin dolphinscheduler-ui
 
以下两种部署方式任选其一种即可，推荐自动化部署
 
2.1 自动化部署
 
 
进入dolphinscheduler-ui目录下执行(注意：自动化部署会自动下载 nginx)
 
cd dolphinscheduler-ui;
sh ./install-dolphinscheduler-ui.sh;
 
  
执行后，会在运行中请键入前端端口，默认端口是8888，如果选择默认，请键入y，或者键入其他端口
然后会让键入跟前端ui交互的api-server的ip
接着是让键入跟前端ui交互的api-server的port
接着是操作系统选择
等待部署完成
 
 
部署完，为防止资源过大无法上传到资源中心,建议修改nginx上传大小参数，具体如下
 
  
添加nginx配置 client_max_body_size 1024m，在http方法体内添加即可
 
vi /etc/nginx/nginx.conf

# add param
client_max_body_size 1024m;
 
  
然后重启Nginx服务
 
systemctl restart nginx
 
 
访问前端页面地址: http://localhost:8888 ，出现前端登录页面，前端web也安装完成了
 
<p align="center">
   <img src="/img/login.png" width="60%" />
 </p>
 
 
2.2 手动部署
 
 
自行安装nginx，去官网下载: http://nginx.org/en/download.html 或者 yum install nginx -y
 
 
修改nginx配置文件(注意自行修改的几处)
 
 
vi /etc/nginx/nginx.conf

server {
    listen       8888;# 访问端口(自行修改)
    server_name  localhost;
    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;
    location / {
        root   /opt/soft/dolphinscheduler-ui/dist;      # 前端解压的dist目录地址(自行修改)
        index  index.html index.html;
    }
    location /dolphinscheduler {
        proxy_pass http://localhost:12345;    # 接口地址(自行修改)
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header x_real_ipP $remote_addr;
        proxy_set_header remote_addr $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_connect_timeout 4s;
        proxy_read_timeout 30s;
        proxy_send_timeout 12s;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
    #error_page  404              /404.html;
    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}
 
 
然后重启Nginx服务
 
systemctl restart nginx
 
 
访问前端页面地址: http://localhost:8888 ，出现前端登录页面，前端web也安装完成了
 
 
 
3、启停服务
 
 
一键停止集群所有服务
 
sh ./bin/stop-all.sh
 
 
一键开启集群所有服务
 
sh ./bin/start-all.sh
 
 
启停Master
 
 
sh ./bin/dolphinscheduler-daemon.sh start master-server
sh ./bin/dolphinscheduler-daemon.sh stop master-server
 
启停Worker
 
sh ./bin/dolphinscheduler-daemon.sh start worker-server
sh ./bin/dolphinscheduler-daemon.sh stop worker-server
 
启停Api
 
sh ./bin/dolphinscheduler-daemon.sh start api-server
sh ./bin/dolphinscheduler-daemon.sh stop api-server
 
启停Logger
 
sh ./bin/dolphinscheduler-daemon.sh start logger-server
sh ./bin/dolphinscheduler-daemon.sh stop logger-server
 
启停Alert
 
sh ./bin/dolphinscheduler-daemon.sh start alert-server
sh ./bin/dolphinscheduler-daemon.sh stop alert-server

简介
 
产品或项目不可能一步到位，一次性推向用户，故而有版本的存在。在app版本更新或者项目迭代的过程中，不可避免需要发布。发布就是部署；部署就是修改；修改则意味着风险。
 
目前有很多用于部署的技术，本文将目前常用的布署方案做一个总结。
 
备注：本文不具有多少原创性，多是网络资源的整理，加上个人的理解。
 
分类
 
蓝绿部署
 
Blue/Green Deployment
 定义
 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。
 
特点
 蓝绿部署无需停机，并且风险较小。
 
布署过程
 
部署版本1的应用（一开始的状态）
 所有外部请求的流量都打到这个版本上。
部署版本2的应用
 版本2的代码与版本1不同(新功能、Bug修复等)。
利用负载均衡将流量从版本1切换到版本2。
如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。
 
小结
 在部署的过程中，应用始终在线，保证系统在不间断提供服务。新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上可以在任何时间回滚到老版本。
 
注意事项
 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；
 
可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
需要提前考虑数据库与应用部署同步迁移 /回滚的问题。
蓝绿部署需要有基础设施支持。
在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
 
优势和不足
 优势：升级切换和回退速度非常快。
 不足：切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；需要两倍机器资源。
 
适用场合
 对用户体验有一定容忍度的场景。
 机器资源有富余或者可以按需分配（AWS 云，或自建容器云）。
 
为什么需要蓝绿发布系统？
 新项目和新需求非常多。
 新需求的上线过程是，先上线一台服务器然后观察会不会出问题，如果没有问题则全部上线。
 分流是关键，但是动态分流是痛点。
 
老分流方案
 外界请求到达nginx，nginx 负载均衡实现分流到配置的upstream1~3
 该方案存在的问题点：
 nginx.conf配置文件里各种if、set和rewrite，并且容易配置出错。
 修改完配置文件后，重启或者reload后才能生效。
 不能实现太复杂的逻辑。
 不能实现一些特殊分流方式。
 
新分流方案
 
 功能说明：
 采用Redis存放分流策略；
 分流策略包括按时间来分流，比如每分钟分流多少笔订单；还有按权重分流，比如新老系统之间的比例是1:9；
 采用OpenResty+lua，整体性能优秀。
 
Rolling update（滚动发布）
 
定义
 一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。
 
特点
 这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数；滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。可以部分部署，例如每次只取出集群的20%进行升级。
 
部署过程
 
滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
 
优势和不足
 优势：用户体验影响小，体验较平滑。
 不足：
 (1) 没有一个确定OK的环境。使用蓝绿部署，确定老版本是OK的，滚动发布无法确定。
 (2) 修改现有的环境。
 (3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。
 (4) 有时还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，还需判断到底哪个节点使用的是哪个代码。
 (5) 因为是逐步更新，在上线代码版本时，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。
 发布和回退时间比较缓慢；发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。
 
灰度发布/金丝雀部署
 
定义
 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
 金丝雀部署也就是灰度发布的一种方式，是增量发布的一种。在原有版本可用的情况下，同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。同时运行同一个软件产品的多个版本，需要软件针对配置和完美自动化部署进行特别设计。
 
A/B Testing
 A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上，不过当然需要后端来支持。
 A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。
 
步骤：
 
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
从负载均衡列表中移除掉“金丝雀”服务器。
升级“金丝雀”应用（排掉原有流量并进行部署）。
对应用进行自动化测试。
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
 
灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。灰度发布还应该可以动态调整不同的权重来进行新老版本的验证。
 
其它发布方式
 
上述都是偏传统的发布方式，能覆盖大部分应用发布场景。针对一些关键新功能的上线发布，或者一些特定的场景，还有一些特殊的发布方式。
 
功能开关发布
 
利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念，研发人员可以灵活定制和自助完成的发布方式。
 
 部署过程
 
功能开关发布需要一个配置中心或者开关中心这样的服务支持，这些都支持开关发布。业界还有专门的功能开关 SaaS 服务，例如 LaunchDarkly。通过配置中心，运维或研发人员可以在运行期动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还能支持其它很多动态配置场景。
功能开关服务一般提供客户端 SDK，方便开发人员集成。在运行期，客户端 SDK 会同步最新的开关值，技术实现有推方式 (push)，也有拉方式 (pull)，或者推拉结合方式。
新功能（V2）和老功能（V1）住在同一套代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开，则走新代码逻辑。可以理解为一个简单的 if/else 逻辑。
应用上线后，开关先不打开，然后运维或研发人员通过开关中心打开新功能，经过流量验证新功能没有问题，则发布完成；如果有问题，则随时可以通过开关中心切回老功能逻辑。
 
优势和不足
 优势：
 升级切换和回退速度非常快；
 相对于复杂的发布工具，实施比较简单，成本相对低廉；
 研发能够灵活定制发布逻辑，支持 DevOps 自助发布。
 不足：
 切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；
 对代码有侵入，代码逻辑会变复杂，需要定期清理老版本逻辑，维护成本变高。
 
影子测试
 
影子测试：对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，采用比较复杂的流量复制、回放和比对技术实现。架构图：
 
 部署过程
 影子测试一般适用于遗留系统的等价重构迁移，如 .net 转 Java，或者 SQLServer 升级为 MySQL，且外部依赖不能太多，否则需要开发很多 mock，测试部署成本会很高，且比对测试更加复杂和不稳定。
 目标实现老的 legacy 服务迁移升级到新的 experimental 服务。
 测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过 kafka 队列收集，然后通过类似 goreplay 这样的工具，消费 kafka 里头的请求日志，复制回放，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。
 影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。
 
优势和不足
 优势：
 对生产用户体验完全无影响；
 可以使用生产真实流量进行测试（复制比对）。
 不足：
 搭建复杂度很高，技术门槛高，数据库的导出复制是难点；
 外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定。
 
总结对比
 
部署方式
简述
优势
劣势
蓝绿部署
不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本
1.同一时间对外服务的只有一个版本，容易定位问题；2.升级和回滚以集群为粒度，操作相对简单
需要维护两个集群，成本高
滚动部署
按批次停止老版本实例，启动新版本实例
只需要维护一个集群，成本低
1. 上线过程中，两个版本同时对外服务，不易定位问题，且容易造成数据错乱；2.升级和回滚以节点为粒度，操作相对复杂
灰度发布/金丝雀部署
不停止老版本，额外搞一套新版本，按照用户设置路由权重，如90%的用户维持使用老版本，10%的用户尝鲜新版本
不同版本应用共存，常用于A/B测试；新版本尝鲜体验反馈；用户体验影响小，灰度发布过程出现问题只影响少量用户
实现方案相对复杂，需要实现发布自动化
参考/推荐阅读
 
金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？
 BlueGreenDeployment-Martin Fowler
 在生产中使用金丝雀部署来进行测试
 Blue-green Deployments, A/B Testing, and Canary Releases
 基于Nginx+lua的蓝绿发布系统
 Using Blue-Green Deployment to Reduce Downtime and Risk
 蓝绿发布的整个部署过程
 Kubernetes之蓝绿部署

 
RuoYi-Vue项目部署
 
项目地址
部署成果
后端部署
jar部署
war部署
  
前端部署
使用nginx部署
tomcat部署
部署在ROOT下（单独占用容器）
部署在ROOT下（和后端同一容器）
部署在非ROOT下
  
 

 
项目地址
 
框架地址：https://gitee.com/y_project/RuoYi-Vue
文档地址：https://doc.ruoyi.vip/ruoyi-vue/
issues：https://gitee.com/y_project/RuoYi-Vue/issues
 
部署成果
 
 
后端部署
 
可以使用idea或者eclipse或者项目下bin目录中的脚本进行打包（war / jar），打包时有几点需要注意：
 
 
 
logback.xml文件中的路径建议改为./logs
 application.yml中的profile需要改为服务器存在的真实路径
 
 
jar部署
 
因为springboot中已经内置了tomcat或者其他容器，不需要另外部署tomcat，按照下面步骤操作：
 
 
将打包后的jar文件放在任意一个位置；
 
 
在服务器上和jar同一个目录下新建一个config目录，将项目里的application-druid.yml、application.yml或者其他yml配置文件复制出来，放入config目录；
 
 
执行命令启动：nohup java -jar ruoyi-admin.jar
 也可以加更多的启动参数，如果是linux也可以把项目下的ry.sh放在jar同级目录下，修改ry.sh里的AppName和相关路径，执行./ry.sh start即可启动
 
  
 
   
脚本使用方法
 启动：./ry.sh start
 停止：./ry.sh stop
 重启：./ry.sh restart
 状态：./ry.sh status
 
  
 
 
可以查看启动日志或者使用curl或者浏览器访问是否已经启动，访问地址：http://ip:port，如果返回{"msg":"请求访问：/，认证失败，无法访问系统资源","code":401}，证明部署成功；
 
  
 
   
—说明
 放在config目录是为了以后修改端口号以及数据库连接等信息方便，直接修改yml配置文件即可，不需要重现打包jar，因为springboot加载配置文件顺序是
 1、/config/application.yml
 2、/application.yml
 3、classpath:/config/application.yml
 4、classpath:/application.yml
 注意：这些文件或者目录是根据命令发起目录来的，假如脚本或命令是在admin目录下执行，而jar文件是在admin/target目录下，则需要将config/xxx.yml文件及目录放在admin目录下
 
  
 
 
war部署
 
将打包后的war文件，放在服务的webapps下，可以使用解压缩软件解压（war其实就是个压缩包），解压后将文件夹重命名为ROOT，如果需要带项目有也可以配置为其他名称，更多tomcat配置这里不再赘述；
启动tomcat，可以查看启动日志或者使用curl或者浏览器访问是否已经启动，访问地址：http://ip:port，如果返回{"msg":"请求访问：/，认证失败，无法访问系统资源","code":401}，证明部署成功；
 
前端部署
 
前端部署可以使用nginx部署或者直接使用tomcat部署。
 
使用nginx部署
 
 
将前端打包，命令：npm run build:prod，将dist（默认的）目录放在服务器的任意一个文件夹下，比如这里放在/home/www/projects/ruoyi-ui
 
 
在nginx配置文件中做下面的配置，此处后端的端口（8080）需要根据实际后端部署情况修改
 
server {
        listen       80;
        server_name  localhost;

		location / {
            root   /home/www/projects/ruoyi-ui/dist;
			try_files $uri $uri/ /index.html;
            index  index.html index.htm;
        }
		
		location /prod-api/{
			proxy_set_header Host $http_host;
			proxy_set_header X-Real-IP $remote_addr;
			proxy_set_header REMOTE-HOST $remote_addr;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_pass http://localhost:8080/;
		}

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
 
 
启动nginx或者重载nginx
 
 
浏览器访问http://ip查看是否正常显示，如果出现登录界面并且显示验证码说明部署成功
 
 
tomcat部署
 
一般情况下使用nginx部署，但是有些时候也有人使用tomcat部署，按照下面的流程进行：
 
部署在ROOT下（单独占用容器）
 
 
 
注意：这里不需要在server.xml下增加HOST节点
 
 
 
如果你的后端和前端不在同一个tomcat下，也就是单独部署vue，那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端地址+端口，例如VUE_APP_BASE_API = '//localhost:8080'
 
 
将前端打包，命令：npm run build:prod，将dist（默认的）目录放在服务器tomcat的webapps下，将dist重命名为ROOT
 
 
在ROOT下新建WEB-INF目录，在WEB-INF目录中新建web.xml文件如下：
 
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
        http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
        version="3.1" metadata-complete="true">
     <display-name>Router for Tomcat</display-name>
     <error-page>
        <error-code>404</error-code>
        <location>/index.html</location>
    </error-page>
</web-app>
 
最终效果如下图：
 
 
 
启动tomcat，浏览器访问http://ip:port，出现登录界面和验证码说明部署成功
 
 
部署在ROOT下（和后端同一容器）
 
 
 
注意：这里不需要在server.xml下增加HOST节点
 
 
 
如果你的后端和前端在同一个tomcat下，那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端的项目名，例如VUE_APP_BASE_API = '/prod-api'，其中prod-api就是你的后端项目名，部署方法可以参考上面的后端部署-war部署
 
 
将前端打包，命令：npm run build:prod，将dist（默认的）目录放在服务器tomcat的webapps下，将dist重命名为ROOT
 
 
在ROOT下新建WEB-INF目录，在WEB-INF目录中新建web.xml文件如下：
 
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
        http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
        version="3.1" metadata-complete="true">
     <display-name>Router for Tomcat</display-name>
     <error-page>
        <error-code>404</error-code>
        <location>/index.html</location>
    </error-page>
</web-app>
 
最终效果如下图：
 
 
 
启动tomcat，浏览器访问http://ip:port，出现登录界面和验证码说明部署成功
 
 
部署在非ROOT下
 
 
 
这里部署的项目名是admin
 
 
 
如果你的后端和前端在同一个tomcat下，那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端的项目名，例如VUE_APP_BASE_API = '/prod-api'，其中prod-api就是你的后端项目名；如果你的后端和前端不在同一个tomcat下，也就是单独部署vue，那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端地址+端口，例如VUE_APP_BASE_API = '//localhost:8080'。
 
 
修改vue.config.js下的publicPath，例如：publicPath: process.env.NODE_ENV === "production" ? "/admin/" : "/", 这里根据你部署的项目名决定，这个影响资源文件的引用
 
 
router/index.js下添加base: "/admin",，如下
 
export default new Router({
  base: "/admin",
  mode: 'history', // 去掉url中的#
  scrollBehavior: () => ({ y: 0 }),
  routes: constantRoutes
})
 
 
Navbar.vue中的退出方法里location.href = '/index';改为location.href = this.$router.options.base + '/index';
 
 
将前端打包，命令：npm run build:prod，将dist（默认的）目录放在服务器tomcat的webapps下，将dist重命名为admin
 
 
在server.xml中加入Host节点下添加：<Context docBase="admin" path="/admin/" reloadable="true" source=""/>
 
 
在admin下新建WEB-INF目录，在WEB-INF目录中新建web.xml文件如下：
 
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
        http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
        version="3.1" metadata-complete="true">
     <display-name>Router for Tomcat</display-name>
     <error-page>
        <error-code>404</error-code>
        <location>/index.html</location>
    </error-page>
</web-app>
 
 
启动tomcat，浏览器访问http://ip:port/admin，出现登录界面和验证码说明部署成功
 
其他配置方式可以自己参考上面的方式尝试，需要注意的点：
 
  
 
   
1、tomcat项目名路径配置
 2、vue静态资源路径配置相应和项目名一致