DevOps落地-成果:容器平台、应用容器环境、CICD

容器平台,难落地

技术升级改造过程,最难落地的部分就是—容器化。
原因是微服务化后,再加上容器化,肯定会遇到部署难,调试难,访问难,配置难
难就难在,任何一个没有解决,都没法完全落地
本文说说容器化工作的容器平台,这部分落地的一些心得。

容器平台成果与技术图谱

容器平台难落地,也难在涉及多层次的技术。
涉及 网络、容器、应用框架(Java 微服务的注册中心、配置中心)。
以容器层为中心,向上涉及应用微服务框架、向下涉及容器网络、基础网络。还涉及DevOps工具链、CICD。
目前落地成型后,涉及到的技术:

技术选型 地址 说明
rancher https://rancher.com/products/rancher/ 多k8s集群管理工具
rke https://rancher.com/products/rke/ 一种k8s发行版
tke/ack/cce 见腾讯云、阿里云、华为云的容器服务 公有云k8s paas服务
nginx-ingress/traefik https://github.com/kubernetes/ingress-nginx ingress controller
nacos https://nacos.io/en-us/ 微服务配置中心、注册中心
vyos/nat/路由器/交换机 https://wiki.vyos.net/ 可云上部署的,多种协议的路由器、交换机、防火墙
s2e-runner https://github.com/chimeh/cicd-s2e-runner 二次开发的cicd
helm https://helm.sh/ 开源k8s 部署工具
docker-compose https://docs.docker.com/compose/reference/ 单机 docker 化工具
xxxxxxxxxxxx

DevOps落地-成果:容器平台、应用容器环境、CICD_第1张图片

神器 : Rancher

开发小M:应用部署后,我想看日志,看应用访问地址,是否Runing …

要实际大幅提高研发体验,提高效率、质量。除了rancher 安装之外还有不少工作要做。
心得:

  • 和AD/LDAP集成,合理分配权限。跟组织架构对应。
  • 配置域名与https。
  • 【重要】取名很重要,大幅降低名称相关的沟通。尤其是代码仓库、应用名称、包括deployment、service 有简单因素关联,比如都以git仓库名为名。
  • rancher cluster和业务cluster分离。
  • 合理设计rancher个数,比如beta、prod一个rancher;非生产的一个rancher
  • 公有云使用import 方式管理Kubernetes;
  • 私有云使用import 方式管理Kubernetes;
  • Project 、Namespace、应用环境有明确对应关系。-dev、-test、-uat、-beta、-prod
  • 敢于做技术取舍。像pvc、statefulset,可维护性低的技术能不用则不用。

下图为某项目,多个微服务应用部署到 Rancher, 的截图。DevOps落地-成果:容器平台、应用容器环境、CICD_第2张图片

私有云k8s: RKE,装!

工作不仅仅是安装。要想大幅提高开发、测试效率。在于安装之外,包括网络、访问方式等方面精心考虑,精心规划!
心得:

  • 【重要】控制面master与负载面分离。
  • 【重要】规划 容器CIDR。解决访问难问题。
  • 【重要】underlay 网络与overlay 容器网络 统一IP空间,统一规划,打通链路。方便访问,才能提高调试效率。
  • 部署ingress(nginx-ingress/traefik/kong-ingress)。解决访问难问题。
  • 泛域名通配符解析,以便ingress 一旦创建,流量就能进入集群。
  • 自建DNS服务。配合泛域名解析。
  • 结合人员组织架构、项目、环境类型;规划RKE。
  • import 到rancher中。
  • 公有云、私有云混合网络,充分利用公有云 数据库PaaS。
    DevOps落地-成果:容器平台、应用容器环境、CICD_第3张图片

公有云k8s:TKE/ACK/CCE,买!

部署简单,就是买!买容器服务 腾讯云TKE/阿里云ACK/华为云CCE。
精心规划!
提高效率、提高可维护性,还也在于,在VPC网络、容器网络、ingress、域名、域名解析方面的巧妙设计:
心得:

  • 参考上一章节私有云心得。
  • 统筹考虑 私有云CIDR、公有云VPC CIDR、容器CIDR、办公网络CIDR。
  • 利用SSL V|P|N、Ipsec、OSPF、vxlan等网络技术 解决访问难、调试难问题。
    DevOps落地-成果:容器平台、应用容器环境、CICD_第4张图片

