GitChat · 运维 | 深入了解 Azure 云平台容器技术服务

原创 2017年09月11日 13:51:19

GitChat 作者:赵文婧
原文:深入了解 Azure 云平台容器技术服务
关注公众号:GitChat 技术杂谈,一本正经的讲技术

容器VS虚拟机

enter image description here

容器和虚拟机作为虚拟化技术,为我们提供了一个隔离的、独立的运行环境,但两者最大的不同之处是容量具有轻量级的优势,上图可以看到,每个虚拟机内部都有完整的操作系统,但一个主机上运行的多个容器是共享Linux内核的,容器和虚拟机的不同之处可以分为以下几点:

  • 操作系统:虚拟机有完整的操作系统,容器共享内核。

  • 体积:虚拟机包含完整的操作系统,才创建过程中要给其分配一定量的内存去支持运转,所以虚拟机比容器的体积更大,消耗资源更多。

  • 启动:在启动虚拟机的过程当中要从操作系统去启动,因此启动较慢,而容器的启动时间是秒级的。

enter image description here

Docker是容器技术发展过程的重要变革,其ICON实鲸鱼驮着非常多的集装箱,这些集装箱即容器,它带来的主要变革有:提供了一套标准化的流程,可以用这个标准化的借口去将自己的应用进行镜像打包,然后在不同的平台上部署和运行,Docker的寓意是码头工人,而它在我们部署运行的过程中起到的是绿色迁移作用。

若把容器迁移过程想象为以集装箱为核心的运输体系,那概念之间可以这样对应:容器是集装箱,云服务提供商是装载集装箱的港口,云服务商提供一些IaaS的服务可以理解为装载集装箱的拖船,同时在进行部署运行的过程中有一套标准化的流程,可以将其看做装运流程。

随着容器的不断发展,可以看到可以看到容器在云平台和物理机平台会形成一个绿色迁移发展,总结了容器的这两个非常重要特点之后,接下来看一下Azure都提供了哪些容器服务。

enter image description here

Azure提供最重要的容器服务名为:Azure Container Service,首先,对于云平台来说,它提供的很重要的资源是Infrastructure,无需购买虚拟机配置分布式集群,云平台提供了基础的框架如Azure上提供的虚拟机,它也会有其自己的Scale Sets,这些虚拟机会根据需求扩展VM的Sets,也会提供一些Availability Sts,帮助实现高可用。

有了基础设施的架构,即可方便地在云平台索取自己的一些计算机资源,在Infrastructure上,Azure Container Service提供了多种不同的编排工具,因为业务所用的容器是跨主机的,此时容器和容器之间需要进行通信、数据管理、网络管理等,编排工具可以帮助实现跨主机容器应用管理,Azure Container Service提供了三种主流的编排工具:Kuberntes、Swarm、DC/OS,可按需求自行选择。

众所周知,Kubernetes内部具有一些非常复杂的资源类型,虽然它提供了很多重要的功能,但在使用时也会非常繁琐,这里有一些工具可以帮助更好地使用Kuberentes,如DEIS这家公司的Helm和Draft。

  • Helm相当于软件包的管理器,类似于Linux上的Apt-Get或Yum,通过Helm可以自动获取一些名为Helm Chart的软件包去快速构建部署Kuberentes集群上的应用。

  • Draft能够自动识别应用的语言,帮助去写Dockerfile和Helm Charts以及快速的构建部署引用,同时,Kuberntes是谷歌根据多年的系统经验做的编排工具,Kuberentes的创始人后来也加入了微软支持Azure。

之前说到的Infrastructure和以上编排工具都通过Azure的ARM模型进行构建,大家知道AWS有Cloud Formation,阿里云上有Resource Orchestration,类似于这种模板文件,Azure上有自己的ARM文件,可以用一些很简单的输入,通过ARM模板在Azure进行部署,除了可以在Azure的Portal上或Azure CLI上去创建Azure Container Service,也可以通过ACS的Engine去创建,使用一些简单输入的定义文件用ACS Engine转化为ARM模板,从而快速去创建部署,ACS Engine现在是开源在GitHub上的,用户可以在其中快速更改自己的部署,从而进行一些自定义的容器服务,我们也希望这些开源的代码能够对社区做出贡献,也帮助我们ACS的服务更快更好地发展。

