搜索到
289
篇与
的结果
-
-
jenkins构建docker镜像 背景 因为有用户需要容器化运行，需要我们提供镜像，但镜像构建分发还是比较麻烦的，涉及到如下步骤： 下载此版本最新的war包 构建war包为镜像 推送到仓库 如果总是人工操作必然会浪费很多时间，于是使用jenkins来提供自动化的流程 注意点 因为Dockerfile/启动脚本的以后可能会修改，这部分我们使用git托管起来，使用jenkins构建的时候也能自动拉取最新代码 流程 jenkins中先拉取代码 jenkins中调用脚本拿到war包，并且获取war包的版本 把脚本从本地发送到远端进行构建，如果是本地就更方便一点了！ 远程机器获取到war版本，设置新镜像名称，根据传送过来的文件中的dockerfile进行构建 构建完成后推送至镜像仓库 代码部分 镜像的dockerfile FROM harbor.xxx.com/base/xxx-centos:7.6-2020120414 COPY dirs/ /usr/local/ COPY ROOT.war start.sh /opt/ CMD sh -x /opt/start.sh dockerfile中的启动命令 #!/bin/bash # # 提供了三个参数： # MEM用来设置内存大小，未设置为1G # SERVICE来设置war名，上下文，否则为ROOT # CLUSTER设置集群ip前缀，docker私有ip有多个，如果做web集群，需要指定能容器之间互通的段 mem=0 war=0 cluster=0 if [ ! -z "${MEM}" ];then if echo ${MEM} | grep "^[[:digit:]]*$" &> /dev/null;then if [ ${MEM} -gt 31 ];then MEM=31 fi mem=1 fi fi if [ ! -z "${SERVICE}" ];then if [ -z "$(echo ${SERVICE} | tr -d '0-9A-Za-z')" ];then if ! echo ${SERVICE} | egrep "^[0-9]|[0-9]$" &> /dev/null;then war=1 fi fi fi if [ ! -z "${CLUSTER}" ];then cluster=1 fi if [ ${cluster} -eq 1 ];then export JAVA_OPTS="-Dsucc.clusterBindAddressPrefix=${CLUSTER}" fi if [ ${mem} -eq 1 ];then sed -i "s/1g/${MEM}g/g" /usr/local/tomcat/bin/catalina.sh fi if [ ${war} -eq 1 ];then cp -a /usr/local/tomcat/ROOT /usr/local/tomcat/webapps/ cp -a /opt/ROOT.war /usr/local/tomcat/webapps/${SERVICE}.war else cp -a /opt/ROOT.war /usr/local/tomcat/webapps/ fi /usr/local/tomcat/bin/catalina.sh start tail -f /etc/getcode/code jenkins部分 this="镜像-4.19.3" release_root="/var/jenkins_home/jobs/bi-4.19.3/workspace/bi" src_FILE="${release_root}/com.succez.bi/dist/ROOT.war" dst_FILE="/var/jenkins_home/jobs/${this}/workspace/ROOT.war" if [ ! -f "${src_FILE}" ];then echo "war包不存在" exit 1 fi \cp -rfa ${src_FILE} ${dst_FILE} version=$(cat ${release_root}/com.succez.bi/src/main/java/META-INF/succ-product.json | grep "version" | awk '{print $2}' | tr -d "\",") echo ${version} > /var/jenkins_home/jobs/${this}/workspace/version 文件传输 文件传输到远程机器使用的jenkins的sftp传输插件，在后台配置server登录账号密码后，在前端设置本地路径和目的路径。 本地路径是以workspace为参照的相对目录，表示当前所有文件，如果下级目录下的所有文件需要两个 目的路径需要写绝对目录 Remove prefix，如果本地目录中的目录层级需要移除，那么写入 后续脚本 cd /usr/local/build/release-bi/ version=$(cat version) time=`date +%Y%m%d%H` echo ${time} echo ${version} image_name="succbi:${version}-${time}" image_prefix="harbor.xxx.com/succbi/" image_latest="harbor.xxx.com/succbi/succbi:latest" image_cn=${image_prefix}${image_name} docker build -t ${image_name} . if [ $? -ne 0 ];then echo "docker build failed" exit 1 fi docker tag ${image_name} ${image_cn} docker tag ${image_name} ${image_latest} docker push ${image_cn} docker push ${image_latest} docker镜像命名规范 suxxx-4.xx.3:latest suxxx-4.xx.3:2022060801 suxxx-4.xx.0:latest suxxx-4.xx.0:2022060801 suxxx-oem:latest suxxx-oem:2022060801
-
v2ray异常错误之二 无法连接之异常 机器过期忘记续费停机了一天，但续费后v2ray死活连不上，有如下报错 服务端： 2022/05/27 02:17:28 [Info] [50130167] app/proxyman/inbound: connection ends > proxy/vmess/inbound: invalid request from 58.48.189.174:0 > proxy/vmess/encoding: connection drained DrainSize = 1589 23 2 > proxy/vmess/encoding: invalid user: VMessAEAD is enforced and a non VMessAEAD connection is received. You can still disable this security feature with environment variable v2ray.vmess.aead.forced = false . You will not be able to enable legacy header workaround in the future. 2022/05/27 02:17:29 [Info] [2512890072] app/proxyman/inbound: connection ends > proxy/vmess/inbound: invalid request from 58.48.189.174:0 > proxy/vmess/encoding: connection drained DrainSize = 1589 23 20 > proxy/vmess/encoding: invalid user: VMessAEAD is enforced and a non VMessAEAD connection is received. You can still disable this security feature with environment variable v2ray.vmess.aead.forced = false . You will not be able to enable legacy header workaround in the future. 客户端 May 27 14:16:37 localhost v2ray: 2022/05/27 14:16:37 [Info] failed to handler mux client connection > v2ray.com/core/proxy/vmess/outbound: connection ends > v2ray.com/core/proxy/vmess/outbound: failed to read header > v2ray.com/core/proxy/vmess/encoding: failed to read response header > websocket: close 1000 (normal) May 27 14:16:37 localhost v2ray: 2022/05/27 14:16:37 [Info] v2ray.com/core/common/mux: failed to read metadata > io: read/write on closed pipe May 27 14:16:37 localhost v2ray: 2022/05/27 14:16:37 [Info] [924485881] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled 排查了客户端和服务端时间同步问题，再就是配置也没有动，突然就连不上了确实很奇怪。查了下资料按照如下方法解决： 1.执行 systemctl status v2ray 命令 2.若步骤1正常输出v2ray的信息 ,观察Drop-In:后面的路径 ,如: Drop-In: /etc/systemd/system/v2ray.service.d 3.进入上述路径 cd /etc/systemd/system/v2ray.service.d 4.执行 ls 命令看是否有一个 .conf后缀的文件,如 10-donot_touch_single_conf.conf 5.vim 修改这个文件: vim 10-donot_touch_single_conf.conf 6. 在[service]下添加一行信息: Environment="V2RAY_VMESS_AEAD_FORCED=false" 7. 文件修改保存后,再执行 systemctl daemon-reload 8. 执行 systemctl restart v2ray
-
nginx rewrite导致的会话问题 异常问题之重新登录 某项目反馈编辑报表页面点击任意按钮会弹出重新登录，很是怪异。 排查 通过浏览器确定了复现问题时候ng的会话变了，那么可以知道后续转发到tomcat就会有新会话，导致重新登录 首先排查了ng配置，没有发现跳转到新tomcat的相关内容，主要是故障漂移等没有触发，那么会话变化不是这里影响 ng开启了upsteam的日志，发现在复现操作的时候有一个跳转，之后upstream地址都变了，于是找到前后相关的请求，并且在浏览器的请求中对比，发现某个请求的上下文路径掉了，于是有了以下解释： 正常情况下，ng的会话是带了上下文路径的，但是这里某个请求没有路径，导致请求到达ng之后会通过rewrite重写来重新定位到此路径上，于是就返回了一个新的会话id，并且分配一个新的tomcat，最终ng会话，tomcat会话都变了，需要重新登录 有了这个推论，那么解决的话只需要开发把这个路径丢失的路径补上就好了。但是和开发交流的过程中发现了另外一个问题，不管是路径丢失还是什么其他错误请求，是不应该覆盖我当前会话的，在这个问题中，用户没有登出的情况下，最终浏览器的会话被覆盖，这也是一个不能接受的问题！于是通过排查浏览器跳转，发现当浏览器给出任意错误路径，请求中是没有cookie，但是响应给出的cookie有异常，如下： 请求的路径不是我们所需的xnzhjtcx，但是cookie却给他设置了值，导致覆盖。根据结果猜测过程，说明此请求是到达了tomcat，才返回路径和cookie，所以当前ng所做的操作可能包括：本地重写了地址，然后发往后端，但用原地址返回。在发往后端的时候发现没有cookie，认为是新请求。 附重写过程中的302： 附ng配置： server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ /xnzhjtcx; } location /xnzhjtcx { proxy_pass http://lb; } } 如何解决 要解决上面任意地址导致cookie覆盖的问题，既然是重写导致，那就需要从这里解决，尝试了如下方案： 在rewrite后面写带根的路径，请求没有cookie，响应设置了路径和cookie，但浏览器没有显示重定向（结果不行） 附ng配置： # 比较奇怪的是此rewrite之后浏览器返回的是200，而不是30x server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ /xnzhjtcx/; } location /xnzhjtcx { proxy_pass http://lb; } } rewirte后面接绝对地址，请求没有cookie，响应没有返回cookie（结果可以） 附ng配置： # 此配置返回30x但没有任何cookie server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ http://61.242.140.32:9100/xnzhjtcx/; } location /xnzhjtcx { proxy_pass http://lb; } } 使用location来配合重写，请求没有cookie，响应没有cookie（结果可以） 附ng配置： location / { rewrite ^ /XTJG/ permanent; } 疑问： 重写只接路径返回了302和cookie，中间经历了什么 基于上面重写路径后面加了根截止返回了200和cookie，中间经历了什么 重写路径修改为ip+port+路径，返回了302，中间经历了什么 其他问题 最后，不管重写的时候是相对地址还是绝对地址，如果重写的时候不以根结束，但是请求是目录，这样会多跳转一次，修改为根结束，可看下图效果： 修改后可以看到重定向少一次
-
