Add authentik, tidy up recipe-footer

Signed-off-by: David Young <davidy@funkypenguin.co.nz>

docs/docker-swarm/authelia.md

@@ -274,4 +274,4 @@ What have we achieved? By adding a simple label to any service, we can secure an
 
 [^1]: The initial inclusion of Authelia was due to the efforts of @bencey in Discord (Thanks Ben!)
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/design.md

@@ -94,4 +94,4 @@ In summary, although I suffered an **unplanned power outage to all of my infrast
 
 [^1]: Since there's no impact to availability, I can fix (or just reinstall) the failed node whenever convenient.
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/docker-swarm-mode.md

@@ -180,4 +180,4 @@ What have we achieved?
 
     * [X] [Docker swarm cluster](/docker-swarm/design/)
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/index.md

@@ -23,7 +23,7 @@ You too, action-geek, can save the day, by...
 
 Ready to enter the matrix? Jump in on one of the links above, or start reading the [design](/docker-swarm/design/)
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}
 
 [^1]: This was an [iconic movie](https://www.imdb.com/title/tt0111257/). It even won 2 Oscars! (*but not for the acting*)
 [^2]: There are significant advantages to using Docker Swarm, even on just a single node.

docs/docker-swarm/keepalived.md

@@ -88,4 +88,4 @@ What have we achieved?
 [^1]: Some hosting platforms (*OpenStack, for one*) won't allow you to simply "claim" a virtual IP. Each node is only able to receive traffic targetted to its unique IP, unless certain security controls are disabled by the cloud administrator. In this case, keepalived is not the right solution, and a platform-specific load-balancing solution should be used. In OpenStack, this is Neutron's "Load Balancer As A Service" (LBAAS) component. AWS, GCP and Azure would likely include similar protections.
 [^2]: More than 2 nodes can participate in keepalived. Simply ensure that each node has the appropriate priority set, and the node with the highest priority will become the master.
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/nodes.md

@@ -77,4 +77,4 @@ After completing the above, you should have:
           * At least 20GB disk space (_but it'll be tight_)
     * [X] Connectivity to each other within the same subnet, and on a low-latency link (_i.e., no WAN links_)
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/registry.md

@@ -110,4 +110,4 @@ Then restart docker itself, by running `systemctl restart docker`
 
 [^1]: Note the extra comma required after "false" above
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/shared-storage-ceph.md

@@ -227,4 +227,4 @@ Here's a screencast of the playbook in action. I sped up the boring parts, it ac
 [patreon]:         <https://www.patreon.com/bePatron?u=6982506>
 [github_sponsor]:   <https://github.com/sponsors/funkypenguin>
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/shared-storage-gluster.md

@@ -172,4 +172,4 @@ After completing the above, you should have:
     1. Migration of shared storage from GlusterFS to Ceph
     2. Correct the fact that volumes don't automount on boot
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/traefik-forward-auth/dex-static.md

@@ -203,4 +203,4 @@ What have we achieved? By adding an additional label to any service, we can secu
 
 [^1]: You can remove the `whoami` container once you know Traefik Forward Auth is working properly
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/traefik-forward-auth/google.md

@@ -133,4 +133,4 @@ What have we achieved? By adding an additional three simple labels to any servic
 
 [^1]: Be sure to populate `WHITELIST` in `traefik-forward-auth.env`, else you'll happily be granting **any** authenticated Google account access to your services!
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/traefik-forward-auth/index.md

@@ -52,6 +52,6 @@ Traefik Forward Auth needs to authenticate an incoming user against a provider.
 * [Authenticate Traefik Forward Auth against a whitelist of Google accounts][tfa-google]
 * [Authenticate Traefik Forward Auth against a self-hosted Keycloak instance][tfa-keycloak] with an optional [OpenLDAP backend][openldap]
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}
 
 [^1]: Authhost mode is specifically handy for Google authentication, since Google doesn't permit wildcard redirect_uris, like [Keycloak][keycloak] does.

docs/docker-swarm/traefik-forward-auth/keycloak.md

@@ -100,4 +100,4 @@ What have we achieved? By adding an additional three simple labels to any servic
 
 [KeyCloak][keycloak] is the "big daddy" of self-hosted authentication platforms - it has a beautiful GUI, and a very advanced and mature featureset. Like Authelia, KeyCloak can [use an LDAP server](/recipes/keycloak/authenticate-against-openldap/) as a backend, but _unlike_ Authelia, KeyCloak allows for 2-way sync between that LDAP backend, meaning KeyCloak can be used to _create_ and _update_ the LDAP entries (*Authelia's is just a one-way LDAP lookup - you'll need another tool to actually administer your LDAP database*).
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}

docs/docker-swarm/traefik.md

@@ -250,4 +250,4 @@ You should now be able to access[^1] your traefik instance on `https://traefik.<
 
 [^1]: Did you notice how no authentication was required to view the Traefik dashboard? Eek! We'll tackle that in the next section, regarding [Traefik Forward Authentication](/docker-swarm/traefik-forward-auth/)!
 
---8<-- "recipe-footer.md"
+{% include 'recipe-footer.md' %}