#Podman als Zwischenstufe von #Docker zu #Kubernetes.
Ich hatte allerdings gehofft, er geht etwas auf das Pod-Konzept ein. Aber egal, war trotzdem wieder sehr lehrreich.
Danke #GLT
#GLT2024 #Graz #ccc #Chaos #systemd #Container #GNU/Linux #PoweredByRSS
https://linuxnews.de/podman-5-0-verbessert-hypervisor-unterstuetzung/ #Podman
Nun gut - der Schritt von #docker zu #podman ist getan und Dank #podman-compose läuft unsere #Nextcloud quasi 1:1 seit 8 Monaten stabil.
Es wird Zeit, den zweiten Schritt zu tun: Den Compose-Rotz in einen #Pod zu migrieren, um dann rootless Port 80 und 443 anzubieten und einfache #systemd - Integration in einem Rutsch zu erhalten.
Hab' ja noch keinen Schimmer, wie ich vorgehen soll...
✅ #Windows10 in #KVM gezwängt
✅ #Steuererklärung fertig - nettes Ergebnis
✅ erster eigener #S3 #Storage mit #minio und #podman aufgebaut
✅ erste sehr vielversprechende Tests mit #restic absolviert
✅ Erkältung eingefangen
Und ihr so?
https://linuxnews.de/opensuse-leap-micro-5-5-veroeffentlicht/
#openSUSE #podman
Auf meinem für einen ganzen Schwung von Aufgaben dienenden Raspberry Pi laufen Home Assistant, Whoogle, Watchtower und Portainer in Docker-Containern. Kurz- bis mittelfristig werden wohl noch weitere auf dieser Art bereitgestellte Dienste hinzukommen.
Möchte ich da eigentlich mittlerweile unbedingt zu podman wechseln? Oder sollte ich vorher genau recherchieren, in welchen Fällen podman aktuell doch noch nicht so ein passgenaues Drop-In-Replacement darstellt?
A very interesting project.
https://www.youtube.com/watch?v=eM1p47tow4o
#distrobox #linux #podman #distribution #container
"The #Linux secret behind the new #TrueNAS release, Intel acquires a major Kernel contributor and our thoughts on #Podman 4.0." https://www.jupiterbroadcasting.com/147737/linux-action-news-229/
I know I’ve posted recently about containers, but I still regret not starting to use them earlier. It was because my hosting was ‘working’ and I did not see the need. But once I started getting more issues with upgrading some applications, I realised the benefits of containers.
Pre-made containers get distributed with just what’s necessary to run the application it contains. With a container engine, like Podman, Docker, or CRI-O, you can run a containerized application without installing it in any traditional sense. Container engines are often cross-platform, so even though containers run Linux, you can launch containers on Linux, macOS, or Windows.
One thing I had to get to grips with, was depending on the image you use to create your container, some just require pulling a new image to update the application, and some require the upgrade to be run as normal within the running application. You also want to be sure to do regular backups of any external volumes, as these contain user data that is not recreated by the container.
See https://opensource.com/article/22/2/start-running-containers
#technology #containers #docker #podman #hosting
#Blog, ##containers, ##docker, ##hosting, ##podman, ##technology
Podman has two main advantages over Docker:
* Does not require root privileges to run Docker containers
* Has no single running daemon as a single point of failure
And although it is compatible with running and creating Docker containers, it cannot use Watchtower for automated checking of updates for containers. But with systemd managed containers there is an auto-update option for Podman which is worth looking at.
See https://opensource.com/article/22/1/run-containers-without-sudo-podman
#technology #containers #docker #podman
#Blog, ##containers, ##docker, ##podman, ##technology
The title presents this as objective advice on "containers", but #ibm #redhat uses that to push its own stuff, which will always work better when you pay IBM. #podman as OSPS https://www.redhat.com/sysadmin/sensitive-data-containers
#ibm #redhat pushing #vendorLockin #podman Enhancements include building images and tearing down pods with play kube and support for Kubernetes-style init containers.
