Get AI summaries of any video or article — Sign up free
18 Weird and Wonderful ways I use Docker thumbnail

18 Weird and Wonderful ways I use Docker

NetworkChuck·
6 min read

Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Run GUI applications inside containers by mapping container ports to unique host ports and using a GUI bridge like Chasm VNC.

Briefing

Docker is being used as a lightweight “app sandbox” for everything from full GUI browsers to office suites, GPU-accelerated scientific workloads, and even a browser-based hacking lab—so tools don’t clash, and risky files get contained. The through-line is isolation: run each workload in its own container, map only the ports you need, and keep dependencies from stepping on one another the way they often do on a shared OS.

One of the most striking demos is running a full graphical web browser inside a container. By pulling a LinuxServer.io browser container and mapping host port 3000 to the container’s port 3001, the browser becomes reachable at localhost while still inheriting container isolation. Access is delivered via Chasm VNC, which provides a GUI session to the containerized browser. The same pattern then gets reused for Obsidian—Obsidian notes inside a container with GUI access—again relying on port remapping so multiple containerized apps can coexist without colliding on the same host ports.

The workflow expands into practical productivity and research tools. LibreOffice runs in a container with host ports mapped (3005/3006 in the demo), letting spreadsheets and documents open directly in the browser. Folding@home is also containerized, including optional NVIDIA GPU acceleration. That part requires enabling GPU support and installing the NVIDIA container toolkit so Docker can pass through the GPU; the demo includes troubleshooting steps like restarting WSL and verifying GPU visibility with nvidia-smi before confirming the Folding@home container is reachable on its mapped port.

For day-to-day management, Docker Desktop is presented as the visual layer over the CLI: it shows CPU and memory usage per container and can integrate with WSL2. Docker Desktop also supports extensions, including Poor Retainer, which adds an environment-management view inside the Desktop UI.

Security and safety get a dedicated segment with the Danger Zone. The tool takes potentially risky documents (PDFs, office files, images), converts them into a “safe” PDF, then reconverts to pixel data in a separate sandbox to strip out danger. It requires Docker Desktop to stay running, and the demo shows the conversion process while monitoring container activity.

The transcript then shifts from “useful containers” to “build your own.” A custom Dockerfile is used to containerize an AI tool called fabric, built from a Go-based Docker image, cloning dependencies from GitHub, installing packages, and setting environment variables. After building the image, the container runs fabric commands, and the user adds a shell alias so the same containerized workflow doesn’t require repeating long commands.

Finally, container security tooling and offensive testing show up. Docker Scout scans images for vulnerabilities and suggests fixes by updating package versions; the demo walks through resolving high- and medium-severity CVEs and notes that a dashboard view exists. For hacking labs, the demo uses Kali Linux in a container with an isolated Docker network, then deploys DVWA (Damn Vulnerable Web Application) into that network so the vulnerable service is reachable only through the Kali container. Docker Compose is used to declare the whole lab (network, Kali, DVWA) in a single yml file and tear it down cleanly with docker compose down.

The closing stretch experiments with other OS containers (Rocky Linux works; macOS-in-Docker attempts lead to trouble), spins up a Raspberry Pi environment inside a container (Raspbian buster light), and finishes with a containerized “IT tools” web app offering utilities like RSA key generation, QR code generation, safe-link decoding, and more.

Cornell Notes

Docker is used as a practical isolation layer: each app or workload runs in its own container, with only selected ports exposed to the host. The demo shows GUI apps (a full browser and Obsidian) accessed through Chasm VNC, productivity tools like LibreOffice, and research workloads like Folding@home—including optional NVIDIA GPU acceleration via the NVIDIA container toolkit. It also demonstrates safety tooling (Danger Zone) that sanitizes untrusted documents using container sandboxes. Beyond using prebuilt images, the transcript shows how to build custom images with Dockerfiles (example: fabric), scan them with Docker Scout for vulnerabilities, and assemble an isolated hacking lab using Docker networks and Docker Compose (Kali Linux + DVWA).

How can a full GUI web browser run “inside Docker” while still being usable on the host?