微服务+容器化

enter image description here

之前了解了Azure Container Service提供的一些服务,下面再分享下微服务和容器化如何更好的结合,在集群部署的情况下,Azure Container Service在哪些方面起到相关作用。

首先,单体的应用。在集群部署的过程中和容器化的应用在集群部署的过程中有什么区别,提到微服务,简单地说即应用程序有多少独立的组件,希望它们能够独立的进行开发测试以及运行,但假设一些单体的应用向把它部署到集群上时,为了实现高可用,将它在集群上的每个节点都进行部署,但对于容器化的应用,可以把这些应用拆分成多个独立的组件,每个独立的组件都能放在容器之中,为它提供一个独立的运行环境,此时,当应用的模块组件放在分布式集群这些节点上时,即可自动地去根据分布式节点的计算资源调整模块分布的位置,假如在ACS部署了一个集群,ACS会帮助做一些负载均衡及网络管理的设置,可以在容器集群上更好地部署容器化应用。

DevOps

enter image description here

说到DevOps,目前很难给它做一个具体的定义,但其主要目的是在应用开发测试以及运行过程中做一个更好地衔接,使应用更新能够快速地进行发布,从而提升提升效率,所以DevOps和容器的特性不谋而合。

通过容器技术可以达到一次编写部署,在这个基础上构建敏捷的DevOps开发若把应用构建在云上,使用Azure上的容器服务,有一些工具可以使用如:Azure Container Registry,可以在它上面构建私有的镜像仓库,其中存储着Docker格式的镜像,此仓库可以与Azure Container Service提供的编排引擎进行集成,如果想在Kubernetes集群上进行应用部署,可直接从这个镜像仓库中Push一个镜像在上面运行,这个Push下来的过程即可直接写在Kubernetes相关的部署文件当中。

镜像仓库是可以和Docker的镜像仓库兼容的,所以如果使用的是Docker工具,也可以进行无缝迁移,同时在Azure上使用容器化服务以及一系列持续集成工具链包括Visual Studio Visual Studio Team Service以及Visual Studio Code,通过一系列的集成工具链即可构建版本代码库,同时进行人员分配的管理调度,达到更好的持续集成、持续交付概念。

Demo:用ACS服务运行应用

enter image description here

接下来会为大家用比较多的时间演示Demo:在ACS上创建一个服务,并运行应用。

第一步:创建ACS的服务

有两种方式:

  • 在Portal里面进行创建。

  • 在Azure的CLI里面进行创建。

首先,这是Azure的Portal,进到里面创建Azure Container Service,可以自定义服务名称,因要使用Kubernetes,我定义这样一个名字,选择资源组,接下来定义Master节点的属性,可以看到很多编排工具可以选择,选择Kubernetes,重新再来看下,最上面可以选择三种不同的编排引擎,接下来我们会定义Master节点的用户名,然后用SSH的Key去登录我们的Portal。

将SSH的Key生成完毕后,直接粘进去,下面是在创建服务时需要一个服务主体,之前已经创建好了,使用它的ID和密码,这里可以设置Agent节点的数量以及设置VM的Size,我们确认信息,然后即可创建Kuberentes的集群了,同样还有另外一种方法可以进行Azure的CLI里,用Az Acs Create 这样的命令来创建自己的集群,那么在这里我们可以指定我们的编排引擎,接着指定我们要将集群放在哪个资源组里面。

在Azure平台里,其实都是通过资源组去管理服务,比如服务需要什么样的计算资源,都会统一放在某个资源组里,此时,让不需要这项服务即可删除整个资源组,然后去删除这些服务,下面定义节点的VM Size以及SSH Key的这些选项,进入Portal里看下之前创建好的Kuberntes集群,可以看到这已经定义了Agent Master这样一些节点,还包括一些负载均衡以及网络的组件,进到Cluster里面看下它的组成:一个Agent Pool,VM Size VM Count显示等,其实只要一些很简单的输入,即可快速地在Azure上创建一个ACS服务。

