I never understood how to use Docker, what makes it so special? I would really like to use it on my Rapsberry Pi 3 Model B+ to ease the setup process of selfhosting different things.

I’m currently running these things without Docker:

  • Mumble server with a Discord bridge and a music bot
  • Maubot, a plugin-based Matrix bot
  • FTP server
  • Two Discord Music bots

All of these things are running as systemd services in the background. Should I change this? A lot of the things I’m hosting offer Docker images.

It would also be great if someone could give me a quick-start guide for Docker. Thanks in advance!

  • slazer2au@lemmy.world
    link
    fedilink
    English
    arrow-up
    61
    arrow-down
    2
    ·
    8 months ago

    IMHO with docker and containerization in general you are trading drive space for consistency and relative simplicity.

    a hypothetical:
    You set up your mumble server and it requires the leftpad 3.7 package to run. you install it and everything is fine.
    Now you install your ftp server but it needs leftpad 5.5. what do you do? hope the function that mumble uses in 3.7 still exists in 5.5? run each app in its own venv?

    Docker and containerization resolve this by running each app in its own mini virtual machine. A container running mumble and leftpad 3.7 can coexist on host that also has a container running a ftp server with leftpad 5.5.

    Here is a good video on what hole docker and containerization looks to fill
    https://www.youtube.com/watch?v=Nm1tfmZDqo8

    • Riskable@programming.dev
      link
      fedilink
      English
      arrow-up
      81
      arrow-down
      1
      ·
      8 months ago

      Docker containers aren’t running in a virtual machine. They’re running what amounts to a fancy chroot jail… It’s just an isolated environment that takes advantage of several kernel security features to make software running inside the environment think everything is normal despite being locked down.

      This is a very important distinction because it means that docker containers are very light weight compared to a VM. They use but a fraction of the resources a VM would and can be brought up and down in milliseconds since there’s no hardware to emulate.

      • notfromhere@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        ·
        8 months ago

        FYI docker engine can use different runtimes and there is are lightweight vm runtimes like kata or firecracker. I hope one day docker will default with that technology as it would be better for the overall security of containers.

      • uzay@infosec.pub
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        9
        ·
        edit-2
        8 months ago

        To put it in simpler terms, I’d say that containers virtualise only the operating system rather than the whole underlying machine.

        I guess not then.

        • pztrn@bin.pztrn.name
          link
          fedilink
          English
          arrow-up
          9
          ·
          8 months ago

          It virtualises only parts of operating system (namely processes and network namespaces with ability to passthru devices and mount points). It is still using host kernel, for example.

          • loudwhisper@infosec.pub
            cake
            link
            fedilink
            English
            arrow-up
            1
            ·
            8 months ago

            I wouldn’t say that namespaces are virtualization either. Container don’t virtualize anything, namespaces are all inherited from the root namespaces and therefore completely visible from the host (with the right privileges). It’s just a completely different technology.

            • steakmeoutt@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              4
              arrow-down
              1
              ·
              8 months ago

              The word you’re all looking for is sandboxing. That’s what containers are - sandboxes. And while they a different approach to VMs they do rely on some similar principals.

            • pztrn@bin.pztrn.name
              link
              fedilink
              English
              arrow-up
              1
              ·
              8 months ago

              I never said that it is a virtualization. Yet for easy understanding I named created namespaces “virtualized”. Here I mean “virtualized” = “isolated”. Systemd able to do that with every process btw.

              Also, some “smart individuals” called comtainerization as type 3 hypervisors, that makes me laugh so hard :)

        • Atemu@lemmy.ml
          link
          fedilink
          English
          arrow-up
          5
          ·
          8 months ago

          The operating system is explicitly not virtualised with containers.

          What you’ve described is closer to paravirtualisation where it’s still a separate operating system in the guest but the hardware doesn’t pretend to be physical anymore and is explicitly a software interface.

        • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          4
          ·
          8 months ago

          Not exactly IMO, as containers themselves can simultaneously access devices and filesystems from the host system natively (such as VAAPI devices used for hardware encoding & decoding) or even the docker socket to control the host system’s Docker daemon.

          They also can launch directly into a program you specify, bypassing any kind of init system requirement.

          OC’s suggestion of a chroot jail is the closest explanation I can think of too, if things were to be simplified

    • loudwhisper@infosec.pub
      cake
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      8 months ago

      I would also add security, or at least accessible security. Containers provide a number of isolation features out-of-the-box or extremely easy to configure which other systems require way more effort to achieve, or can’t achieve.

      Ironically, after some conversation on the topic here on Lemmy I compiled a blog post about it.

      • aksdb@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        8 months ago

        Tbf, systemd also makes it relatively easy to sandbox processes. But it’s opt-in, while for containers it’s opt-out.

        • loudwhisper@infosec.pub
          cake
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          8 months ago

          Yeah, and it also requires quite many options, some with harder-to-predict outcomes. For example RootDirectory can be used to effectively chroot the process, but that carries implications such as the application not having access to CA certificates anymore, which in general in containers is a solved problem.

    • MaximilianKohler@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      8 months ago

      Doesn’t that mean that docker containers use up much more resources since you’re installing numerous instances & versions of each program like mumble and leftpad?

      • slazer2au@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        8 months ago

        Kinda, but it depends on the size of the dependencies, with drive space bing so cheap these days do you really worry about 50Mb of storage being wasted on 4 different versions of glib or leftpad

    • TCB13@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      8 months ago

      Docker and containerization resolve this by running each app in its own mini virtual machine

      While what you’ve written is technically wrong, I get why you did the comparison that way. Now there are tons of other containerization solutions that can exactly what you’re describing without the dark side of Docker.