Hello dear community! I just got my greesy engineer hands on a Raspberry Pi 4 8GB to finally be able to host more than one application at the time on a low power budget. I decided to do such thing using Docker, since it’s widely used and documented.
But I’m running into a very weird issue: anytime I try to run a container with any sort of restart policy the container exits with code 0 and it’s not able to run. Weirdly enough I managed to launch the portainer container with the restart option, but debian buster-slim won’t allow it for whatever reason.
Does anyone know why is it acting like that? Thanks in advance!
UPDATE: I was trying different things and now I can’t even spin up a container with debian-buster-slim WITHOUT the restart option. It seemingly creates one without any issues, but I get the exit with code 0 error once more. I’m lost!
UPDATE 2: Appartently debian can’t run in detached mode on the first boot. Still the restart option is a mistery to me.
Yes, everything is working properly and I’m trying to run debian buster-slim which is available for ARM.
I just think that it’s not possible to run a plain distro in detached because there’s no process attached to keep it alive.
Maybe I’m mistaken, I don’t know.
Well containersnot really meant for running whole distros.
If you need to muck around insite it you can start a shell detached and it will run forever.
I was trying to run mumble server inside it without relying on containers made by someone else and I thought that I could just start a container and install it inside just like I do on a base system. But it didn’t work.
So I should use something like docker run --name xyz exec /bin/bash debian:buster-slim ?
docker run --name xyz -d debian:buster-slim /bin/bash
You will however lose all your data if you dont mount volumes.
Once you know what to install you can make it easier for your future self by writing a Dockerfile.
Unfortunately I know how to install, but it won’t work. But it’s out of the scope of this question so I’m not gonna go into the details.
I looked at some made by other people and they don’t look too difficult. But still I can’t figure out why their containers should work while, if I run the same commands, nothing works on my end.
I don’t know, I personally don’t like Docker that much. I mean, sure, if you rely on someone else’s docker, it’s as easy as it gets, however, if you want to compose a docker yourself, things aren’t as fun.
I think you should be looking into LXD, because it is just like running a VM, but using the host’s kernel. That way you can install Mumble like you are used to. And best of all, you can keep using Debian or whatever host OS and choose another one for the container, like Fedora, Centos 7 / 8 / Stream, OpenSUSE LEAP / Tumbleweeb, Ubuntu, Debian, Void, Alpine, Gentoo etc. Just grab a ROOTFS and you’re good to go.
I didn’t know something like that existed. I’m surely gonna look into it. And why not, use both LXD and Docker (if I manage to make a dockerfile on my own or use official containers).
Surely doing things “the old fashioned way” would be easier.
To just toy around with docker just do the following:
sudo docker pull ubuntu
sudo docker run --name example --rm -it ubuntu bash
This should give you a shell in a temporary Ubuntu container named example which ceases to exist when you exit the shell. The docker images are usually not full distributions and are kept as small as possible. Any software you want to use you may need to manually install. Also Docker needs always at least one running process or the container will quit.
This means the moment you exit the shell it will receive a hangup (HUP) signal. Most processes will gracefully exit then and you container will be terminated.
Well, LXD is not a replacement or competitor of docker. You can run Docker inside LXD. Docker is a container technology which focuses on programs, while LXD is a container which focuses on OS.
From what I know (because I’m an ignorant bigot), Docker is used for temporary applications and it’s good for automation, like launching more instances of the program you want to run when demand is high and killing them when demand lowers; or launching updated instance of a container, take over the traffic from the old ones and kill the old containers as soon as the process is complete, so you can update things like a website without downtime (Google does this with K8s and Docker for YouTube). These are just 2 applications for docker.
I’ll still hold my ground though, if you want to run a mumble server in a classic way on a RPi, but don’t want to run it straight on the host OS, just make a LXD container. I’m not saying you shouldn’t look into Docker, maybe in the future you’ll want to automate updates of a mumble server or something, but for now, LXD should suffice.
Another deeper off-topic: you can run 5-6 LXD containers on the Pi (probably even more, but this should be enough) to get started with k3s, a K8s alternative. It’s a good experience to have. I remember reading somewhere that someone had an issue with a LXC or LXD deploy script and kept pushing containers (with apache / nginx, gitlab, etc) to a single RPi and he only discovered when he tried pushing the 21st container, because it failed, yet the Pi held on its own. It was probably a Pi 2 or 3 with really lightweight containers, probably Alpine. Docker is more lightweight, but LXD holds its own. I just recently got into both Docker and Proxmox’s LXC, but from reading further, I’ll be moving to LXD, because it seems like the better option (and also has live migration through CRIU, unlike Proxmox, which the developers refuse to implement).
Thanks for the long explaination. Tinkering with it a couple hours a day for the past week I figured out that much about it, nothing more unfortunately. I’ll keep trying, reading and see if I can get some more done with it.
Yesterday I immediatly started looking up what LXD is. It’s pretty cool, not gonna lie.
I’ve read the paragraph regarding LXD vs Docker and it’s very interesting that you can push a Pi that much. In the past I set up a Bitwarden container on my Pi 2 and after just a couple weeks the Pi just crashed. I’m having this weird issue with TONS of RAM used by cache and I think that’s what made the whole system crash.
I figured out what was the issue. The “only” thing I was doing wrong is using a password that had a symbol in it that the shell was trying so desperately to parse while trying to write the superuser password to the DB.
Once I removed the symbol everything worked absolutely fine and the server has been running for a couple days now.
