您的位置:首页 > 运维架构 > Docker

Linux文档整理之【Jenkins+Docker自动化部署.Net Core】

2019-12-24 19:39 1041 查看

这次整理的文档是Jenkins+Docker实现自动化部署,很早之前就写的,今天有时间就搬到博客园做个记录。

Jenkins是基于Java开发的一种持续集成工具,主要用于持续、自动的构建/测试软件等相关项目。在Java开发中我们经常能看到使用jenkins来部署,.Net core目前还是比较少见的,但是好的东西我们就应该要拿来使用、借鉴。

1. 安装JenKins

这里使用Docker来安装JenKins,当然也可以直接安装到Linux中。

创建jenkins工作目录

mkdir /usr/local/jenkins

拉取jenkins镜像

docker pull jenkins

这里有个小插曲,我用的是jenkins镜像,默认也是latest一般意味着最后最新版本。很多官方最新镜像也都是如此命名;直到后来安装配置完成后,登录进去提示我不是最新版本,让我更新,并且很多插件已经不支持此版本了。发现当前版本和最新版本还相差好几个。心想这不是官方镜像吗 怎么还是这么旧的版本,最后通过搜索发现,Jenkins官方最新镜像现在已改为jenkins/jenkins的了。

所以最新版是:jenkins/jenkins

 

我们拉取最新lts版本。

docker pull jenkins/jenkins:lts

看如下图jenkinsjenkins/jenkins两个镜像的差别,发现常规下的latest版本并不最新的了,它们的创建时间已经是1年以前了。而jenkins/jenkins 则创建时间在2天不到。

所以常规的latest并不意味着最新版本。

修改jenkins目录和docker目录权限,这里1000是容器中Jenkins 的用户 uid

chown -R 1000:1000 /usr/local/Jenkins

sudo chown -R 1000:1000 /var/run/docker.sock

尤其docker.sock 这个权限很重要,到时候容器里的Jenkins需要执行docker命令需要的

运行Jenkins 注意后面的镜像名称和版本lts

docker run -itd -p 8080:8080 -p 50000:50000 --name jenkins --privileged=true  -v /usr/local/jenkins:/var/jenkins_home -v /usr/bin/docker:/bin/docker  -v /var/run/docker.sock:/var/run/docker.sock jenkins/jenkins:lts 

参数解释:

-p 8080:8080 -p 50000:50000 --映射jenkins端口

--name jenkins --容器名称自己命名

privileged=true --授予容器管理员权限

-v /usr/local/jenkins:/var/jenkins_home --映射jenkins目录

-v /usr/bin/docker:/bin/docker --映射docke目录 到时候需要在容器里执行docker命令

-v /var/run/docker.sock:/var/run/docker.sock --映射docker执行命令 到时候需要容器里执行docker命令。

 

容器是否启动成功最好还是通过docker ps 或者netstat –ntlp |grep 8080 (查看我们容器映射的端口是否监听成功) 查看当前容器是否运行成功。

某些情况下,如权限没有配对,启动会不成功的。

查看正在运行的容器。

docker ps

 

2. 配置JenKins

查看容器启动成功后,我们可以通过地址+端口访问刚刚运行的Jenkins

例如http://192.168.1.101:8080   

安装成功访问后会如下图所示。

提示首次访问需要密码,我们通过刚刚映射的Jenkins目录里查看这个默认密码。

默认密码路径:/usr/local/jenkins/secrets/  (注意前面usr/local/jenkins路径就是刚刚自己映射的目录)

查看密码文件

cat initialAdminPassword

输入密码然后继续下一步。

下一步如果有出现404的,如下图

网上搜索了解听说是Jenkins的一个bug;部分版本存在。

 

 

 

解决办法(以下步骤是解决登录404的;如果没有404则可以跳过)

首先回到Jenkins主目录找到config.xml文件并打开。

将<useSecurity> 修改为false

 

停止并重新运行jenkins

重启后一定要重新查看默认密码,否则旧密码是登录不成功的。

登录进去以后这里默认选择推荐的插件。

接下来就是等待安装,这里需要注意,如果jenkins版本比较老,则可能很多插件安装失败,直接红色的。此时可以跳过该界面进入首页。会有提示让你升级最新Jenkins版本。

