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

Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

news.ycombinator.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#61

Post by Leace »

londons_explore wrote: post #52
chung1905 wrote: post #35

Earlier quoted context omitted.

While developing an image, I use layers as much as possible. But usually, when the image is finished, I prefer to minimize the number of layers, it saves some (or little) storage (I think it will not > 10%).

Fewer layers also performs better in the final image. Things like listing a directory get very slow with thousands of layers.

I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.

This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#62

Post by pm7 »

londons_explore wrote: post #52
chung1905 wrote: post #35

Earlier quoted context omitted.

While developing an image, I use layers as much as possible. But usually, when the image is finished, I prefer to minimize the number of layers, it saves some (or little) storage (I think it will not > 10%).

Fewer layers also performs better in the final image. Things like listing a directory get very slow with thousands of layers.

@Leace

> I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.

That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3...

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#63

Post by 1acct1comment »

dang wrote: post #41
midev wrote: post #11

Earlier quoted context omitted.

I'll explain it, if you'd like. Correct, no one is making an argument against what you said, because everyone understands that point. For most people, it doesn't need to be said. No one is ripping out production infrastructure and replacing it with this image. There's no comment anywhere suggesting it. What you're doing is called "preaching to the choir". You're trying to be a contrarian to show everyone how smart an…

Please don't respond to a bad comment by breaking the site guidelines yourself. That makes this place strictly worse. Crossing into personal attack, which you did here and downthread ( https://news.ycombinator.com/item?id=21308653 ) is particularly bad and the sort thing we ban accounts for, even if another comment was provocative. We're really trying to avoid flamewars here, for the same reason that cities avoid fla…

You're perfect Dang.

Truck you later.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#64

Post by annymsMthd »

Leace wrote: post #61
londons_explore wrote: post #52

Earlier quoted context omitted.

Fewer layers also performs better in the final image. Things like listing a directory get very slow with thousands of layers.

I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.

Multistage builds do not squash at the end.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#65

Post by mnutt »

pm7 wrote: post #62
londons_explore wrote: post #52

Earlier quoted context omitted.

Fewer layers also performs better in the final image. Things like listing a directory get very slow with thousands of layers.

@Leace > I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3.…

Yeah, I suspect that while the author could use a development image to do all of the compiling, given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands, and you'd still want to do all of the package manager operations in the prod build. It's really a tradeoff of development ease vs minimal packaged output.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#66

Post by pm7 »

mnutt wrote: post #65
pm7 wrote: post #62

Earlier quoted context omitted.

@Leace > I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3.…

Yeah, I suspect that while the author could use a development image to do all of the compiling, given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands, and you'd still want to do all of the package manager operations in the prod build. It's really a tradeoff of development ease vs minimal packaged output.

> given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands

Workaround would be to move these files to one directory on host, COPY it in one command to /tmp (or even better, /dev/shm or other ramdisk) and then use script to distribute files where needed.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#67

Post by chatmasta »

annymsMthd wrote: post #64
Leace wrote: post #61

Earlier quoted context omitted.

I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.

Multistage builds do not squash at the end.

You can do this with experimental flags [0] and --squash [1] [2]

[0] https://github.com/moby/buildkit/blob/master/frontend/docker...

[1] https://geraldonit.com/2017/11/13/how-to-create-small-docker...

[2] https://docs.docker.com/engine/reference/commandline/image_b...

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#68

Post by chatmasta »

mnutt wrote: post #65
pm7 wrote: post #62

Earlier quoted context omitted.

@Leace > I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3.…

Yeah, I suspect that while the author could use a development image to do all of the compiling, given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands, and you'd still want to do all of the package manager operations in the prod build. It's really a tradeoff of development ease vs minimal packaged output.

You can make the multi-stage builds actual images themselves, and setup your CI to auto push them to a registry. Then you can have shared multistage builds, which is pretty useful for things like compiling static libraries in their own images, and COPYing them into images that statically link to them.

Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli

#69

Post by anfilt »

tialaramex wrote: post #59
anfilt wrote: post #25

I think 0-RTT is just bad idea security wise.

Good news, any participants under your control can (and so should) refuse to do 0RTT. Clients can choose never to send early data and servers can choose to always reject it, everything still works. At the API layer reject any libraries or tools that try to foist this on you, many today either don't do 0RTT or correctly offer it as a separate API call for those willing to pay a price in terms of Replay resistance.

That's even more concerning that there are libraries that hide such a thing. There is gonna be instances that bites someone hard where said replay is not idempotent.
Post reply on HN