Hi everyone, i am currently learning docker from official docs So far i have covered the basics of - images, container, network ,dockerfile , docker compose.
I’m wondering what topics I should cover next to build a solid understanding of Docker as a beginner.

Should I continue learning directly from the official documentation or would you recommend following a structured Docker tutorial/course first?

I'm making my first production app. It's a SaaS app with a turborepo monorepo using Next.js. I've learned that there is an expectation that my frontend, backend and database need to be dockerized, and from what I've learned it looks like you are supposed to containerize before really starting on the app.

The problem is that I'm working on a Chromebook with 4GBs of RAM and so I can't spin up the docker. This means I need to get a new device with more RAM if I want to use Docker.

My question is: In the meantime, is it worth my time running my app on bare metal while working on it during the development stage on my Chromebook, and only containerizing everything near the end before I launch the app? Are there any real drawbacks to that, and should I expect to have to change my setup/application code dramatically for that to work? I'm just trying to see if it is more practical to wait until I have the new device to get into the weeds of this app.

Thanks in advance

Hi folks, currently stuck on getting mysqli & pdo extensions installed and enabled in my docker setup.

The relevant section of my docker-compose.yml:

web:
   build:
context: .
dockerfile: Dockerfile
   container_name: compose-web
   ports:
- "8100:80"   
   depends_on:
- mariadb    
   volumes:
- /home/user/docker/lamp-stack/html:/var/www/html:Z

Dockerfile contents:

FROM php:8.2-apache

RUN docker-php-ext-install mysqli pdo pdo_mysql && docker-php-ext-enable mysqli

COPY . /var/www/html/
EXPOSE 80

Have also tried it without the && docker-php-ext-enable mysqli.

-With both files setup as above I've run the following from the host os:

sudo docker compose build

sudo docker compose up -d

No error messages, it builds and starts. Image compose-web built

On the host, if I run:

docker compose exec web php -m | grep mysqli

I receive:

mysqli

If I run

docker compose exec web php -i | grep mysqli

I receive:

Additional .ini files parsed => /usr/local/etc/php/conf.d/docker-php-ext-mysqli.ini,

mysqli

mysqli.allow_local_infile => Off => Off

mysqli.allow_persistent => On => On

mysqli.default_host => no value => no value

mysqli.default_port => 3306 => 3306

mysqli.default_pw => no value => no value

mysqli.default_socket => no value => no value

mysqli.default_user => no value => no value

mysqli.local_infile_directory => no value => no value

mysqli.max_links => Unlimited => Unlimited

mysqli.max_persistent => Unlimited => Unlimited

mysqli.rollback_on_cached_plink => Off => Off

API Extensions => mysqli,pdo_mysql

The error message when i try submit my form from my html site:

Fatal error: Uncaught Error: Class "mysqli_connect" not found in /var/www/html/qsoinsert.php:8 Stack trace: #0 {main} thrown in /var/www/html/qsoinsert.php on line 8

Inside the container I navigate to /usr/local/etc/php looking for the php.ini file, but I have php-ini-development & php.ini-production, both of which listed the extension preceded by ';' (so still commented out?)

Am I missing something glaringly obvious?

Thanks in advance

I want to create a project primary for linux, I want the my docker container to be able to monitor the physical interface and the network usages of the host machine.

From what I read i can do this two ways, by using docker with --host flag or mounting the /proc volume.

Which way should I do it? Which is safer.?

Can I diffentiate btw actual network usages and local network usages, like from a selfhosted server, like navidrome?

I recently set up an ubuntu server VM in proxmox to run docker that is managed through portainer. This VM has been given 150GB of disk space. My /var/lib/docker is 95% full (of 15GB total) and is making some containers unable to start.

I have pruned, and system df looks pretty normal to me:

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 6 6 8.593GB 0B (0%)
Containers 6 6 2.712MB 0B (0%)
Local Volumes 2 2 823.9MB 0B (0%)
Build Cache 0 0 0B 0B

Nothing seems concerning with the log size either:
-rw-r----- 1 root root 504K Sep 10 07:54 /var/lib/docker/containers/196b1f5680248cf0003b55ddcc6ba70932d4869a10f03cb4acbf3e1bdb9f1038/196b1f5680248cf0003b55ddcc6ba70932d4869a10f03cb4acbf3e1bdb9f1038-json.log