代码容器化:代码模板

Q:我的新的代码怎么支持CICD?

容器化,不就是写个Dockerfile吗?
实际上引入微服务技术后,git代码仓库的量变多。就没那么简单了。

A:把那3个文件 COPY 到你顶级目录,提交!

做的工具/流程/指导文章是否好,我们内部经常用于自我评价的:
一句话比一篇文章好、一条命令比几个步骤好!

代码模板,解决什么问题呢,心得:

  • 屏蔽技能问题。不是每个前后端开发都会写Dockerfile。
  • 解决标准统一问题。 各个开发写的Dockerfile 基础镜像,entrypoint等都各不一样,Dockerfile 文件目录位置不一样。
  • 解决以上问题。尤其是微服务技术下,Git仓库量多,放大了以上问题。
  • 统一的代码目录结构。优点不言而喻。
  • CICD标准化。更加方便CICD工具处理。
    DevOps落地-成果:容器平台、应用容器环境、CICD_第5张图片

java 微服务工程模板
仓库名规范: 字母开头,不含点,全小写,可用于域名一部分。
注意 docker-entrypoint.sh 已写成通用的!
cicd-java-refer/
├── docker
│ ├── docker-entrypoint.sh
│ ├── healthy.sh
│ └── ready.sh
├── Dockerfile
├── pom.xml
├── README.md
├── src
│ └── main
│ ├── java
│ └── test
│ └── resources

开发人员只需要简单2步,即可支持CICD:

xxx 是你的git 代码仓库
1. 拷贝 docker/ 整个目录,到 xxx 第一级目录,无需修改。
2. 拷贝 .gitlab-ci.yml,到 xxx 第一级目录,无需修改。
3. 拷贝 Dockerfile,到 xxx 第一级目录,可能需要修改里面EXPOSE。
4. git commit 。

cicd runner:二次开发、容器化、工具化!

站在
所以:

开发小M:源码给你,帮我部署到Dev环境。
运维小O:点一下gitlab的那个按钮!
运维小O:不想写yaml,简单一条命令或者一个鼠标左键,能搞定就好了。

场景:你维护者3个项目,6个环境的CICD,共70个git project,你会遇到什么问题、难题?

万众归一,所有的流水线能需要 artifact构建、扫描、docker 构建、入库、部署,能不能写成一个通用工具。我只需要维护好、使用好这个工具即可!

心得:
开发一个易用性好的命令行工具,能一条命令完成 源码检测、构建、docker构建、k8s部署、应用IP访问生产、域名生成。
DevOps落地-成果:容器平台、应用容器环境、CICD_第6张图片
DevOps落地-成果:容器平台、应用容器环境、CICD_第7张图片

巧妙设计namespace:容器环境与灰度

开发小M:每次生产上线,怕!没有安全感。

环境及灰度部署设计,给研发以安全感。
这里的环境设计要综合考虑 基础设施成本、维护成本、团队规模、团队技术能力、可用性、上线稳定性要求。
在非生产的易用性、生产的上线稳定性的的一些,
心得:

  • 生产环境引入beta部署,方便快速在线上验证,并且影响最小化。这对上生产的信心很重要。巧妙的地方在生产两套入口、两套业务容器(namespace)、两套配置中心、但是共用数据库、部分共用注册中心。
  • 生产上多个层次的高可用考虑。在云平台地域、网络层、容器层、应用部署层、上线操作过程均做考虑。
  • 生产应用容器的灰度部署考虑。比如一个应用两个deployment,每个deployment多个pod。
环境 访问入口(域名/IP) 业务容器 namespace 配置中心 注册中心 数据库
dev环境 独立 独立,xxx-dev 独立 独立 独立
test环境 独立 独立,xxx-test 独立 独立 独立
uat&pre环境 独立 独立,xxx-uat 独立 独立 独立
beta&prod环境 独立,2个独立入口,prod入口对外服务 独立 独立 共用 共用,beta和prod共用数据库,prod 有灰度

