Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch to a GKE initiated managedcertificate #1340

Merged
merged 2 commits into from
Dec 15, 2023
Merged

Conversation

sjahl
Copy link
Contributor

@sjahl sjahl commented Dec 5, 2023

We previously created a managedcertificate out of band, in setup.py. This switches to the GKE built-in managedcertificate object. This removes a chicken and egg scenario where we couldn't deploy the app until a cert was present, and couldn't issue the cert until there was an app present.

@sjahl sjahl self-assigned this Dec 5, 2023
@sjahl sjahl marked this pull request as ready for review December 6, 2023 20:21
@sjahl
Copy link
Contributor Author

sjahl commented Dec 6, 2023

Sadly, I don't know if this is going to be able to be deployed without some kind of downtime. It's optimized for the first deployment, where you're probably not urgently waiting for the cert to be provisioned while your site is down.

Roughly, in my experience, it takes around 20 minutes from the time that the ManagedCertificate resource being applied, to the time that it's associated with the ingress. This only happens the first time, or after we delete the ManagedCertificate resource. Subsequent updates to the ingress don't trigger recreating the cert.

The alternative here is to analog the old setup script, and create a separate managed certificate with terraform: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_managed_ssl_certificate

But that terraform provider seems to come with a strongly worded warning that highlights some of the chicken-and-egg issues that I mentioned in the PR description.

I'd personally opt to use the changes from this PR over that, since waiting 20 minutes in rare circumstances seems like a better option than having a deploy process that has a convoluted number of steps when we have to start from scratch, but i'm interested to hear what others think.

EDIT: According to this: https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl we may be able to use both certificate methods at the same time to migrate from one to the other... i will test this

@sjahl
Copy link
Contributor Author

sjahl commented Dec 6, 2023

OK, good news, we can associate multiple certificates with the ingress, and it'll only serve the old valid one until the new one is provisioned.

I did observe a very brief amount of downtime... perhaps 30 seconds, when disassociating the old certificate after the new one was ready.

Copy link
Contributor

@rileyhgrant rileyhgrant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to my eyes!

@sjahl sjahl merged commit 8bb4532 into main Dec 15, 2023
1 check passed
@sjahl sjahl deleted the managed-certificate branch December 15, 2023 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants