Marco's adds

Author: Marco Capuccini

advanced_topics/advanced_topics_intro.rst

@@ -1,22 +1,12 @@
 Cloudflare DNS Records
 ======================
-`Cloudflare <https://www.cloudflare.com>`_ runs one of the largest authoritative DNS networks in the world. With an average of a few milliseconds query speed, DNS updates happen within seconds.
+`Cloudflare <https://www.cloudflare.com>`_ runs one of the largest authoritative DNS networks in the world. In order to resolve domain names for exposed services, KubeNow can optionally configure the Cloudflare dynamic DNS service, so that a base domain name will resolve to the edge nodes (or the master node if no edge node is deployed).
 
-Thus in order to resolve domain names for the Kubenow exposed services, the deployment script adds a wildcard record to the Cloudflare dynamic DNS service, such that a configurable base domain name will resolve to either the edge nodes or the master node when enabled to be working as an edge node.
-
-Cloudflare's settings can be changed within the `terraform.tfvars` created automatically when initializing a :doc:`deploy configuration directory <../getting_started/bootstrap>` by running::
-
-  kn init <your-provider> my_deployment
-
-Precisely, here below can be found an example of the configuration lines to be optionally tweaked in case a user had a different, dedicated Cloudflare account::
+To configure the Cloudflare dynamic DNS service, it is sufficient to uncomment the following lines in the ``terraform.tfvars`` file, specifying credentials, domain and subdomain::
 
   # Cloudflare configuration (optional)
-  # use_cloudflare = "true"
-  # cloudflare_email = "your-cloudflare-email"
-  # cloudflare_token = "your-cloudflare-token"
-  # cloudflare_domain = "your-domain-name"
-  # cloudflare_subdomain = "your-subdomain-name"
-
-Thus it suffices to just decomment these lines and modify the above placeholders with others Cloudflare settings. Nevertheless, since for entry-level users it can be difficult to reserve a domain name and set it up with Cloudflare, it is possible to use NIP.IO instead.
-
-NIP.IO provides for an easy mechanism to resolve domain names without needing any configuration (e.g., foo.10.0.0.1.nip.io maps to 10.0.0.1, bar.10.0.0.2.nip.io maps to 10.0.0.2, etc.).
+  use_cloudflare = "true"
+  cloudflare_email = "your-cloudflare-email"
+  cloudflare_token = "your-cloudflare-token"
+  cloudflare_domain = "your-domain-name"
+  cloudflare_subdomain = "your-subdomain-name"

advanced_topics/cloudflare-dns.rst

@@ -0,0 +1,9 @@
+Cloudflare: Proxied Traffic
+===========================
+Incoming container traffic can be optionally proxied through the `Cloudflare <https://www.cloudflare.com>`_ servers. When operating in this mode Cloudflare provides HTTPS for container services, and it protects against distributed denial of service, customer data breach and malicious bot abuse.
+
+To enable Cloudflare proxied traffic, it is sufficient to uncomment the following lines in the ``terraform.tfvars`` file, specifying DNS records to be proxied::
+
+  # Cloudflare proxy (optional)
+  cloudflare_proxied = "true"
+  cloudflare_record_texts = ["record1","record2",...] # Warn: wildcards are not supported when using proxied records

advanced_topics/cloudflare-proxied-dns.rst

@@ -1,17 +1,15 @@
 Edge Nodes
 ==========
-Edge nodes are specialized service nodes with an associated public IP address, and they act as reverse proxies, and load balancers, for the services that are exposed to the Internet. This behavior is implemented using `Traefik <https://traefik.io>`_ .
+Edge nodes are specialized service nodes with an associated public IP address, and they run `Traefik <https://traefik.io>`_ acting as reverse proxies, and load balancers, for the services that are exposed to the Internet. In the default settings, we don't deploy any edge node enabling the reverse proxy logic in the master node instead. However, in production settings we recommend to deploy one or more edge nodes to reduce the load in the master.
 
-However, when IP addresses are particularly scarce, it is possible to not deploy any edge node, and to use the master node as reverse proxy instead.
+To deploy edge nodes, it is sufficient to uncomment the following lines in the ``terraform.tfvars`` file, and to set the desired number of edge nodes, along with an available instance flavor::
 
-Edge nodes' settings can be changed within the `terraform.tfvars` created automatically when initializing a :doc:`deploy configuration directory <../getting_started/bootstrap>` by running::
-
-  kn init <your-provider> my_deployment
-
-Precisely, here below can be found an example of the configuration lines to be optionally tweaked::
+  # Master configuration (mandatory in general, above all for single-server setup)
+  master_flavor = "your-master-flavor"
+  master_as_edge = "false"
 
   # Edge configuration
-  # edge_count = "2"
-  # edge_flavor = "your-edge-flavor"
-  
-Thus it suffices to just decomment these lines and modify the above placeholders with the desired number of edge nodes and the pick a flavor among the ones available via the used provider's.
+  edge_count = "2"
+  edge_flavor = "your-edge-flavor"
+
+Please notice that we set ``master_as_edge = "false"`` to disable Traefik in the master node.

