基于自动化发布流程多个可实现高效运维工具的实战应用分享_第1页
基于自动化发布流程多个可实现高效运维工具的实战应用分享_第2页
基于自动化发布流程多个可实现高效运维工具的实战应用分享_第3页
基于自动化发布流程多个可实现高效运维工具的实战应用分享_第4页
基于自动化发布流程多个可实现高效运维工具的实战应用分享_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

前言曾几何时,生产部署是一件令运维头痛的事,充满着大量沟通和手动操作,可以说几乎占据着运维人员一半以上的工作时间。在部署前期,架构师要把部署的架构和运维人员交代清楚,然后写成部署文档,运维人员要把这个文档中需要开墙的部分写成开墙需求提交网络管理人员,同时和系统管理人员,交代云上部署的虚拟机或云下部署的实体机,还需要申请上线的时间窗口。在部署期间,运维人员需要参照部署手册上的内容,一条条的实施部署,一个个的去启动应用,费时耗力,还很容易出错。一旦上线失败,就是责任事故,风险颇大。由于测试环境和生产环境的相对独立,有时一个微小的环境上的差异,会导致整个发布卡死甚至失败。而现在,自动化发布完全取代了原先的发布,在发布前期,运维人员通过Terraform构建的完全一致的基础架构,用GitOps的流水线使得发布的代码库的唯一性,使用Jenkins使得持续集成持续发布CICD自动化,使用kubenetes使得测试环境和测试环境完全一致。而在CICD中还集成的单元测试、代码质量检测和代码安全检测等多种功能。可以说,现在的生产发布,几乎是一种水到渠成的工程。完全解决的过去发布的痛点。而在经济大环境的影响下,很多企业都需要降本增效,Serverless正在被越来越多的引入到生产环境上来,很多其他平时的任务和作业适合于这种应用,甚至AWS在Database和Redis上相继推出的Serverless版,打破了业界的认知。所以,目前在对于云上的发布的流程基本上是,Terraform部署基础架构

->

Jenkins类的CICD工具发布应用

->

无服务化部署定时和事件触发的作业。本文将从如何建设自动化发布流程的原理入手,介绍各种工具的用法及如何实现,希望对大家有所帮助。1.整体设计与选型1.1设计我们设计的目标是把基础架构、应用部署、实时作业全部通过代码实现,实现完全自动化的目标。

1.2选型

1.2.1Terraform实际上已经是业界的一个标准,适用于各大公有云,适用性较广,可迁移性较强。在做适当修改后,在aws、tecent云也能部署。1.2.2

