-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[dashboard] Replace nginx with caddy #3851
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
Conversation
5cebadb
to
355d3ef
Compare
/werft run 👎 cannot start job - please talk to whoever's in charge of your Werft installation |
/werft run 👍 started the job as gitpod-build-aledbf-dashboardcaddy.3 |
6b2c495
to
355fa2a
Compare
@@ -50,8 +50,8 @@ spec: | |||
readinessProbe: | |||
failureThreshold: 3 | |||
httpGet: | |||
path: /schemas/gitpod-schema.json | |||
port: 80 | |||
path: /ready |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that would only mean "the http service is running", the previous check means "the dashboard is served". in-between there might be error cases.
@geropl, do you know why we started to use actual resources from the dashboard to be tested for in the readiness probe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can imagine several scenarios why that was:
- convenience: by testing well known dashboard resources, we don't have to think about other paths that we might want to use
- previous breakage: we may have had some misconfiguration at some point and then moved to checking a dashboard resource
Either way, once caddy is running it would serve the dashboard. It makes sense to me to use a readiness endpoint of caddy here.
/werft run 👍 started the job as gitpod-build-aledbf-dashboardcaddy.12 |
355fa2a
to
b1aefd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That worked nicely for me!
I checked that caching works as it used to and known redirects are still in place.
Thanks 🙏🏻
@aledbf @AlexTugarev @csweichel Did anybody verify that caddy emits "ETag" headers based on content-hash of the static files in this configuration? Something we rely upon here. |
} | ||
|
||
(caching) { | ||
header Cache-Control "public, max-age=604800, must-revalidate" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geropl, ups. I've seen the ETags, but didn't check for the implementation. It's indeed based on file size and date. |
Reasons: