Yep, some people sort of miss the point of microservices and make some fairly monolithic containers. Or they’re legacy apps being shoehorned into a container. Some things still require handholding. FreeIPA is a good example. They have a container version, but it’s just a monolithic install in a container and only recommended for testing.
Containerfiles are super easy to write. For the most part if you can do it in a VM, you can do it in a container. This sort of thing is why you would move to containers. Instead of being the “expert” in all the apps you run, you can focus on the things that actually need your attention.
I literally get paid to do this type of work and there is no way for me to be an expert in all the services that our platform runs. Again, that’s kind of the point. Let the person who writes the container be the expert. I’ll provide the platform, the maintenance, upgrades, etc… the developer can provide the expertise in their app.
Correct, not all containers are for services. I would never say that docker is superior. I would however say that containers are (I can be pedantic too). They’re version-controlled, they come with the correct dependencies, etc… There are many reasons why developing with containers is superior and I’m sure you’re aware of them already. Everyone is moving to do exactly that. There are always edge cases, but those are few and far between these days.
30, that’s cute. I currently have 70 containers running on my home server. That doesn’t include any lab I run or the stuff I use at work. Containers make life much easier. I also guarantee you don’t know those apps as well as you think you do either. Just being able to install and configure something doesn’t mean you know the inner workings of them. I used to do the same thing you do. Eventually, I would rather spend my time doing other things or learning certain things more in-depth and be okay with a working knowledge of others. It can be fun and rewarding to do things the hard way but don’t kid yourself and think you’re somehow superior for doing it that way.
Well, yes that’s best practice. That doesn’t mean you have to do it that way.
That’s half the point of the container… You let an expert set it up so you don’t have to know it on that level. You can manage fast more containers this way.
What? No it doesn’t… You could still have just one postgresql database if you wanted just one. It is a big antithetical to microservices, but there is no reason you can do it.
Is it? It becomes much more like the phones and tablets that people are already used to. Go to an app store and get a packaged flatpak app and you’re done.
If all you care about is stability, check my other comments about the Fedora Atomic family. Hard to be more stable than immutable with built-in rollback capabilities. That’s why I currently run Aurora DX.
The biggest downside to Flatpaks is that they’re kind of containers. That’s obviously also they’re biggest upside. But with that isolation comes some bloat compared to rpms directly installed, some don’t integrate as cleanly with the host OS, etc… The Universal Blue images ship with Flatseal and Warehouse which help manage those Flatpaks. For example, if you want to add an external library to the Steam Flatpak, you can use Flatseal to allow the Steam Flatpak to access that directory. By default Steam sandboxes itself to just its own ~/.var area.
A word on toolbox. It’s really cool and it comes with Fedora Atomic spins. However, it was forked and the fork is called distrobox and is miles better. So much better that it’s my opinion that we at Red Hat should deprecate toolbox and just embrace distrobox. What is it? It’s really just a wrapper for podman. It sets up containers to act kind of, sort of like VMs or LXC system containers, but it mounts your home directory inside the container. You can share apps between the distrobox and the host. The idea is that you can create a distrobox for whatever thing you’re doing, install all of that thing’s dependencies, and work from your home directory, but never actually touch your host installation. Kind of like a devcontainer for your system.
Snap is the one we poo poo. Canonical is always going to Canonical. Just like when they tried to make the Unity desktop (which I actually preferred) and the Mir compositor, the community had already settled on GNOME 3 and Wayland. This is sort of snap vs flatpak. Last I knew snap used a proprietary, hosted by Canonical, backend. That’s a big no from me. I’m not staunchly open source or nothing, but there is just no reason for Canonical to be making proprietary anything.
If you can’t tell, I’m stoked about the immutable future of Linux.
systemctl enable syncthing@useris easier than dealing with podman containers right now.
You should check out podman quadlets. It turns your containers into systemd services.
“It just works” is why Linus Torvalds uses Fedora and not Debian. Just saying… Debian does a lot of weird hand holding and many packages come with pre-configured pieces rather than what the developer pushed. They’re usually sensible, but if you don’t know it’s doing that it can be strange. For example, fail2ban on Debian will come with an SSH jail pre-configured. That is what most people use it for, but IMO it’s kind of weird that someone made that decision for you on an app that isn’t pre-installed.
In the defense of Debian vs Ubuntu, Debian won’t force snaps on you.
Silverblue is a totally different beast than what you’re used to. The filesystem is immutable with the exception of /var and /etc. Even /home is moved into /var/home, although a bind mount exists so /home still appears to be there. You are expected to use flatpaks for applications, toolbox for rpms that don’t have a flatpak, and very last resort you can overlay an rpm on the base image. I absolutely think this is the direction linux as a whole is moving. OpenSUSE has MicroOS that does a similar thing and Leap 16 will default to being immutable. Debian has an immutable variant, and SteamOS is built on an immutable flavor of Arch. The Fedora Atomic family specifically supports bootc. You are essentially booting a container as your OS. That’s why it has so much community buy in. You could try looking at the Universal Blue images I mentioned. Bazzite is gaming focused with the option to boot straight into gaming mode, Aurora is a general workstation with KDE, and Bluefin is a general workstation based on GNOME. Each image has a DX version that includes developer tools like VScode and Virtual Machine Manager included.
I’m also a sysad by trade. A consultant for Red Hat. I personally switched to Aurora DX and the only overlayed package I have installed is clevis-dracut so network based disk encryption with tang works. Other than that I have the built-in stuff, flatpaks (Steam is installed this way), and a couple of utilities installed with brew (btop, nvtop). I also don’t want to manage the OS. Getting the OS updates as an atomic image is very appealing. OStree also allows you to rollback if an update does fail for some reason… Doing it this way makes your OS kind of an appliance that you run applications on top of instead of alongside.
Fedora is the obvious answer for you. It’s upstream from your upstream. It has the same tooling you’re used to, but newer packages. A less obvious answer is to embrace the atomic/immutable future and look at Fedora Silverblue or the stuff that the Universal Blue community is putting out. I switched from Silverblue to Aurora-dx and I’ve been extremely happy with it.
The whole thing is told in 3 episode arcs.