Jenkins不用我说,几乎每个开发都知道这个工具,我用过其他的CICD工具,比如ansible、tekton、argocd等,虽然其他工具也很灵活,但这同样也是缺点所在,太灵活导致配置太多了,如果要增加功能很多都需要客户化开发。而jenkins有大量的插件可供我们选择,可以实现低代码化。1.2.3Lambda每一个公有云目前都有自己的功能函数,AWS中的Lambda,aliyun中的FC,这些可以实现无服务化。下面,我将详述介绍这三个工具如何实现以及案例。2基础设施即代码2.1什么是基础设施即代码基础设施即代码是脚本自动执行基础结构和配置管理的一种方法。通过相应的工具集,您可以对物理环境的详细信息进行抽象,从而使您能够专注于重要的代码。基础设施即代码可以解决许多问题。例如,简化配置管理,确保您的基础设施的预配方式与预配方式相同。它不仅仅是文档,也是任何现代软件开发的版本控制的重要组成部分。2.2解决的问题过去我记得公司里有个系统管理员,此人是和IDC机房沟通最为频繁的人,在公司的作用非常重要。机房里所有的布线、交换机的部署和服务器的配置,他都了如指掌。当时的应用部署在就是VmwareESX管理的虚拟机上,必须先行部署实体机。运维人员要部署应用前,必须和他充分沟通,他会驱车赶往机房,然后环境马上就可就绪了。现在就无须这么麻烦了,除非是某些金融企业有自己的私有云需要打理,或某些企业有非常重要的应用必须私有化部署,一般的应用都部署在公有云上,而在公有云上的基础设施如果简单的话,完全可以手动部署。但是,公有云的架构复杂或有其他需求,如测试环境需求随时销毁重建时,或多账号部署需求环境完全一致时,我们就需要使用基础设施即代码,简称Iac(infrastructureascode),顾名思义就是运行代码的方式在部署云上环境。将基础设施部署为代码不仅意味着您可以将基础设施划分为模块化组件,并通过自动化以不同的方式组合它们,还可以通过自动配置服务器和操作系统来节省时间。开发人员每次创建应用时不必手动管理这些内容,从而节省时间。2.3如何实现Iac刚开始的时候,出现的是服务器自动化部署工具,就是如Cobbler、Ux-ignite等,这种类型工具是部署操作系统的,可以一键部署几十台甚至上百台的服务器,如图一。后来随着虚拟化的发展,Ansible可以承担所有虚拟服务器的自动化搭建。但这些功能都无法实现网络的自动化部署,这是一个硬伤。图一随着公有云的兴起,公有云的鼻祖Amazon推出了一种全新的自动化部署理念,并将其实现在Cloudformation中,Cloudformation通过模版来描述所有AWS上的资源,如图二。可以轻松地为您的AWS环境创建模板。抛弃了之前的配置手册。但是缺点也很明显,一就是代码无法转移到其他公司的云服务。图二其次就是官方文档虽然比较完整,但是要花一些时间才能找到如何在代码中设置更好的设置。由于GUI设置的名称和代码中的设置并不总是匹配的,因此可能有必要在某种程度上猜测内容,比如上面GUI图对应的部分代码如图三,从中可以看到,对于图中S3对象存储GUI,并没有办法匹配代码中所有的配置信息。图三也许是出于对以上缺点的考虑,出现了terraform这个工具,这个工具有如下特点:A.声明式配置:Terraform使用一种声明式的编程语言来描述和定义所需的基础设施资源,这种声明式配置方式使得用户可以清晰地定义所需的资源和其属性,而不需要关心底层的具体实现细节。B.版本控制:Terraform支持将基础设施配置代码存储在版本控制系统中,如Git,这使得用户可以轻松地跟踪和管理基础设施的配置历史,以及回滚到之前的版本。C.多云和混合云支持:Terraform可以与多个云服务提供商集成,如AWS、Azure、GoogleCloud等,用户可以使用Terraform来管理跨多个云平台的基础设施,实现资源的跨云迁移和复制。D.自动化部署和更新:Terraform通过执行计划来自动化基础设施的部署和更新过程,用户只需要编写一次基础设施配置代码,然后通过运行Terraform命令来创建、修改或删除资源。E.高可用性和可伸缩性:Terraform提供了一些高级功能,如故障恢复、负载均衡和自动扩展等,以确保基础设施的高可用性和可伸缩性。F.安全性和审计:Terraform支持对基础设施资源的访问控制和权限管理,以及对操作的审计日志记录,这有助于保护基础设施的安全性和合规性。2.4实际案例该案例要构建一个项目,在阿里云上构建三个VPC,分别为computerVPC,storageVPC,façadeVPC,其中computerVPC中放置一个ACK的容器集群,storageVPC中放置Rds、Redis、Kafka,façadeVPC中设置对外的ALB、MSE、SNAT等。三个vpc间用企联网CEN打通。为了高可用,设置了三个可用区,三个可用区结合三个VPC共设置九个vswitch。总体架构,如图四图四Terraform要对这个较为复杂的项目进行编码时,我们要设计一个总的项目目录tf-project,其中包含environmenst和modules两个文件夹,在environment中包含dev、prod两个目录。这体现了我们希望设计的目标,那就是modules共用,但环境的terraform代码和各自的目录下,如图五。图五在dev和prod的main.tf中,写出总体的设计代码,如下所示,其中locals并没有给出。module"vpc_computer"{source="../../modules/vpc"availability_zone=local.availability_zonevpc_name=local.vpc_computer_namevpc_cidr_block=local.vpc_computer_cidr_blockvsw_computer_node_cidrs=local.vsw_computer_node_cidrsvsw_computer_terway_cidrs=local.vsw_computer_terway_cidrs}module"vpc_storage"{source="../../modules/vpc"availability_zone=local.availability_zonevpc_name=local.vpc_storage_namevpc_cidr_block=local.vpc_storage_cidr_blockvsw_cidrs=local.vsw_storage_cidrs}module"vpc_facade"{source="../../modules/vpc"availability_zone=local.availability_zonevpc_name=local.vpc_facade_namevpc_cidr_block=local.vpc_facade_cidr_blockvsw_cidrs=local.vsw_facade_cidrs}module"secgroup"{source="../../modules/secgroup"vpc_id=module.vpc_facade.vpc_id}module"secdbgroup"{source="../../modules/secgroup"vpc_id=module.vpc_storage.vpc_id}module"ecs"{source="../../modules/ecs"region=local.regioninstance_name="bastion-01"vsw_id=module.vpc_facade.vsws_id[0]secgroup_id=module.secgroup.secgroup_id}module"ack"{source="../../modules/ack"k8s_name_prefix=local.ack_nameavailability_zone=local.availability_zoneack_vswitch_id=module.vpc_computer.vsws_computer_idack_terway_vswitch_id=module.vpc_computer.vsws_computer_terway_idack_service_cidr=local.service_cidr}module"rds"{source="../../modules/rds"instance_name=local.rds_instance_nameinstance_type=local.rds_instance_typeinstance_storage=local.rds_instance_storagesecurity_ips=local.rds_security_ipsvpc_id=module.vpc_storage.vpc_idvswitch_id=module.vpc_storage.vsws_idsecurity_group_ids=module.secgroup.secdbgroup_idavailability_zone=local.availability_zonedb_name=local.rds_db_namedb_account=local.rds_db_accountdb_passwd=local.rds_db_passwd}