DevOps落地-成果:容器平台、应用容器环境、CICD_第8张图片
DevOps落地-成果:容器平台、应用容器环境、CICD_第9张图片

创造性的网络互联:打通办公网、容器网络

开发小M:我本地开IDE,想连入环境调试一下,调用过来!

待续

巧妙的泛域名解析:ingress 自动化零介入

运维小O:每个应用都要去配域名DNS,好繁琐啊

待续

神器在手,就没有困难吗?

用了Rancher,容器平台,就没有困难了吗? 不,困难问题还不少,根据落地的经验,一一道来。

应用 - 构建难、部署难

运维小O:我在加班,几十个Dockerfile,几十个.gitlab-ci.yaml 又得改一遍。
开发小M:我的应用部署道XX环境了吗?
运维小O:几百个应用,搞不过来啊,上百个yaml要写改呢。

如果不是微服务架构,请跳过部署难。微服务架构下,部署问题会成为一个比较严重的问题。
体现在:
难点1:人工部署缺乏规范性

  • 名称不规范。deployment、service name。服务数量超过10个,业务开发天天问,应用A部署名称是A1,应用C怎么也是A2,不能取C吗?晕!晕!晕!!
  • label 不规范。这个service到底是哪些deployment的service。能不能统一一下。

难点2:人工部署工作量大

  • 一个项目应用Git代码仓库多个。Git 40+,docker镜像 40+。
  • 环境3+多。Dev、Test、Prod,怎么也得3套吧,还不说UAT、Beta。
  • 项目多。ToB行业,怎么也得3个项目吧。
  • yaml 文件多。每个应用 3+ 个yaml文件,deployment.yaml, service.yaml,configmap.yaml,还不说 ingress
  • 流水线文件维护量大。 维护40个.gitlab-ci.yamlJenkinsfile,改一下都要改40多次。
    很快,团队中都有个人专职 yaml boy了。一个项目维护至少 N405*3=600个yaml。

难点3:人工部署工作重复、易出错

解决要点

要点1: 启用 CICD 流水线,支持自动部署。
DevOps落地-成果:容器平台、应用容器环境、CICD_第10张图片
要点2:赋能开发人员自助配置流水线,非常强调简单性、零维护。

  • CICD流水线化。非常强调自动化,简单性,零维护。
  • CICD流水线配置要及其简单,交给开发。 让开发做最简单的事情,Ctrl-C,Ctrl-V,鼠标单击。
    如何达到这些要点呢?
#s2i:1
stages:
  - s2i
s2i:
  stage: s2i
  script:
     - s2i .

举例,某个工程支持cicd,只需要把以上代码复制、粘贴替换到.gitlab-ci.yaml(类似于Jenkinsfile)里,然后提交。s2i完成了很多事情。而devops,只需要维护s2i就行了。

要点3:runner 容器化,和工具集成
场景:来了一个项目,又得搞一个runner或者jenkins-slave。A项目要求kubectl版本1.13,B项目要求1.18。天天yum install, apk add。
既然业务应用容器化,CICD的工具也容器化,不香吗
开源出来地址:https://github.com/chimeh/cicd-s2e-runner/blob/master/Dockerfile
DevOps落地-成果:容器平台、应用容器环境、CICD_第11张图片
要点4:把应用的源码检测、构建、质量扫描、打docker、生成yaml、部署等等写成一个通用工具s2i

  usage:
  A cicd tool, from src to artifact, to docker img, deploy into kubernetes:
  I. default do all action(artifact,docker,deploy):
  s2i /path/to/srctop

  II. only do specify action:
  s2i /path/to/srctop [ analysis|artifact|docker|deploy|deploy-update-blue ]

    1. only do artifact
    s2i /path/to/srctop artifact

    2. only do docker build push
    export DOCKER_REPO=harbor.benload.com
    export DOCKER_NS=bu5
    s2i /path/to/srctop docker

    3. only do kubernetes deploy
    export K8S_KUBECONFIG=/root/.kube/config
    export K8S_NS_SUFFIX=-dev
    export K8S_NS=default
    export K8S_DOMAIN_INTERNAL=benload.cn
    export K8S_DOMAIN_PUBLIC=bu5-dev.tx
    export INGRESS_INTERNAL_ENABLED=1
    export INGRESS_PUBLIC_ENABLED=1
    export INGRESS_CLASS_INTERNAL=nginx
    export INGRESS_CLASS_PUBLIC=nginx
    s2i /path/to/srctop deploy

  III. do exec cmd:
  s2i /path/to/rundir exec wrappercmd [...]
    1. do ls on /root directory
    s2i /root ls

