重庆企业网站推广方案,张家界建设局网站电话号码,网站建设微信运营推广,网站后台乱码怎么办点击官网了解详情 本文作者#xff1a;何文强——腾讯云 CODING 高级架构师。 负责 CODING DevOps产品解决方案架构设计和技术产品布道以及 CODING 云原生技术研究与落地实践。在多个技术大会担任演讲嘉宾#xff0c;腾讯云 CODING DevOps 课程认证出品人#xff0c;腾讯云云… 点击官网了解详情 本文作者何文强——腾讯云 CODING 高级架构师。 负责 CODING DevOps产品解决方案架构设计和技术产品布道以及 CODING 云原生技术研究与落地实践。在多个技术大会担任演讲嘉宾腾讯云 CODING DevOps 课程认证出品人腾讯云云原生训练营核心初创成员。 精通敏捷精益、DevOps 和云原生领域技术扎实视野开阔格局前瞻在泛互、教育、工业、政务、金融等多个行业拥有数字化落地规划和实战经验多年技术开发和团队管理经验目前专注于一站式研发效能平台的建设和推广聚焦于“以应用为中心“的云原生的落地与实践致力于中国软件工程能力的提升和改进。 良好的实践需要遵循一定的原则通过原则指导的实践才能行稳致远。在云原生应用交付中可通过 The Twelve-Factor App应用 12 因素原则作为云原生应用交付实践的指南。 图5-1
应用 12 因素图5-1主要包括#1基准代码#2依赖#3配置#4后端服务#5构建、发布、运行#6进程#7端口绑定#8并发#9易处理#10开发环境与线上环境等价#11日志#12进程管理。接下来我们将详细介绍基于这 12 个原则的良好实践。
基准代码一份基准代码多份部署
基准代码和应用之间总是保持一一对应的关系
● 一旦有多个基准代码就不能称为一个应用而是一个分布式系统。分布式系统中的每一个组件都是一个应用每一个应用可以分别使用 12-Factor 进行开发。
● 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库然后使用 依赖管理 策略去加载它们。
在“一份基准代码多份部署”的良好实践中图5-2为一个应用的每个模块创建一个代码仓库选择 Master 分支作为基线并以 Master 分支构建镜像 Master 分支构建出来的镜像部署在不同的环境中即所有环境共享由 master 分支构建出来的镜像如 dev 环境、pre-production 环境、production 环境共享同一镜像。在基准代码实践中不同环境使用的镜像是同一份但是不同环境的配置信息不一致通过镜像与配置信息实现不同环境的部署。 依赖显示声明依赖
大多数编程语言都会提供一个打包系统用来为各个类库提供打包服务就像 Perl 的 CPAN 或是 Ruby 的 Rubygems 。通过打包系统安装的类库可以是系统级的或仅供某个应用程序使用部署在相应的目录中。
12-Factor 规则下的应用程序不会隐式依赖系统级的类库。 它一定通过依赖清单 确切地声明所有依赖项。此外在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
在“显示声明依赖”的良好实践中图5-3Python 通过 requirements.txt 显示声明所需要的第三方类库和组件并记录这些类库和组件的所有依赖和精确的版本号Gradle 通过 build.gradle(Maven 通过 pom.xml)的 dependencies 显示声明所需要的第三方类库和组件的所有依赖和版本号。通过显示声明依赖可以有效减少因错误的依赖版本导致的缺陷提升软件供应链的可见性。 图5-3
配置在环境中存储配置
通常应用的 配置 在不同 部署 (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括
● 数据库Memcached以及其他后端服务的配置
● 第三方服务的证书如 Amazon S3、企业微信等
● 每份部署特有的配置如域名等。
有些应用在代码中使用常量保存配置这与 12-Factor 所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在大幅差异代码却完全一致。
在“在环境中存储配置”的良好实践中图5-4将配置管理信息存储在 Git 仓库中对配置进行版本化管理不同环境的配置通过不同分支进行区分和管理如 reviews 模块中每个环境创建一个配置管理分支如 test-folder-ref 分支存储 dev 环境的配置信息、test-base 分支存储 pre-production 环境的配置信息、master 分支存储 production 环境的配置信息实现应用配置与运行环境的对应。
* 图5-4*
在“在环境中存储配置”的良好实践中图5-4应将应用的配置存储于环境变量中。在 Kubernetes 应用中可通过 ConfigMap 和 Secret 对象的 Key-Value 存储配置信息为不同环境创建不同的 ConfigMap 和 Secret不同环境的 ConfigMap 和 Secret 的 Key 相同但是 Value 不同在容器环境变量中引用 ConfigMap 和 Secret 的 Key实现不同环境不同 Value 的注入并在应用启动时加载注入到容器环境的 Key获取到对应环境的 Value。通过将应用的配置存储于环境变量中可以有效管理不同环境的配置。
后端服务把后端服务当做附加资源
后端服务是指程序运行所需要的通过网络调用的各种服务如数据库MySQL消息/队列系统RabbitMQSMTP 邮件发送服务Postfix以及缓存系统Redis。
12-Factor 应用不会区别对待本地或第三方服务。 对应用程序而言两种都是附加资源通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。12-Factor 应用的任意 部署 都应该可以在不进行任何代码改动的情况下将本地 MySQL 数据库换成第三方服务例如 Amazon RDS。
在“把后端资源当做附加资源”的良好实践中图5-5Review 服务所依赖的 MySQL 服务和 Redis 服务都是独立部署的应用服务和附属的后端服务保持松耦合通过协议的方式进行访问(MySQL 通过 MySQL 协议Redis 通过 Redis 协议)。通过“把后端服务当做附加资源”部署可以按需加载或卸载资源如 MySQL 服务异常可从备份中快速恢复卸载当前数据库然后加载新的数据库而不需要修改代码。 图5-5
构建、发布、运行严格分离构建和运行
基准代码 转化为一份部署(非开发环境)需要以下三个阶段图5-6-1
● 构建阶段 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码获取和打包 依赖项编译成二进制文件和资源文件。
● 发布阶段 会将构建的结果和当前部署所需配置相结合并能够立刻在运行环境中投入使用。
● 运行阶段 或者说“运行时”是指针对选定的发布版本在执行环境中启动一系列应用程序 进程。 图5-6-1
在“严格分离构建和运行”的良好实践中图5-6-2代码提交到 CODING 代码库后通过 CODING 持续集成将源代码打包构建为二进制文件将二进制文件存储在 CODING 制品库中二进制文件和配置信息组成发布包通过 CODING 持续部署选择指定发布包进行程序发布。通过“严格分离构建和运行”可以更好的实现职责和关注点的分离同时将代码打包成二进制文件是一种不可变基础设施的体现禁止通过 patch 等方式修改运行时的代码有利于代码的同步和二进制文件的一致性和完整性。 图5-6-2
进程以一个或多个无状态进程运行应用
运行环境中应用程序通常是以一个和多个进程运行的。
无状态应用程序是一种应用程序它不会保存在一个会话中生成的客户端数据以便在与该客户端的下一个会话中使用。每个会话都像第一次一样进行响应不依赖于前一个会话的数据。相反有状态应用程序保存有关每个客户端会话的数据并在客户端下次发出请求时使用该数据。
12-Factor 应用的进程必须无状态且无共享。任何需要持久化的数据都要存储在后端服务内比如数据库。
在“以一个或多个无状态进程运行应用”的良好实践中图5-7在应用设计时需要将应用设计为无状态应用程序同时在 Kubernetes 中采用 Deployment 对象进行声明式部署。 图5-7
端口绑定通过端口绑定提供服务
12-Factor 应用完全自我加载 而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务 并监听发送至该端口的请求。
将网络服务器类库通过依赖声明载入应用。例如Python 的 Tornado, Ruby 的Thin , Java 以及其他基于 JVM 语言的 Jetty。完全由用户端 确切的说应该是应用的代码发起请求和运行环境约定好绑定的端口即可处理这些请求。
在“通过端口绑定提供服务”的良好实践中应在 Dockerfile 中指定端口该端口与应用绑定的端口一致在镜像构建时会将 Dockerfile 中指定的端口进行暴露和通信。应用访问可直接通过 Dockerfile 构建的镜像暴露的端口进行访问。在云原生环境下可在 Kubernetes 的 yaml 文件中的 containerPort 绑定 Dockerfile 中暴露的端口实现 Kubernetes 资源与 Docker 镜像端口的绑定。端口绑定这种方式也意味着一个应用可以成为另外一个应用的 后端服务 调用方将服务方提供的相应 URL 当作资源存入配置以备将来调用 图5-8
并发通过进程模型进行扩展
任何计算机程序一旦启动就会生成一个或多个进程图5-9-1。互联网应用采用多种进程运行方式。
在 12-factor 应用中进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模。12-Factor 应用的进程所具备的无共享水平分区的特性 意味着添加并发会变得简单而稳妥。这些进程的类型以及每个类型中进程的数量就被称作进程构成 图5-9-1
在“通过进程模型进行扩展”的良好实践中图5-9-2面对并发提倡通过水平扩展进程的数量增加应用的副本数量即部署多个相同资源的进程而非垂直扩展进程的容量如增加单一进程的CPU、内存等资源。在云原生应用中可充分利用Kubernetes的水平缩扩容的能力。通过设置repilcas的值来调整副本的数量这种水平横向扩展进程的方式让并发变得简单、高效和安全。 图5-9-2
易处理快速启动和优雅终止可最大化健壮性
12-Factor 应用的进程是易处理disposable的意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用迅速部署变化的代码或配置 稳健的部署应用。
进程应当追求最小启动时间 。理想状态下进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间。更少的启动时间提供了更敏捷的发布以及扩展过程此外还增加了健壮性因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上。
进程一旦接收终止信号SIGTERM 就会优雅的终止 。就网络进程而言优雅终止是指停止监听服务的端口即拒绝所有新的请求并继续执行当前已接收的请求然后退出。
快速启动良好实践
在“快速启动”的良好实践中图5-10采用 Docker 镜像方式进行应用打包Docker 镜像中包含应用本身及其所有的运行时依赖能够快速复制到新环境中并能够快速进行应用的部署。同时Docker 镜像具备强大的跨平台和可移植性可以快速将进程迁移到新的服务器上。
优雅终止良好实践
在“优雅停机”良好实践中图5-10有两个层面可进行设置第一个层面是应用层面若采用 Springboot 框架开发的应用可在 Springboot 中进行优雅停机参数配置通过设置 shutdown: graceful 即可实现应用的优雅终止。第二个层面是 Kubernetes 层面在 Kubernetes yaml 配置中可以通过 lifecycle 生命周期的 preStop 钩子设置 terminationGracePeriodSeconds即可实现容器镜像的优雅终止。通过在应用配置层面和 Kubernetes yaml 中的镜像层面进行优雅终止设置可实现应用优雅停机。 图5-10
开发环境与线上环境等价尽可能保持开发环境预发布环境线上环境相同。
从以往经验来看开发环境即开发人员的本地 部署和线上环境外部用户访问的真实部署之间存在着很多差异。这些差异表现在以下三个方面
● 时间差异 开发人员正在编写的代码可能需要几天几周甚至几个月才会上线。
● 人员差异 开发人员编写代码运维人员部署代码。
● 工具差异 开发人员或许使用 NginxSQLiteOS X而线上环境使用 ApacheMySQL 以及 Linux。
12-Factor 应用想要做到 持续部署 就必须缩小本地与线上差异
传统应用12-factor 应用每次部署间隔数周几小时开发人员 vs 运维人员不同的人相同的人开发环境 vs 线上环境不同尽量接近
在“尽可能保持开发环境预发环境线上环境相同”的良好实践中图5-11。在时间差异上通过 CODING CI/CD 流水线缩短部署实践并且可以采用自动化的方式加速应用的交付速度降低每次部署间隔实践在人员差异上采用谁开发谁构建谁运行原则通过设置开发、构建、发布运行权限实现开发运维一体化授权团队具备端到端交付能力在工具差异上反对在不同环境中使用不同的后端服务尽最大努力消除使用上的差异同时使用 IaC基础设施即代码工具如Terraform进行各类环境资源的创建和维护并将 IaC 配置信息存储到代码库中在 CI/CD 根据 IaC 配置自动创建环境资源实现各类环境的等价。 图5-11
日志把日志当做事件流
日志使得应用程序运行的动作变得透明。在基于服务器的环境中日志通常被写在硬盘的一个文件里但这只是一种输出格式。
日志应该是事件流的汇总将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行日志最原始的格式确实是一个事件一行。日志没有确定开始和结束但随着应用在运行会持续的增加。
12-factor 应用本身从不考虑存储自己的输出流。 不应该试图去写或者管理日志文件。相反每一个运行的进程都会直接的标准输出stdout事件流。开发环境中开发人员可以通过这些数据流实时在终端看到应用的活动。
在“把日志当做事件流”的良好实践中(图5-12)应该使用 logstash 或 Loki 等工具以事件流的方式对日志进行输出并将输出的事件流发送到 SplunkElasticSeach 等日志索引及分析系统中统一对日志进行存储和检索图5-12的良好实践。日志信息不应该以文件的形式存储在运行节点的磁盘上图5-12的不良实践。 图5-12
管理进程 后台管理任务当做一次性进程运行
进程构成process formation是指用来处理应用的常规业务比如处理 web 请求的一组进程。与此不同开发人员经常希望执行一些管理或维护应用的一次性任务例如
● 运行数据移植如数据库定期备份。
● 运行一个控制台 或是其他命令如定期线上数据库状态检查。
● 运行一些提交到代码仓库的一次性脚本。如应用部署前运行数据库脚本
在“后台管理任务当做一次性进行运行”的良好实践中应充分利用 Kubernetes 的 Job 和 CornJob 对象图5-13。对于只执行一次的后台管理任务如应用部署前进行数据库表结构和表数据的导入可以使用 Kubernetes Job 对象进行一次性进程的管理对于重复性的后台管理任务如每日凌晨两点对数据库进行备份可以使用 Kubernetes CronJob 对象进行重复性进程的管理通过设置 CrobJob 中的 schedule 的 Cron 表达式即可实现重复性后台管理任务的执行。 图5-13
点击这里前往 CODING 体验
