容器云和 DevOps 是怎样结合的?
发布于 2021-01-27 08:21
【作者】朱琦，某国内著名餐饮连锁企业运维负责人。从事过数据库、大数据和容器集群的工作，对DevOps流程和工具方面有比较深刻的理解。
1 DevOps和云计算增加容器安全性
容器云，特别是Kubernetes的容器云，安全性是一大问题。尤其是公有云环境的容器云，安全性尤为令人担心。因为只要能登录容器云所在操作系统的任意一个节点，任何人都能对容器云中的应用容器进行操作。开源软件弊端在其身上显露无疑，那就是初期不考虑安全性。关于这一点，有些同学在开源软件中，也可以体会到。
有些同学可能会认为，持续交付和开发实践所带来的持续不断的流量状态，与管理许多不同容器和/或微服务的复杂性，可能会带来各种安全风险。诚然，更多的DevOps工具链组件往往意味着更大的风险，但是运用的好的话，情况恰恰相反。
使用DevOps持续更新基于容器的软件可以创建更高的安全性。这是因为托管的容器平台等云环境不断保持最新状态 ，并转移到最新的补丁级别，这些补丁通过云计算在全球推出。这有助于人们应对最新的威胁，并立即解决它们。反过来，这使得整个环境更加安全，因为应用程序内的不安全的主要来源是过时的软件。
这一点就如同，一个在冬天的冬泳者，虽然光着膀子游泳，极易寒气入侵，但由于不断的锻炼增强了体质，反而，不容易感冒。
2 容器云的兴起对DevOps巨大的推动作用
用户需要持续交付容器体系结构以保证安全和有效。要持续交付工作，需要可重复的软件部署，还需要部署到可容忍更改的环境(包括滚动更新和回滚)。云容器服务需要全球数以万计的集群必须保持最新状态，
而且还要有近乎完善的监控体系，如果没有成熟的DevOps工具可以以可靠的方式实现自动化，实际上是不可能做到的。
如今的许多企业团队并没有运行数以万计的集群。他们正在运行一些集群。但是，当用户运行具有大量容器集群的复杂大型应用程序来管理并保持安全时(特别是在不同地区)时，也还是需要采用不同的DevOps方法来处理的。
3 基于kubernetes DevOps的整体方案
以Kubernetes为基础，为基于java语言研发团队提供一套完整的DevOps解决方案。在此方案中，开发人员基于eclipse集成开发，在各种环境进行代码部署；开发人员所开发的代码交由由Gitlab进行托管、版本管理和分支管理；代码的依赖更新和构建工作由Maven进行处理；为了提升工作效率和代码质量，在DevOps中引入SonarQube进行代码检查；由checkmarx进行安全检查，对于打包构建后代码，交由Docker进行镜像构建，并在私有镜像仓库Nexus中对镜像进行管理；最后，DevOps会将自动从私有镜像仓库从拉取镜像，并在Rancher中进行部署。
基于此DevOps解决方案的整体工作过程如下所示：
开发人员基于eclipse集成开发环境镜像代码开发，将代码到Gitlab中进行托管；
Jenkins从Gitlab拉取代码；
通过Sonarqube进行代码质量；
通过Checkmarx进行代码安全检查；
Jenkins调用Maven对代码进行打包构建；
Jenkins调用Docker构建镜像；
Jenkins将构建好的镜像上传至基于Nexus或者Quay的私有镜像仓库；
通过API接口，将yaml文件传送到K8s，拉取Jenkins构建的镜像进行部署，完成整个CD流程。
4 组件安装部署（未有spinnaker的部署）
4.1 代码托管工具-Gitlab
代码的托管基于Gitlab。下面是在Kubernetes中部署gitlab的YAML配置文件，在此文件中定义了gitlab部署和服务。gitlab部署使用的镜像为gitlab/gitlab-ce:latest，并暴露了443、80和22这三个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中， 端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对gitlab进行访问。
通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署gitlab
kubectl create -f {path}/gitlab.yaml
4.2 镜像仓库-Nexus
采用Nexus作为docker私有镜像仓库和maven的远程仓库。下面是在Kubernetes中部署Nexus的YAML配置文件，在此文件中定义了Nexus部署和服务。Nexus部署使用的镜像为sonatype/nexus3:latest，并暴露了8081、5001这两个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对nexus进行访问。其中，5001作为docker私有镜像仓库的端口。
通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署nexus
$ kubectl create -f {path}/nexus.yaml
4.3 流水线工具-Jenkins
采用jenkins作为流水线工具。下面是在Kubernetes中部署jenkins的YAML配置文件，在此文件中定义了jenkins部署和服务。jenkins部署使用的镜像为lw96/java8-jenkins-maven-git-vim:latest，并暴露了8080这个端口，并通过NFS对配置文件和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对jenkins进行访问。另外，在此镜像中也提供maven和java。
通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署jenkins：
$ kubectl create -f {path}/jenkins-devops.yaml
注意，后续将执行下面的操作：
将Kubernetes集群的kubeconfig文件拷贝到192.168.8.150主机的/k8s-nfs/jenkins-devops/mnt目录下；
将maven的settings.xml文件拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/repo目录下；
将maven的依赖插件包拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/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.xml拷贝到/k8s-nfs/jenkins-devops/repo目录下
4.6 Docker的设置
为了能够支持将远程提交的代码构建成镜像，以及将构建好的镜像上传至镜像仓库需要在/etc/docker/daemon.json的文件中添加下面的内容。其中，10.126.144.40为镜像仓库的地址和端口，tcp://0.0.0.0:5243为对外暴露的地址和端口。damon.json文件如框中所示。然后用以下重启docker。镜像仓库是要为各个节点服务的，所以一般都用0.0.0.0这种地址。不能将其设为127.0.0.1或其他固定ip。
$ systemctl daemon-reload
$ systemctl restart docker
4.7 Sonarqube的设置
Sonarqube为代码质量检查的插件，需要在Kubernetes中建立postgres数据库（数据库建立在k8s中不推荐，但此处只是用于工具运行的数据库），共建立2个yaml文件，sonar-postgres，由于sonarqube非生产库，所以用户名密码明文是允许的，如下：
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 Deploy Plugin：与kubernetes集成的插件，用于将镜像部署到kubernetes环境。该插件有时不能满足要求，建议用shell直接写kubectl。
Checkmax插件：安全组件的插件，但checkmarx为商业化产品，需要费用支出，个人部署可先忽略；
Sonarqube插件：代码质量插件，需配合sonarqube的server和端口，如下所示
并在configure中加入如下模块
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。
相关素材