Open jamesward opened 5 years ago
This is very close to reinventing Deployment Manager, Marketplace or Terraform. I'm currently -1, but if there are minimal things (perhaps like service account provisioning or a GCS bucket) that can we that helps 80-90% of the blocking use cases, we should consider. Otherwise it opens a can of worms.
Yeah, you are right that we don't want to replicate those other systems. So maybe we just keep it confined to a couple common things (GCS, Cloud SQL, Pub/Sub) or alternatively encourage using post-deploy scripts for this (#76).
Here is a project that could use this: https://github.com/jamesward/nodebars
Note that it is slightly more complicated than just provisioning Cloud SQL because I also need to setup the schema. Maybe a good way to handle that part is with #76.
Once we get pre/post create script support (#76) repos will be able to provision resources (Cloud SQL, buckets, service accounts, etc) but they will likely have to do it in postcreate and call gcloud
to update the service. This will work and is a nice low-level escape hatch but it has some downsides: the first deploy may fail due to missing required resources and is pretty manual for common needs. The reason we can't do the provisioning in precreate is that there is no way to propagate the config info to the service since it doesn't exist yet. And the ways in which the propagation need to happen vary. In some cases there is a single env var based on provisioning info, sometimes multiple, and sometimes non-env var config like --service-account
.
So I think we should also add support for having Cloud Run Button provision common resources and then it can handle the individual needs for those resources. For service account see #33
The app.json
changes could be something like:
{
"gcloud": {
"resources": {
"bucket": {},
"service-account": {
"roles": []
},
"cloud-sql": {
"size": "db-f1-micro"
}
}
}
}
Cloud Run Button provision common resources and then it can handle the individual needs for those resources
I prefer we don't go down that route. That's how you build a mini Deployment Manager or Terraform, which I think is a large can of worms. :)
If there's a simpler way we can achieve what the majority of use cases will need, it's better we look out for those opportunities.
I'd be cool if external services that need to be provisioned can be as part of the button deploy. Ideally we use
app.json
to specify these. Maybe they are based on the API names that need to be enabled? Should we have some way to select an existing resource? Examples GCS, Cloud SQL, etc.End goal: An app that needs something like Cloud SQL can be deployed to 100% functionality from the button.