第二步:测试例子应用程序的本地镜像部署和运行

接下来将一个WEB的应用部署在集群中,首先将WEB的应用在本机上进行镜像的打包和运行,从这个地址Clone一个应用,确认Dockers是正在运行着的,查看本机上有哪些Docker镜像,可以看到目前还没有,接下来用Docker Compose这个命令去创建有关应用的所有进项,它会读取Docker Compose文件,进到Docker-Compose文件里查看,定义了两个服务,包括Azure-Vote-Back和Azure-Vote-Front,Redis是数据库的服务,Azure-Vote-Front是前端的投票应用服务。

在创建的过程中,会Push一些基础镜像扩,包括Nginx这个正在Pull下来的WEB Server镜像,还有数据库的镜像,生成应用自身的镜像,完毕后,可以看到本地现在有三个镜像,此时有两个容器正在运行,包括数据库和应用,再来确认下Docker Compose的文件中所确定的应用,本机和容器之间的端口映射,可以看到,进到本机8080端口可以运行WEB应用,这是一个投票软件,会在这个WEB上面进行投票,而后数据库会对这些投票进行记录,此应用现在已经在机器上运行成功,下面会将这个应用部署到刚才创建的集群上面。

第三步:创建Azure Registry并将应用镜像Push进去

在将应用Push到集成之前,首先需要创建一个Azure上的容器注册表,即创建属于自己的镜像仓库,可以看到镜像仓库已经创建完成,可以使用其中的Login Server和Password进行登录,现在需要获取此进项仓库的密码,成功后在本地登录到镜像仓库中,将之前创建的镜像Push到进项仓库中,在此之前,需要用Docker Tag命令为镜像打一个标签,之后用Docker Images确认,这是为了下次在进行应用更新时的版本控制。

现在把镜像Push到刚才创建的镜像仓库中,在Push的过程里会不断地显示Push的阶段,成功后进到Azure的CLI中查看已经Push成功镜像的List,此时显示了刚才大号标签的镜像已经Push到镜像仓库中。

第四步:用Kubectl连接到Kubernetes集群并在集群上运行应用

可以看到在这个应用下载的例子中,有一个定义Kubernetes部署的文件,那么在这个文件中定义了不同的Deployment和不同的Service,可以在这个文件中写清自己的部署,然后利用此文件创建Kubernetes的部署。

将这里使用的镜像更换成之前在镜像仓库中Push进去的镜像,更换镜像仓库的Loginserver,然后会用Kubectl Create的命令根据刚才所看到的的部署文件去创建部署和服务。

现在创建了WEB应用的部署和一些Service,接下来即可Get刚才创建的Service,然后同时用Watch参数进行监控,获得IP后,即可将Watch关掉,进入External的IP里查看应用的运行情况。

第五步:为集群做扩展

进入此IP后,即可看到UI界面,部署完应用后,如何给集群做扩展?有两个方面:包括Kubernetes的单元Pod扩展,也包括集群节点的扩展,依次来看一下:

Kubernetes里面的Pods的情况,现在给Azure-Vote-Front进行扩展,用Kubectl Scale的这个命令扩展副本数是5个,扩展完成后再用Kubectl Get Pods这个命令进行查看,此时Azure-Vote-Front就变成了需要的5个量,可以在更多的量上去做自己的应用计算资源的应用,接下来看一下刚才部署文件中它其实是设置了有关请求的CUP的量,M其实指的是一千分之一核这样的一个单位,请求CPU量为250M现在在500M之内,可以根据CPU的使用率去进行后面的扩展。

定义CPU的Pescent是50,即当CPU的使用率超过50%时,可以给它达到10个Azure-Vote-Front Pods的情况,可以通过这样一个命令来查看已经设置过的自动扩展状态,除了在Kubernetes的Pods做这样一个扩展,还可以在VM的Count这个层面上去做一个扩展,可以设置New-Agent-Count这个数字为4,此时会从刚才的3个Count编程4个Count。

第六步:应用更新后的快速发布

