Azure部署web app的血泪史（详细步骤和坑）

毕业论文需要在云上部署一个博客系统并进行渗透测试，系统细节：

Flask+Mysql

在AWS和Azure上都尝试了几天，发现Azure部署好像比AWS需要考虑的组件少（Azure提供的App Service可以直接通过Github Actions实现持续部署），后来在Azure上部署了3天终于成功，其中遇到了一些坑。

详细步骤：

1）创建资源组（resource group）

2）创建数据库（可以用Azure Database for MySQL，设置允许客户端网络后可以通过本地Workbench操作数据表，好像这个比AWS方便一些）

3）创建Web应用

Azure的应用程序服务提供了三种不同的选项，不是很推荐直接创建Web+数据库，因为这样关于数据库的很多操作都会受限，建议分开创建数据库和web应用

！！有一个隐藏的坑，是Azure好像只接受这个应用叫“app”，哪怕你的application.py文件在启动的gunicorn命令里写了application:application，也会报错...把应用名字改成app，用app=Flask(__name__) 就可以.......

下面是一些坑：

1）关于部署位置：

首先一个坑就是，一般Azure部署之后的网站是：https://<your-website-name>.azurewebsites.net，然后它的控制台其实是：https://<your-website-name>.scm.azurewebsites.net

重点来了，有的教学视频进入控制台的wwwroot目录之后，可以直接上传文件，但实际操作发现是不可以的，必须到这里：

https://<your-website-name>.scm.azurewebsites.net/newui/FileManager

。。。。。关键是这个网站我找遍全网，只在stackoverflow上看到，这个FileManager可以直接通过拖拉上传本地文件，方便后续上传一些requirements.txt和startup.sh等文件。

2）关于部署方法：

感觉Azure的部署方式虽然方便，但是后续的debug流程并不友好，整了3天感觉基本上都只能用kudu控制台的bash操作，没什么直接点点就能修改好的方式，所以需要熟悉linux命令。

3）关于数据库连接：

把application.config['SQLALCHEMY_DATABASE_URI']

里的内容根据azure数据库的hostname,username和password替换，如果想要省事，把Azure Database for MySQL的require secure transport关闭，这样就不强制使用SSL，如果需要更高的安全性，可能还需要在控制台下载SSL证书，导入wwwroot目录下，应用才能正常连接数据库。

3）关于log文件

这个大坑是有的log文件也得在FileManager里看.......在“诊断并解决问题”和“日志流”里也有一部分，但都不是完整的，可读性来说还是CloudWatch好一些。

4）关于版本问题

非常推荐在部署的时候在kudu控制台创建一个虚拟环境，因为Azure的服务器里默认的python3版本是python3.7（我用的B1计划，这里需要注意，因为F1计划是免费的，但是如果应用比较大，可能需要考虑扩展计划，不然部署成功了也无法访问），而且并没有自带pip，这导致很多python插件无法使用或安装，而且如果在服务器本地安装了，重启之后还会有很多问题。用虚拟环境做好隔离。记得要在kudu的bash里把requirements的插件都安装好再部署。

（做好python升级版本安装1个小时。。。。。尤其是网不好的时候，可能还导致里面的包下载失败的准备。。。。。）

5）关于启动命令

在FileManager的site/wwwroot里上传startup.sh文件，里面包含网络的配置，例如gunicorn命令等（记得把gunicorn的版本放到requirements.txt里）。

如果没有这个startup文件，也会导致应用启动失败（离谱的是，好像Azure默认会把site/wwwroot/startup.sh拷贝到opt/startup/startup.sh，但是它似乎又没有默认的startup.sh文件.....不能直接在kudu控制台往opt/startup里写入startup.sh文件，会提示没有权限）

总的来说：

感觉Azure部署相比于AWS来说，离底层更近一些，好处是不需要管太多比如VPC或者安全组的设置，也不需要配置CloudWatch之类的monitoring tool，坏处是大部分依赖Azure CLI或者kudu的bash操作

AWS的文档好像比Azure友好一些，但是上层的部署操作也很复杂。。。。

但是就安全性而言，如果是用AWS，可能在权限控制上更省心，因为可以直接通过控制IAM user的权限和敏感数据加密来实现，但是如果使用Azure，直接连接GitHub来部署，则GitHub端的访问控制也要一并考虑。