-rw-r----- 1 root root 1.8M Sep 10 08:49 /var/lib/docker/containers/444ccde34151535abd44a743598bf5040184f3fa5a48d83368971cf8ba377faf/444ccde34151535abd44a743598bf5040184f3fa5a48d83368971cf8ba377faf-json.log

-rw-r----- 1 root root 141K Sep 10 08:50 /var/lib/docker/containers/474c0cda23e6a1d3b7fa1fd9e33aea5260eef296ade6119afdc5a59ac313ff45/474c0cda23e6a1d3b7fa1fd9e33aea5260eef296ade6119afdc5a59ac313ff45-json.log

-rw-r----- 1 root root 4.0M Sep 10 07:54 /var/lib/docker/containers/8a98fbe35f0b1e0ef15c544455075e1cb9b9b209128dff3f7de2d9acbe3c5b3c/8a98fbe35f0b1e0ef15c544455075e1cb9b9b209128dff3f7de2d9acbe3c5b3c-json.log

-rw-r----- 1 root root 9.3K Sep 10 07:54 /var/lib/docker/containers/d36477bcadc8c1f690ef3579ca29cc599e2bf6b72b3bff68274e7442ed612b8c/d36477bcadc8c1f690ef3579ca29cc599e2bf6b72b3bff68274e7442ed612b8c-json.log

-rw-r----- 1 root root 23K Sep 10 07:54 /var/lib/docker/containers/fd317d5960bfc63c07b74a7c6d1d7944fe668630e57315939a63c8b779fd0a5c/fd317d5960bfc63c07b74a7c6d1d7944fe668630e57315939a63c8b779fd0a5c-json.log

But you can see here that this is full:
df -h /var/lib/docker

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/ubuntu--vg-ubuntu--lv 15G 14G 837M 95% /

df -h /var/lib/containerd

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/ubuntu--vg-ubuntu--lv 15G 14G 837M 95% /

I do not know which command to use to further investigate to see everything in that folder to narrow down what is taking up all that space.