A LinuxServer.io browser container is launched with Docker run, then host ports are mapped 1:1 (the demo maps host port 3000 to container port 3001). Instead of a CLI, GUI access is provided through Chasm VNC, which creates a remote desktop-style session into the container. The browser then appears at localhost:3000 even though the actual GUI session is running in the container’s isolated environment.

Why do port remappings matter when running multiple containerized desktop apps (e.g., Firefox, Obsidian, LibreOffice)?

Containers often default to using the same internal ports. If multiple containers expose the same host port, they conflict. The demo changes host port mappings so each app gets a unique host entry point—for example, Obsidian uses host port 3003 mapped to container port 3000, and host port 3004 mapped to container port 3001. This prevents “stepping on toes” and allows several GUI containers to run simultaneously.

What’s required to run Folding@home with GPU acceleration in a container?

The demo adds optional Docker run switches to enable GPU acceleration and then installs the NVIDIA container toolkit (provided by NVIDIA). After installing, it restarts WSL and verifies GPU access using nvidia-smi. Once Docker can see the GPU, the Folding@home container starts and is reachable via its mapped port (the demo checks localhost:7396 after docker ps shows the container running on that port).

How does Docker Desktop improve container management compared with using only the CLI?

Docker Desktop provides a GUI that surfaces container resource usage (CPU, memory) and makes it easier to see what’s running. It also supports WSL2 integration so Desktop can access images and containers stored in the WSL2 environment. The demo includes a caution: changing WSL integration settings can lead to missing containers (and in the demo, it effectively “deleted” containers from the perspective of Desktop).

How does the hacking lab stay isolated so DVWA isn’t reachable from the host directly?

The demo creates a dedicated Docker network (optionally internal/isolated) and connects Kali Linux and the DVWA container to that same network. DVWA is started on port 80 inside the network, but the host cannot access it directly because it isn’t exposed to the host network. The browser access goes through Kali Linux’s GUI session; the demo confirms this by checking that localhost:80 doesn’t respond while accessing the DVWA container’s IP from within Kali works.

What does Docker Scout do, and how are vulnerabilities addressed in the demo?

Docker Scout analyzes container images for vulnerabilities across packages and layers. The demo scans the fabric image and reports no vulnerabilities, then scans Danger Zone and finds six vulnerabilities, including high-severity issues with CVE details. It then fixes a high-severity CVE by updating the express package version in the Dockerfile, rebuilds the image, and rescans until “no vulnerable packages detected” appears.

Review Questions

  1. When running multiple GUI containers, what combination of internal ports and host port mappings prevents conflicts, and why?
  2. Describe the isolation mechanism used to keep DVWA reachable only through Kali Linux in the demo.
  3. What sequence of steps is needed to enable NVIDIA GPU acceleration for a containerized workload, and how is success verified?

Key Points

  1. 1

    Run GUI applications inside containers by mapping container ports to unique host ports and using a GUI bridge like Chasm VNC.

  2. 2

    Use port remapping to avoid collisions when multiple containers default to the same internal ports.

  3. 3

    For GPU-accelerated containers, install and configure the NVIDIA container toolkit and verify GPU access with nvidia-smi after restarting WSL if needed.

  4. 4

    Docker Desktop adds a resource-monitoring and management layer, and WSL integration settings can affect which containers are visible.

  5. 5

    Danger Zone uses container sandboxes to sanitize untrusted documents by converting them to a safe PDF and then back to pixel data.

  6. 6

    Build repeatable tool environments with Dockerfiles, then run them as containerized apps using docker build and docker run (optionally with shell aliases).

  7. 7

    Harden container usage by scanning images with Docker Scout and iterating on Dockerfile changes until vulnerabilities are resolved.

Highlights

A full browser runs inside a Docker container and is accessed at localhost via Chasm VNC, combining GUI usability with container isolation.
Folding@home can be containerized with optional NVIDIA GPU acceleration—success hinges on the NVIDIA container toolkit and confirming GPU visibility with nvidia-smi.
Danger Zone sanitizes potentially dangerous files by converting them through sandboxed steps, producing a safer PDF output.
Docker Scout provides vulnerability scanning for images and supports a workflow of updating package versions, rebuilding, and rescanning until issues clear.
A hacking lab can be kept isolated by placing Kali Linux and DVWA on a dedicated Docker network so DVWA isn’t reachable directly from the host.

Topics

Mentioned