lemon-wire-69305
08/09/2021, 1:33 AMops
which contains my Pulumi script.
Here's what my project structure looks like:
- ops
- backend-app
- frontend-app
In production my architecture is essentially:
-> AppEngine (frontend-app)
/
<http://www.my-site.com|www.my-site.com>
/
http request -> GCP LOAD BALANCER
\
<http://api.my-site.com|api.my-site.com>
\
-> AppEngine (backend-app)
Flow-wise what I would like is:
• pulumi up
to create all GCP infrastructure from an empty project (including CloudBuild triggers).
• Any time a change is pushed to the master
branch of frontend-app
a new AppEngine Version is created. Traffic is then migrated to this new Version.
• backend-app
flow should work similarly to the frontend-app
For CI I plan to use Cloud Build.
In the docs it seems the intended approach is to run the Pulumi script from CloudBuild. I could do this, however I have a few concerns:
1. The Pulumi script is in the separate ops
project, and so I'd need to pull that project down from source control in a CloudBuild step. This is doable but doesn't seem ideal.
2. Pushes to the master
branch in different projects will kick off multiple `pulumi up`'s at the same time - could this cause any race-condition type issues?
3. Is running pulumi up
for the entire architecture for a single deploy too heavy handed? Could this introduce risk into the system?
4. This approach would require me to keep track of all project version numbers to ensure pulumi up
is configured with the latest AppEngine version numbers. Where should I store these?
5. It doesn't seem like Pulumi automatically migrates traffic from one AppEngine version to a newer one. Would I need to do this as a separate build step?
Any advice on my concerns, thinking, and approach would be much appreciated. I'm not sure whether this is the intended approach or if I'm missing something.
Thanks!