Add comments

manuscript/ha-docker-swarm/design.md

@@ -86,3 +86,6 @@ Upon restore, docker failed to start on one of the VMs due to local disk space i
 In summary, although I suffered an **unplanned power outage to all of my infrastructure**, followed by a **failure of a third of my hosts**... ==all my platforms are 100% available with **absolutely no manual intervention**==.
 
 [^1]: Since there's no impact to availability, I can fix (or just reinstall) the failed node whenever convenient.
+
+
+## Your comments?

manuscript/ha-docker-swarm/docker-swarm-mode.md

@@ -233,3 +233,6 @@ cd ~
 curl -O https://raw.githubusercontent.com/funkypenguin/geek-cookbook/master/examples/scripts/gcb-aliases.sh
 echo 'source ~/gcb-aliases.sh' >> ~/.bash_profile
 ```
+
+
+## Your comments?

manuscript/ha-docker-swarm/keepalived.md

@@ -68,3 +68,6 @@ That's it. Each node will talk to the other via unicast (no need to un-firewall
 
 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. 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 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.
+
+
+## Your comments?

manuscript/ha-docker-swarm/shared-storage-ceph.md

@@ -200,3 +200,6 @@ Future enhancements to this recipe include:
 
 1. Rather than pasting a secret key into /etc/fstab (which feels wrong), I'd prefer to be able to set "secretfile" in /etc/fstab (which just points ceph.mount to a file containing the secret), but under the current CentOS Atomic, we're stuck with "secret", per https://bugzilla.redhat.com/show_bug.cgi?id=1030402
 2. This recipe was written with Ceph v11 "Jewel".  Ceph have subsequently releaesd v12 "Kraken". I've updated the recipe for the addition of "Manager" daemons, but it should be noted that the [only reader so far](https://discourse.geek-kitchen.funkypenguin.co.nz/u/ggilley) to attempt a Ceph install using CentOS Atomic and Ceph v12 had issues with OSDs, which lead him to [move to Ubuntu 1604](https://discourse.geek-kitchen.funkypenguin.co.nz/t/shared-storage-ceph-funky-penguins-geek-cookbook/47/24?u=funkypenguin) instead.
+
+
+## Your comments?

manuscript/ha-docker-swarm/shared-storage-gluster.md

@@ -162,3 +162,6 @@ Future enhancements to this recipe include:
 
 1. Migration of shared storage from GlusterFS to Ceph ()[#2](https://gitlab.funkypenguin.co.nz/funkypenguin/geeks-cookbook/issues/2))
 2. Correct the fact that volumes don't automount on boot ([#3](https://gitlab.funkypenguin.co.nz/funkypenguin/geeks-cookbook/issues/3))
+
+
+## Your comments?

manuscript/ha-docker-swarm/traefik.md

@@ -144,3 +144,6 @@ Additional features I'd like to see in this recipe are:
 1. Include documentation of oauth2_proxy container for protecting individual backends
 2. Traefik webUI is available via HTTPS, protected with oauth_proxy
 3. Pending a feature in docker-swarm to avoid NAT on routing-mesh-delivered traffic, update the design
+
+
+## Your comments?

manuscript/ha-docker-swarm/vms.md

@@ -83,3 +83,6 @@ After completing the above, you should have:
 [X] 3 x fresh atomic instances, at the latest releases,
     running Docker v1.13 (docker-latest)
 ```
+
+
+## Your comments?

manuscript/recipies/autopirate.md

@@ -477,3 +477,5 @@ Log into each of your new tools at its respective HTTPS URL. You'll be prompted
 ## Chef's Notes
 
 1. In many cases, tools will integrate with each other. I.e., Radarr needs to talk to SABnzbd and NZBHydra, Ombi needs to talk to Radarr, etc. Since each tool runs within the stack under its own name, just refer to each tool by name (i.e. "radarr"), and docker swarm will resolve the name to the appropriate container. You can identify the tool-specific port by looking at the docker-compose service definition.
+
+## Your comments?

manuscript/recipies/duplicity.md

@@ -164,3 +164,5 @@ Nothing will happen. Very boring. But when the cron script fires (daily), duplic
 
 1. Automatic backup can still fail if nobody checks that it's running successfully. I'll be working on an upcoming recipe to monitor the elements of the stack, including the success/failure of duplicity jobs.
 2. The container provides the facility to specify an SMTP host and port, but not credentials, which makes it close to useless. As a result, I've left SMTP out of this recipe. To enable email notifications (if your SMTP server doesn't require auth), add ```SMTP_HOST```, ```SMTP_PORT```, ```EMAIL_FROM``` and ```EMAIL_TO``` variables to duplicity.env