安装完成后创建一个用户名和密码,即可完成安装进入首页。

 

3. 创建项目

1、源代码编译发布工程

源代码发布工程即将源代码提交到git服务器,jenkins通过git拉取最新的源代码,并通过Dockerfile里的配置进行编译发布过程。然后通过Docker构建此镜像并运行到容器。

创建一个.Net Core Web项目。

创建项目的时候可以选择启用Docker支持。

对于之前的项目可以右键添加Docker支持。

项目目录

默认的Dockerfile是有帮我们进行代码编译并发布动作的。所以默认的Dockerfile文件是适合和代码一起提交到服务器然后使用Docker进行构建镜像。

 

项目创建完成后随代码一起提交到git服务器。(svn等也都可以)

git项目目录,注意将Dockerfile复制到根目录。由于到时候构建镜像的时候就是从根目录执行的。git目录如下所示。

 

2、已编译的Release工程

已编译的Release工程,此种方式适合git或svn在局域网的;又不希望源代码不暴露到外网的需要。此种方式是将项目工程进行进行发布打包操作。例如java常见的打包成一个war包文件。.Net 就是生成对应的DLL 文件。

项目在发布之前我们对项目的Dockerfile文件属性做个更改,以便在发布时将此文件复制到发布时的目录。

选择上面建立的WebTest项目右键发布,选择发布到指定文件夹。

将发布文件发布到自己的git(或svn)目录,如下图所示的,一定要包含Dockerfile文件。发布后的文件,可以根据自己需要将没有更新DLL或者appsetting.json等文件剔除掉。只保留本次要更新的文件即可。

修改Dockerfile文件,因为默认的Dockerfile文件是包含编译发布的命令,所以这里要将这些相关命令操作删除掉;保留如下命令配置即可。

保存然后提交到所有文件到git服务器。

提交后的git目录。

建议:无论是代码编译发布工程还是已编译的Release工程,第一次使用Docker部署时最好先自己手动将这些文件拷贝到服务器,并手动构建对象并运行容器看是否成功;能否访问网站。也就是先不用Jenkins将这些流程自己手动走一遍,确保一些目录包括Dockerfile等都是配置正确的。

4.  创建JenKins任务

项目工程创建完成并提交到git服务器后,开始在Jenkins里面创建任务。

输入项目描述,源代码管理选择自己对应的即可。

 

我这里选择的git。第一次添加项目时需要添加一种授权方式点击右边添加按钮即可。

选择添加授权方式 常用的就是用户名加密码或者SSH方式。

 

下一步设置构建环境

设置触发器,这里主要是设置自动触发条件,有定时构建、远程触发构建、轮询SCM。

这里只设置轮询SCM形式的,很简单的方式。意思是在指定间隔时间内会去轮询git或svn中版本是否有变化。如果有就立即构建该项目。其实就是做到只要代码提交了 则立刻就能自动构建项目进行发布;不在需要其他任何操作了。

选择构建—>执行shell;当然我们这里是linux服务器所有多数选择执行shell。

添加shell 命令。

 

注意下面的webtest 改为自己的容器名称和对应镜像名称即可。

#!/bin/bash
# 获取短版本号
GITHASH=`git rev-parse --short HEAD`
docker stop webtest
docker rm webtest
echo ---------------Building Docker Image...------------------
docker build -t webtest:$GITHASH .
docker tag webtest:$GITHASH webtest:latest
echo ---------------Launching Container...------------------
docker run --name webtest -d -p 8005:80 webtest:latest 

使用git提交代码进行测试。

自动开始构建了 注意jenkins这里时间是默认是utc时间。utc时间转换我们北京时间是要+8小时的。

 

蓝色图标代表构建成功,如果失败会是红色

 

查看控制台输出信息,尤其构建失败时能够从里面获取到失败原因等。

控制输出如下图所示

构建成功后我们到服务器检查下是否有刚刚构建的镜像和运行的容器。(当然一般情况下只要构建成功这两步可以不用检查)

查看镜像

查看运行的容器

访问站点看能否访问成功。

 

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: