Today I learned that docker creates an empty /.dockerenv file to indicate that you are running in a docker container. Other runtimes like podman commonly use /run/.containerenv. kubernetes uses neither of these, the most common way to detect if you are running in kubernetes is to check for the presence of the KUBERNETES_SERVICE_HOST environment variable. There will also be a directory at /var/run/secrets/kubernetes.io/serviceaccount that contains the service account credentials if you are running in kubernetes.
Posts tagged: containers
All posts with the tag "containers"
backup distrobox image
Today I’m upgrading my distrobox, but don’t want to end up in a situation where I can’t get anything done becauase I work out of my distrobox.
Diun, looks like a very interesting tool to monitor for image updates, it does not make any change, it only makes notifications. This feels like an easy start to getting image updates started with low effort, keep git ops, but requires manual updates. I see this as a tool that would be a great start and pair well with automated image updaters to ensure they are working as expected.
Today I learned that the docs in postiz are a bit behind, (fantastic docs btw, they are to the point, and cover almost all of what you need). The docs state that you need to include an R2 bucket to handle uploads.
This issue shows that more work has been done, one of which is local storage. The compose file they use in the quick start has the required env variables to set this up.
STORAGE_PROVIDER: "local" UPLOAD_DIRECTORY: "/uploads" NEXT_PUBLIC_UPLOAD_DIRECTORY: "/uploads"
looking into my running instance I can see my images there.
Depot’s uptime seems to be great. I definitely hit some issues with it this afternoon 12/24/24 that were not reported. I wonder if my issues were with the fly integration. Maybe fly ran out of credits to depot or something.
Here the integration to depot appears to be opt in using the --depot flag on fly deploy. This must have changed over time though because today it was giving me issues and I had to opt out using fly deploy --depot='false'. Looks like a great service and I just learned about them on their bad day.
Just learned about depot today ironically because it seems to be down and fly is using them under the hood to do the container builds, seems like a really great service for fast builds accross your team.
Dang context can really cause you to pull your hair out. Context seems so freaking convenient, but I’ve avoided it and just ssh in for these reasons. Maybe I’ll come around eventually but for now ssh is my friend.
bootc is the underlying technology that enables OS’s like bazzite, and Aurora from the uBlue ecosystem.
distrobox gives you distrobox-host-exec to run commands on the host. This is handy to get access to host level clis that you probably wouldn’t want to run from the container like podman, docker, flatpak.
DESCRIPTION distrobox-host-exec lets one execute command on the host, while inside of a container.
Under the hood, distrobox-host-exec uses host-spawn a project that lets us execute commands back on the host. If the tool is not found the user will be prompted to install it.
Uptime kuma is a fantastic self hosted monitoring tool. One docker run command and you are up and running. Once you are in you have full control over checking status of urls, frequency, allowed timeouts, and a HUGE list of notification providers
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
I deployed it in my homelab today.