+
+## Your comments?

manuscript/recipies/ghost.md

@@ -69,3 +69,5 @@ Create your first administrative account at https://**YOUR-FQDN**/admin/
 548K	/var/data/ghost/
 [root@ds1 ghost]#
 ```
+
+## Your comments?

manuscript/recipies/gitlab-runner.md

@@ -60,3 +60,6 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 
 1. You'll note that I setup 2 runners. One is locked to a single project (this cookbook build), and the other is a shared runner. I wanted to ensure that one runner was always available to run CI for this project, even if I'd tied up another runner on something heavy-duty, like a container build. Customize this to your use case.
 2. Originally I deployed runners in the same stack as GitLab, but I found that they would frequently fail to start properly when I launched the stack. I think that this was because the runners started so quickly (and GitLab starts so slowly!), that they always started up reporting that the GitLab instance was invalid or unavailable. I had issues with CI builds stuck permanently in a "pending" state, which were only resolved by restarting the runner. Having the runners deployed in a separate stack to GitLab avoids this problem.
+
+
+## Your comments?

manuscript/recipies/gitlab.md

@@ -132,3 +132,6 @@ Log into your new instance at https://[your FQDN], with user "root" and the pass
 A few comments on decisions taken in this design:
 
 1. I use the **sameersbn/gitlab:latest** image, rather than a specific version. This lets me execute updates simply by redeploying the stack (and why **wouldn't** I want the latest version?)
+
+
+## Your comments?

manuscript/recipies/gollum.md

@@ -128,3 +128,6 @@ Authenticate against your OAuth provider, and then start editing your wiki!
 ## Chef's Notes
 
 1. In the current implementation, Gollum is a "single user" tool only. The contents of the wiki are saved as markdown files under /var/data/gollum, and all the git commits are currently "Anonymous"
+
+
+## Your comments?

manuscript/recipies/huginn.md

@@ -143,3 +143,6 @@ Log into your new instance at https://**YOUR-FQDN**. You'll need to use the "Sig
 ## Chef's Notes
 
 1. I initially considered putting an oauth proxy in front of Huginn, but since the invitation code logic prevents untrusted access, and since using a proxy would break oauth for sevices like Twitter integration, I left it out.
+
+
+## Your comments?

manuscript/recipies/kanboard.md

@@ -78,3 +78,6 @@ Log into your new instance at https://**YOUR-FQDN**. Default credentials are adm
 
 1. The default theme can be significantly improved by applying the [ThemePlus](https://github.com/phsteffen/kanboard-themeplus) plugin.
 2. Kanboard becomes more useful when you integrate in/outbound email with [MailGun](https://github.com/kanboard/plugin-mailgun), [SendGrid](https://github.com/kanboard/plugin-sendgrid), or [Postmark](https://github.com/kanboard/plugin-postmark).
+
+
+## Your comments?

manuscript/recipies/mail.md

@@ -170,3 +170,5 @@ Launch the mail server stack by running ```docker stack deploy docker-mailserver
 1. One of the elements of this design which I didn't appreciate at first is that since the config is entirely file-based, **setup.sh** can be run on any container host, provided it has the shared data mounted. This means that even though docker-mailserver was not designed with docker swarm in mind, it works perfectl with swarm. I.e., from any node, regardless of where the container is actually running, you're able to add/delete email addresses, view logs, etc.
 
 2. If you're using sieve with Rainloop, take note of the [workaround](https://discourse.geek-kitchen.funkypenguin.co.nz/t/mail-server-funky-penguins-geek-cookbook/70/15) identified by [ggilley](https://discourse.geek-kitchen.funkypenguin.co.nz/u/ggilley)
+
+## Your comments?

manuscript/recipies/miniflux.md

