Slashdot Mirror


New Hack Shrinks Docker Containers (www.iron.io)

destinyland writes: Promising "uber tiny Docker images for all the things," Iron.io has released a new library of base images for every major language optimized to be as small as possible by using only the required OS libraries and language dependencies. "By streamlining the cruft that is attached to the node images and installing only the essentials, they reduced the image from 644 MB to 29MB,"explains one technology reporter, noting this makes it quicker to download and distribute the image, and also more secure. "Less code/less programs in the container means less attack surface..." writes Travis Reeder, the co-founder of Iron.io, in a post on the company's blog. "Most people who start using Docker will use Docker's official repositories for their language of choice, but unfortunately if you use them, you'll end up with images the size of the Empire State Building..."

17 of 131 comments (clear)

  1. WTF? by msauve · · Score: 3, Insightful

    What are they talking about, and why do I care about the size of the container Levi's ships my Docker khakis in?

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
    1. Re:WTF? by citylivin · · Score: 2, Insightful

      Im not a developer, but i think its like install shield for windows. Creates application packages or something. Still the summary should really give a brief definition.

      --
      As a potential lottery winner, I totally support tax cuts for the wealthy
    2. Re:WTF? by twistedcubic · · Score: 5, Insightful

      Docker is so hyped nowadays I'm surprised people reading Slashdot are claiming they never heard of it. Docker is an application container. It essentially creates an advanced chroot which runs ONE application (usually). Now 644MB seems a lot of overhead for running one app, so shrinking this to 29MB is a welcome improvement. That said, Docker is not for typical users. Use LXC, LXD, or systemd-nspawn if you want containers that can run several apps with their own init.

    3. Re:WTF? by msauve · · Score: 4, Insightful

      Not everyone who reads /. is a software developer, a *nix sysadmin, or whatever other area of specialization would use that. /. is "News for Nerds," and that encompasses a wide range of technologies/interests, many non-overlapping.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    4. Re:WTF? by Impy+the+Impiuos+Imp · · Score: 2

      Docker is so hyped nowadays I'm surprised people reading Slashdot are claiming they never heard of it. Docker is an application container. It essentially creates an advanced chroot which runs ONE application (usually). Now 644MB seems a lot of overhead for running one app, so shrinking this to 29MB is a welcome improvement.

      That said, Docker is not for typical users. Use LXC, LXD, or systemd-nspawn if you want containers that can run several apps with their own init.

      After 12 seconds of reading the first thing that popped up on Google, this is some kind of virtual machine that runs your app. Is this extra crap standard libraries for that language?

      --
      (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
    5. Re:WTF? by WarJolt · · Score: 2

      Even if you know Docker, fewer people actually think about the implications size have on cloud compute systems.

      For example Amazon EC2 Container Registry(ECR) gives 500MB for the free tier and it's relatively cheap to store large container images. Most cloud services store these local registries in their network, so you don't incur bandwidth charges from external registries. Also it should start faster and is likely more reliable, but those are just bonuses.

      It's true that a small image will start faster, but thats usually not a good enough incentive to really sway anyone one way or the other.

      Local bandwidth within a cloud service provider rarely incurs any charges, so really there is little incentive to making it smaller from the bandwidth perspective.

      The problem is that each container takes some memory footprint. Theres usually two ways that footprint size is bad. Some cloud services simply limit the max footprint size that can be deployed. Services like AWS make you manage the AWS instances that will run your container and you get charged AWS instance hours. If you have to start up huge memory instances to run your large containers you will pay more.

      It's all about understanding your computation and memory requirements. Often times your containers are simply sitting their idle doing nothing, but you will always be using the memory, so memory is an important thing to optimize.

  2. Re:the point by xxxJonBoyxxx · · Score: 2

    As a developer, I though the entire point of Docker was to reduce dependence on an entire layer of IT: the human gatekeepers in charge of the release systems and procedures and eventually the care and feeding of maintenance systems (who often f*** something up with manual fumbling or delay things with meetings involving coffee-swilling waterbags).

    At least that's how I've seen Docker used in corporations so far, anyway.

  3. So.... thin jails by 0100010001010011 · · Score: 4, Insightful

    iocage create -c

    Congratulations, you've just (almost) caught up to decade old technology.

    http://phk.freebsd.dk/pubs/san...

    1. Re:So.... thin jails by Anonymous Coward · · Score: 2, Informative

      It's worse, they've combined jails with the equivalent of statically compiled binaries.

      Bit of a nightmare when there's a vulnerability on a library used in multiple containers.

      Except it isn't. You store your base images in a docker registry, you update that base image, and then you can have your CI environment kick off rebuilds of any dependent images. And as an added bonus you get to test your exact deployable image, including all dependencies, before you actually roll prod. In the past you needed something akin to a Satellite / Spacewalk setup to be able to lock combinations of versions of packages to a point-in-time snapshot. Most people don't seem to do this. They either just auto-update all packages on a regular schedule automatically which would occasionally break things, or they'd let things drift until forced to update by some security vulnerability, which then increases the likelihood of surprises.

      Docker is not for everyone, it's certainly overhyped, it's a more complicated stack than more traditional virtualization or bare metal installs, but it doesn't have the specific problem you're imagining it does. In fact, it's a pretty good solution to a lot of the aspects of the problem you bring up.

  4. Re: Wha? by Adriax · · Score: 2

    That should be the new vulnerability metric. Womp rats.
    "A new vulnerability was found in the D-Star app this week, rating at 3.8 womp rats. CEO Tarkin downplayed the severity of the vulnerability and promised the D-Star app will continue to enhance system stability without interference from any rogue squadrons of hackers."

    --
    I don't suffer from insanity, I enjoy every minute of it!
  5. Image sizes by Dragonslicer · · Score: 4, Funny

    Most people who start using Docker will use Docker's official repositories for their language of choice, but unfortunately if you use them, you'll end up with images the size of the Empire State Building...

    What's that in Libraries of Congress?

  6. Re:the point by steveha · · Score: 5, Informative

    The point of Docker is to have a single package ("container") that contains all of its dependencies, running in isolation from any other Docker containers. Since the container is self-contained, it can be run on any Docker host. For example, if you have some wacky old program that only runs on one particular set of library versions, it might be hard for you to get the Docker container just right to make it run; but once you do, that container will Just Work everywhere, and updating packages on the host won't break it.

    The point of the news story is that someone did a better job of stripping the container down, removing libraries and such that were not true dependencies (weren't truly needed).

    Not only does this make for smaller containers, but it should reduce the attack surface, by removing resources that are available inside the container. For example, if someone finds a security flaw in library libfoo, this would protect against that security flaw by removing libfoo when it is not needed. It's pretty hard for an exploit to call code in a library if the library isn't present. Also, presumably all development tools and even things like command-line shells would be stripped out. Thus a successful attacker might gain control over a docker container instance, but would have no way to escalate privileges any further.

    If the stated numbers are correct (a 644 MB container went down to 29 MB) yet the new small package still works, then clearly there is a lot of unnecessary stuff in that standard 644 MB container.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
  7. Re:I will never give up by fibonacci8 · · Score: 2

    "Less code/less programs in the container means less attack surface..."

    --
    Inheritance is the sincerest form of nepotism.
  8. Re:the point by RabidReindeer · · Score: 2

    Wasn't a common library the entire point of Docker?

    Packaging the libs with the app, etc, to reduce dependence on the host OS?

    No, although it's one of Docker's features. Docker images are actually stacked layers of filesystem sub-images operating as overlays, so a typical Docker image might consist of a base OS image, several library images built by the Docker build process, culminating in the actual application image. Done judiciously, those sub-images can be shared by multiple application images, thereby saving space in the Docker image store.

    But Docker is a lot more than that. You can run virtual networks within containers, share resources between selected containers (and ONLY those container), inject external filesystems into the containers and do many other useful things as well.

  9. Re:the point by Dog-Cow · · Score: 2

    Docker containers don't contain a kernel. They use the host OS for services.

  10. Re:the point by thegarbz · · Score: 2

    The problem with your logic (aside from being irrelevant in the case of Docker since it doesn't include a kernel) is that a lot of the "cruft" has been added as a base requirement to make a bootable modern system, and in many cases to improve performance.

    You can strip everything back to 20 years ago, but will you be able to run your harddrives in PIO mode 2 all for the sake of making the kernel smaller by not needing UDMA support? Okay contrived example, but that's what I'm talking about. You want a small kernel, look at HURD. It should boot on a 64bit system sometime before 2020 and it maybe one day will get USB support.