容器云和DevOps是怎样结合的.docxVIP

【导读】Kubernetes集群是集中了 laas和Paas的平台.DevOps是继ITIL后，一种新兴的软件开发和运维模式。DevOps 天生和Kubernetes是匹配的，DevOps+Kubernetes+Scrum可以大大提高产品设计开发进度，帮助团队更好的达到 软件的设计目标。本文介绍了基于kubernetes DevOps的整体方案和组件安装部署。 1 DevOps和云计算增加容器安全性 容器云，特别是Kubernetes的容器云，安全性是一大问题。尤其是公有云环境的容器云，安全性尤为令人担心。 因为只要能登录容器云所在操作系统的任意一个节点,任何人都能对容器云中的应用容器进行操作。开源软件弊端 在其身上显露无疑，那就是初期不考虑安全性。关于这一点，有些同学在开源软件中，也可以体会到。 有些同学可能会认为，持续交付和开发实践所带来的持续不断的流量状态，与管理许多不同容器和/或微服务的复杂 性，可能会带来各种安全风险。诚然，更多的DevOps I具链组件往往意味着更大的风险，但是运用的好的话，情 况恰恰相反。 使用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-cedatest ,并暴露了 443、80和22这三个端口 ,并通过NFS对 配置文件、日志和数据进行持久化.在服务中，端口的类型为NodePort,即允许集群外的用户可以通过映射在主 机节点上的端口对gitlab进行访问。 通过kubectl命令工具,执行如下的命令，在kubernetes集群中部署gitlab kubectl create -f {path}/gitlab.yaml # 定义代理服务 apiVersion： v1 kind： Service metadata： name： gitlab spec： type： NodePort ports： ? Port上的映射端口 -port: 443 targetPort： 443 name: gitl