module"redis"{source="../../modules/redis"db_instance_name=local.redis_instance_nameinstance_class=local.redis_instance_classsecurity_ips=local.redis_security_ipsvswitch_id=module.vpc_storage.vsws_idavailability_zone=local.availability_zoneaccount_name=local.redis_account_nameaccount_passwd=local.redis_account_passwd}

module"kafka"{source="../../modules/kafka"name=local.kafka_namepartition_num=local.kafka_partition_numdisk_type=local.kafka_disk_typedisk_size=local.kafka_disk_sizeio_max=local.kafka_io_maxspec_type=local.kafka_spec_typevswitch_id=module.vpc_storage.vsws_id[1]}

module

"mse"

{source="../../modules/mse"gateway_name=local.mse_gateway_namemse_spec=local.mse_specslb_spec=local.mse_slb_specvsw_id=module.vpc_computer.vsws_computer_terway_idvpc_id=module.vpc_computer.vpc_id}module"certs"{source="../../modules/certification"}module"alb"{source="../../modules/alb"alb_name=local.alb_gateway_nameload_balancer_edition=local.alb_editionaddress_type=local.alb_address_typevsw_id=module.vpc_facade.vsws_idvpc_id=module.vpc_facade.vpc_idacl_entries=local.alb_whitelistacl_name=local.alb_acl_nameserver_idip=module.pamse.mse_gateway_slb_ips[0]cert_id=[module.pacerts.cert_douyin_id,module.pacerts.cert_apollo_id,module.pacerts.cert_vue_id]}module"cen"{source="../../modules/cen"vpc_computer_id=module.vpc_computer.vpc_idvpc_storage_id=module.vpc_storage.vpc_idvpc_facade_id=module.vpc_facade.vpc_idvsws_computer_id=module.vpc_computer.vsws_computer_idvsws_computer_terway_id=module.vpc_computer.vsws_computer_terway_idvsws_storage_id=module.vpc_storage.vsws_idvsws_facade_id=module.vpc_facade.vsws_id}在modules文件夹中,是具体的每个组件实现的代码,如图六所示。图六可以看到,其中redis模块的main.tf中,包含了redis的配置、备份、账户信息。而在prod中的main.tf就可以对其调用。如图七所示。

图七2.5部署风险和应对Terraform的部署支持完整的回退销毁,使用命令terraformdestroy可以销毁所以使用terraformapply部署的基础组件,所以在生产上线前部署是非常安全的,一旦发现有部署不当,可以销毁、调整代码、重建。但是唯一的缺点就是不支持代码上的忽略,就是说,代码上有的组件必须部署不能忽略。这时,我们可以使用terraformrmstate,把不需要部署的组件从代码清单中去除。以后需要了再用terraformimport导入配置。3.应用部署即代码基础架构部署完后,接下来就要部署应用了。这也就是大家熟知的DevOps中的持续集成持续部署(CICD)。持续集成持续部署可以用很多工具来实现。3.1什么是持续集成持续部署3.1.1持续集成:A.集成:就是在一起:代码commit是集成(代码在一起),B.编译是集成(逻辑在一起);C.部署是集成(部署包跟环境在一起),D.测试是集成(功能在一起),E.灰度是集成(系统在一起)不断的做集成和集成结果的修正,就是持续集成;

