精华内容
下载资源
问答
  • 如何在Kubernetes上部署MySQL数据库

    千次阅读 2020-08-16 10:09:36
    Operators将数据库部署到Kubernetes 在Kubernetes上部署数据库是否可行? 1.完全托管的数据库 2.在VM或本地自行部署 3.在Kubernetes上运行 在Kubernetes上部署有状态应用程序: 步骤1:部署MySQL服务 步骤2:...

    原文发表于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

    展开全文
  • Apache DolphinScheduler 单机部署方案

    千次阅读 2020-02-25 12:32:21
    单机部署(Standalone) DolphinScheduler单机部署分为后端部署和前端部署两部分: 1、后端部署 1.1 : 基础软件安装(必装项请自行安装) PostgreSQL (8.2.15+) or Mysql (5.6或者5.7系列) : 两者任选其一即可 JDK (1.8...

    单机部署(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命令查看服务是否启动(jpsjava 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. 部署版本1的应用(一开始的状态)
      所有外部请求的流量都打到这个版本上。
    2. 部署版本2的应用
      版本2的代码与版本1不同(新功能、Bug修复等)。
    3. 利用负载均衡将流量从版本1切换到版本2。
    4. 如版本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. 滚动式发布一般先发 1 台,或者一个小比例,如 2% 服务器,主要做流量验证用,类似金丝雀 (Canary) 测试。
    2. 滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。
    3. 每次发布时,先将老版本 V1 流量从 LB 上摘除,然后清除老版本,发新版本 V2,再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
    4. 一次滚动式发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后续间隔 2 分钟)。
    5. 回退是发布的逆过程,将新版本流量从 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 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信;蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚。

    步骤:

    1. 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
    2. 从负载均衡列表中移除掉“金丝雀”服务器。
    3. 升级“金丝雀”应用(排掉原有流量并进行部署)。
    4. 对应用进行自动化测试。
    5. 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
    6. 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

    灰度发布中,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。灰度发布还应该可以动态调整不同的权重来进行新老版本的验证。

    其它发布方式

    上述都是偏传统的发布方式,能覆盖大部分应用发布场景。针对一些关键新功能的上线发布,或者一些特定的场景,还有一些特殊的发布方式。

    功能开关发布

    利用代码中的功能开关(Feature Flag/Toggle/Switch)来控制发布逻辑,一般不需要复杂的发布工具和智能 LB 配合,是一种低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念,研发人员可以灵活定制和自助完成的发布方式。
    在这里插入图片描述
    部署过程

    1. 功能开关发布需要一个配置中心或者开关中心这样的服务支持,这些都支持开关发布。业界还有专门的功能开关 SaaS 服务,例如 LaunchDarkly。通过配置中心,运维或研发人员可以在运行期动态配置功能开关的值。当然,功能开关发布只是配置中心的一种使用场景,配置中心还能支持其它很多动态配置场景。
    2. 功能开关服务一般提供客户端 SDK,方便开发人员集成。在运行期,客户端 SDK 会同步最新的开关值,技术实现有推方式 (push),也有拉方式 (pull),或者推拉结合方式。
    3. 新功能(V2)和老功能(V1)住在同一套代码中,新功能隐藏在开关后面,如果开关没有打开,则走老代码逻辑,如果开关打开,则走新代码逻辑。可以理解为一个简单的 if/else 逻辑。
    4. 应用上线后,开关先不打开,然后运维或研发人员通过开关中心打开新功能,经过流量验证新功能没有问题,则发布完成;如果有问题,则随时可以通过开关中心切回老功能逻辑。

    优势和不足
    优势:
    升级切换和回退速度非常快;
    相对于复杂的发布工具,实施比较简单,成本相对低廉;
    研发能够灵活定制发布逻辑,支持 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项目部署流程

    千次阅读 2021-04-16 11:55:13
    RuoYi-Vue项目部署,后端部署jar部署、war部署;前端部署,使用nginx部署、tomcat部署

    项目地址

    1. 框架地址:https://gitee.com/y_project/RuoYi-Vue
    2. 文档地址:https://doc.ruoyi.vip/ruoyi-vue/
    3. issues:https://gitee.com/y_project/RuoYi-Vue/issues

    部署成果

    部署成果

    后端部署

    可以使用idea或者eclipse或者项目下bin目录中的脚本进行打包(war / jar),打包时有几点需要注意:

    logback.xml文件中的路径建议改为./logs
    application.yml中的profile需要改为服务器存在的真实路径

    jar部署

    因为springboot中已经内置了tomcat或者其他容器,不需要另外部署tomcat,按照下面步骤操作:

    1. 将打包后的jar文件放在任意一个位置;

    2. 在服务器上和jar同一个目录下新建一个config目录,将项目里的application-druid.ymlapplication.yml或者其他yml配置文件复制出来,放入config目录;

    3. 执行命令启动: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

    4. 可以查看启动日志或者使用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部署

    1. 将打包后的war文件,放在服务的webapps下,可以使用解压缩软件解压(war其实就是个压缩包),解压后将文件夹重命名为ROOT,如果需要带项目有也可以配置为其他名称,更多tomcat配置这里不再赘述;
    2. 启动tomcat,可以查看启动日志或者使用curl或者浏览器访问是否已经启动,访问地址:http://ip:port,如果返回{"msg":"请求访问:/,认证失败,无法访问系统资源","code":401},证明部署成功;

    前端部署

    前端部署可以使用nginx部署或者直接使用tomcat部署。

    使用nginx部署

    1. 将前端打包,命令:npm run build:prod,将dist(默认的)目录放在服务器的任意一个文件夹下,比如这里放在/home/www/projects/ruoyi-ui

    2. 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;
              }
          }
      
    3. 启动nginx或者重载nginx

    4. 浏览器访问http://ip查看是否正常显示,如果出现登录界面并且显示验证码说明部署成功

    tomcat部署

    一般情况下使用nginx部署,但是有些时候也有人使用tomcat部署,按照下面的流程进行:

    部署在ROOT下(单独占用容器)

    注意:这里不需要在server.xml下增加HOST节点

    1. 如果你的后端和前端不在同一个tomcat下,也就是单独部署vue,那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端地址+端口,例如VUE_APP_BASE_API = '//localhost:8080'

    2. 将前端打包,命令:npm run build:prod,将dist(默认的)目录放在服务器tomcatwebapps下,将dist重命名为ROOT

    3. 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>
      

      最终效果如下图:
      ROOT目录

    4. 启动tomcat,浏览器访问http://ip:port,出现登录界面和验证码说明部署成功

    部署在ROOT下(和后端同一容器)

    注意:这里不需要在server.xml下增加HOST节点

    1. 如果你的后端和前端在同一个tomcat下,那就需要修改.env.production文件中的VUE_APP_BASE_API为你后端的项目名,例如VUE_APP_BASE_API = '/prod-api',其中prod-api就是你的后端项目名,部署方法可以参考上面的后端部署-war部署

    2. 将前端打包,命令:npm run build:prod,将dist(默认的)目录放在服务器tomcatwebapps下,将dist重命名为ROOT

    3. 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>
      

      最终效果如下图:
      和后端同一容器

    4. 启动tomcat,浏览器访问http://ip:port,出现登录界面和验证码说明部署成功

    部署在非ROOT下

    这里部署的项目名是admin

    1. 如果你的后端和前端在同一个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'

    2. 修改vue.config.js下的publicPath,例如:publicPath: process.env.NODE_ENV === "production" ? "/admin/" : "/", 这里根据你部署的项目名决定,这个影响资源文件的引用

    3. router/index.js下添加base: "/admin",,如下

      export default new Router({
        base: "/admin",
        mode: 'history', // 去掉url中的#
        scrollBehavior: () => ({ y: 0 }),
        routes: constantRoutes
      })
      
    4. Navbar.vue中的退出方法里location.href = '/index';改为location.href = this.$router.options.base + '/index';

    5. 将前端打包,命令:npm run build:prod,将dist(默认的)目录放在服务器tomcatwebapps下,将dist重命名为admin

    6. 在server.xml中加入Host节点下添加:<Context docBase="admin" path="/admin/" reloadable="true" source=""/>

    7. 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>
      
    8. 启动tomcat,浏览器访问http://ip:port/admin,出现登录界面和验证码说明部署成功

      其他配置方式可以自己参考上面的方式尝试,需要注意的点:

      1、tomcat项目名路径配置
      2、vue静态资源路径配置相应和项目名一致

    展开全文
  • wildfly 21中应用程序的部署

    万次阅读 2020-12-27 20:31:46
    除了配置文件的修改之外,最重要的就是应用程序的部署了。本文将会讲解如何在wildfly 21中,在Managed Domain和standalone两种模式中如何部署应用程序。
  • WAF基本原理与部署方式

    万次阅读 多人点赞 2020-06-14 10:34:16
    WAF常见的部署方式: WAF常见部署方式 WAF一般部署在Web服务器之前,用来保护Web应用。 那么WAF能做什么? WAF可以过滤HTTP/HTTPS协议流量,防护Web攻击。 WAF可以对Web应用进行安全审计 WAF可以防止CC攻击 应用
  • 项目部署的完整流程

    万次阅读 多人点赞 2020-07-09 12:26:04
    作为一个合格的程序猿,仅仅会打代码还是远远不够的,项目的部署也是我们必须要会的操作,也就是所谓的上线,将我们本地开发好的项目部署到远程服务器上,使得任何机器都可以通过我们远程服务器的公网ip或者域名加上...
  • 方法一:前后端分开部署 一、前端部署 1、下载 nginx,官方网址如下: http://nginx.org/en/download.html
  • 微服务的部署

    千次阅读 2019-06-26 00:01:02
    这里根据具体的开发情况介绍两种部署服务的方式:非集群环境下的服务部署和集群环境下的服务部署。 (一). 非集群环境下的服务部署  非集群环境下的服务部署就是根据所需的镜像都存放在本地私有镜像仓库,并且...
  • IPS与IDS部署场景

    万次阅读 多人点赞 2019-08-18 18:49:14
    IPS(入侵防御系统)部署模式:直路部署,单臂部署,旁路部署。 IDS(入侵检测系统)部署模式:旁路部署。 IPS直路部署场景(三种情况): 当NIP作为IPS设备直路部署时,用户只需要将接口对串行接入到需要保护...
  • 本课程讲述如何部署YOLOX在Jetson Nano开发板上。 部署完成后可进行视频文件和摄像头视频的目标检测。部署时将使用AI视频处理加速引擎TensorRT和DeepStream。 课程内容包括: 原理篇(DeepStream介绍、TensorRT...
  • jenkins自动化部署及三种构建部署方式

    万次阅读 多人点赞 2017-12-28 18:22:06
    用于测试环境预上线环境部署,开发push代码或者合并代码到gitlab项目的master分支之后,并不会部署代码,而是需要登录到jenkins的web界面,点击构建按钮,传入对应的参数(比如参数需要构建的tag,需要部署的分支)...
  • 实现热部署的基本原理介绍

    千次阅读 2019-01-21 17:22:11
    我在学校的某个失眠的夜晚去看了SpringBoot,对里面的热部署有了一些兴趣和了解,后来也发现热部署也是个比较重要的知识点,于是呢在这个有
  • Centos7.6部署蓝鲸智云社区版6.0.2Beta并通过git部署个人应用 Centos7.6+蓝鲸社区版6.0.2Beta分布式部署 1、程序包准备: Centos7.6 bkce_src-6.0.2.tar.gz 2、三台linux主机 IP 节点 CPU RAM ROM 192.168.1.91 ...
  • 开发web工程时经常要获取工程的根目录,自己用Java实现的获取Tomcat下war包部署的Web工程根目录路径的方法,主要利用web工程默认的目录结构,此外也可以指定工程名称获取工程目录的绝对路径
  • 手把手带你部署Java项目到Linux服务器

    千次阅读 多人点赞 2019-12-27 09:57:38
    之前领过腾讯云免费的15天体验服务器,在里面进行了一些小项目的部署,基本学会了部署流程,这两天准备购买一个自己用的小服务器,个人使用,最主要的就是要便宜,于是乎开始了货比三家,思来想去(还**不是因为穷)...
  • 最全Pycharm教程(13)——Pycharm部署

    万次阅读 多人点赞 2015-12-10 11:00:25
    自动上传功能意味着无论在IDE中对代码进行了何种改变,Pycharm都会自动将其保存在已部署的默认的服务端。  14、将服务器指定为缺省服务器  缺省服务器的最大优点就是可以使用自动上传功能,指定方法如下:  (1)...
  • 【教程】YOLOv5模型转化-Android端部署

    千次阅读 多人点赞 2021-06-03 19:54:39
    这里写目录标题前言转化方法官方的转化方法合作者的转化方法量化部署部署流程效果展示 前言 最近做毕设使用到yolov5,该模型为ultralytics公司的一个开源产品,由Glenn大佬实现,有很多合作的开发者参与了该项目,...
  • NuxtJS 项目部署如何部署到nginx

    万次阅读 2019-08-28 11:42:01
    NuxtJS 项目完成之后,如何部署到nginx? 总流程:Nuxtjs打包----》服务器上部署运行----》nginx监听----》PM2进程守护 提示:安装nginx (我目前使用的系统是win7) 官网下载地址: ...
  • 如果团队以“增量部署”作为日常部署方法,就必然需要面临维护两种部署模式,增量部署和全量部署。而如果统一使用“全量部署”则可以避免这个问题,一套部署流程统一两种不同部署需求,增强部署的可重复性。 如上...
  • 本文为系列博客tensorflow模型部署系列的一部分,用于实现通用模型的部署。本文主要实现用C++接口调用tensorflow模型进行推理。相关源码见链接 引言 本文为系列博客tensorflow模型部署系列的一部分,用于C++语言...
  • java项目安装部署手册示例

    热门讨论 2012-12-21 16:29:28
    java项目安装部署手册示例 包含jdk安装部署,tomcat安装部署,项目发布
  • FATE支持单机部署、集群部署和KubeFATE部署三种方式,其中单机部署和集群部署都属于原生(Native) 部署方式,要求开发人员配置必要的开发环境和依赖库,主要包括JDK 1.8+、Python 3.6、Python virtualenv、MySQL 5.6+...
  • k8s安装部署

    千次阅读 2020-02-17 18:29:02
    Kubernetes是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 快速部署应用 快速扩展应用 无缝对接新的应用功能 节省资源,优化硬件资源的使用 Kubernetes 特点 可...
  • 本文为系列博客tensorflow模型部署系列的一部分,用于实现通用模型的部署。本文主要实现用tflite接口调用tensorflow模型进行推理。相关源码见链接 引言 本文为系列博客tensorflow模型部署系列的一部分,用于tflite...
  • 重新部署项目 开发环境重新build项目(Mac环境的打包语法) CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build 查找指定端口的进程 博主的端口号9001 netstat -tunlp|grep 9001 结束之前的进程,开启新进程启动...
  • IDEA 出现问题:tomcat热部署没反应解决方案
  • 这里分了个目录,如果已经安装好虚拟机或者linux系统的小伙伴可以直接跳过前面的安装介绍,直接看部署。 文章目录一、总步骤说明二、安装虚拟机三、创建linux系统 一、总步骤说明 下载需要的材料(该博客有提供),...
  • 有没有纠结过框架依赖与独立部署到底有什么区别呢?如果有的话那么这篇文章可以参考下! 为什么要写这篇文章呢?因为今天同事问我框架依赖与独立部署到底应该选哪个呢?有什么区别。印象中只知道框架依赖发布后文件...
  • 前后端分离项目部署(部署在同一台服务器) 博主现在参与的项目是前后端分离的,前端是用vue写的并用npm构建的,后端是用java写的用maven构建的,但是前端和后端在同一个项目中,之前的部署方式是前端代码在本地调试好...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,152,801
精华内容 861,120
关键字:

部署