容器云和DevOps结合的解决方案

1、 容器云和 DevOps 结合的解决方案 【导读】Kubernetes集群是集中了Iaas和Paas的平台，DevOps是继ITIL后，一种新兴的软件开发和运维模式。DevOps天生和Kubernetes是匹配的，DevOps+Kubernetes+Scrum 可以大大提高产品设计开发进度，帮助团队更好的达到软件的设计目标。本文介绍了基于kubernetes DevOps的整体方案和组件安装部署。1 DevOps和云计算增加容器安全性容器云，特别是Kubernetes的容器云，安全性是一大问题。尤其是公有云环境的容器云，安全性尤为令人担心。因为只要能登录容器云所在操作系统的任意一个节点，任何人

2、都能对容器云中的应用容器进行操作。开源软件弊端在其身上显露无疑，那就是初期不考虑安全性。关于这一点，有些同学在开源软件中，也可以体会到。有些同学可能会认为，持续交付和开发实践所带来的持续不断的流量状态，与管理许多不同容器和/或微服务的复杂性，可能会带来各种安全风险。诚然，更多的DevOps工具链组件往往意味着更大的风险，但是运用的好的话，情况恰恰相反。使用DevOps持续更新基于容器的软件可以创建更高的安全性。这是因为托管的容器平台等云环境不断保持最新状态 ，并转移到最新的补丁级别，这些补丁通过云计算在全球推出。这有助于人们应对最新的威胁，并立即解决它们。反过来，这使得整个环境更加安全，因为应

3、用程序内的不安全的主要来源是过时的软件。这一点就如同，一个在冬天的冬泳者，虽然光着膀子游泳，极易寒气入侵，但由于不断的锻炼增强了体质，反而，不容易感冒。2 容器云的兴起对DevOps巨大的推动作用用户需要持续交付容器体系结构以保证安全和有效。要持续交付工作，需要可重复的软件部署，还需要部署到可容忍更改的环境(包括滚动更新和回滚)。云容器服务需要全球数以万计的集群必须保持最新状态，而且还要有近乎完善的监控体系，如果没有成熟的DevOps工具可以以可靠的方式实现自动化，实际上是不可能做到的。如今的许多企业团队并没有运行数以万计的集群。他们正在运行一些集群。但是，当用户运行具有大量容器集群的复杂大型

4、应用程序来管理并保持安全时(特别是在不同地区)时，也还是需要采用不同的DevOps方法来处理的。3 基于kubernetes DevOps的整体方案以Kubernetes为基础，为基于java语言研发团队提供一套完整的DevOps解决方案。在此方案中，开发人员基于eclipse集成开发，在各种环境进行代码部署；开发人员所开发的代码交由由Gitlab进行托管、版本管理和分支管理；代码的依赖更新和构建工作由Maven进行处理；为了提升工作效率和代码质量，在DevOps中引入SonarQube进行代码检查；由checkmarx进行安全检查，对于打包构建后代码，交由Docker进行镜像构建，并在私有镜

5、像仓库Nexus中对镜像进行管理；最后，DevOps会将自动从私有镜像仓库从拉取镜像，并在Rancher中进行部署。基于此DevOps解决方案的整体工作过程如下所示：开发人员基于eclipse集成开发环境镜像代码开发，将代码到Gitlab中进行托管；Jenkins从Gitlab拉取代码；通过Sonarqube进行代码质量；通过Checkmarx进行代码安全检查；Jenkins调用Maven对代码进行打包构建；Jenkins调用Docker构建镜像；Jenkins将构建好的镜像上传至基于Nexus或者Quay的私有镜像仓库；通过API接口，将yaml文件传送到K8s，拉取Jenkins构建的镜像

6、进行部署，完成整个CD流程。4 组件安装部署（未有spinnaker的部署）4.1 代码托管工具-Gitlab代码的托管基于Gitlab。下面是在Kubernetes中部署gitlab的YAML配置文件，在此文件中定义了gitlab部署和服务。gitlab部署使用的镜像为gitlab/gitlab-ce:latest，并暴露了443、80和22这三个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中， 端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对gitlab进行访问。通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署git

7、labkubectl create -f path/gitlab.yaml4.2 镜像仓库-Nexus采用Nexus作为docker私有镜像仓库和maven的远程仓库。下面是在Kubernetes中部署Nexus的YAML配置文件，在此文件中定义了Nexus部署和服务。Nexus部署使用的镜像为sonatype/nexus3:latest，并暴露了8081、5001这两个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对nexus进行访问。其中，5001作为docker私有镜像仓库的端口。通过kubec

8、tl命令工具，执行如下的命令，在kubernetes集群中部署nexus$ kubectl create -f path/nexus.yaml4.3 流水线工具-Jenkins采用jenkins作为流水线工具。下面是在Kubernetes中部署jenkins的YAML配置文件，在此文件中定义了jenkins部署和服务。jenkins部署使用的镜像为lw96/java8-jenkins-maven-git-vim:latest，并暴露了8080这个端口，并通过NFS对配置文件和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对jenkins

9、进行访问。另外，在此镜像中也提供maven和java。通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署jenkins：$ kubectl create -f path/jenkins-devops.yaml注意，后续将执行下面的操作：将Kubernetes集群的kubeconfig文件拷贝到50主机的/k8s-nfs/jenkins-devops/mnt目录下；将maven的settings.xml文件拷贝至到50主机的/k8s-nfs/jenkins-devops/repo目录下；将maven的依赖插件包拷贝至到50主机的/k8s-nfs/jenkins-devo

10、ps/repo目录下。4.4 Nexus设置Nexus在devops中承担两个功能，作为maven的远程仓库和作为docker的私有镜像仓库。在这里，我们使用nexus默认安装的maven-snapshots、maven-releases和maven-public这三个仓库4.5 maven设置maven负责管理代码的依赖关系和构建。maven通过settings.xml文件设置运行环境，包括与远程仓库的连接。本文中的settings.xml文件，最主要是加入了mirrorOf，如下所示，http:/nexus3:8081中的nexus3是在kubernetes中的服务名称。将settings

11、.xml拷贝到/k8s-nfs/jenkins-devops/repo目录下4.6 Docker的设置为了能够支持将远程提交的代码构建成镜像，以及将构建好的镜像上传至镜像仓库需要在/etc/docker/daemon.json的文件中添加下面的内容。其中，0为镜像仓库的地址和端口，tcp:/:5243为对外暴露的地址和端口。damon.json文件如框中所示。然后用以下重启docker。镜像仓库是要为各个节点服务的，所以一般都用这种地址。不能将其设为或其他固定ip。$ systemctl daemon-reload$ systemctl restart docker4.7 Sonarqube的

12、设置Sonarqube为代码质量检查的插件，需要在Kubernetes中建立postgres数据库（数据库建立在k8s中不推荐，但此处只是用于工具运行的数据库），共建立2个yaml文件，sonar-postgres，由于sonarqube非生产库，所以用户名密码明文是允许的，如下：sonar-sonar.yaml，如下4.8 Jenkins的插件选择Jenkins作为devops平台的流程线工具，需要从gitlab中获取代码，并提交给maven进行构建；在代码构建成功后，调用docker构建镜像，并将上传至基于Nexus的私有镜像仓库；最终，在Kubernetes中部署和运行镜像。为了实现上述能力，需要在jenkins中安装如下插件git plugin：与gitlab集成的插件，用于获取代码；maven plugin：与maven集成的插件，用于构建代码；CloudBees Docker Build and Publish plugin：与docker集成的插件，用于构建docker镜像，并上传至镜像仓库；Kubernetes Continuous