Deploy

工作流的几种部署方式 public interface DeploymentBuilder { // 输入流 DeploymentBuilder addInputStream(String resourceName, InputStream inputStream); //类路径方式 DeploymentBuilder addClasspathResource(String resource); //文本方式 DeploymentBuilder addString(String resourceName, String text); //字节流方式 DeploymentBuilder addBytes(String resourceName, byte[] bytes); //压缩流方式 DeploymentBuilder addZipInputStream(ZipInputStream zipInputStream); //模型方式 DeploymentBuilder addBpmnModel(String resourceName, BpmnModel bpmnModel); } //TODO 流方式发布实例 @SneakyThrows public void deploy(String name, MultipartFile file) { InputStream

摘要 坊间传闻java web开发人员写了那么多代码，但是其实一半代码都在处理NPE。总是在加班，却大部分时间都在处理包冲突，类加载不了的bug。这些问题总是让新老程序员都很抓狂，有很多的工具可以辅助我们解决这些问题（maven helper插件，arthas等）但是有没有一些原则可以遵循，在源头上避免这些问题的发生呢。 问题 经常遇到的问题有 ClassNotFoundException 通过 Class.forName() 或者 loadClass() 方法加载类时，当classpath中又找不到这个类，就会抛这个错误。 这个错误一般比较好排查，编译程序时就抛出来了。然后引入对应的jar包，或者刷新classpath就可以解决 NoClassDefFoundError 类在编译的时候存在，但是运行的时候不存在。 NoSuchMethodError 找不到对应的方法，运行时才会抛错，这个错误在日常开发经常遇到，线上诸多bug都是来源于此。 发生的原因就是多个包依赖了不一样版本的另外一个包，比如A,B都依赖了C包，A依赖C1,B依赖C2,工程中加载了C1，但是C1中某个类缺少了C2版本的这个类的某个方法，这时候运行时，B依赖的C2方法被调用到了，就会报这个错。 既然这些问题这么头疼，且难以排查，还容易造成线上故障，那平时在开发过程中如何避免这些问题。 做好二方包的管理

序 本文主要研究一下artemis的FederationManager FederationManager activemq-artemis-2.11.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/federation/FederationManager.java public class FederationManager implements ActiveMQComponent { private final ActiveMQServer server; private Map<String, Federation> federations = new HashMap<>(); private State state; enum State { STOPPED, STOPPING, /** * Deployed means {@link FederationManager#deploy()} was called but * {@link FederationManager#start()} was not called. * <p> * We need the distinction if {@link FederationManager#stop()} is called

作者： 知晓云 - 小程序开发快人一步 来源：知晓课堂 在小程序中生成分享海报是一个很常见的需求，目前主要有以下两种做法： 直接由前端生成，使用小程序提供的 canvas API 由后端(知晓云云函数)生成，前端再获取 本文将介绍通过知晓云云函数来生成分享海报的功能，并使用 webpack 和 mincloud 将代码打包上传到知晓云。 技术栈： 代码打包工具： webpack@4.22.0 部署工具：mincloud@1.0.4 图片处理：gm@1.23.1 其他：知晓云 SDK、imageMagick（云函数内置） 一、项目搭建 项目文件结构： 项目搭建与云函数代码打包示例文档（公众号回复“打包”即可获取）基本一致。项目搭建好后，还需要安装以下依赖（两种安装方式选其一即可）： 修改 deploy 脚本，如下： 最终我们会使用以下两个命令来部署和测试： 二、生成海报 这里分为 4 个步骤： 下载海报需要的资源 图片 / 文本处理 海报绘制 将绘制完成的海报上传到知晓云 使用知晓云 Node SDK 的 request 方法将资源下载下来（不能直接使用其他第三方 request 包）： 引入 gm 库对图片进行处理，云函数沙箱环境已经内置 imageMagick 工具： 在处理文字的时候需要注意，设置字体时需选择知晓云已支持的字体，详见 文档 。 另外，这里有一个 bug

作者： 知晓云 - 小程序开发快人一步 来源：知晓课堂 本文会跟大家介绍， 如何在本地使用知晓云云函数 API 与 cheerio 开发一个图片爬虫 ，并使用 webpack 与 mincloud 将代码打包并上传部署到知晓云。 技术栈： 代码打包工具：webpack@4.20.2 部署工具：mincloud@1.0.2 html 解析：cheerio@1.0.0-rc.2 其他：知晓云 Node SDK（云函数内置） ​ 项目文件结构： 最终我们会使用以下两个命令来部署与测试 一、webpack 配置 由于使用的是 v4 的 webpack，所以只需要很少的配置就可以了。 二、package script 配置 添加 deploy 脚本，如下： 三、入口文件 云函数作为一个模块在沙箱环境中被调用执行，该模块需要暴露出一个 main 方法，模块代码结果如下： 我们的 webpack 入口文件需要暴露出一个函数（签名为：function (event, callback)），打包后就可以生成一个给个跟上面一致的模块文件（在 webpack.config.js 中已经定义了）。所以我们的入口文件主要结构如下： 四、爬虫 这里分为 4 个步骤： 抓取网页 解析页面，抓出所有 img 标签中的 src 将图片下载下来 将下载下来的图片上传到知晓云 使用知晓云 Node SDK 的

Photo by Oscar Ivan Esquivel Arteaga on Unsplash 本文来自流媒体直播集群SRS的官方wiki（https://github.com/ossrs/srs/wiki/v4_CN_K8s），由SRS的创始作者杨成立授权发布。 文 / 杨成立 当SRS遇到K8s：快速构建高并发直播集群 本章描述了基于K8s，如何构建Origin Cluster支持超多推流场景。 Origin Cluster通过配置其他源站的信息，在本源站没有流时查询到流的位置，通过RTMP302定向到指定源站，具体原理可以参考#464。主要应用场景如下： 源站灾备：即使流比较少，也可以用两个源站，这样可以将流分散到不同的源站，避免源站出现问题时影响所有的流。 海量推流：单源站可以支持1000到3000路流，高码率的流支持的路数更少，有DVR和HLS时支持的路更少，源站集群有多个源站同时接收推流，可以支持10k~100k推流，参考规格。 复杂源站业务：源站除了支持推流和拉流，还有重要的功能是DVR、转码、转HLS，DVR和HLS涉及磁盘，转码涉及CPU，都是容易发生瓶颈的资源依赖，源站集群扩展能力更强。 在这个场景下，对比K8s和传统使用方式的差异： Step 1: 由于SRS和Nginx不在一个Pod可能也不在一个Node，需要创建依赖的PV(Persistent

接着前面的《 tox 教程 》，以及刚翻译好的《 nox文档 》，我们继续聊聊 Python 任务自动化的话题。 nox 的作者在去年的 Pycon US 上，做了一场题为《 Break the Cycle: Three excellent Python tools to automate repetitive tasks 》的分享（B站观看地址： https://b23.tv/av86640235），她介绍了三个任务自动化工具：tox、nox 和 invoke，本文的话题正好就是最后的 invoke。 1、invoke 可以做什么？ invoke 是从著名的远程部署工具 Fabric 中分离出来的，它与 paramiko 一起是 Fabric 的两大最核心的基础组件。 除了作为命令行工具，它专注于“任务执行”（task execution），可以标注和组织任务，并通过 CLI（command-line interface，即命令行界面） 和 shell 命令来执行任务。 同样是任务自动化工具，invoke 与我们之前介绍过的 tox/nox 在侧重点上有所不同： tox/nox 主要是在打包、测试、持续集成等方面的自动化（当然它们能做的还不止于此） invoke 则更具普遍性，可以用在任何需要“执行任务”的场景，可以是无相关性的任务组，也可以是有顺序依赖的分步骤的工作流

26.13 安装插件 26.14 构建job 26.15 手动安装jdk 26.16 发布war包 26.13 安装插件 1.系统管理 -> 管理插件，检查是否已经安装 Maven Integration plugin 和 Deploy to container Plugin，若没有安装则需要安装这两个插件 #要配置maven相关的项目必须要安装maven Integration plugin这个插件 Deploy to container Plugin插件可以将war包发布到远程去 2.安装完插件后，需要重启jenkins systemctl restart jenkins 3.创建新任务 4.登录jenkins，点击“新建”，任务名称自定义（我的叫做java-test） 5.选择“构建一个maven项目” #或查看有无这个项目 6.点击“确定” 实例： ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26.14 构建job 1.源码管理 2.选择 “git”, Repository URL填写你的git地址，并配置对应的key，大家最好事前先在jenkins这台机器上能够直接远程git操作私有仓库 3.构建触发器、构建环境、Pre

操作数据表 流程定义部署后操作 activiti数据表如下： act_re_deployment 流程定义部署表，记录流程部署信息 act_re_procdef 流程定义表，记录流程定义信息 act_ge_bytearray 资源表 部署信息表( act_re_deployment ) 部署流程定义时需要被持久化保存下来的信息。 字段名称 字段描述 数据类型 主键 为空 取值说明 ID_ ID_ nvarchar(64) √ 主键ID NAME_ 部署名称 nvarchar(255) √ 部署文件名 CATEGORY_ 分类 nvarchar(255) √ 类别 DEPLOY_TIME_ 部署时间 datetime √ 部署时间 流程定义数据表( act_re_procdef ) 业务流程定义数据表。此表和 ACT_RE_DEPLOYMENT 是多对一的关系，即，一个部署的bar包里可能包含多个流程定义文件，每个流程定义文件都会有一条记录在 ACT_REPROCDEF 表内，每个流程定义的数据，都会对于 ACT_GE_BYTEARRAY 表内的一个资源文件和 PNG 图片文件。和 ACT_GE_BYTEARRAY 的关联是通过程序用 ACT_GE_BYTEARRAY.NAME 与 ACT_RE_PROCDEF.NAME 完成的，在数据库表结构中没有体现。 字段名称 字段描述

是否可以使用 git push 部署网站？ 我有一种预感，它与使用 git钩子 在服务器端执行 git reset --hard 有关，但是我将如何实现呢？ #1楼 我最终创建了自己的基本部署工具，该工具会自动从存储库中提取新更新-https: //github.com/jesalg/SlimJim- 基本上，它会侦听github post-receive-hook并使用代理触发更新脚本。 #2楼 我们使用 capistrano 来管理部署。 我们构建了capistrano以部署在登台服务器上，然后与我们所有的服务器运行rsync。 cap deploy cap deploy:start_rsync (when the staging is ok) 使用capistrano，我们可以在发生错误的情况下轻松回滚 cap deploy:rollback cap deploy:start_rsync #3楼 我对 基督徒的 解决方案的看法。 git archive --prefix=deploy/ master | tar -x -C $TMPDIR | rsync $TMPDIR/deploy/ --copy-links -av username@server.com:/home/user/my_app && rm -rf $TMPDIR/deploy 将主分支归档到tar中