4 ms·

As a sibling noted, people do that. But disk space is cheap, and you aren't really losing much other than disk space for unused portions of the OS that are in a

As a sibling noted, people do that. But disk space is cheap, and you aren't really losing much other than disk space for unused portions of the OS that are in a container, but what you gain is a normalized environment that's easy to develop for, test, and add to as needed.

takeda 3y ago
If your container is big it also takes long time to fetch and start it
- esperent 3y ago
  Alpine docker container starts at 5mb.
  - takeda 3y ago
    OP was arguing that today the big size doesn't matter, because disk space is cheap. I was providing argument that it still does.
- notpushkin 3y ago
  Base image layers are deduplicated though. Now if only we could pick a single base image...
  - chaxor 3y ago
    Alpine or Debian. Those are the only base images you ever need.
    - tracker1 3y ago
      Specifically, Debian-slim. But even then, the versions are varied.
  - takeda 3y ago
    Theoretically that would work, in practice it doesn't. Making distroless containers is the way to go.
ptspts 3y ago
Laptop SSD space for 100s of 1 GB containers is not cheap.
- z33k 3y ago
  The ability to easily see and clear the amount of SSD space that images are wasting on my system is probably supposed to attract me to the proprietary Docker desktop application.
- kbenson 3y ago
  1 GB seems like someone is putting way more than a base OS in a container, and many of the cheapest laptops come with at least a 256GB SSD now (Dell will sell you one for $330). A RHEL 9 universal base image, which you can add just the packages you need to, is 217MB. And if you have hundreds of images on your system, maybe remove some you aren't using. I doubt you're using them all, and if you are using them all, they likely aren't using all the space you think they are because they're probably sharing layers.
  - tracker1 3y ago
    I would suggest Alpine (5mb) or Debian Slim (<80mb) for base images. There's no need to add the overhead of RHEL inside containers, it really doesn't give you anything.
    - kbenson 3y ago
      It gives consistency for those that use RHEL and derivatives outside containers, allows easy use of enterprise software aimed at that distro, and it allows tying into registries such as quay.io that will give you notes about when and what aspects of it are out of date (package wise). I'm not saying to necessarily use it, but I wanted to pick something that was on the heavier end of the spectrum to forestall complaints about how for some people's workloads it's not realistic to run a 5MB alpine image given their work environment and needs.