3.1.2持续交付A.交付:就是将最终的产品发布到线上环境,给用户使用。B.持续交付描述的软件开发,是从原始需求识别到最终产品部署到生产环境这个过程中,需求以小批量形式在团队的各个角色间顺畅流动,能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈,并且在这个过程中,各个角色密切协作,相比于传统的瀑布式软件团队,更少浪费。3.1.3持续部署A.就是持续的将需求部署到目标环境上。B.持续交付的延伸就是持续部署3.2

持续集成持续部署的工具

工具上大致分为2大类,服务器CICD工具和容器CICD工具。3.2.1服务器CICD工具就是以服务器上的应用部署为主的部署,主要工具是ansible+git,slatstack+git等。此类工具在很长一段时间内盛极一时。成为很多大公司的不二之选,Ansible还得到很大的发展,出现了AnsibleTower等图形化应用自动化部署工具,如图八。图八3.2.2容器CICD工具就是以kubenetes容器应用为主的部署,主要工具就是Tiktok+ArgoCD,Jenkins等工具。此类工具是目前的主流,其中Tiktok+ArgoCD工具涉及到大量的配置和定制化的开发,使用较为不变,而Jenkins可以和groovy语句结合,并使用大量的plugins扩大起功能,所以在国内外使用非常广泛。下面对Jenkins在生产使用中的种种配置,一一介绍。Jenkins可以实现参数化部署(BuildwithParameter),这是最为常见的部署方式。在参数中,你可以定义环境、是否需要代码质量检测、版本号等诸多设置,如图九所示。图九Jenkins可以和gitlab、github、bitbucket等多种git工具结合,实现真正的GitOps,如图十。

图十在生产上Jenkins所有部署都不在Jenkisn上设置,都依赖从git中传来的的Jenkinsfile文件,如图十一。图十一3.3实际案例使用Jenkins+groovf来实现CICD部署,在工作中,一般我会遇到2种CICD的方案,一是CI和CD融合,完全流程化。这是在标准化非常成熟的团队使用的方案,大致的意思就是,在这个团队中,开发、测试、运维都实现了标准化,一个工程从研发分支、单元测试、性能测试,不同环境的部署都有详细的定义,流程被不择不扣的执行。二是CI和CD分离,部分流程化,其中加入了人为决定的环节,比如要上线时,什么功能能上线,什么功能要缓一缓要开发主管来决定,而不是由质量测试部门来决定。三是CI和CD部分融合,不完全流程化,比如在测试环境实现CI和CD融合,而在生产环境实现分离。本案例所示是第三种方案。下面是CI的Jenkinsfile的代码,使用ubuntu的agent,以下代码包括了checkout,update

theimage两个stage@Library(['xxxJenkinsLibrary@2','xxxxJenkinsLibrary'])_

importjava.text.SimpleDateFormatimportgroovy.json.JsonOutput

