在前端发行版本的确定中，我们使用的是 Jenkins 的 pipeline 构建文件来进行自动构建的。 你只需要修改 PRJ_VERSION 的版本 PRJ_VERSION 的版本号，然后将代码进行提交然后 PUSH 到 Git 仓库后，项目将会自动被编译并且将新版本的 Docker 文件推送到 Docker 的仓库中。 仓库校验 你需要确定有仓库的访问权限，访问地址：Nexus Repository Manager 这个地址是我们 Docker 容器的仓库地址。 可以在左侧找到项目的版本，然后单击版本在右侧确定版本提交的时间。 以确定前端 UI 版本被正确编译并被推送到仓库中。 https://www.usreio.com/t/usvisatrack-ui/307
这个 413 错误 有 2 个方面的，第一是 nginx 反向代理的问题。 通常这个将包的大小设置到 1024m 都能解决。 我们的坑 我们的坑的错误是我们使用了 cloudflare。 cloudflare 有数据上传限制。 否则会抛出下面的的提示： <html> <head><title>413 Request Entity Too Large</title></head> <body> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>cloudflare</center> </body> </html> 考古后发现下面的配置： Cloudflare limits upload size (HTTP POST request size) per plan type: 100MB Free and Pro 200MB Business 500MB Enterprise by default 如果你需要上传超过上面大小的数据的话，就不能使用 Cloudflare 的 CDN 缓存功能。 你可以只使用 Cloudflare 的 CDN 服务来解决这个问题。 https://www.ossez.com/t/maven-docker-maven-plugin-push-413/14160
配置方案在下面的这几句话。 <executions> <execution> <id>default</id> <phase>deploy</phase> <goals> <goal>build</goal> <goal>push</goal> </goals> </execution> </executions> 上面的话，就会让 Fabric8 Docker Maven Plugin 在 maven 执行 deploy 的时候实现构建 Docker 和推送。 直接运行： mvn clean deploy 就可以完成 Docker 的打包和推送了。 完成推送。 https://www.ossez.com/t/fabric8-docker-maven-plugin-docker/14161
在后台的管理员界面中，禁用匿名访问就可以了。 在匿名访问中，取消选择匿名用户访问。 https://www.ossez.com/t/sonatype-nexus/14155
如果是第一次进行登录的话，我们会看到下面的界面。 在这个界面中可以找到管理的密码。 登录后提示修改管理员密码。 提示是否允许匿名访问。 如果是公司自己的服务器话，就不需要启用匿名访问了。 https://www.ossez.com/t/sonatype-nexus/14154
在安装仓库之前，需要首先确定服务器上已经安装了 Java。 建议是用 11 以上的版本。11 版本是最低的需求。 我们的安装版本是 11。 下载文件 我们会把文件安装到 /opt 目录下，下载文件后解压。 cd /opt wget https://download.sonatype.com/nexus/3/latest-unix.tar.gz tar -xvzf latest-unix.tar.gz 重命名文件夹 有 2 个文件夹需要重命名。 mv nexus-3.42.0-01/ nexus mv sonatype-work nexusdata 重命名后的文件夹如上图。 设置运行的用户权限 我们将会使用 nexus 用户来运行。 依次运行下面的命令： useradd --system --no-create-home nexus chown -R nexus:nexus /opt/nexus chown -R nexus:nexus /opt/nexusdata 来对需要运行的用户进行赋权。 修改数据文件路径 因为我们对数据文件进行了重命名了，所以我们需要修改数据文件的路径。 vim /opt/nexus/bin/nexus.vmoptions 然后保存退出。 -Xms2703m -Xmx2703m -XX:MaxDirectMemorySize=2703m -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=../nexusdata/nexus3/log/jvm.log -XX:-OmitStackTraceInFastThrow -Djava.net.preferIPv4Stack=true -Dkaraf.home=. -Dkaraf.base=. -Dkaraf.etc=etc/karaf -Djava.util.logging.config.file=etc/karaf/java.util.logging.properties -Dkaraf.data=../nexusdata/nexus3 -Dkaraf.log=../nexusdata/nexus3/log -Djava.io.tmpdir=../nexusdata/nexus3/tmp -Dkaraf.startLocalConsole=false -Djdk.tls.ephemeralDHKeySize=2048 # # additional vmoptions needed for Java9+ # # --add-reads=java.xml=java.logging # --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED # --patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.6.jar # --patch-module java.xml=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.java.xml-4.3.6.jar # --add-opens java.base/java.security=ALL-UNNAMED # --add-opens java.base/java.net=ALL-UNNAMED # --add-opens java.base/java.lang=ALL-UNNAMED # --add-opens java.base/java.util=ALL-UNNAMED # --add-opens java.naming/javax.naming.spi=ALL-UNNAMED # --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED # --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED # --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED # --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED # --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED # --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED # --add-exports java.security.sasl/com.sun.security.sasl=ALL-UNNAMED # # comment out this vmoption when using Java9+ # -Djava.endorsed.dirs=lib/endorsed 如果你的数据文件在不同路径的话，这里也可以进行配置。 编辑 nexus.rc 文件 因为我们的运行用户名修改了，所以这个文件也需要进行修改。 /opt/nexus/bin/nexus.rc 将这行取消注释，修改为下面的内容。 run_as_user="nexus" 修改服务端地址和端口 运行下面的命令： vi /opt/nexus/etc/nexus-default.properties 将端口修改为 9090, 当然你也可以不修改这个端口，主要是为了避免和系统中的其他端口冲突。 地址修改为 127.0.0.1 修改后的端口和地址如上图。 修改用户打开文件限制 因为进程有打开文件的限制。 在文件的最后添加下面的内容。 nexus - nofile 65536 使用命令打开文件。 vi /etc/security/limits.conf 在文件的最后添加上面的内容。 设置 Nexus 为服务 使用命令编辑下面的文件： vi /etc/systemd/system/nexus.service 将下面的内容复制到这个文件中。 [Unit] Description=Nexus Service After=syslog.target network.target [Service] Type=forking LimitNOFILE=65536 ExecStart=/opt/nexus/bin/nexus start ExecStop=/opt/nexus/bin/nexus stop User=nexus Group=nexus Restart=on-failure [Install] WantedBy=multi-user.target 然后将上面的文件保存退出。 将服务设置开机启动，并且启动 nexus 服务。 依次运行下面的命名： systemctl daemon-reload systemctl enable nexus.service 启动服务 输入下面的命令来启动服务。 systemctl start nexus 查看服务启动状态 运行下面的命令来查看服务启动的状态。 tail -f /opt/nexusdata/nexus3/log/nexus.log 查看端口状态，如果正常启动端口应该会显示被占用。 上面显示 9090 端口被占用。 需要注意的是，第一次启动比较耗时，需要耐心等待。 校验安装 如果你没有安装反向代理，并且没有防火墙的话。 通过 9090 端口，应该就可以正常访问了。 如果能看到下面的界面，则说明安装已经成功了。 https://www.ossez.com/t/centos-sonatype-nexus/14153
首先需要在群晖的 Docker 中选择 Image，然后选择添加。 输入 Docker HUB 的地址 在弹出的对话框中输入 Docker Hub 的地址。 MongoDB 的地址为： Docker Hub 然后选择添加。 选择版本和运行 在后续的界面中，要求选择版本，我们选择最新的版本即可。 随后，我们需要稍等下把 Image 下载到整列中。 然后选择 Mongo 的版本运行即可，网络按照默认的选择。 下一步继续。 在下一个界面中需要对本地网络进行映射。 对卷进行配置，在默认情况下，可以跳过这一步。 对配置进行校验。 如果没有问题的话，直接下一步进行安装。 启动服务 在安装好的服务中，单击启动 Mongo 服务就可以了。 通过日志来查看启用的状态。 根据你 NAS 的情况不同，你可能没有办法安装到 MongoDB 的最高版本。 这个时候可能你只能用到 4.x 的版本。 如果能够在控制台上看到下面的内容，则说明已经安装成功了。 https://www.ossez.com/t/synology-nas-mongodb/14152
我们都知道 Spring Batch 有 2 种任务方式。 主要是在 Step 阶段，在 Step 阶段，我们可以执行一个 Tasklet，我们也可以按照 Chunk 来执行。 主要区别 如果使用 Tasklet 的话，我们可以一个 Step 对应一个 Tasklet，Spring Batch 不允许一个 Step 对应多个 Tasklet。 考虑有一个场景，我们需要使用 Spring Batch 对数据库中的表进行更新，这个表可能每次 Batch 要更新 几千条数据，需要满足每 5 分钟更新一次。 如果我们采取 Tasklet 的方式的话，正常的思维都是读取需要更新的数据，然后逐条进行更新。 这个没有问题吧，但是恰恰问题就在这里。 问题就是在 Spring Batch 使用的事务，Tasklet 在启动的时候会创建一个事务，那么读取 1000 条数据，处理 1000 条数据，写入 1000 条数据都在一个事务里面。 假设这个处理时间超过 5 分钟，下一次的任务又开始启动了，这个时候 Spring Batch 还会启动一个事务。 假设 10 分钟了，我们还是没有完成，Spring Batch 会继续启动任务和创建事务。 结果是什么，这个显而易见了，就是出现事务堆积，导致锁表，然后所有的任务都失败，无法完成。 针对这种场景，我们就需要 chunk 了。 chunk Chunk 的主要目的就是为了告诉 Spring 一次执行几条记录。 我们如果设置 Chunk 为 1 的话，那么 Spring Batch 每次读取一条记录，处理一条记录，写入一条记录，然后将这个事务进行提交。 这样的话，可以有效的避免事务堆积导致的锁表。 Chunk 的大小，通常比较小，如果一次性设太大了，也会锁表。 https://www.ossez.com/t/spring-batch-chunk/14151
根据 Spring Batch 的设计，在一个 Step 中只能执行一个 Tasklet。 如果想按照顺序执行多个 Tasklet 的话，我们需要设置不同的 Step。 正如上面定义的 Step，虽然我们在这个 Step 中定义了 2 个 Tasklet。 上面代码最后的执行顺序还是只执行最后一个 Tasklet，第一个定义的被忽略掉了。 https://www.ossez.com/t/spring-batch-step-tasklet/14150
对 Spring Batch 有所了解的同学都知道 Batch 是用来进行批量数据处理的。 但是我们在同时使用 Spring JPA 的时候，尤其是循环数据处理的时候，我们希望能够尽快提交事务。 但是，Spring Batch 中，如果使用了 Tasklet 的话，那么Spring 会在 Tasklet 级别创建一个事务。 在 Tasklet 不完成的情况下，事务是不会提交的。 这就需要对我们代码进行进行处理的时候，需要对数据量有多大有比较清楚的了解。 否则，非常容易遇到事务堆叠导致锁表的情况。 解决办法 针对一个 Tasklet 只完成一个特定的工作，如果 Job 的处理数据比较多的话，需要分开不同的 Tasklet 来做。 如上图，哪怕我们在这里调用了不同的服务，调用了不同的数据层。 事务都是没有办法提交的。 简单的办法就是针对上面的操作使用不同的 Tasklet 来做。 有人问过，能不能在循环中一次一次的进行提交。 Spring Batch 这样设计的目的就是为了保持数据的完整性，因此需要对 Batch 的逻辑进行考虑，而不建议考虑怎么省事怎么来。 https://www.ossez.com/t/spring-batch/14148