`gcloud app deploy`与`appcfg.py`

Question

我一直是appcfg.py的长期用户,我甚至在它上面构建了一些bash脚本.

1. 我们应该切换到gcloud app部署吗？将appcfg.py被弃用？如果是,那么时间表是什么？

2. 为什么没有yaml文件向后兼容的宽限期？切换到gcloud app部署我得到:

[application]字段在文件[.../app.yaml]中指定.gcloud不使用此字段,必须将其删除.应该gcloud config set project MY_PROJECT 通过--project在单个命令执行上设置标志来指定项目名称.

和

错误:[version]字段在文件[.../app.yaml]中指定.gcloud不使用此字段,必须将其删除.默认情况下会自动生成版本,但也可以通过--version在各个命令执行时设置标志来手动指定.

我这样说,因为这可能是模块/服务字段:

警告:不推荐使用应用程序.yaml文件中的"module"参数.请改用"service"参数.

3. 你如何上传queue.yaml中,dispatch.yaml和cron.yaml与gcloud应用程序部署？

4. 部署应用程序的两种方式有什么区别？

   我对需要注意的警告和事情很感兴趣:

FLAGS --promote促进部署的版本以接收所有流量.默认为True.

这意味着w/gcloud app部署应用程序将被部署,新版本将被设置为活动版...这正是appcfg.py执行操作的相反方式,因为您必须调用set_default_version将版本标记为活性.

这引出了我的最后一个问题:如果我选择不通过使用其中任何一个来激活它

$ gcloud config set app/promote_by_default false

要么

使用--no-promote禁用.

我是否必须重新部署w /默认值,以便我可以将其激活？

Answer 1

长话短说:

1. gcloud app deploy将成为未来部署的首选路径,目前支持.我们宣布弃用过渡大约一年后.
2. 在我们弃用之前appcfg.py,我们将提供包含所有更改的完整迁移指南.我们不希望完全向后兼容,因为我们抓住这个机会用旧工具修复一些瑕疵.
3. 您可以运行gcloud app deploy cron.yaml等等来部署备用YAML文件.
4. 同样,在我们想要强制您使用新工具之前,我们计划编写迁移指南.

所以我认为你可以appcfg直截了当,直到我们正式弃用工具 - gcloud app这真的是为了那些想要现在最新和最闪亮的勇敢探险家.