1
0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 09:46:23 +00:00

Experiment with PDF generation

Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2022-08-19 16:40:53 +12:00
parent c051e0bdad
commit abf9309cb1
317 changed files with 124 additions and 546 deletions

View File

@@ -0,0 +1,17 @@
# Data layout
The applications deployed in the stack utilize a combination of data-at-rest (_static config, files, etc_) and runtime data (_live database files_). The realtime data can't be [backed up][duplicity] with a simple copy-paste, so where we employ databases, we also include containers to perform a regular export of database data to a filesystem location.
So that we can confidently backup all our data, I've setup a data layout as per the following example:
## Configuration data
Configuration data goes into `/var/data/config/[recipe name]`, and is typically only a docker-compose .yml, and a .env file
## Runtime data
Runtime data (*typically database files or files-in-use*) are stored in `/var/data/runtime/[recipe-name]`, and are **excluded** from backup (_They change constantly, and cannot be safely restored_).
## Static data
Static data goes into `/var/data/[recipe name]`, and includes anything that can be safely backed up while a container is running. This includes database exports of the runtime data above.

View File

@@ -0,0 +1,44 @@
---
title: Docker Swarm Network allocations
---
# Networks
In order to avoid IP addressing conflicts as we bring swarm networks up/down, we will statically address each docker overlay network, and record the details below:
| Network | Range |
|-----------------------------------------------------------------------------------------------------------------------|----------------|
| [Traefik](/docker-swarm/traefik/) | _unspecified_ |
| [Docker-cleanup](/docker-swarm/docker-swarm-mode/#setup-automated-cleanup) | 172.16.0.0/24 |
| [Mail Server](/recipes/mail/) | 172.16.1.0/24 |
| [Gitlab](/recipes/gitlab/) | 172.16.2.0/24 |
| [Wekan](/recipes/wekan/) | 172.16.3.0/24 |
| [NightScout](/recipes/nightscout/) | 172.16.4.0/24 |
| [Tiny Tiny RSS](/recipes/tiny-tiny-rss/) | 172.16.5.0/24 |
| [Huginn](/recipes/huginn/) | 172.16.6.0/24 |
| [Gollum](/recipes/gollum/) | 172.16.7.0/24 |
| Immich (coming soon!) | 172.16.8.0/24 |
| Mastodon (coming soon!) | 172.16.9.0/24 |
| [Duplicity](/recipes/duplicity/) | 172.16.10.0/24 |
| [Autopirate](/recipes/autopirate/) | 172.16.11.0/24 |
| [Nextcloud](/recipes/nextcloud/) | 172.16.12.0/24 |
| [Portainer](/recipes/portainer/) | 172.16.13.0/24 |
| [Home Assistant](/recipes/homeassistant/) | 172.16.14.0/24 |
| [OwnTracks](/recipes/owntracks/) | 172.16.15.0/24 |
| [Plex](/recipes/plex/) | 172.16.16.0/24 |
| [Calibre-Web](/recipes/calibre-web/) | 172.16.18.0/24 |
| [Wallabag](/recipes/wallabag/) | 172.16.19.0/24 |
| [InstaPy](/recipes/instapy/) | 172.16.20.0/24 |
| [MiniFlux](/recipes/miniflux/) | 172.16.22.0/24 |
| [Gitlab Runner](/recipes/gitlab-runner/) | 172.16.23.0/24 |
| [Bookstack](/recipes/bookstack/) | 172.16.33.0/24 |
| [Swarmprom](/recipes/swarmprom/) | 172.16.34.0/24 |
| [Realms](/recipes/realms/) | 172.16.35.0/24 |
| [ElkarBackup](/recipes/elkarbackup/) | 172.16.36.0/24 |
| [OpenLDAP](/recipes/openldap/) | 172.16.39.0/24 |
| [PrivateBin](/recipes/privatebin/) | 172.16.41.0/24 |
| [Wetty](/recipes/wetty/) | 172.16.45.0/24 |
| [phpIPAM](/recipes/phpipam/) | 172.16.47.0/24 |
| [Keycloak](/recipes/keycloak/) | 172.16.49.0/24 |
| [Duplicati](/recipes/duplicati/) | 172.16.55.0/24 |
| [Restic](/recipes/restic/) | 172.16.56.0/24 |
| [Paperless NG](/recipes/paperless-ng/) | 172.16.58.0/24 |

View File

@@ -0,0 +1,3 @@
# Oauth2 proxy
I've deprecated the oauth2-proxy recipe in favor of [Traefik Forward Auth](/docker-swarm/traefik-forward-auth/). It's infinitely more scalable and easier to manage!

61
docs/reference/openvpn.md Normal file
View File

@@ -0,0 +1,61 @@
---
title: OpenVPN on Docker Swarm
---
# OpenVPN
Sometimes you need an OpenVPN tunnel between your docker hosts and some other environment. I needed this to provide connectivity between swarm-deployed services like Home Assistant, and my IOT devices within my home LAN.
OpenVPN is one application which doesn't really work in a swarm-type deployment, since each host will typically require a unique certificate/key to connect to the VPN anyway.
In my case, I needed each docker node to connect via [OpenVPN](http://www.openvpn.org) back to a [pfsense](http://www.pfsense.org) instance, but there were a few gotchas related to OpenVPN at CentOS Atomic which I needed to address first.
## SELinux for OpenVPN
Yes, SELinux. Install a custom policy permitting a docker container to create tun interfaces, like this:
````bash
cat << EOF > docker-openvpn.te
module docker-openvpn 1.0;
require {
type svirt_lxc_net_t;
class tun_socket create;
}
#============= svirt_lxc_net_t ==============
allow svirt_lxc_net_t self:tun_socket create;
EOF
checkmodule -M -m -o docker-openvpn.mod docker-openvpn.te
semodule_package -o docker-openvpn.pp -m docker-openvpn.mod
semodule -i docker-openvpn.pp
````
## Insert the tun module
Even with the SELinux policy above, I still need to insert the "tun" module into the running kernel at the host-level, before a docker container can use it to create a tun interface.
Run the following to auto-insert the tun module on boot:
````bash
cat << EOF >> /etc/rc.d/rc.local
# Insert the "tun" module so that the vpn-client container can access /dev/net/tun
/sbin/modprobe tun
EOF
chmod 755 /etc/rc.d/rc.local
````
## Connect the VPN
Finally, for each node, I exported client credentials, and SCP'd them over to the docker node, into /root/my-vpn-configs-here/. I also had to use the NET_ADMIN cap-add parameter, as illustrated below:
````bash
docker run -d --name vpn-client \
--restart=always --cap-add=NET_ADMIN --net=host \
--device /dev/net/tun \
-v /root/my-vpn-configs-here:/vpn:z \
ekristen/openvpn-client --config /vpn/my-host-config.ovpn
````
Now every time my node boots, it establishes a VPN tunnel back to my pfsense host and (_by using custom configuration directives in OpenVPN_) is assigned a static VPN IP.

View File

@@ -0,0 +1,26 @@
# Troubleshooting
Having difficulty with a recipe? Here are some tips..
## Why is my stack not launching?
Run ```docker stack ps <stack name> --no-trunc``` for more details on why individual containers failed to launching
## Attaching to running container
Need to debug **why** your oauth2_proxy container can't talk to its upstream app? Start by identifying which node the proxy container is running on, using ```docker ps <stack name>```.
SSH to the host node, and attach to the container using ```docker exec -it <continer id> /bin/bash``` (_substitute ```/bin/ash``` for ```/bin/bash```, in the case of an Alpine container_), and then try to telnet to your upstream host.
## Watching logs of container
Need to see what a particular container is doing? Run ```docker service logs -f <stack name>_<container name>``` to watch a particular service. As the service dies and is recreated, the logs will continue to be displayed.
## Visually monitoring containers with ctop
For a visual "top-like" display of your container's activity (_as well as a [detailed per-container view](https://github.com/bcicen/ctop/blob/master/_docs/single.md)_), try using [ctop](https://github.com/bcicen/ctop).
To execute, simply run `docker run --rm -ti --name ctop -v /var/run/docker.sock:/var/run/docker.sock quay.io/vektorlab/ctop:latest`
Example:
![ctop screenshot](https://github.com/bcicen/ctop/raw/master/_docs/img/grid.gif)