Hiddenden/Knowledge-Base
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

first version of the knowledge base :)

Browse Source
This commit is contained in:
Latte
2026-03-14 11:41:54 +01:00
commit 27965301ad
47 changed files with 4356 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

133
20 - Knowledge/containers/container-networking.md Normal file
View File

@@ -0,0 +1,133 @@
---
title: Container Networking
description: Overview of Docker container networking modes and practical networking patterns
tags:
- containers
- docker
- networking
category: containers
created: 2026-03-14
updated: 2026-03-14
---
# Container Networking
## Introduction
Container networking determines how workloads talk to each other, the host, and the rest of the network. In Docker environments, understanding bridge networks, published ports, and special drivers is essential for secure and predictable service deployment.
## Purpose
This document explains how container networking works so you can:
- Choose the right network mode for a workload
- Avoid unnecessary host exposure
- Troubleshoot service discovery and connectivity problems
- Design cleaner multi-service stacks
## Architecture Overview
Docker commonly uses these networking approaches:
- Default bridge: basic isolated network for containers on one host
- User-defined bridge: preferred for most application stacks because it adds built-in DNS and cleaner isolation
- Host network: container shares the host network namespace
- Macvlan or ipvlan: container appears directly on the physical network
- Overlay: multi-host networking for orchestrated environments such as Swarm
## Network Modes
### User-defined bridge
This is the normal choice for single-host multi-container applications. Containers on the same network can resolve each other by service or container name.
Example:
```bash
docker network create app-net
docker run -d --name db --network app-net postgres:16
docker run -d --name app --network app-net ghcr.io/example/app:1.2.3
```
### Published ports
Publishing a port maps traffic from the host into the container:
```bash
docker run -d -p 8080:80 nginx:stable
```
This exposes a service through the host IP and should be limited to the ports you actually need.
### Host networking
Host networking removes network namespace isolation. It can be useful for performance-sensitive agents or software that depends on broadcast-heavy behavior, but it increases the chance of port conflicts and broad host exposure.
### Macvlan or ipvlan
These drivers give a container its own presence on the LAN. They can be useful for software that needs direct network identity, but they also bypass some of the simplicity and isolation of bridge networking.
## Configuration Example
Compose network example:
```yaml
services:
reverse-proxy:
image: caddy:2
ports:
- "80:80"
- "443:443"
networks:
- edge
app:
image: ghcr.io/example/app:1.2.3
networks:
- edge
- backend
db:
image: postgres:16
networks:
- backend
networks:
edge:
backend:
internal: true
```
In this pattern, the database is not reachable directly from the host or external clients.
## Troubleshooting Tips
### Container can reach the internet but not another container
- Verify both containers are attached to the same user-defined network
- Use container or service names rather than host loopback addresses
### Service is reachable internally but not from another host
- Confirm the port is published on the host
- Check host firewall rules and upstream routing
### Random connectivity issues after custom network changes
- Inspect network configuration with `docker network inspect <name>`
- Check for overlapping subnets between Docker networks and the physical LAN
- Restart affected containers after major network topology changes
## Best Practices
- Use user-defined bridge networks instead of the legacy default bridge where possible
- Publish only reverse proxy or explicitly required service ports
- Keep databases and internal backends on private internal networks
- Avoid `network_mode: host` unless there is a clear technical reason
- Document custom subnets to avoid conflicts with VPN and LAN address plans
## References
- [Docker: Bridge network driver](https://docs.docker.com/network/drivers/bridge/)
- [Docker: Networking overview](https://docs.docker.com/engine/network/)
- [Docker: Published ports](https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/)

125
20 - Knowledge/containers/persistent-volumes.md Normal file
View File

@@ -0,0 +1,125 @@
---
title: Persistent Volumes
description: Storage patterns for keeping container data durable across restarts and upgrades
tags:
- containers
- docker
- storage
category: containers
created: 2026-03-14
updated: 2026-03-14
---
# Persistent Volumes
## Introduction
Containers are disposable, but application data usually is not. Persistent volumes provide storage that survives container restarts, recreation, and image upgrades.
## Purpose
Use persistent volumes to:
- Preserve databases, uploads, and application state
- Separate data lifecycle from container lifecycle
- Simplify backup and restore workflows
- Reduce accidental data loss during redeployments
## Architecture Overview
Docker storage typically falls into three categories:
- Named volumes: managed by Docker and usually the best default for persistent app data
- Bind mounts: direct host paths mounted into a container
- Tmpfs mounts: memory-backed storage for temporary data
## Storage Patterns
### Named volumes
Named volumes are portable within a host and reduce the chance of coupling to host directory layouts.
```bash
docker volume create postgres-data
docker run -d \
--name db \
-v postgres-data:/var/lib/postgresql/data \
postgres:16
```
### Bind mounts
Bind mounts are useful when:
- The application expects editable configuration files
- You need direct host visibility into files
- Backups are based on host file paths
Example:
```bash
docker run -d \
--name caddy \
-v /srv/caddy/Caddyfile:/etc/caddy/Caddyfile:ro \
-v /srv/caddy/data:/data \
caddy:2
```
### Permissions and ownership
Many container storage issues come from mismatched UID and GID values between the host and containerized process. Check the image documentation and align ownership before assuming the application is broken.
## Configuration Example
Compose example with named volumes:
```yaml
services:
app:
image: ghcr.io/example/app:1.2.3
volumes:
- app-data:/var/lib/app
db:
image: postgres:16
volumes:
- db-data:/var/lib/postgresql/data
volumes:
app-data:
db-data:
```
## Troubleshooting Tips
### Data disappears after updating a container
- Verify the service is writing to the mounted path
- Check whether a bind mount accidentally hides expected image content
- Inspect mounts with `docker inspect <container>`
### Permission denied errors
- Check ownership and mode bits on bind-mounted directories
- Match container user expectations to host permissions
- Avoid mounting sensitive directories with broad write access
### Backups restore but the app still fails
- Confirm the restored data matches the application version
- Restore metadata such as permissions and database WAL files if applicable
- Test restores on a separate host before using them in production
## Best Practices
- Use named volumes for most stateful container data
- Use bind mounts deliberately for human-managed configuration
- Keep backups separate from the production host
- Record where every service stores its critical state
- Test restore procedures, not only backup creation
## References
- [Docker: Volumes](https://docs.docker.com/engine/storage/volumes/)
- [Docker: Bind mounts](https://docs.docker.com/engine/storage/bind-mounts/)
- [Docker: Tmpfs mounts](https://docs.docker.com/engine/storage/tmpfs/)