node('ubuntu_java-11_docker-20'){env.USER_EMAIL="xxxx@"env.USER="xxxx"env.TOKEN="sonar-xx-xxx-token"

node('ubuntu_java-11_docker-20'){env.USER_EMAIL="xxxx@"env.USER="xxxx"env.TOKEN="sonar-xx-xxx-token"env.SONAR_HOST_URL="/"env.PROJECT_NAME="xxxx.xxxx.java"stage('checkout'){checkoutscmcommitId=tools.git.getCommitId()version=BUILD_NUMBERdefsdf=newSimpleDateFormat("yyyyMMddHHmmss")env.COMPONENT=env.APP_NAMEenv.COMPONENT_COMMIT=commitIdenv.COMPONENT_VERSION=versionenv.DateTime=sdf.format(newDate())}//setdockerimagenameif(["develop"].any{branch->BRANCH_NAME.startsWith(branch)}){env.simplifiedBranchName='develop'}elseif(["release/","release","feature/","bugfix/","hotfix/","function/"].any{branch->BRANCH_NAME.startsWith(branch)}){env.simplifiedBranchName=BRANCH_NAME.toLowerCase().split('/')[0]}elseif(["PR-"].any{branch->BRANCH_NAME.startsWith(branch)}){env.simplifiedBranchName='pull-request'}elseif(['master'].any{branch->BRANCH_NAME.startsWith(branch)}){env.simplifiedBranchName='master'}else{env.simplifiedBranchName=''}if(env.simplifiedBranchName!=''){env.IMAGE_NAME=env.APP_NAME+"_"+env.simplifiedBranchName+":"+'-'+env.DateTime}if(["develop"].any{branch->BRANCH_NAME.startsWith(branch)}){env.DEPLOY_ENV='development'}else{env.DEPLOY_ENV=''}if(env.BRANCH_NAME=='develop'||env.BRANCH_NAME.startsWith('function/')||env.BRANCH_NAME.startsWith('bugfix/')||env.BRANCH_NAME.startsWith('feature/')||env.BRANCH_NAME.startsWith('release/')){stage('Uploadtheimage'){println"OMNI_COMPONENT_COMMIT=${OMNI_COMPONENT_COMMIT}"timeout(time:30,unit:'MINUTES'){withCredentials([string(credentialsId:ARTIFACTORY_CREDENTIAL,variable:'JFROG_KEY'),usernamePassword(credentialsId:ACR_DOCKER_CREDENTIAL,usernameVariable:'ACR_DOCKER_USERNAME',passwordVariable:'ACR_DOCKER_PASSWORD'),usernamePassword(credentialsId:ADI_DOCKER_CREDENTIAL,usernameVariable:'ADI_DOCKER_USERNAME',passwordVariable:'ADI_DOCKER_PASSWORD')]){sh"""#!/bin/bashset-xenvsubst'\\\\${JFROG_KEY}'<.mvn/settings.xml.template>.mvn/settings.xmldockerlogin${ADI_HARBOR_ADDR}-u${ADI_DOCKER_USERNAME}-p${ADI_DOCKER_PASSWORD}./mvnwcleanpackage-Dmaven.test.skip=true-s.mvn/settings.xml-Udockerlogin${ACR_HARBOR_ADDR}-u${ACR_DOCKER_USERNAME}-p${ACR_DOCKER_PASSWORD}dockerbuild-t${ACR_HARBOR_ADDR}/${ACR_NAMESPACE}/${IMAGE_NAME}--build-argOMNI_COMPONENT=${OMNI_COMPONENT}--build-argOMNI_COMPONENT_VERSION=${OMNI_COMPONENT_VERSION}--build-argOMNI_COMPONENT_COMMIT=${OMNI_COMPONENT_COMMIT}.dockerpush${ACR_HARBOR_ADDR}/${ACR_NAMESPACE}/${IMAGE_NAME}dockerrmi${ACR_HARBOR_ADDR}/${ACR_NAMESPACE}/${IMAGE_NAME}"""}}}上传镜像后,如果是测试环境,需要去调动CD流水线,执行发布,代码如下:if(env.IMAGE_NAME!=''&&env.DEPLOY_ENV!=''){stage("TriggerDeployment"){buildjob:env.DEPLOYMENT_PIPELINE,parameters:[string(name:'IMAGE_NAME',value:env.IMAGE_NAME),string(name:'environment',value:env.DEPLOY_ENV),string(name:'APP_NAME',value:env.APP_NAME)]}}最后一个stage是sendnotification,对相关人员的通知。if(env.BRANCH_NAME=='develop'||env.BRANCH_NAME.startsWith('release/')){stage('SendNotification'){defbody="BuildCompleted:${env.JOB_NAME}withbuildnumber${env.BUILD_NUMBER}(<${env.BUILD_URL}|Link)>itsresultwasunclear"if(currentBuild.currentResult=="SUCCESS"){body="Job:${env.JOB_NAME}\\\\nStatus:*SUCCESS*\\\\nBuildReport:${env.BUILD_URL}"}elseif(currentBuild.currentResult=="FAILURE"){body="Job:${env.JOB_NAME}\\\\nStatus:*FAILURE*\\\\nErrordescription:*Failedwhilebuildingapplication*\\\\nBuildReport:${env.BUILD_URL}"}elseif(currentBuild.currentResult=="UNSTABLE"){body="Job:${env.JOB_NAME}\\\\nStatus:*UNSTABLE*\\\\nErrordescription:*Unstablewhilebuildingapplication*\\\\nBuildReport:${env.BUILD_URL}"}timeout(time:5,unit:'MINUTES'){emailextbody:body,subject:'Deploymentresult',to:"${USER_EMAIL}",mimeType:'text/html',replyTo:"${USER_EMAIL}",compressLog:true}}}}在CD代码中,该项目使用kustomize实现对不同的环境,使用不同的配置进行部署,同样是如同terraform一样的目录结构,base目录是基本的配置,通常我们这里放的是开发环境的配置,而在overlay中的四个目录对应用于dev,staging、perprod,production四个环境,可以把对不同环境所对应的配置写在里面。如图十二所示。图十二比如,如果在测试环境中,我要加入pod反亲和力,来实现离散的pod部署,如图十三所示。图十三在CD流水线的jenkinsfile中,主要是对ack(k8s)cluster的部署,以下2个stage就是对k8s的部署和检查部署是否成功stage("deploydeploymenttok8s"){//Deployink8sif("${params.environment}"=='production'){//RequestuserinputinordertodeploytoProductionuserProviderInput(message:"DeployinProduction",timeout_message:"Thereisapending${APP_NAME}deploymentof${params.environment}in\\\\nPlease,confirmthedeployment*<${env.RUN_DISPLAY_URL}|here>*",)withCredentials([file(credentialsId:'svc-aliyun-ack-kubeconfig',variable:'KUBECONFIG')]){sh"chmod+w${KUBECONFIG}"sh"kubectlconfiguse-context${contexts[environment]}"sh"kustomizebuild./overlay/${environment}|kubectlapply-f--n${namespaces[environment]}"}}else{withCredentials([file(credentialsId:'svc-aliyun-ack-kubeconfig',variable:'KUBECONFIG')]){sh"chmod+w${KUBECONFIG}"sh"kubectlconfiguse-context${contexts[environment]}"sh"kustomizebuild./overlay/${environment}|kubectlapply-f--n${namespaces[environment]}"}}}stage("Checkdeploymentink8s"){withCredentials([file(credentialsId:'svc-aliyun-ack-kubeconfig',variable:'KUBECONFIG')]){sh"chmod+w${KUBECONFIG}"sh"kubectlconfiguse-context${contexts[environment]}"for(Stringitem:deployments[environment]){sh"""#!/bin/bashkubectlrolloutstatusdeploy${item}-n${namespaces[environment]}&waitprintf"TheDeploymenthasbeensuccessful!""""}}}3.4部署风险和应对在编写Jenkinspipeline时,一般由于疏忽和环境因素会遇到各种错误,但是一旦顺利跑通,再制定相应的操作SOP,那失败的风险就主要在于应用开发的错误。所以,Jenkinspipeline一般可以交付给开发使用,运维人员几乎不用操心。4.无服务部署4.1什么是无服务部署Serverless架构是采用FaaS(函数即服务)和BaaS(后端服务)服务来解决问题的一种设计。

FaaS就是Functionasaservice(函数即服务)。每一个函数都是一个服务,函数可以由任何语言编写,直接托管在云平台,以服务形式运行,通过事件触发。BaaS则是Backendasaservice(后端即服务)。云平台提供的后端组件整合,开发者无需开发和维护后端服务,通过API/SDK的调用,便可获得例如数据存储、消息推送、账号管理等能力。

4.2无服务部署的实质Serverless的背后,依然是虚拟机和容器。只不过,服务器部runtime安装、编译等工作,都由Serverless计算平台负责完成了。对开发人员来说,只需要维护源代码和Serverless执行环境的相关配置即可。这就叫“无服务器计算”。4.3无服务部署的优势Serverless架构的最大优势,显然就是帮助用户彻底摆脱了基础设施管理这样的“杂事”,更加专注于业务开发,从而提升了效率,降低了开发和运营成本。根据业界的统计,在商业和企业数据中心里的典型服务器,日常仅仅只提供了5%~15%的平均最大处理能力的输出。这是一种算力资源的巨大浪费。Serverless的出现,可以让用户按照实际算力使用量进行付费,属于真正的“精确计费”。4.4

实际例子在AWS中,运维需要把测试环境中的资源在休息日自动关闭,或在晚上关闭,以实现降本增效。这里用Lambda来取代pod的部署,可以实现用时收费,不同免费,这是Serverless的精神所在。以下是在aws的Lambda中,用python写下非常短小的代码://关闭服务器importboto3region='cn-north-1'

#Enteryourinstanceshere:ex.['X-XXXXXXXX','X-XXXXXXXX']

instances=[#nonprod-pms-bastion'i-xxxxxexxxxxxxxxxx']deflambda_handler(event,context):ec2=boto3.client('ec2',region_name=region)ec2.stop_instances(InstanceIds=instances)print('stoppedyourinstances:'+str(instances))//关闭DocumentDBimportboto3

deflambda_handler(event,context):docd

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论