advanced_topics/cloudflare-proxied.rst

@@ -1,17 +1,10 @@
 GlusterFS Nodes
 ===============
-Storage nodes are specialized nodes too. They run **only** the shared distributed file system, and they are attached to a block storage volume to provide additional capacity. The shared file system is implemented by `GlusterFS <https://www.gluster.org>`_ and `Heketi <https://github.com/heketi/heketi>`_ .
-The two frameworks enable user applications for provisioning shared volumes seamlessly, trough the standard `Kubernetes API <https://kubernetes.io/>`_ .
+GlusterFS nodes are specialized service nodes. They run only `GlusterFS <https://www.gluster.org>`_ and they are attached to a block storage volume to provide additional capacity. In the default settings, we don't deploy GlusterFS nodes, as it is not required in many use cases. However, GlusterFS can be particularly convenient when a distributed file system is needed for container synchronization.
 
-GlusterFS nodes settings can be changed within the `terraform.tfvars` created automatically when initializing a :doc:`deploy configuration directory <../getting_started/bootstrap>` by running::
-
-  kn init <your-provider> my_deployment
-
-Precisely, here below can be found an example of the configuration lines to be tweaked optionally if need be::
+To deploy GlusterFS nodes, it is sufficient to uncomment the following lines in the ``terraform.tfvars`` file, and to set the desired number of edge nodes, along with an available instance flavor and block storage disk size::
 
  # Gluster configuration
- # glusternode_count = "1"
- # glusternode_flavor = "your-glusternode-flavor"
- # glusternode_extra_disk_size = "200" # Size in GB
-
-As you may notice, these lines are commented by default thus leaving a user freedom of choosing custom solutions for a shared distributed file system if need be (which most of the time is actually the case for distributed microservice-oriented applications).
+ glusternode_count = "1"
+ glusternode_flavor = "your-glusternode-flavor"
+ glusternode_extra_disk_size = "200" # Size in GB

advanced_topics/edge-nodes.rst

@@ -1,20 +1,16 @@
-Single Node Deployments
+Single-Node Deployments
 =======================
-For single-server setups, it is possible to deploy the master node only, and enable it for service scheduling.
+When resources are scarce, or for testing purpose, KubeNow enables single-node deployments. In fact, it is possible to deploy the master node only, which will automatically enabled for service scheduling.
 
-This configuration can be enabled within the `terraform.tfvars` created automatically when initializing a :doc:`deploy configuration directory <../getting_started/bootstrap>` by running::
-
-  kn init <your-provider> my_deployment
-
-Precisely you can achieve this by commenting all the lines for the other instance type (i.e. edge node, gluster node and worker node) but the master one as shown below::
+You can achieve this by commenting all of the lines for the other instance types (i.e. edge node, gluster node and worker node) in the ``terraform.tfvars`` file, leaving the master node only as it is shown below::
 
     # Master configuration (mandatory in general, above all for single-server setup)
     master_flavor = "your-master-flavor"
     master_as_edge = "true"
 
     # Node configuration
-    #node_count = "3"
-    #node_flavor = "your-node-flavor"
+    # node_count = "3"
+    # node_flavor = "your-node-flavor"
 
     # Edge configuration
     # edge_count = "2"
@@ -24,14 +20,3 @@ Precisely you can achieve this by commenting all the lines for the other instanc
     # glusternode_count = "1"
     # glusternode_flavor = "your-glusternode-flavor"
     # glusternode_extra_disk_size = "200" # Size in GB
-
-    # Cloudflare configuration (optional)
-    # use_cloudflare = "true"
-    # cloudflare_email = "your-cloudflare-email"
-    # cloudflare_token = "your-cloudflare-token"
-    # cloudflare_domain = "your-domain-name"
-    # cloudflare_subdomain = "your-subdomain-name"
-
-    # Cloudflare proxy (optional)
-    # cloudflare_proxied = "true"
-    # cloudflare_record_texts = ["record1","record2",...] # Warn: wildcards are not supported when using proxied records

advanced_topics/glusterfs-nodes.rst

@@ -19,17 +19,16 @@ Welcome to KubeNow's documentation! This is a place where we aim to help you to
   troubleshoot/trouble-os
   troubleshoot/trouble-kubernetes
   troubleshoot/trouble-misc
-  
+
 .. toctree::
   :maxdepth: 2
   :caption: Advanced Topics
 
-  advanced_topics/advanced_topics_intro
-  advanced_topics/cloudflare-dns
-  advanced_topics/cloudflare-proxied-dns
   advanced_topics/edge-nodes
   advanced_topics/glusterfs-nodes
   advanced_topics/single-node-deployments
+  advanced_topics/cloudflare-dns
+  advanced_topics/cloudflare-proxied
 
 .. toctree::
   :maxdepth: 2