Objective
DevOps articles are very early to share, squeeze a little time to build some of the previous time to improve the development of the efficiency of things to share with you.
This article describes a. Netcore MVC Web project, starting from project push to GitHub
- Automatically pull the replacement code from GitHub
- Compile, build, publish
- Stop the Docker container and remove the Docker image
- Create a new Docker image from the project's Dockerfile
- Run container, auto-bind IP, site start
The whole process only needs a button on Jenkins, the automation tool. Let's take a brief look at this in order.
The use of content is very basic, it is important that all automated thinking, we want to improve our development efficiency, reduce the development phase wasted unnecessary time.
First, the installation/deployment of Jenkins
This is explained in a separate section, where you first take a place, and then put a link (* ^_^ *), you can refer to my previous reference to a post 1190000007086764
In fact, Jenkins configuration when the pit more, a brief introduction of a few, perhaps we met, you can directly ask me.
- When constructing the prompt does not have permission, permission problem
II. configuration of the command to execute commands from the GitHub pull-up code 1, GitHub plugin installation and GitHub configuration
Git plug-ins in fact in the Jenkins installation process recommended plug-in hints, if the recommended plug-in installed directly, then no need to install.
If the recommended plugin is not installed, then you can enter Jenkins's system management
Manage Plugins
Install git-related plugins
This should be very simple, not to repeat.
We open a project (no new) and then go to the project configuration:
Enter the GIT address for the project, I'm writing a project address for GitHub, and the address can be directly opened for GitHub replication:
This entry is the item's browse address, copied directly from the browser address bar
and write it in this position.
also supports selecting branches for building
This feature is not the default, need to install a plug-in, called Git Parameter Plugin installation method has been introduced before, consistent. Once you have installed this plugin, you are free to configure the parametric build process.
Source management continue to fill out the Git address and copy the project address directly from GitHub
Then fill in the corresponding location
The core content is of course the command that was executed at the time of the build, and the detailed anatomy of the build command in the next section
2. Create a Jenkins Build command (from the shell script)
We went on to explain our build command, and Jenkins's workflow was done from a line of commands, so we gave Jenkins a series of commands that Jenkins would silently execute in order one by one in the background, so that Jenkins was powerful or not, The decision is whether our script commands are comprehensive and powerful.
Let's start with a new shell script.
Jenkins is able to execute shell commands directly, and we can fill in the command text area of the build with the corresponding script command, as shown in:
Why do we invoke shell scripting instead of just writing all the commands here?
The answer must be: for reuse, easy to modify maintenance! Imagine, if our 10 build projects all use the same build compiler to release NuGet to NuGet server commands, we have to write a bunch of commands separately in 10 build projects, one day we need to modify the NuGet server Push key, We need to open different build projects separately to modify the command parameters. In many cases the project will be quite complex.
In contrast, when we add new build projects, we just need to copy from the historical project and then modify the name of the solution.
Let's add a line number to the command to explain it individually.
The command line 1/2/3/4/5 is a variable of life, followed by the value of the variable. The ${variable name} is the value of the variable
The role of the variable is annotated, where 2 is the container name of the Docker
The function of line 6th of the command is to execute a dotnetcorewebpublishtodockercommon.sh shell script in this relative directory, and pass the variables obtained in the following one by one as parameters to the shell script.
III. instructions for compiling and publishing
Our previous section explained the invocation of a shell script in a directory, so this section begins to dissect the main script content (build process decomposition), and in the end we will put all the scripts out.
1. Variable reading of shell scripts
First, we read the arguments passed in from the beginning of the script, and then define the new variables to store their values.
Read parameters are read using the $ variable sequence number, so be sure to note the correctness of the order.
2. Define the directory where the published project code is stored and the directory where the content is backed up
Define the table of contents, we use the echo command to output the start of the build prompt message.
Use the same directory each time, and use the RM-RF command to clear the Publish directory (delete all files) before building
3, publish publish the project to the prepared directory
The purpose of this command is to use the. Netcore Publish command that publishes the project code under the ${jenkins_home}/workspace/${job_name}/${csprojdir} directory (stitched. csproj project path) to- O of this directory, of course, this directory is the directory we are ready to store, according to the project name in the corresponding folder.
The command of/p:version=1.0.${build_number} is a built-up version number, followed by the Jenkins Task Sequence number (Build_number). Otherwise you have to change the project information every time, very troublesome.
This serial number is the serial number generated automatically at the time of construction
4. Copy the required configuration to the Publish directory
Why do we have to do this?
For some of the configuration security of the project, such as connection string address, server address and other sensitive information, if all on GitHub, it is not to be the heart of the people to engage in the blind.
Therefore, we ourselves put the sensitive information configuration file in a specific directory, build the time to automatically copy the replacement project inside the configuration file.
Everything for the security of the server!
Iv. Docker container Command 1, stop the old container, and delete the old mirror
Docker command I will not say it, there are comments.
2. Create a mirror through dockerfile and map the port run container
Through ${containername} ${webdir}/${job_name}/. Directory (this directory is git pull down the project directory, later we explain Dockerfile) under the Dockerfile file build container.
The constructed container is named according to our parameters.
Use the Docker Run command to run the container and map port 80 of the container to the Linux server port specified by our parameter.
Prints a message that the publication was successful.
3, Dockerfile's description
On a point we built a new image using Dockerfile, and our dockerfile is actually stored along with the solution.
Dockerfile is actually very simple, in the VS2017 new. Netcore project, can be directly attached to the automatic construction, if not, we can manually to create.
It's actually very simple, just a few lines of code.
1. Describes the latest version of the official Docker image from Microsoft as the basis for creating a new image (unclear understanding of Docker mirroring mechanism)
2. Nothing to say
3. The working directory is specified, and the/publish folder is automatically generated when we finish building
4. External exposure 80 ports
5. Copy the file into the mirror (required configuration), copy the project code from the/pulish directory into the Mirror
6. Entry point assemblies for related projects
V. Pre-production preparation
What, it's going to be a hurry to get that little button?
If you are still calm, you should know that many pits have not been filled.
1, the Docker environment preparation
Docker installation is extremely simple, just a few lines of command can be configured to complete, this is also a lot of people love Docker reasons, do not need to install a complex variety of software operating environment, you can simply set up a program should be the operating environment (predecessors have done, And will not appear to look at other people's tutorials will have a variety of problems problems).
$ #安装Docker $ yum Install docker$ #启动docker服务 $ systemctl start docker.service$ #配置开机启动 $ systemctl Enable Docker.service
Centos7 install Docker commands, not the focus of this article, if you encounter problems, you can find data to solve.
2, Microsoft official image docker.io/microsoft/aspnetcore:latest Preparation
The Docker pull Microsoft/aspnetcore command automatically pulls up the latest. Netcore image, which is the image used in this article. Too slow you can find a way to configure the accelerator yourself. I don't have a match, I don't think it's too slow.
Once successful, use the Docker Images command to view the image that was pulled. Approximately 300 MB in size.
3. Preparing for the. NET core environment
If there is no. Netcore environment (which may involve the configuration of environment variables), then the dotnet command in the shell script will not be discussed.
Directly into the official Microsoft documentation, very clearly explained. Netcore environment installation, of course, outside the wall access is slow, if not smooth open, then only listen to the next word.
Official link here: https://www.microsoft.com/net/learn/get-started/windows
Choose Linux on the left
Choose your environment for CentOS
installation command:
Install the. NET SDK
sudo rpm-uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpmsudo Yum updatesudo yum install dotnet-sdk-2.0
If the installation and configuration are successful, the direct input dotnet can prompt the message
Six, enjoy building it 1, one-click Release
Click Build, select Branch (if no branch management tool is configured, skip), start building
1. View build Details
We can view our build process from the console output
Pull replacement code and restore dependency package
Remove the mirror and rebuild the image
Copy project files from Microsoft Official image to create a new image
Running the container
Success!
Vii. possible problems 1, I temporarily think of the pits are in the 5th, if we have encountered problems raised, I will add this. Viii. Acknowledgements
Thanks a bunch of people who are eager for knowledge have been giving me the motivation to complete a post that is helpful to everyone and is called a useful blog post.
Thank you for being able to move forward on the road to automation tools
Thank myself for saving a lot of time (live a few more years)
IX. Annex 1.Dockerfile Documents
From docker.io/microsoft//+/. /Publishentrypoint ["dotnet"" SevenTiny.Cloud.MultiTenantPlatform.Web.dll"]
2.dotnetcorewebpublishtodockercommon.sh Shell Script
#要构建的解决方案名称solutionName=$1#.sln file full path SolutionDir=$2#.csproj file full path Csprojdir=$3container name for #docker run ContainerName=$4#制定run的端口port=$5#项目发布的目录webDir=/vdb1/jenkins/publish/webapp# Archive Directory Archivesdir=/vdb1/jenkins/publish/ArchivesEcho "7tiny:dotnet Publish"#清空文件夹RM-RF ${webdir}/${job_name}/*
#发布网站到webDirdotnet Publish ${jenkins_home}/workspace/${job_name}/${csprojdir}-C Release-o ${webdir}/${job_name }/p:version=1.0.${build_number} #复制配置文件cp-rf/vdb1/jenkins/dotnetcorewebpublishtodockercommonconfigs/* ${webDir}/ ${job_name}/#停止docker容器docker Stop ${containername} #删除当前容器docker rm ${containername} #删除镜像docker RMI ${containername} #通过Dockerfile重新构建镜像docker build-t ${containername} ${webdir}/${job_name}/. #docker the Run container and bind to the port Docker run-d-P ${port} :--name ${containername} ${containername}echo "7tiny:success!"
. netcore MVC Docker Environment Jenkins One-click Deployment (DEVOPS)