在IT领域略有些阅历的童鞋可能还记得，多年前，业内流行的是使用虚拟机来运行应用。一台物理服务器上创建多台虚拟机，然后把不同程序跑在里面，不仅满足了相互隔离、互不影响等要求，同时可以进一步减少需要维护的物理计算机数量，降低成本。简单来说，虚拟机的基本原理是这样的：

不过毕竟虚拟机所虚拟的是底层硬件，这就显得有些“笨重”，同时包括硬件和虚拟的操作系统在内，这些东西的虚拟和运行本身也需要一定资源开销，所以在运行效率方面依然有改进的余地。

而这两年更时兴的做法是使用容器（Container），直接在底层物理硬件的基础上，对操作系统本身进行虚拟，借此创建出所谓的“容器”，然后在容器中运行各种应用程序。

这种方式的好处非常直观：容器和其中的应用程序启动速度快，应用程序更易于移植，容器重建成本更低，扩展更容易。

为了帮助大家更好地了解并使用Azure平台来运行自己的容器化服务和应用程序，我们准备了这一系列的《Azure容器服务完全锻造手册》，围绕微软云原生服务Azure Web Apps，Azure Kubernetes 服务理论与实践，Azure API 以及Functions ，帮助大家基于Azure相关服务打造容器运行平台。

本期我们就小试身手，一起试试看如何通过Azure Web Apps部署自己的容器。

基础知识入门   

围绕容器技术已经衍生出很多技术名词，比如Docker、Docker Image、Docker Registry、Volume、Calico、Kubernetes、Prometheus等。所有这些技术都是开源的，以社区为导向，用户完全可以全部通过虚拟机创建，因此极为自主可控，但同时也需要一个专业团队来进行管理维护，学习与管理成本都很高。而且很多时候，这部分平台的建设与维护，并不会给业务带来任何价值，这也是很多公司在考虑用容器服务时，会评估并使用公有云提供的托管的容器服务的主要原因。

其实这也不难理解，毕竟随着业务系统容器化复杂程度，以及公司容器化平台策略的不同，需要引入的服务也会越来越多，持久化存储、数据库、密码管理、监控运维、持续开发等，会有越来越多周边服务被提到。这一切全靠虚拟机来构建并不现实，只有结合云端PaaS服务来一起设计这个架构才能够快速的推进项目落地。

每个云服务都提供了容器化的服务，Azure也一样。Azure中与容器相关的服务有很多，但主要用来部署、运行容器的服务主要有：Azure App Service、Azure Kubernetes Service（AKS）、Azure   Container Instance（ACI）、Azure   Functions，以及托管的商用容器化平台（如OpenShift & Spring Cloud）。

那么多与容器有关的服务，那么接下来不免需要考虑：我到底该选择哪个容器化服务？

一般情况下，这些与容器有关的服务之间并没有什么明确的界限。例如，用户将一个应用网站打包成容器镜像，接下来选择部署的方式时发现，部署在Web App和AKS中其实都可以，那么到底该选哪个？针对这样的问题，一直没有什么统一的答案，具体要看需求、企业容器化规划以及个人喜好。

大体上，App   Service与AKS更多会用于部署需要长期运行的应用服务，ACI与Azure Functions更适合用于处理随机触发的事件。Kubernetes虽然也是一个非常火的技术平台，很多人也将其与容器画了等号，但其实Kubernetes并不负责运行容器，而是用于管理容器的。因此在选择服务到底要运行在App Service还是AKS中的时候，可以首先考虑下列这几个问题：

1. 应用系统基于容器的部署，是可以通过Docker Compose来完成，还是需要通过Kubernetes来完成：Kubernetes目前算是每个容器新手都会遇到的一个技术标准，但也会有人提出，对于一两个容器实例的运行，Kubernetes太重了，还是Docker Compose更方便。其实此时Web App for Container会更合适，当然如果是复杂应用，需要考虑多个服务的配合，或者要计划打造容器化平台的话，Kubernetes更适合。

2. 有关容器镜像数量的考虑：这个听上去有些武断，但判断起来比较直观。如果部署的应用系统是独立的，且只涉及到一两个Docker镜像，是可以考虑用Web App for Container的；但如果部署的系统涉及到多个组件，多个Docker镜像，且有考虑几个应用系统部署到一个环境中，那AKS就是不二的选择。因为Kubernetes的缺点就是：它是一个平台，必然会涉及到管理组件，而且平台学习曲线比较高；但优点是：它是用来做容器编排的，只有容器数量多了才需要编排和管理，在编排方面，它提供了高度扩展的一套管理框架。

3. 看公司的技术选型及发展规划：如果硬要说五个Docker镜像一定不能部署在Web App   for Container中，那就是抬杠了。但具体部署在哪里跟公司的策略有很大关系，如果之前习惯了使用Web App，对其的管理方式、部署槽的使用、CI/CD的实现都比较熟悉，那当Web App for Container出来之后，对于本质上Web App的使用并没有改变，这就是一个好的选择；但如果公司选型容器平台，准备未来基于容器构建新的系统，那Kubernetes从长远看会更合适。

本文我们主要介绍的Azure App Service for Container，其架构类似于下图：

这张图主要涉及几个部分：工具集的完整性，以及服务的连接性和安全性。接下来将利用一个小实验来对Container in Azure Web App进行一个简单介绍。实验素材可参见参考资料，实验涉及的具体步骤可自行翻阅文档学习尝试。

