9090是什么端口(9090端口被占用)？如果你对这个不了解，来看看！
一行代码创建文件共享服务器,下面一起来看看本站小编我的都是你的给大家精心整理的答案，希望对您有帮助
9090是什么端口(9090端口被占用)1
说到局域网共享文件首先想到的是什么？飞秋？共享文件夹？
如果你本地有python环境的话，只需要一行代码，轻松实现局域网文件共享服务器。
具体怎么操作呢？
1、首先有安装python。
2、创建一个用于分享的文件夹。
3、在此文件夹打开命令行窗口，运行下面的命令。9090是端口，可以随意设置
python -m http.server 9090
4、ipconfig到自己的ip
5、将http://你的ip地址:9090/，例如http://192.168.1.1:9090/分享给你的小伙伴即可。
通过浏览器访问即可看到文件夹内所有的文件，效果如下，点击即可下载，同时命令行还会输出访问者ip、访问的路径和下载的文件。
9090是什么端口(9090端口被占用)2
Dockerfile是Docker用来构建镜像的文本文件,包括自定义的指令和格式。可以通过docker build命令从Dockerfile中构建镜像。用户可以通过统一的语法命令来根据需求进行配置，通过这份统一的配置文件，在不同的文件上进行分发，需要使用时就可以根据配置文件进行自动化构建，这解决了开发人员构建镜像的复杂过程。
Dockerfile的使用
Dockerfile描述了组装对象的步骤，其中每条指令都是单独运行的。除了FROM指令，其他每条命令都会在上一条指令所生成镜像的基础上执行，执行完后会生成一个新的镜像层，新的镜像层覆盖在原来的镜像之上从而形成了新的镜像。Dockerfile所生成的最终镜像就是在基础镜像上面叠加一层层的镜像层组建的。
Dockerfile指令
Dockerfile的基本格式如下:
# CommentINSTRUCTION arguments复制代码
在Dockerfile中,指令(INSTRUCTION)不区分大小写，但是为了与参数区分，推荐大写。Docker会顺序执行Dockerfile中的指令，第一条指令必须是FROM指令，它用于指定构建镜像的基础镜像。在Dockerfile中以#开头的行是注释，而在其他位置出现的#会被当成参数。
Dockerfile中的指令有FROM、MAINTAINER、RUN、CMD、EXPOSE、ENV、ADD、COPY、ENTRYPOING、VOLUME、USER、WORKDIR、ONBUILD,错误的指令会被忽略。下面将详细讲解一些重要的Docker指令。
FROM
格式: FROM <image> 或者 FROM <image>:<tag>
FROM指令的功能是为后面的指令提供基础镜像,因此Dockerfile必须以FROM指令作为第一条非注释指令。从公共镜像库中拉取镜像很容易,基础镜像可以选择任何有效的镜像。在一个Dockerfile中FROM指令可以出现多次,这样会构建多个镜像。tag的默认值是latest,如果参数image或者tag指定的镜像不存在，则返回错误。
ENV
格式: ENV <key> <value> 或者 ENV <key>=<value> ...
ENV指令可以为镜像创建出来的容器声明环境变量。并且在Dockerfile中，ENV指令声明的环境变量会被后面的特定指令(即ENV、ADD、COPY、WORKDIR、EXPOSE、VOLUME、USER)解释使用。
其他指令使用环境变量时，使用格式为$variable_name或者${variable_name}。如果在变量面前添加斜杠\可以转义。如\$foo或者\${foo}将会被转换为$foo和${foo},而不是环境变量所保存的值。另外，ONBUILD指令不支持环境替换。
COPY
格式: COPY <src> <dest>
COPY指令复制所指向的文件或目录,将它添加到新镜像中,复制的文件或目录在镜像中的路径是<dest>。<src>所指定的源可以有多个,但必须是上下文根目录中的相对路径。不能只用形如 COPY ../something /something这样的指令。此外,<src>可以使用通配符指向所有匹配通配符的文件或目录，例如，COPY home*
/mydir/ 表示添加所有以"hom"开头的文件到目录/mydir/中。
<dest>可以是文件或目录，但必须是目标镜像中的绝对路径或者相对于WORKDIR的相对路径(WORKDIR即Dockerfile中WORKDIR指令指定的路径,用来为其他指令设置工作目录)。若<dest>以反斜杠/结尾则其指向的是目录；否则指向文件。<src>同理。若<dest>是一个文件，则<src>的内容会被写到<dest>中；否则<src>指向的文件或目录中的内容会被复制添加到<dest>目录中。当<src>指定多个源时，<dest>必须是目录。如果<dest>不存在，则路径中不存在的目录会被创建。
ADD
格式：ADD <src> <dest>
ADD与COPY指令在功能上很相似，都支持复制本地文件到镜像的功能，但ADD指令还支持其他功能。<src>可以是指向网络文件的URL,此时若<dest>指向一个目录，则URL必须是完全路径，这样可以获得网络文件的文件名filename，该文件会被复制添加到<dest>/<filename>。比如 ADD
http://example.com/config.property / 会创建文件/config.property。
<src>还可以指向一个本地压缩归档文件，该文件会在复制到容器时会被解压提取，如ADD sxample.tar.xz /。但是若URL中的文件为归档文件则不会被解压提取。
ADD 和 COPY指令虽然功能相似，但一般推荐使用COPY,因为COPY只支持本地文件，相比ADD而言，它更加透明。
EXPOSE
格式: EXPOSE <port> [<port>/<protocol>...]
EXPOSE指令通知Docker该容器在运行时侦听指定的网络端口。可以指定端口是侦听TCP还是UDP，如果未指定协议，则默认值为TCP。这个指令仅仅是声明容器打算使用什么端口而已，并不会自动在宿主机进行端口映射,可以在运行的时候通过docker -p指定。
EXPOSE 80/tcpEXPOSE 80/udp复制代码
USER
格式: USER <user>[:<group] 或者 USER <UID>[:<GID>]
USER指令设置了user name和user group(可选)。在它之后的RUN,CMD以及ENTRYPOINT指令都会以设置的user来执行。
WORKDIR
格式: WORKDIR /path/to/workdir
WORKDIR指令设置工作目录，它之后的RUN、CMD、ENTRYPOINT、COPY以及ADD指令都会在这个工作目录下运行。如果这个工作目录不存在，则会自动创建一个。WORKDIR指令可在Dockerfile中多次使用。如果提供了相对路径，则它将相对于上一个WORKDIR指令的路径。例如
WORKDIR /aWORKDIR bWORKDIR cRUN pwd复制代码
输出结果是 /a/b/c
RUN
格式1： RUN <command> (shell格式)格式2： RUN ["executable", "param1", "param2"] (exec格式，推荐使用)
RUN指令会在前一条命令创建出的镜像的基础上创建一个容器，并在容器中运行命令，在命令结束运行后提交容器为新镜像，新镜像被Dockerfile中的下一条指令使用。
RUN指令的两种格式表示命令在容器中的两种运行方式。当使用shell格式时，命令通过/bin/sh -c运行。当使用exec格式时，命令是直接运行的，容器不调用shell程序，即容器中没有shell程序。exec格式中的参数会被当成JSON数组被Docker解析，故必须使用双引号而不能使用单引号。因为exec格式不会在shell中执行，所以环境变量的参数不会被替换。
比如执行RUN ["echo", "$HOME"]指令时，$HOME不会做变量替换。如果希望运行shell程序，指令可以写成 RUN ["/bin/bash", "-c", "echo", "$HOME"]。
CMD
CMD指令有3种格式。
格式1：CMD <command> (shell格式)格式2：CMD ["executable", "param1", "param2"] (exec格式，推荐使用)格式3：CMD ["param1", "param2"] (为ENTRYPOINT指令提供参数)
CMD指令提供容器运行时的默认值，这些默认值可以是一条指令，也可以是一些参数。一个Dockerfile中可以有多条CMD指令，但只有最后一条CMD指令有效。 CMD ["param1",
"param2"]格式是在CMD指令和ENTRYPOINT指令配合时使用的，CMD指令中的参数会添加到ENTRYPOING指令中.使用shell和exec格式时，命令在容器中的运行方式与RUN指令相同。
不同之处在于，RUN指令在构建镜像时执行命令，并生成新的镜像；CMD指令在构建镜像时并不执行任何命令，而是在容器启动时默认将CMD指令作为第一条执行的命令。如果用户在命令行界面运行docker run命令时指定了命令参数，则会覆盖CMD指令中的命令。
ENTRYPOINT
ENTRYPOINT指令有两种格式。
格式1：ENTRYPOINT <command> (shell格式)格式2：ENTRYPOINT ["executable", "param1", "param2"] (exec格式，推荐格式)
ENTRYPOINT指令和CMD指令类似，都可以让容器在每次启动时执行相同的命令，但它们之间又有不同。一个Dockerfile中可以有多条ENTRYPOINT指令，但只有最后一条ENTRYPOINT指令有效。
当使用Shell格式时，ENTRYPOINT指令会忽略任何CMD指令和docker run命令的参数，并且会运行在bin/sh -c中。这意味着ENTRYPOINT指令进程为bin/sh -c的子进程,进程在容器中的PID将不是1，且不能接受Unix信号。即当使用docker stop <container>命令时，命令进程接收不到SIGTERM信号。
推荐使用exec格式，使用此格式时，docker run传入的命令参数会覆盖CMD指令的内容并且附加到ENTRYPOINT指令的参数中。从ENTRYPOINT的使用中可以看出，CMD可以是参数，也可以是指令，而ENTRYPOINT只能是命令；另外，docker run命令提供的运行命令参数可以覆盖CMD,但不能覆盖ENTRYPOINT。
Dockerfile实践心得
使用标签
给镜像打上标签，有利于帮助了解进镜像功能
谨慎选择基础镜像
选择基础镜像时，尽量选择当前官方镜像库的肩宽，不同镜像的大小不同，目前Linux镜像大小由如下关系:
busybox < debian < centos < ubuntu
同时在构建自己的Docker镜像时,只安装和更新必须使用的包。此外相比Ubuntu镜像，更推荐使用Debian镜像，因为它非常轻量级(目前其大小是在100MB以下),并且仍然是一个完整的发布版本。
充分利用缓存
Docker daemon会顺序执行Dockerfile中的指令，而且一旦缓存失效，后续命令将不能使用缓存。为了有效地利用缓存，需要保证指令的连续性，尽量将所有Dockerfile文件相同的部分都放在前面，而将不同的部分放到后面。
正确使用ADD与COPY命令
当在Dockerfile中的不同部分需要用到不同的文件时，不要一次性地将这些文件都添加到镜像中去，而是在需要时添加，这样也有利于重复利用docker缓存。另外考虑到镜像大小问题，使用ADD指令去获取远程URL中的压缩包不是推荐的做法。应该使用RUN wget或RUN curl代替。这样可以删除解压后不在需要的文件，并且不需要在镜像中在添加一层。
错误做法:
ADD http://example.com/big.tar.xz /usr/src/things/RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/thingsRUN make -C /usr/src/things all复制代码
正确的做法:
RUN mkdir -p /usr/src/things \
&& curl -SL http://example.com/big.tar.xz \
tar -xJC /usr/src/things \
&& make -C /usr/src/things all复制代码
RUN指令
在使用较长的RUN指令时可以使用反斜杠\分隔多行。大部分使用RUN指令的常见是运行apt-wget命令，在该场景下请注意以下几点。
不要在一行中单独使用指令RUN apt-get update。当软件源更新后，这样做会引起缓存问题，导致RUN apt-get install指令运行失败。所以,RUN apt-get update和RUN apt-get install应该写在同一行。比如 RUN apt-get update && apt-get install -y package-1
package-2 package-3
避免使用指令RUN apt-get upgrade 和 RUN apt-get dist-upgrade。因为在一个无特权的容器中，一些必要的包会更新失败。如果需要更新一个包(如package-1)，直接使用命令RUN apt-get install -y package-1。
CMD和ENTRYPOINT命令
CMD和ENTRYPOINT命令指定是了容器运行的默认命令，推荐二者结合使用。使用exec格式的ENTRYPOINT指令设置固定的默认命令和参数，然后使用CMD指令设置可变的参数。
比如下面这个例子:
FROM busyboxWORKDIR /appCOPY run.sh /appRUN chmod +x run.shENTRYPOINT ["/app/run.sh"]CMD ["param1"]复制代码
run.sh内容如下:
#!/bin/shecho "$@"复制代码
运行后输出结果为param1, Dockerfile中CMD和ENTRYPOINT的顺序不重要(CMD写在ENTRYPOINT前后都可以)。
当在windows系统下build dockerfile你可能会遇到这个问题
standard_init_linux.go:207: exec user process caused "no such file or directory"复制代码
这是因为sh文件的fileformat是dos,这里需要修改为unix,不需要下载额外的工具，一般我们机器上安装了git会自带git bash,进入git bash,使用vi 编辑，在命令行模式下修改(:set ff=unix)。
不要再Dockerfile中做端口映射
使用Dockerfile的EXPOSE指令，虽然可以将容器端口映射在主机端口上，但会破坏Docker的可移植性，且这样的镜像在一台主机上只能启动一个容器。所以端口映射应在docker run命令中用-p 参数指定。
# 不要再Dockerfile中做如下映射EXPOSE 80:8080# 仅暴露80端口,需要另做映射EXPOSE 80复制代码
实践Dockerfile的写法
Java 服务的DockerFile
FROM openjdk:8-jre-alpineENV spring_profiles_active=devENV env_java_debug_enabled=falseEXPOSE 8080WORKDIR /appADD target/smcp-web.jar /app/target/smcp-web.jarADD run.sh /appENTRYPOINT ./run.sh复制代码
可以看到基础镜像是openjdk,然后设置了两个环境变量,服务访问端口是9090(意味着springboot应用中指定了server.port=8080),设置了工作目录是/app。通过ENTRYPOINT设定了启动镜像时要启动的命令(./run.sh)。这个脚本中的内容如下:
#!/bin/sh# Set debug options if requiredif [ x"${env_java_debug_enabled}" != x ] && [ "${env_java_debug_enabled}" != "false" ]; then
java_debug_args="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"fi# ex: env_jvm_flags="-Xmx1200m -XX:MaxRAM=1500m" for productionjava $java_debug_args $env_jvm_flags -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -jar target/smcp-web.jar复制代码
如果我们要指定jvm的一些参数,可以通过在环境变量中设置env_jvm_flags来指定。
Maven Dockerfile
maven的Dockerfile也写的很好，这里我发上来也给大家参考下
FROM openjdk:8-jdkARG MAVEN_VERSION=3.6.3ARG USER_HOME_DIR="/root"ARG SHA=c35a1803a6e70a126e80b2b3ae33eed961f83ed74d18fcd16909b2d44d7dada3203f1ffe726c17ef8dcca2dcaa9fca676987befeadc9b9f759967a8cb77181c0ARG BASE_URL=https://apache.osuosl.org/maven/maven-3/${MAVEN_VERSION}/binariesRUN mkdir -p /usr/share/maven /usr/share/maven/ref \
&& curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz \
&& echo "${SHA}
/tmp/apache-maven.tar.gz"
sha512sum -c - \
&& tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1 \
&& rm -f /tmp/apache-maven.tar.gz \
&& ln -s /usr/share/maven/bin/mvn /usr/bin/mvnENV MAVEN_HOME /usr/share/mavenENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"COPY mvn-entrypoint.sh /usr/local/bin/mvn-entrypoint.shCOPY settings-docker.xml /usr/share/maven/ref/ENTRYPOINT ["/usr/local/bin/mvn-entrypoint.sh"]CMD ["mvn"]复制代码
可以看到它是基于openjdk这个基础镜像来创建的，先去下载maven的包，然后进行了安装。 然后又设置了MAVEN_HOME和MAVEN_CONFIG这两个环境变量，最后通过mvn-entrypoing.sh来进行了启动。
前端服务的两阶段构建
我有一个前端服务，目录结构如下：
nbsp;ls frontend/myaccount/
resources/
third_party/复制代码
myaccount目录下是放置的js,vue等，resources放置的是css,images等。third_party放的是第三方应用。
这里采用了两阶段构建，即采用上一阶段的构建结果作为下一阶段的构建数据
FROM node:alpine as builderWORKDIR '/build'COPY myaccount ./myaccountCOPY resources ./resourcesCOPY third_party ./third_partyWORKDIR '/build/myaccount'RUN npm installRUN npm rebuild node-sassRUN npm run buildRUN ls /build/myaccount/distFROM nginxEXPOSE 80COPY --from=builder /build/myaccount/dist /usr/share/nginx/html复制代码
需要注意结尾的 --from=builder这里和开头是遥相呼应的。
总结
我相信看完dockerfile指令,你看任何一个dockerfile应该都没有太大问题,不记得的命令回来翻一下就行了。如果你觉得还可以，关注下哟。
作者：think123链接：https://juejin.im/post/5e60745d518825492e4965ed
9090是什么端口(9090端口被占用)3
【 ①Java代码自动部署-总结简介】
代码部署是每一个软件开发项目组都会有的一个流程，也是从开发环节到发布功能必不可少的环节。对于Java开发者来说，Java代码的发布部署也是经常需要做的一件事，特别是互联网公司。代码的发布上线关系到保证生产环境能够正常启动及功能是否能正常运行，所以代码部署在整个项目开发周期还是占据很重要的地位。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
由于本人近期在学习Java代码自动发布相关的知识，此系列文章是对此次学习到的知识进行巩固和总结；同时，也希望能够帮助到和我一样对此方面知识感兴趣的同行们。言不多说，直接进入真题。下面针对此次系列文章做一个简要的概述。
1、学习代码自动部署的目的
高效且简化代码的部署发布
2、使用的相关工具及技术
1、 CentOS操作系统（可以使用虚拟机安装Linux系统）
2、 Maven
3、 Git
4、 Shell脚本
5、 Jenkins
3、学习代码自动发布相关技术的顺序
阶段1：
优点：部署流程简单方面，开发完成后开发人员在开发环境即可进行代码部署上线。
缺点：发布流程粗糙，代码部署不够严谨，不建议生产环境使用此方式。
阶段2：
优点：由Git进行项目版本管理，降低了代码发布的风险，发布过程有运维人员进行发布。
缺点：由于代码的发布由运维人员发布，需开发人员配合进行代码发布部署，与发布部署不成功，得由开发人员查找问题，增加了部署复杂性。
阶段3：
优点：由Jenkins工具进行代码的发布部署，规范了代码的发布流程，提供可视工具监听整个发布流程等。
缺点：对技术要求更高了，需要了解Jenkins工具，会编写Shell脚本等。
4、Java代码自动部署总结分为以下系列
①总结简介
②使用Maven进行代码部署
③使用Shell进行代码部署
④使用Jenkins进行代码部署
⑤课程总结及心得
【 ②使用Maven进行代码部署】
在使用maven进行代码发布的时候，需要用Maven工具的相关插件将需要部署的项目发布到指定的服务器的部署目录中。
在学习此技术时，我用的的是一个秒杀项目的ssm版，大家在学学习此技术的时候可以用简单一点的Maven项目进行测试。因本项目是学习如何进行部署项目技术的，本次就针对具体项目进行介绍。
1、 使用Maven进行部署项目要求
1) 项目本身属于Maven项目（必要条件）
2) 需要部署的是war包
3) 引入插件
在需要部署的项目的pom,xml文件中引入tomcat插件,在project->build-> plugins节点引入tomcat插件。
<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<!-- 引入tomcat插件 -->
<artifactId>tomcat7-maven-plugin</artifactId>
<configuration>
<!-- <url>http://localhost:8080/manager</url> --> <!-- tomcat6部署管理路径 -->
<url>http://192.168.25.133:8080/manager/text</url> <!-- tomcat7部署管理路径 -->
<!-- tomcat控制台账号 -->
<username>admin</username> <!-- tomcat的管理员账号 -->
<!-- tomcat控制台密码-->
<password>admin</password>
<!-- 本地运行时指定的端口号 -->
<port>8080</port>
<path>/seckill-manager</path> <!-- 部署路径 -->
<charset>UTF-8</charset>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
4) 执行Maven的redeploy操作
执行的命令：tomcat7:redeploy
在eclipse下配置的命令如下：
2、需要注意的问题点
1、在将项目发布到远程Tomcat时需要启动远程Tomcat管理控制台账号
开启tomcat管理控制台账号地址为：Tomcat安装目录/conf/tomcat-users.xml文件
在tomcat-users.xml文件中需要配置允许访问纯文本接口权限，以便maven的tomat插件能够通过此方式进行部署项目。
在tomcat-users节点新增role属性和user属性，如下：
<role rolename="manager-script" />
<role rolename="manager-gui"/>
<user username="admin" password="admin" roles="manager-gui,manager-script"/>
解释：给账号admin配置manager-script及manager-gui权限
Tomcat角色解释图:
2、在需要远程发布到的目标Tomcat应该是运行状态，保证Maven的tomcat插件能够访问到目标Tomcat完成项目的部署。
【③使用Shell进行代码部署】
在使用Shell脚本进行重新部署项目时，需要掌握Shell脚本的编写，Shell脚本需要完成以下功能：
1、 将代码clone到服务器指定目录
2、 根据pom.xml文件将代码打包成war包
3、 将war发布到指定服务器
环境要求：
1、 安装Maven并配置环境变量
2、 Git客户端，并配置环境变量
3、 熟悉Shell脚本相关知识
1、编写Shell脚本
在Linux的指定目录新建shell脚本,我是在项目的专用tomcat根目录新建了shell脚本，方便进行tomcat集群部署操作。脚本内容如下：
#!/bin/bash
#shell功能概要:seckill的service提供者构建shell
#发布service提供者的服务器的进程名
serverName="seckill_provider"
#获取发布service提供者的服务器的进程PID
PID=$(ps -ef
grep $serverName
grep -v grep
awk '{ print $2 }')
#java代码本地仓库地址
javaBaseSrc="/opt/java_project_src/"
#项目路径
javaProjectSrc="sekill/seckill-manager/seckill-service/target/seckill-service.war"
#发布的tomcat集群，数组方式存储
projectServicersPath=(/opt/seckill-tomcat/seckill-tomcat-02 /opt/seckill-tomcat/seckill-tomcat-03)
projectName="sekill"
#循环强制停止指定tomcat
for var in ${PID};
do
echo "准备强制停止PID:$var"
kill -9 $var
done
echo "kill $serverName sucess"
#切换到git本地仓库目录
cd $javaBaseSrc
#删除仓库库中代码
rm -rf $projectName
echo "从/opt/java_project_src仓库中删除项目$projectName成功"
#从远程仓库下载代码，因涉及到账户信息，此处更改为描述信息
git clone 远程git仓库项目URL
cd $javaBaseSrc/sekill/seckill-manager
#安装项目并跳过测试
mvn -Dmaven.test.skip=true clean install
#判断执行上面mvn操作的返回值是否为0
if [ $? -ne 0 ]
then
echo "构建失败，请查看代码问题！"
exit 1;
fi
#循环将项目部署到集群tomcat中
for projectServicer in ${projectServicersPath[@]}
do
cp $javaBaseSrc$javaProjectSrc $projectServicer/webapps
echo "$projectServicer 代码发布成功!"
sh $projectServicer/bin/startup.sh
if [ $? -ne 0 ]
then
echo "$projectServicer 启动失败"
exit 1;
else
echo "$projectServicer 启动成功";
fi
done
echo "启动 $serverName 成功"
2、需要注意的问题点
在编写Shell脚本时需要知道每句Shell的含义，尽可能将所有问题点都能考虑到，比如：
a) 强杀进程问题
进行PID=$(ps -ef
grep $serverName
grep -v grep
awk '{ print $2 }')时，要确定查询的只是目标Tomcat的进程pid，防止在后续强制停止时将其他应用Tomcat误强行停止，这里建 议给每一个目标Tomcat设置指定的进程名，设置方法为：
在指定tomcat的bin/ setclasspath.sh文件中找到if [ -z "$_RUNJAVA" ]判断语句，进行以下设置即可
if [ -z "$_RUNJAVA" ]; then
#_RUNJAVA="$JRE_HOME"/bin/java
#注释tomcat默认进程名，设置指定的进程名称，集群的时候可以进行编号01,02,03设置
cp "$JAVA_HOME/bin/java" "$JAVA_HOME/bin/seckill_consumer01"
_RUNJAVA="$JRE_HOME/bin/seckill_consumer01"
fi
b) Shell脚本尽可能通用
我吸取了现在比较流行的一句话“约定大于配置”及平时所看所想，在编写Shell脚本时可以提取可变或多处使用的变量，使整个Shell脚本尽可能提炼成通用，以便类似项目部署可以使用现有脚本进行更改后使用，减少重新编写新Shell脚本带来不可控的问题。
【④使用Jenkins进行代码部署】
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
在使用Jenkins进行项目部署时，需要将Jenkins的war包放在服务器的指定位置。Jenkins的war的下载可以去Jenkins的官网进行下载。
使用Jenkins进行代码部署时需要的环境支持：
1、安装Maven并配置环境变量
2、Git客户端，并配置环境变量
3、熟悉Shell脚本相关知识
4、对Jenkins有一定了解
使用Jenkins进行代码部署如下：
1、 启动Jenkins工具
在jenkins.war目录执行以下命令操作启动Jenkins工具。
[xiongshx@localhost jenkins]$ java -jar jenkins.war
Jenkins工具初始化的一些操作可以百度或者去Jenkins查看可以参考【https://www.cnblogs.com/cheng95/p/6542036.html】
初始化后需要进行的配置
工具配置
【系统管理】->【全局工具配置】
Jdk配置：
Git配置：
Maven配置：
2、 新建任务
需要注意的点：
1、填写源码仓库地址
2、构建时操作及自定义shell代码
Shell代码如下：
#!/bin/bash
#shell功能概要:seckill的Web消费者构建shell
#引用的技术有：git、maven
#发布web消费者的服务器的进程名
serverName="seckill_consumer"
#获取发布web消费者的服务器的进程PID
PID=$(ps -ef
grep $serverName
grep -v grep
awk '{ print $2 }')
#需要在脚本开始时添加export BUILD_ID=dontKillMe。
#原因：因为Jenkins执行完当前任务之后需要执行下一个任务,此时Jenkins会直接把tomcat进程杀掉，
#因此在脚本中编写的tomcat启动命令是不会执行的。
export BUILD_ID=dontKillMe
#java代码本地仓库地址
javaBaseSrc="/home/xiongshx/.jenkins/workspace/"
#项目路径
javaProjectSrc="seckill/seckill-web/target/seckill-web.war"
#发布的tomcat
projectServicersPath=(/opt/seckill-tomcat/seckill-tomcat-01)
projectName="sekill"
for var in ${PID};
do
echo "准备强制停止PID:$var"
kill -9 $var
done
echo "kill $serverName sucess"
#如果上一个命令执行失败，执行的状态码不为0
if [ $? -ne 0 ]
then
echo "构建失败，请查看代码问题！"
exit 1;
fi
for projectServicer in ${projectServicersPath[@]}
do
cp $javaBaseSrc$javaProjectSrc $projectServicer/webapps
echo "$projectServicer 代码发布成功!"
/bin/bash $projectServicer/bin/startup.sh
if [ $? -ne 0 ]
then
echo "$projectServicer 启动失败"
exit 1;
else
echo "$projectServicer 启动成功";
fi
done
echo "启动 $serverName 成功"
3、 启动项目
【立即构建】->【点击构建的链接】->【控制台输出】即可查看整个代码部署过程中的信息输出。
4、需要注意的问题点：
1、Jenkins的war问题
最简单jenkins.war的启动方式是在控制台终端执行命令：java -jar jenkins.war；但是此方法会占用一个终端窗口，且关闭后Jenkins工具就不能进行访问，可以使用命令进行后台执行，命令如下：
nohup java -jar jenkins.war --httpPort=9090 > /dev/null 2>&1 &
命令解释：
nohup 后台执行操作
--httpPort=9090表示指定占用9090端口进行访问
> /dev/null 将日志输出到/dev/null
2>&1 & 用来将标准错误2重定向到标准输出1中的此处1前面的&就是为了让bash将1解释成标准输出而不是文件1。最后一个&，则是让bash在后台执行。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
另外一种更优雅的方式是使用Shell脚本控制Jenkins工具的启动、停止、重启等操作。
样例如下：
#!/bin/bash
#功能描述：用于Jenkins运行，停止，重启
#将此脚本放在jenkins.war同级目录
#获取Jenkins的进程id
pid=$(ps -ef
grep "jenkins.war"
grep -v grep
awk '{print $2}')
#jenkins默认端口号
jekinsDefaultPort=9090
#如果用户有自定义端口号，则使用用户自定义的端口号启动jenkins
if [ x$2 != x ]
then
jekinsDefaultPort=$2
fi
#启动jenkins
start(){
if [ x$pid != x ]
then
echo "jenkins已经是启动状态..."
exit 1
fi
nohup java -jar jenkins.war --httpPort=$jekinsDefaultPort > /dev/null 2>&1 &
echo "jenkins启动成功，端口号为：$jekinsDefaultPort..."
return $?
}
stop(){
echo "准备停止jenkins..."
if [ x$pid != x ]
then
kill -9 $pid
echo "jenkins已经停止..."
exit $?
else
echo "jenkins的进程id不存在，无法进行停止操作..."
exit 1
fi
}
# 重新加载Jenkins
restart() {
stop
start
echo "jenkins重新加载成功，jekins端口号为：$jekinsDefaultPort..."
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo $"提示: 请在jenkins后输入以下参数:{start|stop|restart} 端口号（不填写时默认端口9090）"
exit 1
esac
exit $?
2、Jenkins中自定义Shell问题
#需要在脚本开始时添加export BUILD_ID=dontKillMe。
#原因：因为Jenkins执行完当前任务之后需要执行下一个任务,此时Jenkins会直接把tomcat进程杀掉，#因此在脚本中编写的tomcat启动命令是不会执行的。
export BUILD_ID=dontKillMe
【⑤课程总结及心得】
学习代码自动部署的缘由一来是由于在平时开发过程中经常会遇到代码部署的环节，希望通过学习此知识后，如果后续有机会针对自己学会的方案进行评估后简化项目中的项目部署，二来是巩固自己近期来学习到的一些知识，通过层层迭进来学习代码的自动部署方案。虽然目前自己的这些流程方案可能还有所欠缺，且还没有经过实际项目考验，但能学到很多实际的知识也足够了，比如Maven相关知识、Shell相关知识以及Jenkins相关知识，这些是只能通过自己动手慢慢去实践才能获取到的经验。如果对代码部署也感兴趣且觉得我写的东西对你有帮助的同行们，我建议可以按照我的学习步骤去学习自动构建技术。
此系列文章可能写的还不够好，并且很多地方我都进行了一些精简。其实我希望给大家提供的是一个思路。比如学习整个项目部署的思路，由Maven插件部署到Shell脚本部署再到Jenkins部署项目，其实越到后面，Jenkins只是对一些操作做了集成封装，但是我觉得如果我们能从最基本做起，了解其中的流程及原理，真正使用Jenkins进行代码部署时，我们能知道所以然，那样我觉得可以更好的使用Jenkins工具。另外，比如Jenkins.war的启动，我很自然的想到使用Shell脚本将它的启动、运行、重启等命令进行封装，并把它设置为开机启动，我觉得这是一个优雅的方式，以后有类似的情况时，我也会考虑这么做。
本文中还有一些没有提及和没有实现的内容，我希望以及对此技术感兴趣的同行们，都可以发散思维，把事情尽善尽美，做到最优做好。通过编写此系列文章，我巩固了我此类技术的知识的了解以及拓展，也希望能够帮助到大家。如果大家在学习此类技术上遇到疑惑或问题，可以百度查看解决办法，也可以给我留言进行探讨。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
最后，希望所有人在不久的将来都能遇到一个优秀的自己。