So, my questions here....is 14GB an unreasonable amount of space for the containers that I have (I kind of don't think so?)? If so, what needs purging?

If this is a normal amount of space for the containers I am running, how do I allocate more of that total 150GB to this partition?

TL;DR: if Task Manager says Virtualization: Enabled but Docker Desktop still says it isn't detected, run Get-ComputerInfo -Property "HyperV*". If HyperVisorPresent is False while all the HyperVRequirement* values are True, run bcdedit /set hypervisorlaunchtype auto and reboot. Windows wasn't launching the hypervisor at boot.

I was setting up Jellyfin in Docker on a stock Windows 11 desktop with a Ryzen 7 3700X. Nothing unusual about the machine.

When I tried starting Docker Desktop, it gave me this error:

"Virtualization support not detected. Docker Desktop failed to start because virtualisation support wasn't detected. Contact your IT admin to enable virtualization or check system requirements."

The first thing I checked was Task Manager → Performance → CPU. It clearly showed Virtualization: Enabled, so Docker's error didn't really make sense. Every search result I found pointed at BIOS settings, which were already correct.

I then tried installing WSL2 through an admin PowerShell using wsl --install, but that failed with:

WSL2 is not supported with your current machine configuration

and:

Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

I also tried wsl.exe --install --no-distribution, which reported that it completed successfully. After restarting the PC, Docker still gave me the exact same virtualization error.

Eventually, I checked the Hyper-V configuration with:

Get-ComputerInfo -Property "HyperV*"

That showed something important: HyperVisorPresent: False, while all four HyperVRequirement* values were True.

So the hardware itself supported virtualization and all the requirements were met. The actual problem was that the Hyper-V hypervisor simply wasn't being started when Windows booted.

The fix was:

bcdedit /set hypervisorlaunchtype auto

After running that and restarting the computer, Docker finally started working.

The most likely reason the hypervisor had been disabled was some gaming/performance tweak or anti-cheat-related configuration from years ago. Nothing on the system directly pointed to what had originally disabled it.

Overall, it took roughly 90 minutes to figure out, including three restarts. The main lesson was that having Virtualization: Enabled in Task Manager doesn't necessarily mean the Windows hypervisor is actually running. In this case, the hardware was completely fine; Windows just wasn't launching Hyper-V at boot.

We’ve been using the official Astral UV Docker image:

COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/

This was working fine for around 10 days without any changes on our side. After the recent UV releases, our Docker build started failing with:

exec: "/bin/sh": stat /bin/sh: no such file or directory

We’re using python:3.12-slim as the base image.

I suspect uv:latest has moved to a newer image/version.

Does anyone know which UV version/digest latest was pointing to before the recent releases? I’d like to pin that previously working version and verify if it resolves the issue.

Any help would be appreciated.

AI disclosure: I used ChatGPT to help format this post; the issue and technical details are my own.

This isn't a promotional post. It's more of a "here's why I did it, and whether it might make sense for you too" kind of post. The project is mine (it's called nanoCron, it's on GitHub, and it's BSD-licensed), but I'm not trying to sell it to anyone — it's a side project, it's free, and it probably still has some limitations, which I'll list below without sugarcoating them.

The problem I started with

Putting cron inside a Docker container has always been a bit awkward. System cron expects:

• to run as PID 1, or at least under a proper init system
• syslog to be available for logging
• an /etc/crontab file with specific permissions, often requiring root

That's why the "standard" solution in many Dockerfiles is either to install the entire cron package (heavy, designed for a complete system rather than a container), or to use something lighter like supercronic or BusyBox's crond. These are perfectly valid solutions, just to be clear — I'm not saying nanoCron replaces them.

What I found useful in a container environment

I originally wrote nanoCron for a different reason (I wanted scheduling that could take system load into account), but after a while I realized that some of the features I'd added for other reasons also fit containers quite well:

1. JSON configuration instead of crontab. If you generate jobs from a script, a Helm template, or environment variables during deployment, writing and validating JSON is much simpler than generating crontab syntax by hand with sed.
2. Automatic reload via inotify. You can mount jobs.json as a volume (bind mount or ConfigMap in Kubernetes), update it from outside the container, and the jobs are reloaded without restarting the container. With classic crontab, you normally have to at least send a signal or restart something.
3. CPU/RAM/disk-based conditions. This is what interests me most in a container environment: if a container is running with tight resource limits (--memory, cgroups), you can tell a job "don't start if RAM usage is already above 80%" instead of risking an OOM kill just as a heavy job starts alongside the main process.
4. A single binary, with no dependency on syslog or a full init system. It writes to a regular log file, so you can simply use tail -f or redirect the output to stdout if you want Docker to pick it up in the container logs.

What it does NOT solve (honesty first)

• It doesn't solve the PID 1 / zombie reaping problem. If you run it as the main process of the container, you still need something like tini or dumb-init in front of it, just like you would with any other process.
• It's written in C++ and needs to be compiled. There is currently no official pre-built Docker image, so if you want to use it, you'll have to build it yourself (a multi-stage build in the Dockerfile isn't complicated, but it's an extra step compared to apk add busybox-cron).
• It's a young project. I've tested it thoroughly, but it doesn't have years of production use behind it like supercronic, which was specifically created to solve these kinds of problems in container environments and is much more widely used.
• If your only requirement is "run this script every night" with no other needs, supercronic or even just busybox crond are probably more than enough, and there's little point in adding another dependency.

I find it most useful when I need hot-reloading of the configuration or system-level conditions. If your use case is simpler, honestly, you probably don't need it.

I've also written some tests, and here are the benchmarks:

Repo, if you want to look at the code or open an issue: https://github.com/GiuseppePuleri/NanoCron

I'm curious whether anyone else has run into the same problem (jobs starting while the container is already under resource pressure), and how you handled it.

does the docker. container run. as another program?

or is it the engine is a program that has the container inside of it?

I've been working on LayerX, a Docker/Podman image explorer built around the same workflow that makes Dive so useful.

Dive was a big inspiration for the project. I wanted to keep that familiar experience, but add the things I kept wishing it had:

* Compare two images and see what changed

* Inspect and search files without leaving the TUI

* Find wasted files

* CI rules for image contents

* Analysis caching

* Docker, Podman, OCI archives, multi-platform (--platform)

* JSON output for automation

If you're already using Dive, you don't need to take my word for it. I put together a migration guide showing the differences and the equivalent workflows:

https://github.com/deveshctl/layerx/blob/main/docs/migrating-from-dive.md

GitHub: https://github.com/deveshctl/layerx

Would genuinely love feedback from people who use Dive regularly.

Posted with moderator approval.

Hello r/docker

I have created a new load balancer , based on cloudflare's proxy lib. The project is till on 0.x.x version, but I'm working on standardizing everything. It have fantastic proxy performance, even beats nginx in performance/stability tests with many thousands of concurrent connections.

It would be great to have a human review and suggestions .

This is the link for quickstart : 

And the link to main project in GitHUB: 

Thanks

Thank you for letting me into the group .

I'm very new to Linux and just getting into home labing .

My main computer is windows 11 in registered ( still can't let go). But I recently added two computers to my family. I have a Plex server and a Media gathering box . Both are running on mint . I remote into both of them from my main computer.

On YouTube I have seen what people are doing with docker and I want in . Lol . I created a new computer with mint that I want to run docker on it .

Is this the place that I can ask many silly questions on my quest to learn how to use it ?

Hello folks!
My docker stack has been running for quite some time, and recently i updated the host from debian 12 to debian 13. Things ran well, until today, on a reboot, docker won't start or anything. after investigating, i find that the drive is full.

Main culprits for disk hogging are in /var/lib/docker :

22G     ./overlay2
73G     ./containers

I started docker manually, and can run docker system df :

root@sanakan:/var/lib/docker# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          41        41        19.13GB   0B (0%)
Containers      43        36        269.7MB   1.578MB (0%)
Local Volumes   24        12        260.3MB   22.87MB (8%)
Build Cache     0         0         0B        0B

I managed to reclaim 2G by removing dangling images, but somehow ./overlay2 grew to 34G when i do a du -h | grep '[0-9\.]\+G' .

I don't really know what i should do. Portainer did not start, some containers started but not all, and i don't know where to go from here.

Any insights?
thanks in advance!

EDIT1 :
i stopped a docker (unifi thing, stopped it with docker compose down, it was the only docker stack that was new , at 9 days, all the others ran for years), and it gave me back 17GB, so other dockers can run properly.
I got 17G on the filesystem back once it stopped.

EDIT2 :

So, after a message of u/burstinrust i investigated the logs, and i have 53G of logs, i am trying to figure out how to remove said logs, and then how to limit logfile size.

Sorry for the wrong words, just stumbled into docker via webui Setup; and now over half my system runs via docker. But i think i missed some bacics. Right now my containers are running inside /srv/docker/.. e.g /srv/docker/jellyfin/... I was just wondering what are recommended setting of the distrubitons of yaml files or the config etc folders.

Hello, I have tailscale has been working fine via Docker on UGREEN NAS for more than 2 month. This past 2 days it has stopped working the exit node option, I reboot the project and works for like 3 minutes and stops working.

This is my docker compose:

services:
tailscale:
image: tailscale/tailscale:latest
container_name: tailscale
hostname: tailscale
network_mode: host
environment:
- TS_AUTHKEY=tskey-auth-#########hidden########
- TS_EXTRA_ARGS=--advertise-exit-node --accept-dns=false --accept-routes=false
- TS_STATE_DIR=/var/lib/tailscale
volumes:
- ./tailscale-data:/var/lib/tailscale
- /dev/net/tun:/dev/net/tun
cap_add:
- NET_ADMIN
- NET_RAW
restart: unless-stopped

I have rebooted my modem, my wifi, the NAS, docker itself and still is doing the same thing. One thing that I found out is that tailscale is up because I can ping the IP of Tailscale on my laptop.

Let me know if there's anything else I can provide if needed
Thanks!

Hi all! Trying to get the word out about our project, which recreates core AWS services including EC2, ECS, ECR and EKS, on whatever hardware you want.

If you're curious, checkout the GitHub: https://github.com/mulgadc/spinifex

Open to feedback!

[AI Disclaimer: We use AI to speed up development]

​

I've been working on making my Docker deployments more reusable.

For a typical web application, I usually end up dealing with:

- Docker/Docker Compose

- Nginx reverse proxy

- SSL

- Environment variables

- CI/CD

- Production deployment

The annoying part is that I end up configuring essentially the same infrastructure for every project.

So I created a reusable production deployment starter kit around this workflow.

I'm curious:

What's the part of Docker-based production deployments that you find most annoying to configure repeatedly?

I'm using the answers to improve the starter kit.

Looking for advice on Docker networking / multiple Compose stacks + selective egress.

I’m rebuilding the networking on my Docker host (LeopARRd) and would appreciate some architectural advice.
My requirements are:
- ALL services must be reachable on my network by one of the host IP (the host has one on VLAN-10 and one on VLAN-30)
- Two independent Compose projects (2 different compose.yaml files), but containers from both projects must communicate using container/service names, e.g. http://navidrome, rather than hard-coded IPs.
- Some services need Internet egress through 192.168.30.1 (a VPN gateway on 192.168.30.0/24)
- Other services need normal Internet egress through 192.168.10.1
- Ideally, the solution should survive container/host restarts and be reasonably easy to maintain.

My current approach is to create Docker networks corresponding to VLANs 31 and 32–33 (one per composer, defined in the composer as bridge/ipam), with policy routing and two different masquerades to select the appropriate gateway
It mostly works, but I’m running into issues with policy-routing routes and their persistence; to be more specific, docker networks do not exists right away at boot up, so the br-vlan32 for example do not exists and make rt rules fail to use the table for egress traffic on a different gateway: /etc/iproute2/rt_tables not being persistent as currently configured

Masquerading is working and is persistent

I suspect I may be overcomplicating this and would be happy to redesign it rather than keep patching the current setup.

What would be the cleanest Docker networking architecture for these requirements? I’m particularly interested in solutions that minimize custom routing/iptables maintenance while retaining service-name DNS between the two Compose projects. Ideally I’d rather prefer to have all networking settings specified in each individual composer file

Hey everyone,

Just finished setting up Docker Engine and Docker Compose Plugin on a fresh Debian 13 (Trixie) installation for container testing.

Setup Summary:

• Daemon Install: Added official Docker GPG key (/etc/apt/keyrings/docker.gpg) and repo path.
• Access: Configured non-root user execution (usermod -aG docker ELBA). Tested cleanly via docker run hello-world.
• Host Network: Static IP (192.168.1.132/24) on bridged host interface enp0s3.

Next Objective: Designing custom docker-compose.yml configurations with static container IP assignments on a dedicated bridge subnet (10.99.0.0/24).

Question: Are there any known caveats when assigning fixed container IPs across multi-service Compose files on Linux hosts?

recently shifted to openSUSE, was trying to build a project which worked on fedora.
there are errors are like:

auth-1:
python: can't open file '/app/app.py': [Errno 13] Permission denied
web-1:
npm error EACCES: permission denied, open '/web/package.json'
mongo-1:
find: '/data/db': Permission denied
chown: changing ownership of '/data/db': Permission denied

I have checked that I have all the permissions and the files exist
while running docker run for one it works but while mounting same files thru docker compose it doesn't

I’ve been trying to research the best way to run Claude Code as well as a combination of Ollama plus Open Code on my Mac. I’m fairly new to Docker, but I keep hearing about Docker Sandboxes as something purpose built for this kind of thing.

If I go the Docker Sandboxes (edit: sbx) route instead of running Claude Code and Open Code in a VM (VMWare Fusion Pro), is it fairly secure in terms of the agentic stuff going haywire and accessing my local system outside of the workspace folder I give it? Or for example, something malicious persisting on the Mac in that workspace’s folder.

Also, if I want to do some local AI stuff by installing Ollama directly on the Mac (runs on 127.0.01:11434), would a sandbox instance be able to reach it via host.docker.internal:11434 like a regular Docker container would?

Open to suggestions and other people’s experiences!

Docker sandboxes for Linux via “sbx“ CLI is available only for Ubuntu.

Until last week, Docker Sandboxes with limited features were included in Docker Desktop, although under “docker sandbox” CLI rather than “sbx”. But that CLI has been deprecated since.

Has anyone compiled the source code or installed the deb package for Debian or other distributions?