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

Build a Container Image from Scratch

danishpraka.sh

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Build a Container Image from Scratch

#31

Post by vaylian »

godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

> I often wonder, why isn't systemd-nspawn[0] used more often?

I think most people simply don't know about it. A lot of people also don't know that there are alternatives to Docker.

I use both, systemd-nspawn and podman containers. They serve different purposes:

systemd-nspawn: Run a complete operation system in a container. Updates are applied in-place. The whole system is writeable. I manage this system myself. I also use the -M switch for the systemctl and journalctl commands on the host to peek into my nspawn-containers. I create the system with debootstrap.

podman: Run a stripped down operating system or just a contained executable with some supporting files. Most of the system is read-only with some writeable volumes mounted at well-defined locations in the file system tree. I don't manage the container image myself and I have activated auto-updates via the quadlet definition file. I create the container based on an image from a public container registry.

Both solutions have their place. systemd-nspawn is a good choice if you want to create a long-lived linux system with lots of components. podman/docker containers are a good choice if you want to containerize an application with standard requirements.

systemd-nspawn is good for pet containers. podman is good for cattle containers.

Re: Build a Container Image from Scratch

#32

Post by bionsystem »

godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

What is the advantage of nspawn vs lxc ? I use lxc extensively at the moment to test ansible recipes and it works pretty well even though I'm constrained on an old version.

Re: Build a Container Image from Scratch

#33

Post by fuhsnn »

vaylian wrote: post #31
godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

> I often wonder, why isn't systemd-nspawn[0] used more often? I think most people simply don't know about it. A lot of people also don't know that there are alternatives to Docker. I use both, systemd-nspawn and podman containers. They serve different purposes: systemd-nspawn: Run a complete operation system in a container. Updates are applied in-place. The whole system is writeable. I manage this system myself. I a…

I just started learning to setup containers and found nspawn a total convenience, just create ./usr, throw some static-linked binaries to ./bin and systemd-nspawn -D would handle the rest including network pass-through.

Re: Build a Container Image from Scratch

#34

Post by globular-toast »

placardloop wrote: post #15
ranger207 wrote: post #13

Earlier quoted context omitted.

Yeah, this. Docker/container's greatest feature is less the sandboxing than the distribution. The sandboxing is essential to making the distribution work well, but it's a side feature most of the time

It’s kind of funny that people think of “sandboxing” as the main feature of containers, or even as a feature at all. The distribution benefits have always been the entire point of Docker. The logo of Docker is a ship with a bunch of shipping containers on it (the original logo was clearer, but the current logo still shows this). “Containers” has never been about “containment”, but about modularity and portability.

It's not about sandboxing or distribution, it's about having a regular interface. This is why the container analogy works. In the analogy the ship is a computer and the containers are programs. Containers provide a regular interface such that a computer can run any program that is packaged up into a container. That's how things like Kubernetes work. They don't care what's in the container, just give them a container and they can run it.

This is as opposed to the "old world" where computers needed to be specifically provisioned for running said program (like having interpreters and libraries available etc.), which is like shipping prior to containers: ships were more specialised to carrying particular loads.

The analogy should not be extended to the ship moving and transporting stuff. That has nothing to do with it. The internet, URLs and tarballs have existed for decades.

Re: Build a Container Image from Scratch

#35

Post by mrbluecoat »

bionsystem wrote: post #32
godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

What is the advantage of nspawn vs lxc ? I use lxc extensively at the moment to test ansible recipes and it works pretty well even though I'm constrained on an old version.

or nspawn vs apptainer for that matter

Re: Build a Container Image from Scratch

#36

Post by adminm »

DeathArrow wrote: post #26

By containers here the author seems to understand Docker containers. But there are other types of containers like Linux/OpenVZ containers, Windows containers etc.

Yep. Also containers used in the shipping industry. You might have yet another ype in your fridge.

The thing is that because Docker started the craze, the word "container" without further context in the IT world has become to mean docker container.

Re: Build a Container Image from Scratch

#37

Post by guappa »

ranger207 wrote: post #13
cmeacham98 wrote: post #11

Earlier quoted context omitted.

Because Docker/OCI/etc got the most important part right (or at least much better than the alternatives): distribution. All you need to start running a Docker container is a location and tag (or hash). To update, all you do is bump the tag (or hash). If a little more complicated setup is necessary (environment variables, volumes, ports, etc) - this can all be easily represented in common formats like Docker compose o…

Yeah, this. Docker/container's greatest feature is less the sandboxing than the distribution. The sandboxing is essential to making the distribution work well, but it's a side feature most of the time

Docker containers ran as root by default for a great number of years. I'm not even sure if it has now finally been changed.

They provided no sandboxing whatsoever.

Re: Build a Container Image from Scratch

#38

Post by ninkendo »

guappa wrote: post #37
ranger207 wrote: post #13

Earlier quoted context omitted.

Yeah, this. Docker/container's greatest feature is less the sandboxing than the distribution. The sandboxing is essential to making the distribution work well, but it's a side feature most of the time

Docker containers ran as root by default for a great number of years. I'm not even sure if it has now finally been changed. They provided no sandboxing whatsoever.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container.

Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed.

Running as non-root in the container is an additional layer of security but it’s not all-or-nothing: doing so doesn’t make you perfectly secure (privilege escalation bugs will continue to exist) and not doing so doesn’t constitute “nothing whatsoever”.

Re: Build a Container Image from Scratch

#39

Post by psnehanshu »

jmholla wrote: post #18

If the author is here, I think there's a typo in this. In section 1.4, you start working from the scratch layer, but the content continues to refer to alpine as the base layer. FROM scratch COPY ./hello /root/ ENTRYPOINT ["./hello"] > Here, our image contains 2 layers. The first layer comes from the base image, the alpine official docker image i.e. the root filesystem with all the standard shell tools that come along…

That, and they also added the "time" command in the config with the scratch base image.

Re: Build a Container Image from Scratch

#40

Post by prakashdanish »

jmholla wrote: post #18

If the author is here, I think there's a typo in this. In section 1.4, you start working from the scratch layer, but the content continues to refer to alpine as the base layer. FROM scratch COPY ./hello /root/ ENTRYPOINT ["./hello"] > Here, our image contains 2 layers. The first layer comes from the base image, the alpine official docker image i.e. the root filesystem with all the standard shell tools that come along…

Thanks for pointing that out, I'm curating a PR with all the suggestion from here, should be fixed soon!
Post reply on HN