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

最新推荐文章于 2024-01-14 09:00:00 发布

jimninh

最新推荐文章于 2024-01-14 09:00:00 发布

阅读量1.1k

点赞数

分类专栏：容器化与DevOps落地之路

本文链接：https://blog.csdn.net/hjmhz/article/details/106796263

版权

容器化与DevOps落地之路专栏收录该内容

4 篇文章 0 订阅

订阅专栏

容器平台，难落地

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

容器平台成果与技术图谱

容器平台难落地，也难在涉及多层次的技术。
涉及网络、容器、应用框架（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

pic/tsp-tech-stack-m1.png

神器： 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，的截图。 pic/rancher-idc-hh-dev-workload.png

私有云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访问生产、域名生成。
pic/gitlab-cicd-feature-branch-1.png
pic/runner-docker-compose-4.png

巧妙设计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 有灰度

pic/proj-container-env-plan.png
pic/branch-model-with-cicd.png

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

开发小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 流水线，支持自动部署。
pic/gitlab-cicd-feature-branch-1.png
要点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
pic/runner-docker-compose-4.png
要点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配置？微服务化后，难！难在人工工作量大，难在人工缺乏规范性。
pic/host-app-vs-docker-app.png
pic/kubenetes-app-visit-demo.png
难点2：用NodePort 端口有限，不直观，人工配置