Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shrinking my static site

hampton.pw

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Shrinking my static site

#61

Post by mholt »

1337shadow wrote: post #59
francislavoie wrote: post #17

You can probably shrink it even more. The Caddy alpine image is 14MB compressed. https://hub.docker.com/_/caddy/ You also get automatic TLS certificate management and tons of other goodies that nginx doesn't offer out of the box.

So, if you want to host multiple sites on the same port of your server, from the same process, then you can also have Caddy behind Traefik, but then why would you need Caddy ? Traefik got docker load balancing right: watch docker.sock and self configure on the fly. I missed the whole Caddy thing anyway because the source code was not completely open back in the days I was looking for nginx alternatives that provided…

> the source code was not open back in the days

The Caddy source code has always been open source (Apache 2.0 licensed) from day one all the way to today, and will continue to be in the future.

Beware when using other Let's Encrypt integrations. Caddy will keep your site online when other servers don't. (We saw this recently when Let's Encrypt had a revocation incident and when OCSP responders / other network infrastructure went down. Caddy kept the sites up, where other sites went down or left sysadmins scrambling to renew their certs.)

Re: Shrinking my static site

#62

Post by herohamp »

oefrha wrote: post #34

3 minutes to build a static blog (with a grand total of five posts) that doesn’t look any different from decade-old blogs. Pulling hundreds of MB from the Internet in the process. Wow. https://github.com/herohamp/eleventy-blog/tree/master/posts

yes it is sub-optimal, but that is not because building it takes so much time, it is because of the node_modules. I am looking into migrating to Hugo as has been suggested by MANY people

Re: Shrinking my static site

#63

Post by 1337shadow »

mholt wrote: post #61
1337shadow wrote: post #59

Earlier quoted context omitted.

So, if you want to host multiple sites on the same port of your server, from the same process, then you can also have Caddy behind Traefik, but then why would you need Caddy ? Traefik got docker load balancing right: watch docker.sock and self configure on the fly. I missed the whole Caddy thing anyway because the source code was not completely open back in the days I was looking for nginx alternatives that provided…

> the source code was not open back in the days The Caddy source code has always been open source (Apache 2.0 licensed) from day one all the way to today, and will continue to be in the future. Beware when using other Let's Encrypt integrations. Caddy will keep your site online when other servers don't. (We saw this recently when Let's Encrypt had a revocation incident and when OCSP responders / other network infrast…

Interesting, I thought they only solved these issues last October, I guess I'm just part of the people that were confused by the situation back then. Sorry about that !

https://github.com/caddyserver/caddy/issues/2786

Re: Shrinking my static site

#64

Post by Symbiote »

oplav wrote: post #41
ig0r0 wrote: post #7

I use Hugo as my static site generator, single binary, no dependencies, generating hundreds of pages in milliseconds ... so reading this feels so wrong, I want to call it JavaScript masochism. Taking a simple concept like a static site and adding a ton of complex tooling around it because it is the trend now? Why would you even need a docker image to run a static website? The best thing about a static website us you…

At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static websites. In production, we do exactly what you suggest: serve through a CDN. However, for our dev environments and PR builds, programmatically setting up CDN to handle these use cases is not easily integrated with our CI/CD workflow. Our CI/CD environment is…

Possibly this is far too old fashioned, but all our internal static sites (and a good few external static sites) I deploy to a single Apache server.

Re: Shrinking my static site

#65

Post by mholt »

1337shadow wrote: post #63
mholt wrote: post #61

Earlier quoted context omitted.

> the source code was not open back in the days The Caddy source code has always been open source (Apache 2.0 licensed) from day one all the way to today, and will continue to be in the future. Beware when using other Let's Encrypt integrations. Caddy will keep your site online when other servers don't. (We saw this recently when Let's Encrypt had a revocation incident and when OCSP responders / other network infrast…

Interesting, I thought they only solved these issues last October, I guess I'm just part of the people that were confused by the situation back then. Sorry about that ! https://github.com/caddyserver/caddy/issues/2786

We distributed commercial binaries to businesses for a time and considered making various plugins paid-only to fund its development. But the source code has always been open and Apache-licensed, and there was never any requirement that you had to use the commercial binaries. Caddy has always been an open source project. Arguably more open than nginx, which hides many features behind paid versions, enterprise support, and expensive licensing restrictions. Several of nginx's paid features are free in Caddy, for example NTLM proxying and a config API.

Re: Shrinking my static site

#66

Post by 1337shadow »

mholt wrote: post #65
1337shadow wrote: post #63

Earlier quoted context omitted.

Interesting, I thought they only solved these issues last October, I guess I'm just part of the people that were confused by the situation back then. Sorry about that ! https://github.com/caddyserver/caddy/issues/2786

We distributed commercial binaries to businesses for a time and considered making various plugins paid-only to fund its development. But the source code has always been open and Apache-licensed, and there was never any requirement that you had to use the commercial binaries. Caddy has always been an open source project. Arguably more open than nginx, which hides many features behind paid versions, enterprise support,…

> Caddy will keep your site online when other servers don't.

Interestingly, the LetsEncrypt incident you mentioned went completely under my radar, none of my traefik instances in production or else were affected at all, or it wasn't caught by my uptimerobot, so I'm really not sure what you were talking about then. Maybe the 2017 incident, but I was still using nginx at the time. Pretty concerning, going to check it out.

Honestly I didn't require any of the nginx paid features ever nor did I with traefik, which also has an EE edition that I just found about, I suppose needing those would be a "problem I want to have" kind of problem (meaning the project I'm taking care of is growing). I'm more into software that will generate configuration by introspecting my systems but configuration APIs are also nice to have otherwise.

Nonetheless, Caddy is a great alternative in a domain where innovation had been stalling for a while. I would like to send over a one-time donation to help Caddy development if possible to support development.

Re: Shrinking my static site

#67

Post by francislavoie »

herohamp wrote: post #45
francislavoie wrote: post #17

You can probably shrink it even more. The Caddy alpine image is 14MB compressed. https://hub.docker.com/_/caddy/ You also get automatic TLS certificate management and tons of other goodies that nginx doesn't offer out of the box.

all of my docker containers are placed behind traefik which handles TLS certifactes, HTTPS redirect, compression, and routing to the correct container

This post talks about a single-container setup though, with the static site bundled with Nginx. That's what I'm replying to, not the usecase where you have many containers you need to proxy to.

Re: Shrinking my static site

#68

Post by herohamp »

1337shadow wrote: post #55
herohamp wrote: post #48

Earlier quoted context omitted.

yeah, that is a mistake. I just did not fully rethink my code when I moved the build layers. I will be removing that tonight along with a few changed suggested here

On a second thought, I also don't understand why do npm in two different images, why not just copy the webpack bundles from the builder image into the nginx image ? For me the cause of the big image size was in COPY --from=npmpackages /app /app From your third Dockerfile, it seems replacing the above with the following would have done the trick without adding an extra stage COPY --from=npmpackages /app/_site/ /usr/sh…

I do npm in two different images so that the node_modules can be cached between builds. this massively speeds up my build. The npmpackages layer only installs the npm modules

Re: Shrinking my static site

#69

Post by mholt »

1337shadow wrote: post #66
mholt wrote: post #65

Earlier quoted context omitted.

We distributed commercial binaries to businesses for a time and considered making various plugins paid-only to fund its development. But the source code has always been open and Apache-licensed, and there was never any requirement that you had to use the commercial binaries. Caddy has always been an open source project. Arguably more open than nginx, which hides many features behind paid versions, enterprise support,…

> Caddy will keep your site online when other servers don't. Interestingly, the LetsEncrypt incident you mentioned went completely under my radar, none of my traefik instances in production or else were affected at all, or it wasn't caught by my uptimerobot, so I'm really not sure what you were talking about then. Maybe the 2017 incident, but I was still using nginx at the time. Pretty concerning, going to check it o…

> none of my traefik instances in production or else were affected at all

It didn't affect every site. But it did affect millions of them. You're lucky!

Re: Shrinking my static site

#70

Post by Drdrdrq »

azangru wrote: post #53
licebmi__at__ wrote: post #26

Earlier quoted context omitted.

Well, the article mentions an obvious improvement. The node_moduoes won't be rebuilt after any changes to the code, only changes specific to the packages.json. Basically the main step is the COPY . . step (previously COPY . /app) which will invalidate the cache every change to the code. Also that on the builder, the steps beyond npm run are not needed, but well they won't improve much on the performance or space of t…

> The node_moduoes won't be rebuilt after any changes to the code, only changes specific to the packages.json. But that's only if the builder image gets cached and can be reused, right?

Correct.
Post reply on HN