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 |
神器 ： 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， 的截图。
私有云k8s： RKE，装！
工作不仅仅是安装。要想大幅提高开发、测试效率。在于安装之外，包括网络、访问方式等方面精心考虑，精心规划！
心得：
- 【重要】控制面master与负载面分离。
- 【重要】规划 容器CIDR。解决访问难问题。
- 【重要】underlay 网络与overlay 容器网络 统一IP空间，统一规划，打通链路。方便访问，才能提高调试效率。
- 部署ingress（nginx-ingress/traefik/kong-ingress）。解决访问难问题。
- 泛域名通配符解析，以便ingress 一旦创建，流量就能进入集群。
- 自建DNS服务。配合泛域名解析。
- 结合人员组织架构、项目、环境类型；规划RKE。
- import 到rancher中。
- 公有云、私有云混合网络，充分利用公有云 数据库PaaS。
公有云k8s：TKE/ACK/CCE，买！
部署简单，就是买！买容器服务 腾讯云TKE/阿里云ACK/华为云CCE。
精心规划！
提高效率、提高可维护性，还也在于，在VPC网络、容器网络、ingress、域名、域名解析方面的巧妙设计：
心得：
- 参考上一章节私有云心得。
- 统筹考虑 私有云CIDR、公有云VPC CIDR、容器CIDR、办公网络CIDR。
- 利用SSL V|P|N、Ipsec、OSPF、vxlan等网络技术 解决访问难、调试难问题。
代码容器化：代码模板
Q：我的新的代码怎么支持CICD？
容器化，不就是写个Dockerfile吗？
实际上引入微服务技术后，git代码仓库的量变多。就没那么简单了。
A：把那3个文件 COPY 到你顶级目录，提交！
做的工具/流程/指导文章是否好，我们内部经常用于自我评价的：
一句话比一篇文章好、一条命令比几个步骤好！
代码模板，解决什么问题呢，心得：
- 屏蔽技能问题。不是每个前后端开发都会写Dockerfile。
- 解决标准统一问题。 各个开发写的Dockerfile 基础镜像，entrypoint等都各不一样，Dockerfile 文件目录位置不一样。
- 解决以上问题。尤其是微服务技术下，Git仓库量多，放大了以上问题。
- 统一的代码目录结构。优点不言而喻。
- CICD标准化。更加方便CICD工具处理。
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访问生产、域名生成。
巧妙设计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 有灰度 |
创造性的网络互联：打通办公网、容器网络
开发小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.yaml或Jenkinsfile，改一下都要改40多次。
很快，团队中都有个人专职 yaml boy了。一个项目维护至少 N405*3=600个yaml。
难点3：人工部署工作重复、易出错
解决要点
要点1： 启用 CICD 流水线，支持自动部署。
要点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
要点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配置？微服务化后，难！难在人工工作量大，难在人工缺乏规范性。
难点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
| 评价 | 说明 |
|---|---|
| 优 | |
| 劣 |
kubernetes dashboard 阶段
地址：https://github.com/kubernetes/dashboard
| 评价 | 说明 |
|---|---|
| 优 | |
| 劣 |
okd（openshift） 阶段
地址：https://docs.okd.io/
| 评价 | 说明 |
|---|---|
| 优 | |
| 劣 |
Rancher/RKE/TKE/容器服务阶段
RKE 地址：https://rancher.com/products/rke/
Rancher地址：https://rancher.com/products/rancher/
| 评价 | 说明 |
|---|---|
| 优 | |
| 劣 |
下一个阶段，servicemesh？
2020年初，我们经过评估，servicemesh的复杂性过高。
还需要等待技术更成熟，包括易用性，再考虑升级到servicemesh。