The basic idea
The server configuration is as follows:
192.168.159.50 gitlab server (Gitlab, the memory is at least 5 G, or it can't run at all)
192.168.159.51 jenkins server (Jenkins-Server+Maven+JDK)
192.168.158.52 Test server (JDK)
1. jenkins installs maven dependencies
2. git installation
git install
Here first install a git on the jenkins machine
copyyum install -y git
3. Create a new task in Jenkins
Create a new task, here choose to build a maven project
Project name write first
3.1 git configuration
Enter the project address (that is, our project address on our own gitlab server)
Select the branch to see if yours is the master branch or the main branch
3.2 maven configuration
Write here the maven installation location on your jenkins server: mine is /usr/local/maven
3.3 pom.xml configuration
The location of pom.xml in the code repository
It also depends on the location of your pom.xml file. If it is not directly exposed on the outermost layer of the warehouse, such as in the demo directory, it should be written as demo/pom.xml
3.4 build
Click the build button
Look at the console output:
See the following page to indicate that the packaging is complete.
Dashboard can also see success here, and shows the time of success and failure
Go to the jenkins server to check whether the packaging is successful, as follows, you can see that the target directory and jar package indicate that the packaging is successful
Run the jar package to test it
copyjava -jar demo-0.0.1-SNAPSHOT.jar --server.port=8888
This is just a test project, there is only one Controller responsible for testing, the structure is roughly as follows
To test a simple business class, visit: http://192.168.159.51:8888/index/hello
There is no problem with the test of simple business classes. Such a simple automated deployment is complete, but we also want to automatically transfer the jar package to the test server (192.168.159.52) for execution instead of manually executing the jar package.
4. Automatically publish to the test server and execute it automatically (Test-server)
4.1 Install the Publish Over SSH plugin
First install a plugin on the jenkins server: Publish Over SSH
Select, click Install without restart
4.2 Modify Post Steps configuration
1. Since the test server has not been added yet, go to System Configuration to configure it first
2. In the Configure System menu, pull down and find Publish over SSH
3. Add a target server: here my test server IP is 192.168.159.52
4. Test whether the link is normal, and the lower left corner displays Success, indicating that the connection is ok
5. Go to Post Steps again, select Send files or execute commands over SSH
Here you can see the testserver we just added, as shown in the figure below.
6. Publish the configuration to the remote server
This allows the jar package on the remote test server to start 4.3 as a background process to execute the build
View console output
Check whether the jar package is delivered to the test server, as shown in the figure below.
Check whether the test server has executed the script to start the jar package (the script is the line we configured in Post Steps)
copyjps
It can be seen that the jar package has been executed.
Verify whether the business class is accessible, 192.168.159.52:8888/index/hello
Well, so far we have learned about the basic operations of continuous integration and continuous deployment. Of course, these are still superficial, and we will study them later.
4.4 publish over ssh optimization
1. Timeout mechanism
Be careful not to let the window get stuck when outputting commands, otherwise Jenkins will think that it has not been completed
2. shell log output
Modify the script after the jenkins build is successful to the following command:
copynohup java -jar /root/xxoo/demo*.jar >mylog.log 2>&1 &
Or the following can also
copynohup java -jar /root/xxoo/demo*.jar &>mylog.log &
Data flow redirection is to transfer the data that should appear on the screen after a command is executed to other places
Standard input (stdin): code is 0, use < or <<;
Standard output (stdout): code is 1, use > or >>;
Standard error output (stderr): code is 2, use 2> or 2>>
> Overwrite
>> Append write
> is a data flow operator, 2>&1 normal output and error output are all appended
Modify the configuration file of jenkins:
As you can see, 201 milliseconds, the time is shortened
4.5 Clean up before running
Configuration kills previously running processes
We need to write this x.sh script on the test server, the content of the script is as follows
#!/bin/bash
#Delete historical data
rm -rf xxoo
appname=$1
#Get the incoming parameters
echo "arg:$1"
#Get the running jar package pid
pid=`ps -ef | grep $1 | grep 'java -jar' | awk '{printf $2}'`
echo $pid
#If the pid is empty, prompt, otherwise, execute the kill command
if [ -z $pid ];
#Use -z to make a null value judgment
then
echo "$appname not started"
else
kill -9 $pid
echo "$appname stoping...."
check=`ps -ef | grep -w $pid | grep java`
if [ -z $check ];
then
echo "$appname pid:$pid is stop"
else
echo "$appname stop failed"
fi
fi4.6 Code submission test
Let's change the code and submit it to the GitLab server
Then execute the build
Visit: http://192.168.159.52:8888/index/hello to see if the build is successful
It is all manual here, which is quite troublesome. Later, it will be changed to automatic with a hook.
5. Episode
4.1 When building, an error is reported that jdk cannot be found
By default, when yum installs java, it will show that openjdk1.8 is installed, but in fact only jre is actually installed.
copyyum install -y java-devel
4.2 Aliyun image configuration
Modify /usr/local/maven/conf/settings.xml
<?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>${user.home}/.m2/repository</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
| Specifies a further group identifier to use for plugin lookup.
<pluginGroup>com.your.plugins</pluginGroup>
-->
<pluginGroup>org.mortbay.jetty</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>releases</id>
<username>ali</username>
<password>ali</password>
</server>
<server>
<id>Snapshots</id>
<username>ali</username>
<password>ali</password>
</server>
</servers>
<!-- mirrors
| This is a list of mirrors to be used in downloading artifacts from remote repositories.
|
| It works like this: a POM may declare a repository to use in resolving certain artifacts.
| However, this repository may have problems with heavy traffic at times, so people have mirrored
| it to several places.
|
| That repository definition will have a unique id, so we can create a mirror reference for that
| repository, to be used as an alternate download site. The mirror site will be the preferred
| server for that repository.
|-->
<mirrors>
<!-- mirror
| Specifies a repository mirror site to use instead of a given repository. The repository that
| this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
| for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
|
<mirror>
<id>mirrorId</id>
<mirrorOf>repositoryId</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://my.repository.com/repo/path</url>
</mirror>
-->
<mirror>
<!--This sends everything else to /public -->
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
</mirror>
<mirror>
<!--This is used to direct the public snapshots repo in the
profile below over to a different nexus group -->
<id>nexus-public-snapshots</id>
<mirrorOf>public-snapshots</mirrorOf>
<url>http://maven.aliyun.com/nexus/content/repositories/snapshots/</url>
</mirror>
<mirror>
<!--This is used to direct the public snapshots repo in the
profile below over to a different nexus group -->
<id>nexus-public-snapshots1</id>
<mirrorOf>public-snapshots1</mirrorOf>
<url>https://artifacts.alfresco.com/nexus/content/repositories/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>
<id>development</id>
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
<snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
<snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<profile>
<!--this profile will allow snapshots to be searched when activated-->
<id>public-snapshots</id>
<repositories>
<repository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>development</activeProfile>
<activeProfile>public-snapshots</activeProfile>
</activeProfiles>
<!-- activeProfiles
| List of profiles that are active for all builds.
|
<activeProfiles>
<activeProfile>alwaysActiveProfile</activeProfile>
<activeProfile>anotherAlwaysActiveProfile</activeProfile>
</activeProfiles>
-->
</settings>4.3 Build exception after configuring testserver
Exception when publishing, exception message Exec timed out or was interrupted after 120,001 ms
After referring to the articles of other big guys, you need to check the Exec in pty option
Then the rebuild was successful
