Docker+gitlab+jenkins builds automated deployment from scratch

Preface:

After several days of study and my own understanding, I have compiled a tutorial on automatic deployment of Docker+Jenkins. If there are any deficiencies, please give me more advice. Thank you!

Advantages of Docker:

Docker allows developers to package their applications and dependent packages into a portable container and then publish it to any popular Linux machine to achieve virtualization. Docker has changed the way virtualization is done, allowing developers to directly put their own results into Docker for management. Convenience and speed are already the biggest advantages of Docker. Tasks that used to take days or even weeks can now be completed in seconds using Docker containers.
Structure: Client → Docker_Host (host) → Warehouse Three concepts container → image → warehouse

Why use Jenkins:

For traditional deployment projects, when the project is completed, we need to pull the code from the code repository to the local, complete the packaging, upload it to the server, and then configure the project's operating environment and start it. This obviously has a flaw. Some bugs that exist during development cannot be discovered immediately, which leads to the risk of a chain reaction when fixing the bugs later. Moreover, after we modify the code, we often need to repackage it, upload it to the server, and then run it. When there are many projects, such repetitive mechanical operations make us feel overwhelmed.
After we use Jenkins, we can truly achieve automated deployment. When our code is updated and pushed to the code repository, we only need to click on the build project in the Jenkins visual interface. Jenkins will automatically pull the code according to the repository address we configured, automatically package it, and run it to complete the automated deployment.

1. Install Docker

Docker requires the CentOS kernel version to be above 3.10. Check the prerequisites on this page to verify whether your CentOS version supports Docker.

1. Check your current kernel version with the uname -r command

uname -r

2. Log in to CentOS with root privileges. Make sure the yum package is updated to the latest version.

yum -y update

3. Uninstall the old version (if you have installed an old version)

yum remove docker docker-common docker-selinux docker-engine

4. Install the required packages. yum-util provides the yum-config-manager function. The other two are dependencies of the devicemapper driver.

yum install -y yum-utils device-mapper-persistent-data lvm2

5. Set up the yum source

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

6. You can view all docker versions in all repositories and select a specific version to install

yum list docker-ce --showduplicates | sort -r

7. Install Docker

sudo yum install -y docker-ce #Since only the stable repository is enabled by default in the repo, the latest stable version 18.03.1 is installed here

8. Start and add to boot

systemctl start docker //Start docker
systemctl enable docker //Set to start at boot

9. Verify whether the installation is successful (the presence of client and service parts indicates that the Docker installation and startup are successful)

docker version

2. Install Jenkins with Docker

1. Search for the Jenkins image in the repository

docker search jenkins        

jenkins indicates the image name you want to search for. The images containing jenkins in the DESCRIPTION will also be displayed.

2. Pull the jenkins image to the local images

docker pull jenkins/jenkins

Note that the version pulled here is jenkins/jenkins, because the previous jenkins version was only 2.60, which caused the installation of the jenkins plug-in to fail. You can specify the version when pulling, for example, docker pull java:8 means that the pulled java version is 8; if you do not specify a version, the default is the latest version.

3. Start the Jenkins container

docker run --name myjenkins -d -p 8081:8080 -p 8085:8085 jenkins/jenkins

–name myjenkins specifies the container name as myjenkins
-d means running in the background
-p 8081: 8080 indicates the mapping between the Docker Host port (the host running Docker) and the port running in the Docker container.
8081 is the port of DockerHost, and 8080 is the port in the container. External access to 8081 can access port 8080 of the Docker container.
jenkins/jenkins means the started image is jenkins/jenkins. You can view the local image through docker images.

illustrate:
1. The ports in the container cannot be directly accessed from the outside because the port mapping between the Docker Host and the container needs to be configured. Multiple mappings can be configured;
Since the project needs to be deployed later, configure the project's port number -p 8085:8085 in advance. You can also leave it unconfigured and modify the port mapping file later.
2. In fact, we can also omit the second step of pull operation and directly start a container. Docker will first check whether there is this image in the local images. If not, it will go to the DockerHub warehouse to download it.

