Single and HA install (#93)

This commit is contained in:
Sebastiaan van Steenis
2018-05-08 08:03:01 +02:00
committed by Mark Bishop
parent 4fb432d012
commit 1653048c9e
9 changed files with 471 additions and 158 deletions
@@ -0,0 +1,9 @@
Rancher uses etcd as datastore. When using the Single Node Install, the embedded etcd will be used. The persistent data will be stored in `/var/lib/rancher` inside the container. You can bind mount a host volume to this location to preserve data on the host it is running on.
<u>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 \
-v /host/rancher:/var/lib/rancher \
rancher/rancher
```
@@ -0,0 +1,39 @@
- How do I know if my certificates are in **PEM** format?
You can recognize the **PEM** format by:
**Starting with**: `-----BEGIN CERTIFICATE-----`</br>
**Ending with**: `-----END CERTIFICATE-----`
<u>Example of a PEM certificate</u>
```
----BEGIN CERTIFICATE-----
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
... more lines
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
-----END CERTIFICATE-----
```
- What is the order of certificates in case I want to add my intermediate(s)?
The order of adding certificates is as follows:
```
-----BEGIN CERTIFICATE-----
(Your certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your intermediate certificate)
-----END CERTIFICATE-----
```
- How do I validate my certificate chain?
You can validate the certificate chain by using the `openssl` binary. If the output of the command (See <u>Command to use:</u> below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file should be the same as you supplied to the `rancher/rancher` container. When using a certificate signed by a well known Certificate Authority, you can omit the `-CAfile` parameter.
<u>Command to use:</u>
```
openssl s_client -CAfile ca.pem -connect rancher.yourdomain.com:443
...
Verify return code: 0 (ok)
```
@@ -4,11 +4,12 @@ weight: 350
---
# Installing From a Private Registry
Rancher supports installing from a private registry. In every [release](https://github.com/rancher/rancher/releases), we provide you with the needed images and scripts to mirror those images to your own registry.
Rancher supports installing from a private registry. In every [release](https://github.com/rancher/rancher/releases), we provide you with the needed system-images and scripts to mirror those images to your own registry. The system-images are used when nodes are added to a cluster, or when you enable features like pipelines or logging.
>**Prerequisite:** It is assumed you either have your own private registry or other means of distributing docker images to your machine. If you need help with creating a private registry, please refer to the [Docker documentation for private registries](https://docs.docker.com/registry/).
>**Note:** In Rancher v2.0.0, registries with authentication are not supported for installing from a private registry. This does not apply to workloads.
>**Note:** In Rancher v2.0.0, registries with authentication are not supported for installing from a private registry. The system-images can only be pulled from a registry without authentication enabled. This limitation only applies to system-images. See [Configure Registry for Workloads](#dummy) how to configure private registries for your workloads.
## Release files
@@ -1,40 +1,21 @@
---
title: HA Server Install
title: High Availability Install
weight: 275
---
# High Availability Rancher Server Install
# High Availability Install
This set of instructions creates a new Kubernetes cluster dedicated to running Rancher Server in a high-availabilty (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher Server.
This set of instructions creates a new Kubernetes cluster dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
## Objectives
* Round Robin DNS
* NGINX Ingress controller
We've broken installation of Rancher in an HA configuration into a series of smaller tasks. Here's what you'll do during your install.
![Rancher HA]({{< baseurl >}}/img/rancher/ha/rancher2ha.svg)
1. [Provision Linux Hosts](#provision-linux-hosts)
## Provision Linux Hosts
Begin by provisioning Linux hosts. Make sure your hosts meet Rancher requirements.
Before you install Rancher, confirm you meet the host requirements. Provision 3 new Linux hosts using the requirements below.
2. [Get RKE](#get-rke)
Download the Rancher Kubernetes Engine (RKE) installer from GitHub.
3. [Get YAML Template](#get-yaml-template)
During installation, RKE uses a `.yml` config file containing specifications for your cluster. Download our template from GitHub.
4. [Edit YAML Template](#edit-yaml-template)
Edit the `.yml` config file so that it's pointing toward your Linux hosts.
5. [Run RKE](#run-rke)
Finally, run the RKE installer with it pointing toward your `.yml` config file.
### Provision Linux Hosts
Before you install Rancher, confirm you meet the requirements. Provision three new Linux hosts using the requirements below.
#### Requirements
### Host requirements
{{< requirements_os >}}
@@ -44,180 +25,252 @@ Before you install Rancher, confirm you meet the requirements. Provision three n
{{< requirements_ports >}}
<!--##### Certificate Requirements
## Configure DNS
Before starting this procedure, you should generate or obtain your own certificate.
The certificate can either be:
- Self-signed
- Signed by a certificate authority (CA)
Choose a fully qualified domain name (FQDN) you want to use to access Rancher (this is usually something like `rancher.yourdomain.com`).<br/><br/>You need to create a DNS A record, pointing to the IP addresses of your [Linux hosts](#provision-linux-hosts). If the DNS A record is created, you can validate if it's setup correctly by running `nslookup rancher.yourdomain.com`. It should return the 3 IP addresses of your [Linux hosts](#provision-linux-hosts) like in the example below.
>**Note:**
>-If you use a self-signed certificate, all certificates and keys must be signed by the same CA.<br/>
>-Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.-->
> Because it is round robin DNS, the order of the returned IPs can be different.
```
$ nslookup rancher.yourdomain.com
Server: your_nameserver_ip
Address: your_nameserver_ip#53
Non-authoritative answer:
Name: rancher.yourdomain.com
Address: ip_of_node1
Name: rancher.yourdomain.com
Address: ip_of_node2
Name: rancher.yourdomain.com
Address: ip_of_node3
```
### Get RKE
## Download RKE
Rancher Kubernetes Engine (RKE) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can download RKE from GitHub.
Rancher Kubernetes Engine (RKE) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will be using RKE to setup our cluster and run Rancher.
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases) page. Download the latest RKE installer.
From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run the following command:
* **MacOS**: `rke_darwin-amd64`
* **Linux**: `rke_linux-amd64`
```
$ chmod +x rke
```
Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run the following command:
>**Note:** Adjust the command for the version of RKE that you downloaded (e.g., `rke_darwin-amd64`)
``` bash
# MacOS
$ chmod +x rke_darwin-amd64
# Linux
$ chmod +x rke_linux-amd64
```
3. Confirm that RKE is now executable by running the following command:
Confirm that RKE is now executable by running the following command:
```
$ ./rke -version
```
```
# MacOS
$ ./rke_darwin-amd64 -version
# Linux
$ ./rke_linux-amd64 -version
```
**Result:** You receive output similar to what follows:
```
rke version v<N.N.N>
```
### Get YAML Template
## Download Config Template based on SSL certificate
During installation, RKE uses a `.yml` config file to install and configure your Kubernetes cluster. Download the `3-node-certificate.yml` config file linked below to get you started.
RKE uses a `.yml` config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
[Download 3-node-certificate.yml](https://github.com/rancher/rancher/blob/master/rke-templates/3-node-certificate.yml)
- [Template for using Self Signed Certificate (3-node-certificate.yml)](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate.yml)
- [Template for using Certificate Signed By A Recognized Certificate Authority (3-node-certificate-recognizedca.yml)](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate.yml)
### Edit YAML Template
## Configure nodes section
Once you have the `.yml` config file template, edit the nodes section to point toward your Linux hosts.
1. Open `3-node-certificate.yml`, which you just downloaded.
Open `3-node-certificate.yml` or `3-node-certificate-recognizedca.yml` in your favorite text editor.
2. Update the `nodes` section with your [Linux hosts](#provision-linux-hosts).
Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts)
For each node in your cluster, update the following placeholders:
For each node in your cluster, update the following placeholders:
- `<IP>`: The IP address or hostname of the node.
- `<USER>`: The node root user (usually `root`).
- `<PEM_FILE>`: The path of the `.pem` file used to authenticate.
- `<IP>`: The IP address or hostname of the node.
- `<USER>`: The username to use to setup a SSH connection to the node. If the user is not the `root` user, make sure the user has access to the Docker socket. This can be tested by logging in on the node as the configured user and run `docker ps`.
- `<SSHKEY_FILE>`: The path of the SSH private key file used to authenticate to the node.
**Example YAML**
**Example nodes section YAML**
nodes:
- address: <IP> # IP to access nodes
user: <USER> # root user (usually 'root')
role: [controlplane,etcd,worker] # K8s roles for node
ssh_key_path: <PEM_FILE> # path to PEM file
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
```
nodes:
- address: 1.1.1.1
user: root
role: [controlplane,etcd,worker]
ssh_key_path: ~/.ssh/id_rsa
- address: 2.2.2.2
user: root
role: [controlplane,etcd,worker]
ssh_key_path: ~/.ssh/id_rsa
- address: 3.3.3.3
user: root
role: [controlplane,etcd,worker]
ssh_key_path: ~/.ssh/id_rsa
```
3. Scroll to `kind: Ingress`. Replace the two `<FQDN>` placeholders with the FQDN mapped to each of your nodes. On your DNS Server, each node should be added to the DNS entry for the FQDN.
## Configure certificates
**Example YAML**
Certificates can be configured by using base64 encoded strings in the config file. The base64 encoded string can be generated using the following command:
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 80
tls:
- secretName: cattle-keys-ingress
hosts:
- <FQDN> # FQDN to access cattle server
- **MacOS**: `cat FILENAME| base64`
- **Linux**: `cat FILENAME | base64 -w0`
- **Windows**: `certutil -encode FILENAME FILENAME.base64`
4. Scroll to the codeblock that follows.
### Self Signed Certificate
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-server
namespace: cattle-system
type: Opaque
data:
cert.pem: <BASE64_CRT> # ssl cert for cattle server.
key.pem: <BASE64_KEY> # ssl key for cattle server.
cacerts.pem: <BASE64_CA> # CA cert used to sign cattle server cert and key
```
>**Note:**
> If you are using Certificate Signed By A Recognized Certificate Authority, [click here](#certificate-signed-by-a-recognized-certificate-authority) to proceed.
Replace each placeholder with the applicable certificate `.pem`.
If you are using a Self Signed Certificate, you will need to generate base64 encoded strings for each of your files (Certificate file, Certificate Key file, and CA certificate file).
- `<BASE64_CRT>`
- `<BASE64_KEY>`
- `<BASE64_CA>`
In the `kind: Secret` with `name: cattle-keys-ingress`:
>**Reminder:** Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.
* Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
* Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
5. Scroll to the codeblock that follows.
See the example below:
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-ingress
namespace: cattle-system
type: Opaque
data:
tls.crt: <BASE64_CRT> # ssl cert for ingress. If self-signed, must be signed by same CA as cattle server
tls.key: <BASE64_KEY> # ssl key for ingress. If self-signed, must be signed by same CA as cattle server
```
```
---
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-ingress
namespace: cattle-system
type: Opaque
data:
tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
```
Replace each placeholder with the applicable `.pem`.
In the `kind: Secret` with `name: cattle-keys-server`:
- `<BASE64_CRT>`
- `<BASE64_KEY>`
* Replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
See the example below:
```
---
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-server
namespace: cattle-system
type: Opaque
data:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
```
### Certificate Signed By A Recognized Certificate Authority
If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file.
In the `kind: Secret` with `name: cattle-keys-ingress`:
* Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
* Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
See the example below:
```
---
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-ingress
namespace: cattle-system
type: Opaque
data:
tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
```
>**Reminder:** Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.
## Configure FQDN
6. Save the `.yml` file and close it.
There are 2 references to `<FQDN>` in the config file. Both need to be replaced with the FQDN chosen in [Configure DNS](#configure-dns).
### Run RKE
In the `kind: Ingress` with `name: cattle-ingress-http`:
Enter the command to run RKE while pointing to `3-node-certificate.yml`. RKE installs Kubernetes and Rancher using your parameters.
* Replace `<FQDN>` with the FQDN chosen in [Configure DNS](#configure-dns).
1. From your workstation, make sure `3-node-certificate.yml` and RKE are in the same directory.
See the example below:
2. Open a Terminal instance. Change to the directory that contains `3-node-certificate.yml` and RKE.
```
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
spec:
rules:
- host: rancher.yourdomain.com
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 80
tls:
- secretName: cattle-keys-ingress
hosts:
- rancher.yourdomain.com
```
3. Enter the following command.
Save the `.yml` file and close it.
```
rke up --config 3-node-certificate.yml
```
## Run RKE
### What's Next?
All configuration is in place to run RKE. You can do this by running the `rke up` command and using the `--config` parameter to point to your config file.
Log in to Rancher to make sure it deployed successfully. Open a web browser and navigate to the FQDN used earlier in this procedure.
From your workstation, make sure your config file (`3-node-certificate.yml` or `3-node-certificate-recognizedca.yml`) and the downloaded `rke` binary are in the same directory.
Open a Terminal instance. Change to the directory that contains your config file and `rke`.
<!--SSL is required to secure Rancher communications. Before completing one of the procedures below, complete the procedure in its companion note.
* Using `3-node-certificate.yml`:
Complete one of the following procedures to install Rancher in an HA configuration.
```
# MacOS
./rke_darwin-amd64 up --config 3-node-certificate.yml
# Linux
./rke_linux-amd64 up --config 3-node-certificate.yml
```
* Using `3-node-certificate-recognizedca.yml`:
- [SSL Passthrough]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-passthrough/)
```
# MacOS
./rke_darwin-amd64 up --config 3-node-certificate-recognizedca.yml
# Linux
./rke_linux-amd64 up --config 3-node-certificate-recognizedca.yml
```
In this scenario, your High-Availability Rancher Servers handle SSL decryption rather than a Load Balancer.
The output should be similar to the snippet below:
>**Note:**
> Before you begin this procedure, you must complete [SSL Config: In the Rancher Container]({{< baseurl >}}/rancher/v2.x/en/installation/ssl-config/#certificate-host-inside-the-rancher-container).
```
INFO[0000] Building Kubernetes cluster
INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
INFO[0000] [network] Deploying port listener containers
INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
...
INFO[0101] Finished building Kubernetes cluster successfully
```
- [SSL Termination]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-termination/)
## What's Next?
In this scenario, your Load Balancer handles all SSL encryption, and then forwards on the communication within your Kubernetes cluster unencrypted.
Log in to Rancher to make sure it deployed successfully. Open a web browser and navigate to the FQDN chosen in [Configure DNS](#configure-dns).
>**Note:**
> Before you begin this procedure, you must complete [SSL Config: External Load Balancer or Proxy]({{< baseurl >}}/rancher/v2.x/en/installation/ssl-config/#instructions-for-the-loadbalancer-or-proxy).-->
If you are using a [Certificate Signed By A Recognized Certificate Authority](#certificate-signed-by-a-recognized-certificate-authority), you will need to clear the `cacerts` value from the CA (until [GitHub #11388](https://github.com/rancher/rancher/issues/11388) is resolved). This can be done under `Settings` -> `cacerts`, choose `Edit` and remove the contents and click `Save`.
@@ -0,0 +1,126 @@
---
title: Single Node Install with External Loadbalancer
weight: 260
---
# Single Node Install with External Loadbalancer
For development environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then install Rancher on your host using a single Docker container.
>**Note:**
> If you want don't want to use an external loadbalancer, please see [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/single-node-install/).
## Provision Linux Host
Provision a single Linux host to launch your {{< product >}} Server.
### Requirements
{{< requirements_os >}}
{{< requirements_hardware >}}
{{< requirements_software >}}
>**Note:**
>- `rancher/rancher` is hosted on [DockerHub](https://hub.docker.com/r/rancher/rancher/tags/). If you don't have access to DockerHub, or you are installing Rancher without an internet connection, refer to [Installing From a Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-from-private-registry/).<br/><br/>
>- For a list of other Rancher Server tags available, refer to [Rancher Server Tags]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/).
## Configuration
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication which happens when you login or interact with a cluster for example.
You can choose from the following scenarios:
* [Self-Signed Certificate](#self-signed-certificate)
* [Certificate signed by a well known Certificate Authority](#certificate-signed-by-a-recognized-certificate-authority)
### Self signed certificate
When using self signed certificates on the loadbalancer/proxy, you still need to supply the CA certificate to the `rancher/rancher` container. This will be used to validate connections to Rancher.
| Type | Location in container |
| ---------------------------- | ---------------------------: |
| CA certificates file | /etc/rancher/ssl/cacerts.pem |
<u>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 \
-v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
rancher/rancher
```
### Certificate signed by a recognized Certificate Authority
If the certificate you want to use on the loadbalancer/proxy is signed by a recognized Certificate Authority, you will have to remove the default generated CA certificate information in Rancher. This can be done under `Settings` -> `cacerts`, choose `Edit` and remove the contents and click `Save`.
### Instructions for the loadbalancer or proxy
When using a loadbalancer or proxy in front of the `rancher/rancher` container, there is no need for the `rancher/rancher` container to redirect port **TCP/80** (HTTP) to port **TCP/443** (HTTPS). By passing the header `X-Forwarded-Proto:
https` header, this redirect will be disabled.
The loadbalancer or proxy has to be configured to support the following:
* Support **WebSocket** connections
* **SPDY** / **HTTP/2** support
* Passing/setting the following headers
| Header | Value | Description |
| -------------------- | ----------------------------------------- | :----------------------------------------------------------- |
| `Host` | Hostname that is used to reach Rancher | To identify the server requested by the client |
| `X-Forwarded-Proto` | `https` | To identify the protocol that a client used to connect to the loadbalancer or proxy<br />*If this Header is present, `rancher/rancher` will not redirect HTTP to HTTPS* |
| `X-Forwarded-Port` | Port used to reach Rancher | To identify the protocol that client used to connect to the loadbalancer or proxy |
| `X-Forwarded-For` | IP of the client connection | To identify the originating IP address of a client |
#### Example NGINX configuration
This NGINX configuration is tested on NGINX 1.13 (mainline) and 1.14 (stable)
```
upstream rancher {
server rancher-server:80;
}
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}
server {
listen 443 ssl http2;
server_name rancher.yourdomain.com;
ssl_certificate /etc/your_certificate_directory/fullchain.pem;
ssl_certificate_key /etc/your_certificate_directory/privkey.pem;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://rancher;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
# This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
proxy_read_timeout 900s;
}
}
server {
listen 80;
server_name rancher.yourdomain.com;
return 301 https://$server_name$request_uri;
}
```
#### Example HAProxy configuration
#### Example Amazon ELB configuration
## SSL FAQ / Troubleshooting
{{< readfile file="rancher/v2.x/en/data/files/ssl_faq.md" markdown="true" >}}
## Persistent data
{{< readfile file="rancher/v2.x/en/data/files/persistentdata.md" markdown="true" >}}
@@ -3,13 +3,18 @@ title: Single Node Install
weight: 250
description: For development environments, we recommend installing Rancher by deploying a single Docker container.
---
# Single Node Rancher Server Install
For development environments, we recommend installing Rancher by deploying a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then install Rancher on your host using a single Docker container.
# Single Node Install
For development environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then install Rancher on your host using a single Docker container.
>**Note:**
> If you want to use an external loadbalancer, please see [Single Node Install with an External Loadbalancer]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/single-node-install-external-lb/).
## Provision Linux Host
Provision a single Linux host before launching your {{< product >}} Server.
Provision a single Linux host to launch your {{< product >}} Server.
### Requirements
@@ -19,20 +24,89 @@ Provision a single Linux host before launching your {{< product >}} Server.
{{< requirements_software >}}
## Install Rancher
>**Note:**
>- `rancher/rancher` is hosted on [DockerHub](https://hub.docker.com/r/rancher/rancher/tags/). If you don't have access to DockerHub, or you are installing Rancher without an internet connection, refer to [Installing From a Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-from-private-registry/).<br/><br/>
>- For a list of other Rancher Server tags available, refer to [Rancher Server Tags]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/).
Installing Rancher on a Linux host using a single Docker container is simple. Simply connect to your host and run the command below.
## Choose how you want to use SSL
1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection.
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication which happens when you login or interact with a cluster for example.
2. From your shell, enter the following command:
You can choose from the following scenarios:
```
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher: latest
```
* [Automatically generated self signed certificate](#automatically-generated-default-self-signed-certificate)
* [Bring your own Self-Signed Certificate](#bring-your-own-self-signed-certificate)
* [Bring your own Certificate signed by a well known Certificate Authority](#bring-your-own-certificate-signed-by-a-recognized-certificate-authority)
* [Using automatically requested Let's Encrypt certificates](#using-automatically-requested-let-s-encrypt-certificates)
>**Note:**
>- `rancher/rancher` is hosted on [DockerHub](https://hub.docker.com/r/rancher/rancher/tags/). If you don't have access to DockerHub, or you are installing Rancher without an internet connection, refer to [Installing From a Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-from-private-registry/).<br/><br/>
>- For a list of other Rancher Server tags available, refer to [Rancher Server Tags]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/).
### Automatically generated default self signed certificate
**Result:** Rancher is installed.
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.
By running the `rancher/rancher` container without any additional parameters or configuration, a self-signed certificate will automatically be created on startup.
<u>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 rancher/rancher
```
### Bring your own Self-Signed Certificate
You can use your own certificate 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](#ssl-faq-troubleshooting). Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. [example](#ssl-faq-troubleshooting)
| 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>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 \
-v /etc/your_certificate_directory/fullchain.pem:/etc/rancher/ssl/cert.pem \
-v /etc/your_certificate_directory/privkey.pem:/etc/rancher/ssl/key.pem \
-v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
rancher/rancher
```
### Bring your own Certificate signed by a recognized Certificate Authority
If the certificate you want to use are signed by a recognized Certificate Authority, you only have to provide the certificate file and the certificate key file to the container. In this case, mounting an additional CA certificate file is not needed as it is signed by a recognized Certificate Authority.
| Type | Location in container |
| ---------------------------- | ---------------------------: |
| Certificate file | /etc/rancher/ssl/cert.pem |
| Certificate key file | /etc/rancher/ssl/key.pem |
<u>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 \
-v /etc/your_certificate_directory/fullchain.pem:/etc/rancher/ssl/cert.pem \
-v /etc/your_certificate_directory/privkey.pem:/etc/rancher/ssl/key.pem \
rancher/rancher
```
### Using automatically requested Let's Encrypt certificates
Rancher supports requesting Let's Encrypt certificates out-of-the-box. This is done using the **http-01 challenge**, this means that the hostname you want to use for accessing Rancher (for example, `rancher.mydomain.com`) will have to point to the IP of the machine it is running on. This can be done by creating an A record in DNS.
As the Let's Encrypt challenge can come from any source IP address, port **TCP/80** needs to be open for every source IP address. You enable the Let's Encrypt functionality by passing the parameter `--acme-domain rancher.mydomain.com` when running the `rancher/rancher` container.
<u>Command to use:</u>
```
docker run -d -p 80:80 -p 443:443 rancher/rancher --acme-domain rancher.mydomain.com
```
*Note: Let's Encrypt provides rate limits for requesting new certificates, keep this in mind when creating and destroying the container multiple times. Read more on this in the [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).*
## SSL FAQ / Troubleshooting
{{< readfile file="rancher/v2.x/en/data/files/ssl_faq.md" markdown="true" >}}
## Persisent data
{{< readfile file="rancher/v2.x/en/data/files/persistentdata.md" markdown="true" >}}
@@ -1,6 +1,7 @@
---
title: SSL Configuration
weight: 325
draft: true
---
# SSL Configuration
+8
View File
@@ -0,0 +1,8 @@
{{$file := .Get "file"}}
{{- if eq (.Get "markdown") "true" -}}
{{- $file | readFile | markdownify -}}
{{- else if (.Get "highlight") -}}
{{- highlight ($file | readFile) (.Get "highlight") "" -}}
{{- else -}}
{{ $file | readFile | safeHTML }}
{{- end -}}
File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 20 KiB