Merge pull request #65 from MBishop17/edits

image fixes, air gap fix, install title update
2026-09-10 19:25:48 +00:00 · 2018-05-01 23:41:31 -07:00
parent 62b9a86143 cc003b0db5
commit fd7e545a35
9 changed files with 22 additions and 16 deletions
@@ -19,7 +19,7 @@ Cluster Deployment                            | Layer-4 Load Balancer Support
 ----------------------------------------------|--------------------------------
 Amazon EKS                                    | Supported by AWS cloud provider
 Google GKE                                    | Supported by GCE cloud provider
-Azure AKS                                     | TODO: check with Nathan
+Azure AKS                                     | Supported by Azure cloud provider
 RKE on EC2                                    | Supported by AWS cloud provider
 RKE on DigitalOcean                           | Not Supported
 RKE on vSphere                                | Not Supported
@@ -37,7 +37,7 @@ Cluster Deployment                            | Layer-7 Load Balancer Support
 ----------------------------------------------|--------------------------------
 Amazon EKS                                    | Supported by AWS cloud provider
 Google GKE                                    | Supported by GKE cloud provider
-Azure AKS                                     | TODO: check with Nathan
+Azure AKS                                     | Not Supported
 RKE on EC2                                    | Nginx Ingress Controller
 RKE on DigitalOcean                           | Nginx Ingress Controller
 RKE on vSphere                                | Nginx Ingress Controller
@@ -11,8 +11,12 @@ There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and

 Persistent Volumes are pre-provisioned storage volumes that can be bound to specific pods later. For example, on Amazon EC2, you might want to create a number of EBS volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, its creates Persistent Volume Claims (PVCs) that binds to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that offers at least as much resource as the PVC demands. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.

+![Persistent Volumes]({{< baseurl >}}/img/rancher/persistent-volume.png)
+
 Rancher allows you to create PVs at cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.

 ## Storage Classes

 Storage classes enable you to create PVCs dynamically without having to create PVs first. For example, an EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A storage class is similar to the notion of a “storage driver.” The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.
+
+![Storage Classes]({{< baseurl >}}/img/rancher/storage-classes.png)
@@ -1,7 +1,6 @@
 ---
 title: Air Gap Installation
 weight: 345
-draft: true
 ---

 # Air Gap Installation
@@ -1,7 +1,6 @@
 ---
 title: Installing From a Private Registry
 weight: 350
-draft: true
 ---
 # Installing From a Private Registry

@@ -3,7 +3,7 @@ title: Rancher Server Installation
 weight: 225
 ---

-# Server
+# Rancher Server Installation

 This section contains instructions for setting up Rancher Server in development and production environments. The section also contains supplementary documentation for configuring load balancers and SSL certificates to work with Rancher.

@@ -5,39 +5,43 @@ weight: 325

 # SSL Configuration

-Rancher is secure by default. This means that SSL is required when interacting with Rancher. Using SSL ensures communication from and to Rancher is encrypted, like logging in to the Rancher UI or when using tools to interact with your Kubernetes clusters (like `kubectl`). By default, Rancher will generate a self-signed certificate that will be used when contacting Rancher on port **TCP/443** (HTTPS). All traffic going to port **TCP/80** (HTTP) will be automatically redirected to port **TCP/443** (HTTPS). There are other options which are described below, first you will need to decide where your certificates will be stored.
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL encrypts all Rancher communications: login, cluster interaction, and so on.
+
+By default, Rancher generates a self-signed certificate that's used to encrypt communication over port 443 (HTTPS). Any traffic directed to port 80 (HTTP) is automatically forwarded to 443. If you're content with using this certificate, there's no further action required on your part.
+
+If you want to use your own certificate that's self-signed or signed by a certificate authority, refer to the documentation below.

 ## Before You Start: Choose a Certificate Host

-There are two places where you certificates can be stored and used:
+There are two locations that can host your own certificates. Choose one.

- Inside the `rancher/rancher` container
+- Inside the Rancher container
 - Using an external loadbalancer or proxy

-## Options for inside the `rancher/rancher` container
+## Certificate Host: Inside the Rancher Container

-### Automatically generated default self signed certificate
+<!-- ### Automatically generated default self signed certificate

 By running the `rancher/rancher` container without any additional parameters or configuration, a self-signed certificate will automatically be created on startup.

-<u>Example command:</u>
+**Example**

 ```
 docker run -d -p 80:80 -p 443:443 rancher/rancher:v2.0.0
-```
+``` -->

-### Providing your own self-signed certificates to the container
+### Self-Signed Certificate

-You can use your own certificates and let Rancher use them to provide SSL. You can provide them by mounting the certificate files when running the container. The certificate files should be in **PEM** format. Make sure that your certificate file includes all the intermediate certificates in the chain.
+You can use your own certificates and let Rancher use them to provide SSL. You can provide them by mounting the certificate files when running the container. The certificate files should be in `.pem` format. Make sure that your certificate file includes all the intermediate certificates in the chain.

 | Type                         |        Location in container |
 | ---------------------------- | ---------------------------: |
 | Certificate file             |    /etc/rancher/ssl/cert.pem |
 | Certificate key file         |     /etc/rancher/ssl/key.pem |
 | CA certificates file         | /etc/rancher/ssl/cacerts.pem |
+<br/>

-<u>Example command:</u>
-
+**Example**
 ```
 docker run -d -p 80:80 -p 443:443 \
  -v /etc/your_certificate_directory/fullchain.pem:/etc/rancher/ssl/cert.pem \