我是 appcfg.py 的长期用户,我甚至在其上构建了一些bash脚本。
我们应该切换到 gcloud app deploy 吗? appcfg.py 会被弃用吗?如果是,那么时间表是什么?
为什么没有yaml文件向后兼容的宽限期?切换到 gcloud app deploy 我得到:
[application]字段在文件[... / app.yaml]中指定。这个 gcloud不使用该字段,必须将其删除。项目名称应该 而是由
gcloud config set project MY_PROJECT
指定 或者通过在单个命令执行上设置--project
标志。
和
错误:[version]字段在文件[... / app.yaml]中指定。这个 gcloud不使用该字段,必须将其删除。版本是 默认情况下自动生成,但也可以手动指定 通过在单个命令执行上设置
--version
标志。
我这样说,因为这可能是模块/服务字段:
警告:"模块"应用程序.yaml文件中的参数是 弃用。请使用"服务"参数而不是。
如何使用 gcloud app deploy <上传 queue.yaml , dispatch.yaml 和 cron.yaml /强>
部署应用程序的两种方式有什么区别?
我对注意事项感兴趣&amp;需要注意的事项:
FLAGS --promote推广已部署的版本以接收所有流量。默认为True。
这意味着w / gcloud app deploy 将部署应用程序并将新版本设置为活动版本...这正是相反的方式 appcfg.py 做了一些事情你需要调用 set_default_version 来将版本标记为活动版。
这引出了我的最后一个问题:如果我选择不使用
激活它$ gcloud config set app / promote_by_default false
或
使用--no-promote禁用。
我是否必须重新部署w /默认值才能激活它?
答案 0 :(得分:9)
长话短说:
gcloud app deploy
将成为未来部署的首选路径,目前支持。我们宣布弃用过渡后大约一年。appcfg.py
之前,我们会提供包含所有更改的完整迁移指南。我们并不希望完全向后兼容,因为我们抓住这个机会用旧工具修复一些瑕疵。gcloud app deploy cron.yaml
等来部署备用YAML文件。所以我认为你可以直截了当,直到我们正式弃用appcfg
工具 - gcloud app
真正意味着那些想要现在最新和最狡猾的勇敢探险家。