5 ms·

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up bei

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.

winrid 3y ago
I've been desensitized by my world of 500mb docker containers.
- nine_k 3y ago
  Docker containers are actually smaller if they share layers with other containers in the system. A ton of containers based on the same image reaps many deduplication benefits.
  - tracker1 3y ago
    Yeah, I notice many/most images are based on a recent Debian base if they aren't on Alpine or closer to bare images. I don't consider even Alpine as a base too bad for a lot of apps.
- thewataccount 3y ago
  Have you tried using alpine based images instead of debian/ubuntu/others? I know it's not always possible especially because of musl but for most things it works fine and is tiny.
  - winrid 3y ago
    It becomes a political issue at this point w/ battling the ops team. I have more important battles.
    - thewataccount 3y ago
      Yeah that's fair, if it works it works. Depending on your setup it doesn't really matter anyway.
    - beanjuiceII 3y ago
      how about ubuntu chisel
    - zaphar 3y ago
      If it's a battle by all means avoid it. But it's weird that your ops team would care about the image type. The whole point of containers is that they don't need to care.
      - winrid 3y ago
        I guess I should have said infra and not ops. But cost cutting has interesting implications on responsibilities :)
  - verdverm 3y ago
    If everyone is on the same base image, then you aren't really dealing with 500mb images, but much smaller layers on top.
  - jrockway 3y ago
    Why even include Alpine? Distroless is the way to go.
- claytongulick 3y ago
  Yeah, this is honestly one of the things that turns me off of containers in general. Like, the whole point was to effectively use linux kernel namespaces with cgroups in an intelligent way to give VM-like isolation, but non-emulated performance - and supposedly not having to deal with image size bloat from the OS like you get in VMs. What we got was an unholy mashup of difficult to debug, bloated images and ridiculously complex deployment and maintenance mechanisms like kubernetes. I just do old school /home/app_name deployments with systemd unit files, and user-level permissions. Oh, and it's webscale[1]. [1] https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
  - tracker1 3y ago
    It doesn't HAVE to be that bulky or complex. You have a lighter space like Dokku or just direct scripted deployments pretty easily. As to the size, you can use debian-slim or alpine as a base for smaller options. There's also bare containers, or close to bare for some languages and platforms as well (go in particular).
    - claytongulick 3y ago
      What's even "lighter" is a single binary sitting in /home/app running under "app" user and launched by systemd unit file with auto restart. Look, I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. Sometimes you don't have a choice of technology, so I get it. What I don't understand is folks that use containers for stuff like go binaries. Or nodejs. I mean, it's just an "npm install". Or now bun with it's fancy new build option, you don't even need that. I honestly don't get the point of containers with languages that have good dependency management, unless you're in a big matrix organization or something. Or, as one HN user put it years ago, "containers are static compilation for millennials". I snorted beer out of my nose the first time I read that.
      - TechBro8615 3y ago
        It feels like the same people who make this argument are also using the other side of their mouth to lament that nobody uses containers for their original purpose of containerization. And yet, that's a legitimate use case that is totally orthogonal to any build process or artifact distribution method. In fact the argument itself betrays a misunderstanding, because the underlying complaint is about using Docker images as a build artifact, but it's presented as if containers are the problem. But they're separate concepts (you don't compile a container, so the snarky analogy to static compilation is nonsensical upon closer inspection). There are plenty of good reasons to containerize even a single binary executable, as demonstrated by the fact that officially maintained images exist for containerizing processes like Postgres or haproxy. Sure, you could run both Postgres and haproxy as services directly on the host, but then you'd miss out on all the benefits either provided by or complementary to containerization, like isolated cgroups and network namespaces that make declarative service orchestration easily achievable with maintainable configuration.

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.

winrid 3y ago

I've been desensitized by my world of 500mb docker containers.

nine_k 3y ago
Docker containers are actually smaller if they share layers with other containers in the system. A ton of containers based on the same image reaps many deduplication benefits.
- tracker1 3y ago
  Yeah, I notice many/most images are based on a recent Debian base if they aren't on Alpine or closer to bare images. I don't consider even Alpine as a base too bad for a lot of apps.
thewataccount 3y ago
Have you tried using alpine based images instead of debian/ubuntu/others? I know it's not always possible especially because of musl but for most things it works fine and is tiny.
- winrid 3y ago
  It becomes a political issue at this point w/ battling the ops team. I have more important battles.
  - thewataccount 3y ago
    Yeah that's fair, if it works it works. Depending on your setup it doesn't really matter anyway.
  - beanjuiceII 3y ago
    how about ubuntu chisel
  - zaphar 3y ago
    If it's a battle by all means avoid it. But it's weird that your ops team would care about the image type. The whole point of containers is that they don't need to care.
    - winrid 3y ago
      I guess I should have said infra and not ops. But cost cutting has interesting implications on responsibilities :)
- verdverm 3y ago
  If everyone is on the same base image, then you aren't really dealing with 500mb images, but much smaller layers on top.
- jrockway 3y ago
  Why even include Alpine? Distroless is the way to go.
claytongulick 3y ago
Yeah, this is honestly one of the things that turns me off of containers in general. Like, the whole point was to effectively use linux kernel namespaces with cgroups in an intelligent way to give VM-like isolation, but non-emulated performance - and supposedly not having to deal with image size bloat from the OS like you get in VMs. What we got was an unholy mashup of difficult to debug, bloated images and ridiculously complex deployment and maintenance mechanisms like kubernetes. I just do old school /home/app_name deployments with systemd unit files, and user-level permissions. Oh, and it's webscale[1]. [1] https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- tracker1 3y ago
  It doesn't HAVE to be that bulky or complex. You have a lighter space like Dokku or just direct scripted deployments pretty easily. As to the size, you can use debian-slim or alpine as a base for smaller options. There's also bare containers, or close to bare for some languages and platforms as well (go in particular).
  - claytongulick 3y ago
    What's even "lighter" is a single binary sitting in /home/app running under "app" user and launched by systemd unit file with auto restart. Look, I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. Sometimes you don't have a choice of technology, so I get it. What I don't understand is folks that use containers for stuff like go binaries. Or nodejs. I mean, it's just an "npm install". Or now bun with it's fancy new build option, you don't even need that. I honestly don't get the point of containers with languages that have good dependency management, unless you're in a big matrix organization or something. Or, as one HN user put it years ago, "containers are static compilation for millennials". I snorted beer out of my nose the first time I read that.
    - TechBro8615 3y ago
      It feels like the same people who make this argument are also using the other side of their mouth to lament that nobody uses containers for their original purpose of containerization. And yet, that's a legitimate use case that is totally orthogonal to any build process or artifact distribution method. In fact the argument itself betrays a misunderstanding, because the underlying complaint is about using Docker images as a build artifact, but it's presented as if containers are the problem. But they're separate concepts (you don't compile a container, so the snarky analogy to static compilation is nonsensical upon closer inspection). There are plenty of good reasons to containerize even a single binary executable, as demonstrated by the fact that officially maintained images exist for containerizing processes like Postgres or haproxy. Sure, you could run both Postgres and haproxy as services directly on the host, but then you'd miss out on all the benefits either provided by or complementary to containerization, like isolated cgroups and network namespaces that make declarative service orchestration easily achievable with maintainable configuration.