Tiny Container Challenge: Building a 6kB Containerized HTTP Server

Re:Tiny Container Challenge: Building a 6kB Containerized HT... by SahAssar on Thursday April 22, 2021 @04:27AM (#26900258)

Let's say you are installing this from a normal package manager and want to limit it:

To install:

    apt install mypackage

To edit the systemd unit (automatically creating the file in the right place):

    systemctl edit mypackage

Then add these lines to limit to 2 cpus and 500mb memory:

    [Service]
    CPUAccounting=true
    CPUQuota=200%
    MemoryAccounting=true
    MemoryHigh=500M

And then to start it now and on boot:

    systemctl enable --now mypackage

This is now integrated with package updates, starts on boot, logs to the same place that most other system utilities do and so on.

[ Parent | on HN ]

Re:Tiny Container Challenge: Building a 6kB Containerized HT... by hardwaresofton on Thursday April 22, 2021 @04:57AM (#26900442)

I'm not about to argue against systemd, it's great software, and it's in every distro right now for a reason. Understanding apt (+/- how to package for it), systemctl, and the options you've laid out in your unit file are not trivial, and I would argue that they are less trivial (or harder) than understanding what's happening with containers, especially if you're running rootless containers, and/or using a container tool like podman which does without the daemon.

  --cpus 2 --memory 500M

is easier, and gets you the same results though they may not be as permanent or as well managed -- the management and external stuff is an orthogonal concern, and that's not the situation I was addressing. The original point was insinuating that throwing up a binary and getting it to run. your filesystem is also not available to the container by default, and in this way docker sort of fails closed. If you're running a rootless container, the story is even better.

One thing you have not covered is filesystem isolation, which docker also does very easily. There is a lot to configure on the systemd side[0] and the parts that are overlapping are just easier to configure and run with docker. Systemd is the better tool to build repeatable installs for pet processes, but again, there is a lot of knowledge underneath that is related. People to this day still complain that systemd does too much (I personally like it a lot, and it's great to have everything in one place).

[EDIT] Just to make myself clear, systemd is an amazing tool -- I like it, I run it, I'm not smart enough to administer a more complicated setup -- but docker is easier, for a large part of the small subset of systemd's capabilities that docker covers.

[0]: https://www.redhat.com/sysadmin/mastering-systemd

[ Parent | on HN ]

Re:Tiny Container Challenge: Building a 6kB Containerized HT... by aequitas on Thursday April 22, 2021 @05:19AM (#26900567)

But there is a lot of work to be done before you can do the simple apt install. I (gladly) don't know how it is nowadays but before Dockerfiles/Docker creating your own packages according to the various standards was a pita. Most companies needed a 'packaging specialist/release engineer' role as most developers where not up to the task. Solutions like FPM[0] did help somewhat, but it was still hard when dealing with non-homogeneous environments. Containers solved that problem universally for all distributions.

[0] https://github.com/jordansissel/fpm

[ Parent | on HN ]