个人感觉这个实验素材特别的好，实验原本是针对AKS的，涉及到了几个服务，这几个服务彼此之间存在着连接调用关系，又连接到了后端的数据库。

实验内容比较简单：用户想把本地部署的一个服务迁移到云端，并有两个诉求：尽量使用PaaS并部署在容器中。实验的前提是已经评估过Azure Web App for Container + Azure SQL PaaS的方案，希望通过PoC进一步梳理。

1. 环境准备

首先需要分别创建Azure   Container Registry、Azure SQL Database以及Azure App Service Plan这几个服务：

随后构建POI镜像，并上传到Azure   Container Registry：

# 下载需要Build的源代码及Dockerfilegit clone https://github.com/Azure-Samples/openhack-containerscd ./openhack-containers/src/poi

# 登录 Azure, 并将整个Build工作提交到ACR, 本地无需 Docker Engine
az loginaz acr build -t poi:v1 -r zjacr01 -g zj-webapp-demo -f ../../dockerfiles/Dockerfile_3 .

最后对Azure   SQL Database灌入测试数据：

 

#运行如下命令将测试数据灌入 Azure SQL Database，灌入测试数据前，记得确保添加正确的防火墙规则，以便可以连接到 Azure SQL Databasesudo docker run -d --name dataload -e "SQLFQDN=$yourConnection" -e "SQLUSER=$yourUser" -e "SQLPASS=$yourPassword" -e "SQLDB=$yourDB" openhack/data-load:v1

2. 创建Web   App服务并确保运行正常

接下来我们通过Azure门户上传镜像，并创建一个应用服务：

随后添加Docker镜像运行时所需传入的环境变量：

更新完成后访问$url/api/poi，预期结果如下：

3. 讨论一下大家对于此架构比较关心的问题

这里比较的不是Docker与Kubernetes，而是虚拟机与Docker，或者虚拟机与PaaS。

很多过去几年甚至更长时间里习惯将系统部署在虚拟机中的用户，往往最关心的就是：这样部署的好处是什么？

从虚拟机换到容器的最大好处是：迁移方便，确保开发测试出来的应用部署到生产环境后，跑出来的结果是一样的，避免在虚拟机本身环境不一致浪费太多时间。

从虚拟机换到Web   App for Container的最大好处是容器化部署的同时，继承了Web App的特点：

灵活扩缩容 | 根据需要手动或自动调整计算能力

可配置的持久化存储

容器的一大好处是：干掉一个容器的成本特别低。一般在Docker中，如果发现容器运行出错，最直接的办法就是删掉重建。但这会有一个问题：一些用户想要持久化保持的东西随着删除重建就会丢失，所以在容器中会有Volume（一个独立的，可持久存储的文件目录）的概念。

在虚拟机中，Volume就是虚拟机中的一个文件夹；在Web   App中，用户也会关心Volume是如何实现的。目前Web App   for Container也提供持久化存储，用户可以将持久化文件存储在/home目录下并映射到容器中，但前提是预先开启配置WEBSITES_ENABLE_APP_SERVICE_STORAGE。

当然，虚拟机中常见的另一种需求是：一个应用服务中会包含多个服务，虚拟机中很容易做到，容器中该如何做？可以理解为多个服务就是多个容器实例，在Docker中，这是通过Docker Compose实现的，Docker Compose会将一组容器服务组织起来，并确定彼此之间的调用关系。

监控

通过Azure   Monitor，平台提供了针对Web   App的Metrics，并能针对这部分Metrics进行告警。

当然，默认提供的算是标准的监控信息，如果想要获取更详细的信息，包括一些访问日志，可以设置诊断日志，并发送到Azure Log Analytics。

对于容器内部日志，如果想要实时查看的话，可以通过配置来完成：

安全

这个话题特别大，涉及多个服务。但如果只看Web App的话，有三点是容器相关的：

1. 针对操作系统层面的更新及安全补丁，由平台维护而非用户；

2. 容器镜像的安全，包括了基础镜像的安全更新后，ACR也会更新基础镜像，镜像的安全扫描，这部分是ACR所提供的；

3. 容器运行中，需要调用的密码等，例如调用SQL PaaS时需要的密码，这部分就可以结合Managed Identity和Azure Key Vault来完成。

第一步，Enable   Managed Identity，这里先使用System   Assigned就可以：

第二步，在Azure   Key Vault设置Access   Policy，将SQL   PaaS的密码存储在Key   Vaults中，并添加对于Secrets访问权限：

第三步，在Web   App Application Setting中，使用Azure Key Vaults：

这样，所有密码都存在了Key Vaults中。

总结           

到这里，这个Demo就基本结束了。我们可以看到，如果只有几个容器准备部署，或者本来就觉得Kubernetes太重，打算直接拿Docker Run & Docker Compose来运行的话，那Web App for Container 还是比较合适的。但我们同时也看到，很多 Kubernetes 中涉及到的管理概念，如 Replica、Secret、Configmap、Persist Volume 等，这部分在Web App中还是弱化的。

这也好理解，当一个环境中资源或人员相对较少时，并不需要复杂的流程和规章制度，只有发展到一定阶段或一定数量，一个完善的流程和制度会确保环境运行的成功。

参考资料：

实验中涉及的基础Dockerfile包

使用自定义容器将自定义软件迁移到Azure应用服务

在Azure中运行基本的Web应用程序

本篇内容至此结束。还请继续关注后续文章，进一步了解有关Azure Kubernetes Service的理论和实战，以及API和Function在容器中的使用。