内容简介:本技术方案为基于Kubernetes为核心的持续部署(下文简称CD)方案,可以满足开发方的程序级日志查看分析,运维方的快速扩容与日常运维分析,并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升,在不降低服务可靠性的前提下降低资源使用成本。本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程,在Kubernetes方案中,所有的Node节点均采用统一配置,根据业务环境的需求进行节点数量的控制
方案概述
本技术方案为基于Kubernetes为核心的持续部署(下文简称CD)方案,可以满足开发方的程序级日志查看分析,运维方的快速扩容与日常运维分析,并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升,在不降低服务可靠性的前提下降低资源使用成本。
使用场景分析
本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程,在Kubernetes方案中,所有的Node节点均采用统一配置,根据业务环境的需求进行节点数量的控制
技术架构与选型
- Kubernetes:一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署,规划,更新,维护的一种机制。
- Nginx:一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。
- Harbor:Harbor是一个用于存储和分发 Docker 镜像的企业级Registry服务器,通过添加一些企业必需的功能特性,例如安全、标识和管理等,扩展了开源Docker Distribution。
- Jenkins:一个开源软件项目,是基于 Java 开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
- Filebeats:是一个日志文件托运工具,在你的服务器上安装客户端后,Filebeat会监控日志目录或者指定的日志文件,追踪读取这些文件(追踪文件的变化,不停的读),并且转发这些信息到Elasticsearch或者Logstarsh中存放。
- Elasticsearch:是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。
- Kibana是一个开源的分析和可视化平台,设计用于和Elasticsearch一起工作来搜索,查看,并和存储在Elasticsearch索引中的数据进行交互。
- GitLab自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目(这里的Gitlab并不涉及到开发的CI方案,主要为运维的CD方案)。
- Weave Scope Docker和Kubernetes可视化监控工具。Scope提供了至上而下的集群基础设施和应用的完整视图,用户可以轻松对分布式的容器化应用进行实时监控和问题诊断。
Kubernetes集群部署模式:Stacked etcd topology
Kubernetes的安装使用kubeadm安装为高可用集群,并选用Stacked etcd topology 模式。
详情参考 https://kubernetes.io/docs/set ... lity/
Kubernetes生态技术选型:网络层面选型Weave
容器网络解决方案。Weave创建的虚拟网络可以将部署在多个主机上的容器连接起来。对容器来说,Weave就像一个巨大的以太网交换机,所有容器都被接入这个交换机,容器可以直接通信,无需 NAT 和端口映射。
原理详解: http://dockone.io/article/262
Kubernetes生态技术选型:对外服务选型NodePort
Kubernetes目前支持NodePort、LoadBanlace、Ingress三种对外提供服务的模式,其中LoadBanlace需要云平台的支持,阿里云提供了解决方案,但腾讯云未找到,Ingress技术为新出技术。整体评估采用NodePort方式更为灵活,每个服务一个唯一的对外IP地址,并且使用Nginx进行负载均衡(采用Nginx主要为日志分析)。
介绍与使用方法: https://kubernetes.io/docs/con ... eport 。
持续部署过程
- Jenkins构建时,需要传入程序版本号,构建类型(发布还是删除),程序类型(测试还是正式)。
- CD的全过程由位于Jenkins上的脚本执行
- 开发部将对应版本的ROOT.war传入Jenkins指定目录
- 下拉配置(包含config,hosts,dockerfile,k8syaml等等)
- 由Dockerfile生成Docker容器,并将root.war,hosts与配置文件内置入容器中
- 将Docker容器打包并推送入Registry
- 通过kubectl通过k8syaml更新/生成新的服务
各组件业务配置
Kubernetes业务配置
命名空间
在业务上,Kubernetes默认配置两套Namespace,分别为Master存放正式环境,Develop配置测试环境。
对外端口
正式环境Web端口以32001开始,测试环境以31001开始,且一一对应。
Master数据目录
/data └── k8s-cd-config └── test.gyyx.cn ├── develop │ └── v1.2.0-92-3fdd00f.yaml ├─develop.yaml -> /data/k8s-cd-config/test.gyyx.cn/develop/v1.2.0-92-3fdd00f.yaml ├── master │ └── v1.2.0-91-746284e.yaml └──master.yaml->/data/k8s-cd-config/test.gyyx.cn/master/v1.2.0-91-746284e.yaml
K8s-Master下的data目录下为k8s-cd-config, k8s-cd-config目录存放各业务的yaml配置,二级目录为域名,三级目录划分Master(正式),Develop(测试),目录下以 版本号-构建ID-GITID.yaml 命名文件,时间最后一个即为当前线上的使用配置文件,为了运维方便,在二级目录同级内,生成一个软链连接到最新的正式与测试配置文件。注意,k8s-cd-config仅在其中一台Master中存在。
Node数据目录
/data ├── filebeat ├── dockerlibs └── nodelogs ├── develop │ ├── accesslogs │ │ └── test.gyyx.cn │ │ └── test-gyyx-cn-76d9d8d5b5-hdnql │ │ └── localhost_access_log.2018-12-24.txt │ ├── devlogs │ │ └── test.gyyx.cn │ │ └── test-gyyx-cn-76d9d8d5b5-hdnql │ │ └── interface.datareport.wyx.cn │ │ ├── error.log │ │ ├── info.log │ │ └── trace.log │ └── tomcatlogs │ └── test.gyyx.cn │ └── test-gyyx-cn-76d9d8d5b5-hdnql │ ├── catalina.2018-12-24.log │ ├── host-manager.2018-12-24.log │ ├── localhost.2018-12-24.log │ └── manager.2018-12-24.log └── master ├── accesslogs │ └── test.gyyx.cn │ └── test-gyyx-cn-895cc5994-sx7gk │ └── localhost_access_log.2018-12-24.txt ├── devlogs │ └── test.gyyx.cn │ └── test-gyyx-cn-895cc5994-sx7gk └── tomcatlogs └── test.gyyx.cn └── test-gyyx-cn-895cc5994-sx7gk ├── catalina.2018-12-24.log ├── host-manager.2018-12-24.log ├── localhost.2018-12-24.log └── manager.2018-12-24.log
节点下的/data一级目录下分Filebeat、Dockerlibs、Nodelogs,其中Dockerlibs存放Docker相关数据,Nodelogs目录通过volume的方式挂载入Kubernetes的Pod, Nodelogs下分Develop与Master目录,区分正式环境与测试环境,每个Master与Develop下分为accesslogs、devlogs、tomcatlogs分别存放访问日志,开发部日志,Tomcat日志,日志目录下为项目(域名),域名下为Pod名称目录。
注意事项: 节点加入集群后,一定要下载手工下载kubernetes-dashboard-amd64镜像,防止dashboard所在节点挂掉以后dashboard无法在其他节点启动。
Harbor业务配置
业务分组
Harbor重定义其Registry的存储路径直接使用docker-compose安装。template 存放基础进项,各域名分组存放业务镜像。
镜像命名
分组下镜像以站点域名:版本号-类型-CDGITLAB为名称,并基于版本号确定不同的站点版本。
数据目录
Harbor数据目录统一存放在/data下。
备份策略
Harbor默认不设置备份,对于业务镜像无需进行备份,每次进行构建即可,对于模板类镜像,在Jenkins机器上均可以找到,若Harbor出现问题,则直接重建,并将Jenkins上的模板镜像进行重新push。
注意:为了业务的稳定性,Harbor由独立的服务运行(基于Docker),并不运行在Kubernetes内。
Jenkins业务配置
数据目录
. ├── dockerlibs ├── thinbackups └── gitlab-files │ └── gyyx.cn │ └── test.gyyx.cn └── jks-cd-config └── test.gyyx.cn └── v1.2.0 ├── develop │ └── 101_138a37a │ ├── … │ └── v1.2.0-101-138a37a.yaml ├── master │ └── 102_4f228a7 │ ├── … │ └── v1.2.0-102-4f228a7.yaml └── ROOT.war
Jenkins下的data目录分为dockerlibs、thinbackups、gitlab-files 、jks-cd-config。
Dockerlibs存放Docker相关文件,thinbackups存放每日的Jenkins备份,gitlab-files存放构建GitLab的文件(运维可以在此操作pull,push),jks-cd-config为jks构建目录。
Jenkins机使用/data/jks-cd-config目录存放构建内容,二级目录为域名,三级目录为版本号(以开发部版本号为准),三级目录下存放ROOT.war,四级目录为构建ID_GITID,目录下存放构建的原始数据。
节点每天进行images清理工作。
业务分组
Jenkins的分组分为template与各domain,template存放模板,domain以域名的形式存放正式项目:
新项目由运维手工创建,后续的秩序构建过程由开发部调用API完成。
构建参数
Jenkins构建时,需要传递三参数,1:程序版本号,2:类型:apply与delete,3:正式环境还是测试环境,正式环境为Master,测试环境为Develop,对应Kubernetes的Namespace。
此部分功能后期将通过开发部的构建凭条调用JenkinsAPI实现。
JenkinsAPI
curl -X POST http://jenkinsapi.com/job/域名/build \ –user admin:11b80a61d260aa41eb4a43ef0115bcbb26 \ –data-urlencode json=’{“parameter”: [{“name”:”VERSION”, “value”:”v1.2.0”}, {“name”:”TYPE”, “value”:”apply”}, {“name”:”BRANCH”, “value”:”develop”}]}’
APIDoc: https://wiki.jenkins.io/displa ... 2BAPI
Token: https://jingyan.baidu.com/arti ... .html
备份策略
Jenins安装ThinBackup插件,配置每小时进行一次全局备份,且最多保留10份,备份后数据传至异地。
注意:为了业务的稳定性,Jenkins由独立的服务运行,并不运行在Kubernetes内。
GitLab业务配置
业务分组
CD GitLab项目下分两个组template与各domain,template存放模板文件。例如:
Git分支
default下以域名划分项目,每个项目划分Master与Develop两个分支,分别存放正式环境与测试环境CD文件。
CD文件树
├── catalina.sh #tomcat配置文件 ├── config #程序配置文件,此文件夹会替换掉容器内的/data/conf │ └── hello.conf ├── deployment.yaml #k8s deploymen配置 ├── dockerfile #docker镜像生成文件 ├── hosts #docker镜像的hosts,此文件将合并到deployment.yaml ├── service.yaml #k8s service配置 └── tomcat #tomcat配置文件 ├── Catalina │ └── localhost ├── catalina.policy ├── catalina.properties ├── context.xml ├── logging.properties ├── server.xml ├── tomcat-users.xml └── web.xml
备份策略
GitLab使用gitlab-rake gitlab:backup:create进行每日定期备份,并传送至异地。
EFK与日志管理
Elasticsearch
ES数据通过索引仅保留近10天的数据,每日通过脚本方式进行数据删除。ES的数据保存在/data/elasticsearch目录下。
Filebeat
在每个Node节点启动一个Filebeat进程,用于日志的采集工作,filebeat分别监控:
- /data/nodelogs//accesslogs///
- /data/nodelogs//devlogs///
- /data/nodelogs//tomcatlogs///
其中,tomcatlogs日志需要进行特殊处理,进行多行合并,数据写入ES时,使用processors. Dissect进行目录名称截取,并使用域名作为ES的索引使用。
processors: - dissect: tokenizer: "%{?key1}/%{?key2}/%{?key3}/%{wtype}/%{ltype}/%{domain}/%{?key7}/%{?key8}" field: "source" target_prefix: "gy"
截取gy. wtype ( master或develop) , ltype(accesslogs 、tomcatlogs、devlogs),domain(xxx.gyyx.cn)。
Kibana
Kibana目前我们仅使用其discover节点,用于日志数据的查询,在配置方面。
Kibana配置使用”域名-*”方式进行配置,每次新增域名,需要在此进行手工配置。
Kibana使用discover查看时,默认展示一个域名下所有的日志,可以通过gy.wtype筛选选择查看测试环境还是正式环境,或者通过gy.ltype哪种日志类型。
容器资源监控
容器资源使用WeaveScope进行资源消耗监控。
原文链接: http://www.toryzen.cn/2018/12/30/ 基于kubernetes的持续部署(CD)方案/
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 前端自动化部署方案探索
- Golang基于Gitlab CI/CD部署方案
- Golang基于GitLab CI/CD部署方案
- golang jenkins部署及slb平滑上线方案
- 企业MySQL5.7.20多实例部署方案
- K8S1.14高可用生产集群部署方案
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
算法技术手册
[美]海涅曼 (Heineman.G.T.)、[美]波利切 (Pollice.G.)、[美]塞克欧 (Selkow.S.) / 东南大学出版社 / 2009-4 / 58.00元
创造稳定的软件需要有效的算法,但是程序设计者们很少能在问题出现之前就想到。《算法技术手册(影印版)》描述了现有的可以解决多种问题的算法,并且能够帮助你根据需求选择并实现正确的算法——只需要一定的数学知识即可理解并分析算法执行。相对于理论来说,本书更注重实际运用,书中提供了多种程序语言中可用的有效代码解决方案,可轻而易举地适合一个特定的项目。有了这本书,你可以: 解决特定编码问题或改进现有解决......一起来看看 《算法技术手册》 这本书的介绍吧!