最后一步会为大家分享如何进行应用更新后的快速部署和运行,进到刚才下载下来的应用,进入UI定义文件,将刚才的Cats和Dogs更改成其他的单词,让它可以显示在UI上,以表示更新。完成后仍之前提过的Count应用重新给应用进行打包镜像,成功后此时将应用以一个新的标签来传到刚才的Registry里,显示刚才的Count结果,定义Count为4,此时编程了新的VMcount,相当于在Cluster理有4个可用的VM。

把刚才更新好的应用重新打一个标签:V2,发现已经定义成功,接下来把打好标签的镜像Push到之前创建好的镜像仓库中,可以看到其实有一些内容已经存在了,这是刚才扩展后的情况,对这个更新好的镜像进行重新部署,它提示这个镜像已经更新成功,重新看到Pods的情况是有一些已经进行更新了,从最右边的Age来看Pods的存在时间,下面重新Get Service来去查看这个应用的运行结果,登录到这个响应的IP里去查看一下。

可以看到现在选项已经编程了White和Black,从进行应用更新到快速在集群上部署运行,只需要很短的时间即可进行。

今天给大家介绍的内容主要是有关Azure Container Service上面的容器化应用。谢谢大家。


这里写图片描述

版权声明:本文为GitChat作者的原创文章,未经 GitChat 允许不得转载。

如何打造一个高逼格的云运维平台?

在标准化实施完以后,由于数目的增加,或者是一些运维场景的增多,我们会逐步的进行一些工具化和自动化,这个阶段我们的运维的效率得到提升。但是众多的工具以及自动化脚本,会让我们的管理过程中比较困难,随着人员...
  • u014743697
  • u014743697
  • 2016年12月04日 11:35
  • 1753

传统运维和云运维区别比较不同观点想法

有人说在云计算工程领域,最难的部分是运维,因为管100台、1万台或是100万台机器,是完全不同的概念,你想机器少可以人管,机器多了还能靠人么,当然不能了。再则,运维系统不属于功能性的东西,常常因为用户...
  • u010098331
  • u010098331
  • 2016年08月19日 00:45
  • 4571

基于微服务架构的云平台总体设计

正好这段时间我们在封闭研发我们的新一代数字化云平台(theplatform),借此机会和大家分享一下我们的总体设计及思路: theplatform是一款基于微服务架构的DevOps容...
  • guwei9111986
  • guwei9111986
  • 2016年05月12日 23:36
  • 6913

魅族容器云平台自动化运维实践

魅族容器云平台主要是基于 k8s 的技术。将从以下六个方面介绍魅族容器云的实践过程,分别是基本介绍、k8s 集群、容器网络、外部访问4/7层负载均衡、监控/告警/日志、业务发布/镜像/多机房。 ...
  • petpig0312
  • petpig0312
  • 2017年07月22日 20:47
  • 358

UnitedStack有云UOS云平台新增Redis服务 为用户提供安全、高性能、免运维的缓存服务

2015年10月27日至30日,OpenStack领域的盛会OpenStack Summit在东京盛大举办。中国第一家Openstack云公司UnitedStack有云亮相,并在会上宣布在其系统UOS...
  • sdwzzx
  • sdwzzx
  • 2017年05月04日 15:23
  • 104

微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源,开发人员...
  • J_bean
  • J_bean
  • 2017年11月26日 12:57
  • 204

解读1号店运维云平台

  • 2016年09月01日 09:09
  • 11.99MB
  • 下载

何刚:云平台研发和运维的挑战和启示

  • 2014年05月29日 14:06
  • 1.41MB
  • 下载

网易容器云平台的微服务化实践

摘要:网易云容器平台期望能给实施了微服务架构的团队提供完整的解决方案和闭环的用户体验,为此从 2016 年开始,我们容器服务团队内部率先开始进行 dogfooding 实践,看看容器云平台能不能支撑得...
  • FL63Zv9Zou86950w
  • FL63Zv9Zou86950w
  • 2017年12月15日 00:00
  • 630

IBM-私有云关键技术—云平台服务

  • 2012年05月23日 17:16
  • 3.33MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:GitChat · 运维 | 深入了解 Azure 云平台容器技术服务
举报原因:
原因补充:

(最多只允许输入30个字)