应用 - 访问难

开发小M:xxx 应用的访问地址是啥?
开发小M:帮我配置一下域名、IP端口,我要公网https访问。
运维小O:好多yaml要写啊!又写错了
运维小O:靠,NodePort端口冲突!

应用部署进Kubernetes集群内了。部署搞定、下一步要访问了。
访问难,难在哪?
难点1:部署后,不能立即直接访问
主机/系统/应用 、主机/系统/docker-compose/应用 方式部署时,访问简单直观。可以使用HOST-IP和HOST-PORT, 如下图。
但是,Kubernetes 里的应用访问呢?
NodePort、Ingress、LoadBalancer配置?微服务化后,难!难在人工工作量大,难在人工缺乏规范性。
DevOps落地-成果:容器平台、应用容器环境、CICD_第12张图片
DevOps落地-成果:容器平台、应用容器环境、CICD_第13张图片
难点2:用NodePort 端口有限,不直观,人工配置

  • 用NodePort 端口难管理。
  • 用NodePort 研发人员记不住。

难点3:用ingress 只支持https(s),人工配置工作量大

  • 用 ingress,几十上百个ingress yaml 谁来写。
  • 用ingress 不支持TCP。只有http,https,纯粹TCP呢,集群外怎么访问?

解决要点

应用 - 调试难

开发小M:这个IP地址:端口是哪个应用的地址?又忘了
开发小M:有没有https
开发小M:每次调试都要提交代码走CICD好慢啊,能不能本地调
开发小M:哪里看日志?
开发小M:…,效率好低,又得加班

解决要点

待续…

应用 - 配置难

开发小M:容器重启以后啥都没了,我配置放哪里,
开发小M:DEV、TEST的数据库的地址不一样

待续…

解决要点

待续…

应用 - 权限难

测试小T:谁把我的应用容器重启了,我在测试啊
开发小M:谁重启了我的应用。。。
待续…
待续…

应用 - 上线难

开发小M:我要上生产,怎么个流程
待续…

集群 - 稳定难

待续…

集群 - 混合云

待续…

人员 - 多业务部门

待续…

应用 - 日志/监控/APM

待续…

思考

DevOps部门平台化OR部门化?

待续…

颠簸的技术升级历程回顾

回顾一下我们的容器平台历程,有一些参考意义。

docker-compose 阶段

地址:http://docs.rancher.com/rancher/v1.6/en

评价 说明

DevOps落地-成果:容器平台、应用容器环境、CICD_第14张图片
DevOps落地-成果:容器平台、应用容器环境、CICD_第15张图片

kubernetes dashboard 阶段

地址:https://github.com/kubernetes/dashboard

评价 说明

DevOps落地-成果:容器平台、应用容器环境、CICD_第16张图片

okd(openshift) 阶段

地址:https://docs.okd.io/

评价 说明

DevOps落地-成果:容器平台、应用容器环境、CICD_第17张图片

Rancher/RKE/TKE/容器服务阶段

RKE 地址:https://rancher.com/products/rke/
Rancher地址:https://rancher.com/products/rancher/

评价 说明

DevOps落地-成果:容器平台、应用容器环境、CICD_第18张图片
DevOps落地-成果:容器平台、应用容器环境、CICD_第19张图片

下一个阶段,servicemesh?

2020年初,我们经过评估,servicemesh的复杂性过高。
还需要等待技术更成熟,包括易用性,再考虑升级到servicemesh。

你可能感兴趣的:(容器化与DevOps落地之路)