3. Initialization operation of logging into Jenkins

1. Access the Jenkins interface. For example, if my virtual machine IP is 192.168.199.188, enter 192.168.199.188:8081 and press Enter to display the following interface.

Enter the container where Jenkins is installed

docker exec -it myjenkins bash // Enter the specified container, myjenkins represents the name we specified for the container when we started the container cat /var/jenkins_home/secrets/initialAdminPassword` // View the password, copy the password and paste it into the text box

Operation diagram:

2. Install the plug-in. Here we install the plug-in recommended by Jenkins.

Click to install the recommended plugin:

3. The installation is in progress. Please wait for a moment. Click Continue after the installation is complete.

4. Create an administrator user, or you can directly use the admin account to continue:

5. The instance configuration is saved directly:

6. Start using Jenkins:

7. Go to the Jenkins homepage:

4. Global tool configuration (configuration environment)

Click System Management - Global Tool Configuration

1. Configure JDK: Cancel automatic installation (the JDK environment is usually installed in the container), enter the docker container, use echo $JAVA_HOME to get the JDK installation path, and copy the path to the JAVA_HOME text box

2. Configure Maven: Specify a name, install automatically, and click Save

5. Install the Maven plugin Click System Management – ​​Plugin Management

6. Create a new task to complete automated deployment

1. Return to the home page, click New task, and build a Maven project

2. Click OK and return to the home page. We found an additional task named SpringBoot_AutoTest1 (the task above is the previous one, so ignore it)

3. Click the project name SpringBoot_AutoTest1 --> Click Configure

3.1 Source code management (configure the git repository address, Jenkins will pull the code from the remote repository):

3.2 Build configuration (Jenkin will automatically execute the packaging command after pulling the code):

3.3 Configure the shell script (after Jenkins packaging is completed, the shell script is automatically executed to start the project and realize automatic deployment), and then save it:

Attached shell script:

#!/bin/bash
# #!/bin/bash means that this script uses /bin/bash to interpret and execute. Among them, #! is a special indicator, followed by the shell path that interprets this script. Bash is just one type of shell. There are many other shells, such as: sh, csh, ksh, tcsh, ...
# #!/bin/bash can only be placed on the first line. If there is #! after it, it can only be regarded as a comment.

#Service name SERVER_NAME = SpringBoot_AutotTest

#Source jar path, after mm packaging is completed, the jar package name in the target directory can also be selected as a war package, and the war package can be moved to Tomcat.
JAR_NAME=jekins-0.0.1-SNAPSHOT


#target package generates the directory of the jar package JAR_PATH=/var/jenkins_home/workspace/SpringBoot_AutotTest/target # Based on the specific packaging location, you can build the project once and view the packaged directory through the log #After packaging, move the iar package to the directory where the jar package is run JAR_WORK_PATH=/var/jenkins_home/workspace/SpringBoot_AutotTest/target

echo "Query process id-->$SERVER_NAME"
PID=`ps -ef | grep "$SERVER_NAME" | awk '{print $2}'`
echo "Get process ID: $PID"
echo "End process"
for id in $PID
do
kill -9 $id
echo "killed $id" 
done
echo "End process completed"

#Copy the jar package to the execution directory_

echo"Copy the jar package to the execution directory:cp $JAR_PATH/$JAR_NAME.jar $JAR_WORK_PATH"
cp $JAR_PATH/$JAR_NAME.jar $JAR_WORK_PATH
echo "Complete copying of jar package"
cd $JAR_WORK_PATH
#Change file permissions chmod 755 $JAR_NAME.jar

# Front desk startup #java -jar $JAR_NAME.jar

#Background startup BUILD_ID=dontKillMe nohup java -jar $JAR_NAME.jar &

This is the end of this article about building automated deployment from scratch with docker+gitlab+jenkins. For more information about automated deployment with docker+gitlab+jenkins, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!