@@ -70,3 +70,6 @@ Log into your new instance at https://**YOUR-FQDN**. Default credentials are adm
 
 1. I chose [saghul/miniflux](https://hub.docker.com/r/saghul/miniflux/)'s over the "official" [miniflux/miniflux](https://hub.docker.com/r/miniflux/miniflux/) image, because currently the official image doesn't log to stdout (which you want, for docker logging commands), and because I have an expectation that nginx is more lightweight (faster) than apache.
 2. Find the bookmarklet under the "about" page. I know, it took me ages too.
+
+
+## Your comments?

manuscript/recipies/piwik.md

@@ -92,4 +92,4 @@ Launch the Piwik stack by running ```docker stack deploy piwik -c <path -to-dock
 
 Log into your new instance at https://**YOUR-FQDN**, and follow the wizard to complete the setup.
 
-## Chef's Notes
+## Your comments?

manuscript/recipies/template.md

@@ -109,3 +109,5 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 ## Chef's Notes
 
 1. If you wanted to expose the Wekan UI directly, you could remove the oauth2_proxy from the design, and move the traefik-related labels directly to the wekan container. You'd also need to add the traefik network to the wekan container.
+
+## Your comments?

manuscript/recipies/tiny-tiny-rss.md

@@ -134,3 +134,5 @@ There are several TTRSS containers available on docker hub, none of them "offici
 1. Docker swarm looses the docker-compose concept of "dependencies" between containers. In the case of this stack, the application server typically starts up before the database container, which causes the database autoconfiguration scripts to fail, and brings up the app in a broken state. To prevent this, I  include "[wait-for](https://github.com/Eficode/wait-for/)", which (combined with "S6_BEHAVIOUR_IF_STAGE2_FAILS=2"), will cause the app container to restart (and attempt to auto-configure itself) until the database is ready.
 
 2. The upstream git URL [changed recently](https://discourse.tt-rss.org/t/gitlab-is-overbloated-shit-garbage/325/6), but my experience of the new repository is that it's **SO** slow, that the initial "git clone" on setup of the container times out. To work around this, I created [my own repo](https://github.com/funkypenguin/tt-rss.git), cloned upstream, pushed it into my repo, and pointed the container at my own repo with TTRSS_REPO. I don't get the _latest_ code changes, but at least the app container starts up. When upstream git is performing properly, I'll remove TTRSS_REPO to revert back to the "rolling release".
+
+## Your comments?

manuscript/recipies/wekan.md

@@ -142,3 +142,6 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 ## Chef's Notes
 
 1. If you wanted to expose the Wekan UI directly, you could remove the oauth2_proxy from the design, and move the traefik-related labels directly to the wekan container. You'd also need to add the traefik network to the wekan container.
+
+
+## Your comments?

manuscript/reference/data_layout.md

@@ -15,3 +15,6 @@ Realtime data (typically database files or files-in-use) are stored in /var/data
 ## 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.
+
+
+## Your comments?

manuscript/reference/git-docker.md

@@ -50,3 +50,6 @@ The key's randomart image is:
 ```
 
 Now add the contents of /var/data/git-docker/data/.ssh/id_ed25519.pub to your git account, and off you go - just run "git" from your Atomic host as usual, and pretend that you have the client installed!
+
+
+## Your comments?

manuscript/reference/networks.md

@@ -5,7 +5,7 @@ In order to avoid IP addressing conflicts as we bring swarm networks up/down, we
 Network  | Range
 --|--
 [Traefik](https://geek-cookbook.funkypenguin.co.nz/ha-docker-swarm/traefik/)  | _unspecified_
-[Docker-cleanup](https://geek-cookbook.funkypenguin.co.nz/ha-docker-swarm/docker-swarm-mode/#setup-automated-cleanup) | 
+[Docker-cleanup](https://geek-cookbook.funkypenguin.co.nz/ha-docker-swarm/docker-swarm-mode/#setup-automated-cleanup) |
 172.16.0.0/24
 [Mail Server](https://geek-cookbook.funkypenguin.co.nz/recipies/mail/)  | 172.16.1.0/24
 [Gitlab](https://geek-cookbook.funkypenguin.co.nz/recipies/gitlab/) | 172.16.2.0/24
@@ -17,3 +17,6 @@ Network  | Range
 [Kanboard](https://geek-cookbook.funkypenguin.co.nz/recipies/kanboard/)  |  172.16.8.0/24
 [Gollum](https://geek-cookbook.funkypenguin.co.nz/recipies/gollum/)  |  172.16.9.0/24
 [Duplicity](https://geek-cookbook.funkypenguin.co.nz/recipies/duplicity/)  |  172.16.10.0/24
+
+
+## Your comments?

manuscript/reference/oauth_proxy.md

@@ -77,3 +77,6 @@ Note above how:
 * Labels are required to tell Traefik to forward the traffic to the proxy, rather than the backend container running the app
 * An environment file is defined, but..
 * The redirect URL must still be passed to the oauth_proxy in the command argument
+
+
+## Your comments?

manuscript/reference/openvpn.md

@@ -56,3 +56,6 @@ docker run -d --name vpn-client \
 ````
 
 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.
+
+
+## Your comments?