我一直是appcfg.py的长期用户,我甚至在它上面构建了一些bash脚本.
我们应该切换到gcloud app部署吗？将appcfg.py被弃用？如果是,那么时间表是什么？
为什么没有yaml文件向后兼容的宽限期？切换到gcloud app部署我得到:
[application]字段在文件[.../app.yaml]中指定.gcloud不使用此字段,必须将其删除.应该
gcloud config set project MY_PROJECT通过--project在单个命令执行上设置标志来指定项目名称.
和
错误:[version]字段在文件[.../app.yaml]中指定.gcloud不使用此字段,必须将其删除.默认情况下会自动生成版本,但也可以通过
--version在各个命令执行时设置标志来手动指定.
我这样说,因为这可能是模块/服务字段:
警告:不推荐使用应用程序.yaml文件中的"module"参数.请改用"service"参数.
你如何上传queue.yaml中,dispatch.yaml和cron.yaml与gcloud应用程序部署？
部署应用程序的两种方式有什么区别？
我对需要注意的警告和事情很感兴趣:
FLAGS --promote促进部署的版本以接收所有流量.默认为True.
这意味着w/gcloud app部署应用程序将被部署,新版本将被设置为活动版...这正是appcfg.py执行操作的相反方式,因为您必须调用set_default_version将版本标记为活性.
这引出了我的最后一个问题:如果我选择不通过使用其中任何一个来激活它
$ gcloud config set app/promote_by_default false
要么
使用--no-promote禁用.
我是否必须重新部署w /默认值,以便我可以将其激活？
我在Docs:Scaling Puppet中找到了以下内容:
您使用的是默认网络服务器吗？
WEBrick是用于启用Puppet Web服务连接的默认Web服务器,它本质上是一个参考实现,并且在大约十个受管节点之外变得不可靠.在为许多节点提供服务的任何类型的生产环境中,您应该切换到更高效的Web服务器实现,例如Passenger或Mongrel.
10个托管节点中的数字10来自哪里？
我有20多个节点,我可能很快就会超过30个.我应该改为乘客吗？