This article is SpringCloud combat (nine) -Docker automated continuous integration and deployment, to focus on the first article, please click the portal:
SpringCloud combat (eight) - Breaker monitoring and cluster monitor (Hystrix Dashboard)
We previously introduced Hystrix cluster monitoring. This paper describes SpringCloud constructed mirror and a distal deployment.
A, Docker Automated Deployment Profile
As the business grows, the demand began to increase, the size of each requirement, the development cycle, release time are inconsistent. Overlay system architecture based micro services, functions, corresponding to the number of services is also increasing, fast iterative function of size, require the deployment of more rapid and intelligent. Therefore, the traditional manual deployment has been beyond their grasp.
Continuous integration, continuous deployment, continuous development of interactive services for micro, the team is to improve the overall efficiency an integral part. Rational use of CI, CD can greatly improve production efficiency, but also improve the interactive quality of the product. This article does not do too much introduction three concepts, are interested can read this article: at The Product Managers' Guide to the Continuous Delivery and DevOps I think there will be some gains.
Second, prepare for work
The operating system is Centos7, we need to build a good advance Gitlab, Jenkins, and install Maven, Git, Jdk1.8, Docker, Nexus3, etc., I have these tools installed and deployed tutorials are written directly below the transfer belt door:
After the above-mentioned build a good environment, we can begin to configure Jenkins to automate the deployment of the relevant architecture is as follows:
First, before the user account name password to Jenkins, and then select the service modules need to build, click construct, Client-side case a request is sent to Jenkins, Jenkins will be pulled from the service Gitlab module code, then execution has configured Shell scripts, Shell scripts will first projects labeled Jar package, and then build the Jar package into a mirror, the mirror will then be uploaded to image warehouse Nexus, Jenkins after completing the upload image action will launch the code quality testing to Sonar request, upon request Sonar will pull the code from the gitlab, then pulled to code Bug, bad taste is detected, Sonar detection result will show on the monitor platform, quality inspection after completion of this step, Jenkins will pass SSH connection node and remote execution 192.168.3.206 pulling mirror, cluster deployment command, the user can view and manage the cluster through Portainerio.
Third, configure Jenkins
Details jenkins need to configure more, we do not miss any details Kazakhstan.
1, jenkins plug-in installed
First, we need to use to install some plug-ins, when Jenkins during installation page will automatically give you install some plug-ins, but we also need to use some other plug-ins, we find to be logged jenkins plug-in management, visit http: // 127.0.0.1:8371/ , as shown:
Find and click optional plug-ins tab, you can accurately find the plug from the filter input plug-in name box, and then install it, I have listed here a list of plug-ins need to be installed:
GitLab Plugin
Localization: Chinese (Simplified)
SSH plugin
Maven Integration plugin
JDK Tool Plugin
Git pluginVisual inspection should be complete, if the following steps I found pages and not the same, possibly because of missing plug-ins installed, you remind me directly in the comments section, I immediately completion.
After installing the plug-in tools that we find the global configuration (on the system administration page), as shown:
Click to go to enter the global tool configuration page, as shown here:
We here arranged on Maven, Jdk, Git, Docker, as shown:
Here Jdk, Maven need to configure the environment variables look, focus on preparations for configuration details above, then our global tool configuration is a good job.
Let us to configure the system settings, as shown:
系统设置这里我们配置两个地方就好了，一个是SSH，一个是Gitlab，SSH的配置是为了我们能够连接到远端主机进行镜像拉取和部署，Gitlab的配置是为了和Jenkins建立关联，如图所示：
这里SSH的凭证用远端机器的登录用户名和密码，Gitlab凭证用Gitlab登录后的token，如图所示：
到这里系统设置就配置完成了。
四、新建任务
Jenkins配置完之后，我们来新建一个任务。
我们新建一个Maven风格的项目，然后点击确定，进入到项目配置页面，如图所示：
这里我们需要配置Gitlab项目所在的地址，并且需要用token认证，Gitlab项目所在地址如图所示：
然后我们还需要写一下构建中和构建后执行的脚本。
Build阶段脚本如下：
$ clean install dockerfile:build dockerfile:pushPost Steps本地执行脚本如下：
docker rmi 192.168.3.202:8088/oascloud/eureka-server | truePost Steps远端执行脚本如下：
docker stop eureka-server | true
docker rm -v eureka-server | true
docker rmi 192.168.3.202:8088/oascloud/eureka-server | true
docker pull 192.168.3.202:8088/oascloud/eureka-server
docker run -itd -p 8761:8761 -v /usr/local/logs:/usr/local/logs --name eureka-server 192.168.3.202:8088/oascloud/eureka-server对照着上面的图就更清楚了。
五、eureka-server工程改造
然后我们需要创建一个springboot工程，这里我直接只用本专栏前面的eureka-server工程，需要做修改的地方是需要在工程的pom文件中增加docker插件配置
<build>
<plugins>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>1.3.6</version>
<configuration>
<repository>${docker.image.url}/${docker.image.prefix}/${project.artifactId}</repository>
<useMavenSettingsForAuth>true</useMavenSettingsForAuth>
<buildArgs>
<JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
</buildArgs>
</configuration>
</plugin>
</plugins>
</build>如果需要将eureka-server上传到远端仓库，则需要在pom文件中增加Nexus远端仓库配置（这里的id需要与maven setting中的<servers><server><id>保持一致，通过相同的id进行配置关联）
<!--定义snapshots库和releases库的nexus地址-->
<distributionManagement>
<repository>
<id>nexus-releases</id>
<url>
http://192.168.3.202:8083/repository/maven-releases/
</url>
</repository>
<snapshotRepository>
<id>nexus-snapshots</id>
<url>
http://192.168.3.202:8083/repository/maven-snapshots/
</url>
</snapshotRepository>
</distributionManagement>并且需要在pom文件的同级目录新建一个Dockerfile文件，内容如下：
FROM frolvlad/alpine-java:jdk8-slim
VOLUME /tmp
ARG JAR_FILE
ADD ${JAR_FILE} app.jar
RUN sh -c 'touch /app.jar'zz
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
ENV JAVA_OPTS="-server -Xms512m -Xmx512m -Xss512k"
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ]我们的SpringBoot工程就改造好了。
六、maven setting配置
我们需要修改maven的setting文件，需要增加我们的nexus上的镜像仓库地址，所以需要我们提前在nexus中新建一个docker仓库并获取到他的镜像仓库暴露端口，图示如下
然后我们拿到docker仓库的访问路径之后，去修改maven setting中的docker仓库配置。
setting配置内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!--
| This is the configuration file for Maven. It can be specified at two levels:
|
| 1. User Level. This settings.xml file provides configuration for a single user,
| and is normally provided in ${user.home}/.m2/settings.xml.
|
| NOTE: This location can be overridden with the CLI option:
|
| -s /path/to/user/settings.xml
|
| 2. Global Level. This settings.xml file provides configuration for all Maven
| users on a machine (assuming they're all using the same Maven
| installation). It's normally provided in
| ${maven.conf}/settings.xml.
|
| NOTE: This location can be overridden with the CLI option:
|
| -gs /path/to/global/settings.xml
|
| The sections in this sample file are intended to give you a running start at
| getting the most out of your Maven installation. Where appropriate, the default
| values (values used when the setting is not specified) are provided.
|
|-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>C:\Users\Lenovo\.m2\repo\</localRepository>
<!-- interactiveMode
| This will determine whether maven prompts you when it needs input. If set to false,
| maven will use a sensible default value, perhaps based on some other setting, for
| the parameter in question.
|
| Default: true
<interactiveMode>true</interactiveMode>
-->
<!-- offline
| Determines whether maven should attempt to connect to the network when executing a build.
| This will have an effect on artifact downloads, artifact deployment, and others.
|
| Default: false
<offline>false</offline>
-->
<!-- pluginGroups
| This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
| when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
| "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
|-->
<pluginGroups>
<pluginGroup>com.spotify</pluginGroup>
</pluginGroups>
<!-- proxies
| This is a list of proxies which can be used on this machine to connect to the network.
| Unless otherwise specified (by system property or command-line switch), the first proxy
| specification in this list marked as active will be used.
|-->
<proxies>
<!-- proxy
| Specification for one proxy, to be used in connecting to the network.
|
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
-->
</proxies>
<!-- servers
| This is a list of authentication profiles, keyed by the server-id used within the system.
| Authentication profiles can be used whenever maven must make a connection to a remote server.
|-->
<servers>
<!-- server
| Specifies the authentication information to use when connecting to a particular server, identified by
| a unique name within the system (referred to by the 'id' attribute below).
|
| NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
| used together.
|
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
-->
<!-- Another sample, using keys to authenticate.
<server>
<id>siteServer</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional; leave empty if not used.</passphrase>
</server>
-->
<server>
<id>nexus-releases</id>
<username>admin</username>
<password>admin123</password>
</server>
<server>
<id>nexus-snapshots</id>
<username>admin</username>
<password>admin123</password>
</server>
<server>
<id>192.168.3.202:8088</id>
<username>admin</username>
<password>admin123</password>
</server>
</servers>
<mirrors>
<mirror>
<id>maven-public</id>
<mirrorOf>*</mirrorOf>
<url>http://192.168.3.202:8083/repository/maven-public/</url>
</mirror>
</mirrors>
<!-- profiles
| This is a list of profiles which can be activated in a variety of ways, and which can modify
| the build process. Profiles provided in the settings.xml are intended to provide local machine-
| specific paths and repository locations which allow the build to work in the local environment.
|
| For example, if you have an integration testing plugin - like cactus - that needs to know where
| your Tomcat instance is installed, you can provide a variable here such that the variable is
| dereferenced during the build process to configure the cactus plugin.
|
| As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles
| section of this document (settings.xml) - will be discussed later. Another way essentially
| relies on the detection of a system property, either matching a particular value for the property,
| or merely testing its existence. Profiles can also be activated by JDK version prefix, where a
| value of '1.4' might activate a profile when the build is executed on a JDK version of '1.4.2_07'.
| Finally, the list of active profiles can be specified directly from the command line.
|
| NOTE: For profiles defined in the settings.xml, you are restricted to specifying only artifact
| repositories, plugin repositories, and free-form properties to be used as configuration
| variables for plugins in the POM.
|
|-->
<profiles>
<!-- profile
| Specifies a set of introductions to the build process, to be activated using one or more of the
| mechanisms described above. For inheritance purposes, and to activate profiles via <activatedProfiles/>
| or the command line, profiles have to have an ID that is unique.
|
| An encouraged best practice for profile identification is to use a consistent naming convention
| for profiles, such as 'env-dev', 'env-test', 'env-production', 'user-jdcasey', 'user-brett', etc.
| This will make it more intuitive to understand what the set of introduced profiles is attempting
| to accomplish, particularly when you only have a list of profile id's for debug.
|
| This profile example uses the JDK version to trigger activation, and provides a JDK-specific repo.
<profile>
<id>jdk-1.4</id>
<activation>
<jdk>1.4</jdk>
</activation>
<repositories>
<repository>
<id>jdk14</id>
<name>Repository for JDK 1.4 builds</name>
<url>http://www.myhost.com/maven/jdk14</url>
<layout>default</layout>
<snapshotPolicy>always</snapshotPolicy>
</repository>
</repositories>
</profile>
-->
<!--
| Here is another profile, activated by the system property 'target-env' with a value of 'dev',
| which provides a specific path to the Tomcat instance. To use this, your plugin configuration
| might hypothetically look like:
|
| ...
| <plugin>
| <groupId>org.myco.myplugins</groupId>
| <artifactId>myplugin</artifactId>
|
| <configuration>
| <tomcatLocation>${tomcatPath}</tomcatLocation>
| </configuration>
| </plugin>
| ...
|
| NOTE: If you just wanted to inject this configuration whenever someone set 'target-env' to
| anything, you could just leave off the <value/> inside the activation-property.
|
<profile>
<id>env-dev</id>
<activation>
<property>
<name>target-env</name>
<value>dev</value>
</property>
</activation>
<properties>
<tomcatPath>/path/to/tomcat/instance</tomcatPath>
</properties>
</profile>
-->
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.jdbc.url>
jdbc:mysql://192.168.3.203:3306/sonar
</sonar.jdbc.url>
<sonar.jdbc.driver>com.mysql.jdbc.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>root</sonar.jdbc.username>
<sonar.jdbc.password>aidclouddb@123!@#</sonar.jdbc.password>
<sonar.host.url>http://192.168.3.202:9000</sonar.host.url>
</properties>
</profile>
<profile>
<id>nexus</id>
<repositories>
<repository>
<id>nexus-public</id>
<url>http://192.168.3.202:8083/repository/maven-public/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>nexus-public</id>
<url>http://192.168.3.202:8083/repository/maven-public/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>nexus</activeProfile>
<activeProfile>sonar</activeProfile>
</activeProfiles>
<!-- activeProfiles
| List of profiles that are active for all builds.
|
<activeProfiles>
<activeProfile>alwaysActiveProfile</activeProfile>
<activeProfile>anotherAlwaysActiveProfile</activeProfile>
</activeProfiles>
-->
</settings>我们同时还需要修改远端主机上的docker配置文件，需要指定镜像仓库为nexus的地址，所以我们先登陆到远端主机，通过下面的命令找到配置文件
$ vim /etc/docker/daemon.json添加如下配置，将以下配置写入到文件中，保存并退出。
{
"insecure-registries":["192.168.3.202:8088"],
"registry-mirrors": ["http://hub-mirror.c.163.com"]
}其中192.168.3.202:8088就是我们nexus的docker仓库暴露出来的端口地址。
修改完之后我们就可以在Jenkins中执行构建，如图所示：
然后我们就成功构建了Springboot工程，访问远端主机的服务路径，我这里是 http://192.168.3.206:8761/，之后就成功显示出eureka服务端监控平台，说明我们已经成功自动化部署了一个eureka-server项目。
到此自动化部署和持续集成配置完成，我已经很尽力的在描述了，如果各位有不太清楚的地方，请在下方评论区留言，之后的文章我会讲自动化集群部署和管理。