muxator 3y ago
I understand this is easy for a developer, but I think it is not responsible security-wise: that container is a whole toolbox at the disposal of whoever may breach in it. On top of this, as some sibling commenters were saying, it is a waste of bandwidth, time and disk space.
- kbenson 3y ago
  You think manually compiling all your libraries into a singular executable, or custom making your own minimal distro, is safer than using a minimal distro image from an actual OS distribution with security reviews, notifications about package updates, and easy patching, and where you can literally start a shell instance in the container and just check for updates to see if you have security issues? Good luck manually tracking all the security announcements for all the libraries and modules you used. You are doing that, given this is a conversation about security in containers, right? If you aren't shipping setuid binaries in your container, even if someone gets a full shell in the container they are locked down by the container permissions and cgroup limitations, which is the whole point. That some extra utility or library exists but is not running that has an exploit is really not providing much of an attack vector. If an attacker can arbitrarily run something the fact that some code is on the system is not likely to really change their abilities, unless it's setuid, so get rid of that stuff.
  - muxator 3y ago
    There are many facets to security. I would not like someone to have shell access + bash, curl, awk, jq in a container that has full network access to sensitive systems in my applications both upstream and downstream. As per the dependencies of important projects: yep, I read their release notes. And since I do no like to do it, I try to keep them to a minimum, unless it is a prototype or a research project. I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to.
    - kbenson 3y ago
      > I would not like someone to have shell access + bash, curl, awk, jq Having an OS as the container doesn't mean shipping with everything. bash and awk are commnon, and curl might be for some as well since it may be a dependency for something else, buy jq won't be, as well as many other things (and often you have to include the few things I noted anyway, as many applications will call external items and strict exec use isn't always the norm). > I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to. Please consider that perhaps you're being a bit too sensitive, given this is a text medium and you can't hear my inflection. I understand I may have sounded a bit facetious, but I was being honest there. It's a lot of work keeping up with dependencies, so good luck with that if you, I wouldn't want to do it myself, and if you are doing that, I'm always interested in hearing about ways in which people manage it[1]. It's directly relevant to my job. If you weren't doing that, then it was meant as a gentle note that hey, you really should be if you're concerned about security, because anyone that's statically compiling external requirements into a single binary and isn't has got much more to worry about then whether there's other utilities shipped in their container. 1: For example, I wrote https://news.ycombinator.com/item?id=36450815 https://news.ycombinator.com/item?id=36450815 just the other day, which is directly relevant to that idea.
colonelpopcorn 3y ago
You might be unnecessarily exposing attack surface by including unused binaries in your container.

takeda 3y ago

If your container is big it also takes long time to fetch and start it

esperent 3y ago
Alpine docker container starts at 5mb.
- takeda 3y ago
  OP was arguing that today the big size doesn't matter, because disk space is cheap. I was providing argument that it still does.
notpushkin 3y ago
Base image layers are deduplicated though. Now if only we could pick a single base image...
- chaxor 3y ago
  Alpine or Debian. Those are the only base images you ever need.
  - tracker1 3y ago
    Specifically, Debian-slim. But even then, the versions are varied.
- takeda 3y ago
  Theoretically that would work, in practice it doesn't. Making distroless containers is the way to go.

ptspts 3y ago

Laptop SSD space for 100s of 1 GB containers is not cheap.

z33k 3y ago
The ability to easily see and clear the amount of SSD space that images are wasting on my system is probably supposed to attract me to the proprietary Docker desktop application.
kbenson 3y ago
1 GB seems like someone is putting way more than a base OS in a container, and many of the cheapest laptops come with at least a 256GB SSD now (Dell will sell you one for $330). A RHEL 9 universal base image, which you can add just the packages you need to, is 217MB. And if you have hundreds of images on your system, maybe remove some you aren't using. I doubt you're using them all, and if you are using them all, they likely aren't using all the space you think they are because they're probably sharing layers.
- tracker1 3y ago
  I would suggest Alpine (5mb) or Debian Slim (<80mb) for base images. There's no need to add the overhead of RHEL inside containers, it really doesn't give you anything.
  - kbenson 3y ago
    It gives consistency for those that use RHEL and derivatives outside containers, allows easy use of enterprise software aimed at that distro, and it allows tying into registries such as quay.io that will give you notes about when and what aspects of it are out of date (package wise). I'm not saying to necessarily use it, but I wanted to pick something that was on the heavier end of the spectrum to forestall complaints about how for some people's workloads it's not realistic to run a 5MB alpine image given their work environment and needs.

muxator 3y ago

I understand this is easy for a developer, but I think it is not responsible security-wise: that container is a whole toolbox at the disposal of whoever may breach in it. On top of this, as some sibling commenters were saying, it is a waste of bandwidth, time and disk space.

kbenson 3y ago
You think manually compiling all your libraries into a singular executable, or custom making your own minimal distro, is safer than using a minimal distro image from an actual OS distribution with security reviews, notifications about package updates, and easy patching, and where you can literally start a shell instance in the container and just check for updates to see if you have security issues? Good luck manually tracking all the security announcements for all the libraries and modules you used. You are doing that, given this is a conversation about security in containers, right? If you aren't shipping setuid binaries in your container, even if someone gets a full shell in the container they are locked down by the container permissions and cgroup limitations, which is the whole point. That some extra utility or library exists but is not running that has an exploit is really not providing much of an attack vector. If an attacker can arbitrarily run something the fact that some code is on the system is not likely to really change their abilities, unless it's setuid, so get rid of that stuff.
- muxator 3y ago
  There are many facets to security. I would not like someone to have shell access + bash, curl, awk, jq in a container that has full network access to sensitive systems in my applications both upstream and downstream. As per the dependencies of important projects: yep, I read their release notes. And since I do no like to do it, I try to keep them to a minimum, unless it is a prototype or a research project. I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to.
  - kbenson 3y ago
    > I would not like someone to have shell access + bash, curl, awk, jq Having an OS as the container doesn't mean shipping with everything. bash and awk are commnon, and curl might be for some as well since it may be a dependency for something else, buy jq won't be, as well as many other things (and often you have to include the few things I noted anyway, as many applications will call external items and strict exec use isn't always the norm). > I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to. Please consider that perhaps you're being a bit too sensitive, given this is a text medium and you can't hear my inflection. I understand I may have sounded a bit facetious, but I was being honest there. It's a lot of work keeping up with dependencies, so good luck with that if you, I wouldn't want to do it myself, and if you are doing that, I'm always interested in hearing about ways in which people manage it[1]. It's directly relevant to my job. If you weren't doing that, then it was meant as a gentle note that hey, you really should be if you're concerned about security, because anyone that's statically compiling external requirements into a single binary and isn't has got much more to worry about then whether there's other utilities shipped in their container. 1: For example, I wrote https://news.ycombinator.com/item?id=36450815 https://news.ycombinator.com/item?id=36450815 just the other day, which is directly relevant to that idea.

colonelpopcorn 3y ago

You might be unnecessarily exposing attack surface by including unused binaries in your container.