Merge pull request #1820 from Indevver/audit-23
changing images to responsive images with srcset
Denise
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 69 KiB After Width: | Height: | Size: 69 KiB |
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 77 KiB After Width: | Height: | Size: 77 KiB |
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 134 KiB |
|
Before Width: | Height: | Size: 8.4 KiB After Width: | Height: | Size: 8.4 KiB |
|
Before Width: | Height: | Size: 164 KiB After Width: | Height: | Size: 164 KiB |
|
Before Width: | Height: | Size: 443 KiB After Width: | Height: | Size: 443 KiB |
|
Before Width: | Height: | Size: 831 KiB After Width: | Height: | Size: 831 KiB |
|
Before Width: | Height: | Size: 1.2 MiB After Width: | Height: | Size: 1.2 MiB |
|
Before Width: | Height: | Size: 889 KiB After Width: | Height: | Size: 889 KiB |
|
Before Width: | Height: | Size: 1.3 MiB After Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 177 KiB After Width: | Height: | Size: 177 KiB |
|
Before Width: | Height: | Size: 883 KiB After Width: | Height: | Size: 883 KiB |
|
Before Width: | Height: | Size: 429 KiB After Width: | Height: | Size: 429 KiB |
|
Before Width: | Height: | Size: 1.5 MiB After Width: | Height: | Size: 1.5 MiB |
|
Before Width: | Height: | Size: 452 KiB After Width: | Height: | Size: 452 KiB |
|
Before Width: | Height: | Size: 1.1 MiB After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 1.3 MiB After Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 1.5 MiB After Width: | Height: | Size: 1.5 MiB |
|
Before Width: | Height: | Size: 1.1 MiB After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 613 KiB After Width: | Height: | Size: 613 KiB |
|
Before Width: | Height: | Size: 349 KiB After Width: | Height: | Size: 349 KiB |
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 75 KiB After Width: | Height: | Size: 75 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 223 KiB After Width: | Height: | Size: 223 KiB |
|
Before Width: | Height: | Size: 212 KiB After Width: | Height: | Size: 212 KiB |
|
Before Width: | Height: | Size: 274 KiB After Width: | Height: | Size: 274 KiB |
|
Before Width: | Height: | Size: 260 KiB After Width: | Height: | Size: 260 KiB |
|
Before Width: | Height: | Size: 721 KiB After Width: | Height: | Size: 721 KiB |
|
Before Width: | Height: | Size: 206 KiB After Width: | Height: | Size: 206 KiB |
|
Before Width: | Height: | Size: 879 KiB After Width: | Height: | Size: 879 KiB |
|
Before Width: | Height: | Size: 886 KiB After Width: | Height: | Size: 886 KiB |
|
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 179 KiB |
|
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 114 KiB |
|
Before Width: | Height: | Size: 81 KiB After Width: | Height: | Size: 81 KiB |
|
Before Width: | Height: | Size: 115 KiB After Width: | Height: | Size: 115 KiB |
|
Before Width: | Height: | Size: 80 KiB After Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 115 KiB After Width: | Height: | Size: 115 KiB |
|
Before Width: | Height: | Size: 75 KiB After Width: | Height: | Size: 75 KiB |
|
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
|
Before Width: | Height: | Size: 182 KiB After Width: | Height: | Size: 182 KiB |
|
Before Width: | Height: | Size: 125 KiB After Width: | Height: | Size: 125 KiB |
|
After Width: | Height: | Size: 117 KiB |
|
After Width: | Height: | Size: 168 KiB |
|
Before Width: | Height: | Size: 823 KiB After Width: | Height: | Size: 823 KiB |
|
Before Width: | Height: | Size: 801 KiB After Width: | Height: | Size: 801 KiB |
|
Before Width: | Height: | Size: 1.9 MiB After Width: | Height: | Size: 1.9 MiB |
|
Before Width: | Height: | Size: 1.5 MiB After Width: | Height: | Size: 1.5 MiB |
|
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 113 KiB |
|
Before Width: | Height: | Size: 217 KiB After Width: | Height: | Size: 217 KiB |
|
Before Width: | Height: | Size: 150 KiB After Width: | Height: | Size: 150 KiB |
|
Before Width: | Height: | Size: 164 KiB After Width: | Height: | Size: 164 KiB |
|
Before Width: | Height: | Size: 166 KiB After Width: | Height: | Size: 166 KiB |
|
Before Width: | Height: | Size: 123 KiB After Width: | Height: | Size: 123 KiB |
|
Before Width: | Height: | Size: 192 KiB After Width: | Height: | Size: 192 KiB |
|
Before Width: | Height: | Size: 88 KiB After Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 175 KiB After Width: | Height: | Size: 175 KiB |
@@ -5,6 +5,7 @@ title = "Rancher Labs"
|
||||
theme = "rancher-website-theme"
|
||||
themesDir = "node_modules"
|
||||
pluralizeListTitles = false
|
||||
timeout = 30000
|
||||
|
||||
enableRobotsTXT = true
|
||||
pygmentsCodeFences = true
|
||||
|
||||
@@ -35,7 +35,7 @@ System Docker runs a special container called **Docker**, which is another Docke
|
||||
|
||||
We created this separation not only for the security benefits, but also to make sure that commands like `docker rm -f $(docker ps -qa)` don't delete the entire OS.
|
||||
|
||||
|
||||
{{< img "/img/os/rancheroshowitworks.png" "How it works">}}
|
||||
|
||||
### Running RancherOS
|
||||
|
||||
|
||||
@@ -25,17 +25,17 @@ Let’s walk through how to import and create a RancherOS on EC2 machine using t
|
||||
|
||||
|
||||
1. First login to your AWS console, and go to the EC2 dashboard, click on **Launch Instance**:
|
||||
|
||||
{{< img "/img/os/Rancher_aws1.png" "RancherOS on AWS 1">}}
|
||||
2. Select the **Community AMIs** on the sidebar and search for **RancherOS**. Pick the latest version and click **Select**.
|
||||
|
||||
{{< img "/img/os/Rancher_aws2.png" "RancherOS on AWS 2">}}
|
||||
3. Go through the steps of creating the instance type through the AWS console. If you want to pass in a [cloud-config]({{< baseurl >}}/os/v1.x/en/installation/configuration/#cloud-config) file during boot of RancherOS, you'd pass in the file as **User data** by expanding the **Advanced Details** in **Step 3: Configure Instance Details**. You can pass in the data as text or as a file.
|
||||
|
||||
{{< img "/img/os/Rancher_aws6.png" "RancherOS on AWS 6">}}
|
||||
After going through all the steps, you finally click on **Launch**, and either create a new key pair or choose an existing key pair to be used with the EC2 instance. If you have created a new key pair, download the key pair. If you have chosen an existing key pair, make sure you have the key pair accessible. Click on **Launch Instances**.
|
||||
|
||||
{{< img "/img/os/Rancher_aws3.png" "RancherOS on AWS 3">}}
|
||||
4. Your instance will be launching and you can click on **View Instances** to see it's status.
|
||||
|
||||
{{< img "/img/os/Rancher_aws4.png" "RancherOS on AWS 4">}}
|
||||
Your instance is now running!
|
||||
|
||||
{{< img "/img/os/Rancher_aws5.png" "RancherOS on AWS 5">}}
|
||||
|
||||
## Logging into RancherOS
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ System Docker runs a special container called **Docker**, which is another Docke
|
||||
|
||||
We created this separation not only for the security benefits, but also to make sure that commands like `docker rm -f $(docker ps -qa)` don't delete the entire OS.
|
||||
|
||||
|
||||
{{< img "/img/os/rancheroshowitworks.png" "How it works">}}
|
||||
|
||||
### Running RancherOS
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ $ sudo system-docker run -d --net=host --name busydash husseingalal/busydash
|
||||
```
|
||||
In the command, we used `--net=host` to tell System Docker not to containerize the container's networking, and use the host’s networking instead. After running the container, you can see the monitoring server by accessing `http://<IP_OF_MACHINE>`.
|
||||
|
||||
|
||||
{{< img "/img/os/Rancher_busydash.png" "System Docker Container">}}
|
||||
|
||||
To make the container survive during the reboots, you can create the `/opt/rancher/bin/start.sh` script, and add the Docker start line to launch the Docker at each startup.
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ $ ldapsearch -x -D "acme\jdoe" -w "secret" -p 389 \
|
||||
|
||||
This command performs an LDAP search with the search base set to the domain root (`-b "dc=acme,dc=com"`) and a filter targeting the user account (`sAMAccountNam=jdoe`), returning the attributes for said user:
|
||||
|
||||
|
||||
{{< img "/img/rancher/ldapsearch-user.png" "LDAP User">}}
|
||||
|
||||
Since in this case the user's DN is `CN=John Doe,CN=Users,DC=acme,DC=com` [5], we should configure the **User Search Base** with the parent node DN `CN=Users,DC=acme,DC=com`.
|
||||
|
||||
@@ -179,7 +179,7 @@ $ ldapsearch -x -D "acme\jdoe" -w "secret" -p 389 \
|
||||
|
||||
This command will inform us on the attributes used for group objects:
|
||||
|
||||
|
||||
{{< img "/img/rancher/ldapsearch-group.png" "LDAP Group">}}
|
||||
|
||||
Again, this allows us to determine the correct values to enter in the group schema configuration:
|
||||
|
||||
|
||||
@@ -9,57 +9,57 @@ Before configuring Rancher to support AD FS users, you must add Rancher as a [re
|
||||
|
||||
1. Open the **AD FS Management** console. Select **Add Relying Party Trust...** from the **Actions** menu and click **Start**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-overview.png" style="width:800px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-overview.png" "">}}
|
||||
|
||||
1. Select **Enter data about the relying party manually** as the option for obtaining data about the relying party.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-2.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-2.png" "">}}
|
||||
|
||||
1. Enter your desired **Display name** for your Relying Party Trust. For example, `Rancher`.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-3.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-3.png" "">}}
|
||||
|
||||
1. Select **AD FS profile** as the configuration profile for your relying party trust.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-4.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-4.png" "">}}
|
||||
|
||||
1. Leave the **optional token encryption certificate** empty, as Rancher AD FS will not be using one.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-5.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-5.png" "">}}
|
||||
|
||||
1. Select **Enable support for the SAML 2.0 WebSSO protocol**
|
||||
and enter `https://<rancher-server>/v1-saml/adfs/saml/acs` for the service URL.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-6.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-6.png" "">}}
|
||||
|
||||
1. Add `https://<rancher-server>/v1-saml/adfs/saml/metadata` as the **Relying party trust identifier**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-7.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-7.png" "">}}
|
||||
|
||||
1. This tutorial will not cover multi-factor authentication; please refer to the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs) if you would like to configure multi-factor authentication.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-8.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-8.png" "">}}
|
||||
|
||||
1. From **Choose Issuance Authorization RUles**, you may select either of the options available according to use case. However, for the purposes of this guide, select **Permit all users to access this relying party**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-9.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-9.png" "">}}
|
||||
|
||||
1. After reviewing your settings, select **Next** to add the relying party trust.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-10.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-10.png" "">}}
|
||||
|
||||
|
||||
1. Select **Open the Edit Claim Rules...** and click **Close**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-rpt-11.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-rpt-11.png" "">}}
|
||||
|
||||
1. On the **Issuance Transform Rules** tab, click **Add Rule...**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-edit-cr.png" style="width:450px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-edit-cr.png" "">}}
|
||||
|
||||
1. Select **Send LDAP Attributes as Claims** as the **Claim rule template**.
|
||||
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-tcr-1.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-tcr-1.png" "">}}
|
||||
|
||||
1. Set the **Claim rule name** to your desired name (for example, `Rancher Attributes`) and select **Active Directory** as the **Attribute store**. Create the following mapping to reflect the table below:
|
||||
|
||||
@@ -70,7 +70,7 @@ Before configuring Rancher to support AD FS users, you must add Rancher as a [re
|
||||
| Token-Groups - Qualified by Long Domain Name | Group |
|
||||
| SAM-Account-Name | Name |
|
||||
<br/>
|
||||
<img src="{{< baseurl >}}/img/rancher/adfs/adfs-add-tcr-2.png" style="width:600px;"/>
|
||||
{{< img "/img/rancher/adfs/adfs-add-tcr-2.png" "">}}
|
||||
|
||||
1. Download the `federationmetadata.xml` from your AD server at:
|
||||
```
|
||||
|
||||
@@ -13,7 +13,7 @@ There are two recommended deployment strategies. Each one has its own pros and c
|
||||
|
||||
In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run in an HA (high-availability) configuration, and there would be impact due to latencies.
|
||||
|
||||
|
||||
{{< img "/img/rancher/bpg/hub-and-spoke.png" "Hub and Spoke Deployment">}}
|
||||
|
||||
### Pros
|
||||
|
||||
@@ -30,7 +30,7 @@ In this deployment scenario, there is a single Rancher control plane managing Ku
|
||||
---
|
||||
In the regional deployment model a control plane is deployed in close proximity to the compute nodes.
|
||||
|
||||
|
||||
{{< img "/img/rancher/bpg/regional.png" "Regional Deployment">}}
|
||||
|
||||
### Pros
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub
|
||||
3. Enter a **Name** for the class.
|
||||
4. Under **Provisioner**, select **VMWare vSphere Volume**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/vsphere-storage-class.png" "vsphere-storage-class">}}
|
||||
|
||||
5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.html) for details.
|
||||
5. Click **Save**.
|
||||
@@ -37,7 +37,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub
|
||||
5. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step.
|
||||
6. Enter the required **Capacity** for the volume. Then click **Define**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/workload-add-volume.png" "workload-add-volume">}}
|
||||
|
||||
7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
|
||||
8. Click **Launch** to create the workload.
|
||||
|
||||
@@ -38,21 +38,21 @@ The following steps create a role with the required privileges and then assign i
|
||||
|
||||
3. Create a new role. Give it a name and select the privileges listed in the [permissions table](#annex-vsphere-permissions).
|
||||
|
||||
|
||||
{{< img "/img/rancher/rancherroles1.png" "image">}}
|
||||
|
||||
4. Go to the **Users and Groups** tab.
|
||||
|
||||
5. Create a new user. Fill out the form and then click **OK**. Make sure to note the username and password, as you will need it when configuring node templates in Rancher.
|
||||
|
||||
|
||||
{{< img "/img/rancher/rancheruser.png" "image">}}
|
||||
|
||||
6. Go to the **Global Permissions** tab.
|
||||
|
||||
7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/globalpermissionuser.png" "image">}}
|
||||
|
||||
|
||||
{{< img "/img/rancher/globalpermissionrole.png" "image">}}
|
||||
|
||||
## Creating vSphere Clusters
|
||||
|
||||
@@ -79,13 +79,13 @@ To create a cluster, you need to create at least one vSphere [node template]({{<
|
||||
|
||||
7. Ensure that the [OS ISO URL](#instance-options) contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`).
|
||||
|
||||
|
||||
{{< img "/img/rancher/vsphere-node-template-1.png" "image">}}
|
||||
|
||||
8. **Optional:** Provide a set of [Configuration Parameters](#instance-options) for the VMs.
|
||||
|
||||
9. Under **Scheduling**, enter the name/path of the **Data Center** to create the VMs in, the name of the **VM Network** to attach to, and the name/path of the **Datastore** to store the disks in.
|
||||
|
||||
|
||||
{{< img "/img/rancher/vsphere-node-template-2.png" "image">}}
|
||||
|
||||
10. **Optional:** Assign labels to the VMs that can be used as a base for scheduling rules in the cluster.
|
||||
|
||||
@@ -111,7 +111,7 @@ After you've created a template, you can use it stand up the vSphere cluster its
|
||||
|
||||
6. {{< step_create-cluster_node-pools >}}
|
||||
|
||||
|
||||
{{< img "/img/rancher/vsphere-cluster-create-1.png" "Image">}}
|
||||
|
||||
7. Review your configuration, then click **Create**.
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ In Rancher, Canal is the default CNI network provider combined with Flannel and
|
||||
|
||||
Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/) for more details.
|
||||
|
||||
|
||||
{{< img "/img/rancher/canal-diagram.png" "Canal Diagram">}}
|
||||
|
||||
For more information, see the [Canal GitHub Page](https://github.com/projectcalico/canal).
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get st
|
||||
|
||||
The Target Groups configuration resides in the **Load Balancing** section of the **EC2** service. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/ec2-loadbalancing.png" "EC2 Load Balancing section">}}
|
||||
|
||||
Click **Create target group** to create the first target group, regarding TCP port 443.
|
||||
|
||||
@@ -54,11 +54,11 @@ Success codes | `200-399`
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 443 settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-443.png" "Target group 443">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 443 Advanced settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-443-advanced.png" "Target group 443 Advanced">}}
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -86,11 +86,11 @@ Success codes | `200-399`
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 80 settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-80.png" "Target group 80">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 80 Advanced settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-80-advanced.png" "Target group 80 Advanced">}}
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -100,19 +100,19 @@ Next, add your Linux nodes to both target groups.
|
||||
|
||||
Select the target group named **rancher-tcp-443**, click the tab **Targets** and choose **Edit**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/edit-targetgroup-443.png" "Edit target group 443">}}
|
||||
|
||||
Select the instances (Linux nodes) you want to add, and click **Add to registered**.
|
||||
|
||||
<hr>
|
||||
**Screenshot Add targets to target group TCP port 443**<br/>
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/add-targets-targetgroup-443.png" "Add targets to target group 443">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Added targets to target group TCP port 443**<br/>
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/added-targets-targetgroup-443.png" "Added targets to target group 443">}}
|
||||
|
||||
When the instances are added, click **Save** on the bottom right of the screen.
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get st
|
||||
|
||||
The Target Groups configuration resides in the **Load Balancing** section of the **EC2** service. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/ec2-loadbalancing.png" "EC2 Load Balancing section">}}
|
||||
|
||||
Click **Create target group** to create the first target group, regarding TCP port 443.
|
||||
|
||||
@@ -62,11 +62,11 @@ Success codes | `200-399`
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 443 settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-443.png" "Target group 443">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 443 Advanced settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-443-advanced.png" "Target group 443 Advanced">}}
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -94,11 +94,11 @@ Success codes | `200-399`
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 80 settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-80.png" "Target group 80">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Target group TCP port 80 Advanced settings**<br/>
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/create-targetgroup-80-advanced.png" "Target group 80 Advanced">}}
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -108,19 +108,19 @@ Next, add your Linux nodes to both target groups.
|
||||
|
||||
Select the target group named **rancher-tcp-443**, click the tab **Targets** and choose **Edit**.
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/edit-targetgroup-443.png" "Edit target group 443">}}
|
||||
|
||||
Select the instances (Linux nodes) you want to add, and click **Add to registered**.
|
||||
|
||||
<hr>
|
||||
**Screenshot Add targets to target group TCP port 443**<br/>
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/add-targets-targetgroup-443.png" "Add targets to target group 443">}}
|
||||
|
||||
<hr>
|
||||
**Screenshot Added targets to target group TCP port 443**<br/>
|
||||
|
||||
|
||||
{{< img "/img/rancher/ha/nlb/added-targets-targetgroup-443.png" "Added targets to target group 443">}}
|
||||
|
||||
When the instances are added, click **Save** on the bottom right of the screen.
|
||||
|
||||
|
||||
@@ -52,11 +52,11 @@ In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
1. Open `https://<your-rancher-server>/v3/catalogs/system-library` in your browser.
|
||||
|
||||
|
||||
{{< img "/img/rancher/airgap/system-charts-setting.png" "Open">}}
|
||||
|
||||
1. Click **Edit** on the upper right corner and update the value for **url** to the location of the Git mirror of the `system-charts` repository.
|
||||
|
||||
|
||||
{{< img "/img/rancher/airgap/system-charts-update.png" "Update">}}
|
||||
|
||||
1. Click **Show Request**
|
||||
|
||||
@@ -65,4 +65,4 @@ In the catalog management page in the Rancher UI, follow these steps:
|
||||
**Result:** Rancher is configured to download all the required catalog items from your `system-charts` repository.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -34,7 +34,7 @@ ConfigMaps store general configuration information for an application, such as c
|
||||
>
|
||||
>**Tip:** You can add multiple key value pairs to the ConfigMap by copying and pasting.
|
||||
>
|
||||
> 
|
||||
> {{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}}
|
||||
|
||||
**Result:** Your ConfigMap is added to the namespace. You can view it in the Rancher UI from the **Resources > Config Maps** view.
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ When creating a secret, you can make it available for any deployment within a pr
|
||||
|
||||
>**Tip:** You can add multiple key value pairs to the secret by copying and pasting.
|
||||
>
|
||||
> 
|
||||
> {{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}}
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
|
||||
@@ -61,7 +61,7 @@ For example, for the web-deployment.yml file parsed from v1.6 that we've been us
|
||||
|
||||
<figcaption>Port Mapping: Setting HostPort</figcaption>
|
||||
|
||||
|
||||
{{< img "/img/rancher/set-hostport.gif" "Set HostPort">}}
|
||||
|
||||
## NodePort
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ When provisioning clusters in Rancher using the [vSphere node driver]({{< baseur
|
||||
6. Expand **Cluster Options** and configure as required.
|
||||
7. Set **Cloud Provider** option to `Custom`.
|
||||
|
||||
|
||||
{{< img "/img/rancher/vsphere-node-driver-cloudprovider.png" "vsphere-node-driver-cloudprovider">}}
|
||||
|
||||
8. Click on **Edit as YAML**
|
||||
9. Insert the following top-level structure to the pre-populated cluster YAML. Note that the `name` *must* be set to `vsphere`. Refer to the [configuration reference](#configuration-reference) to learn about the properties of the `vsphereCloudProvider` directive.
|
||||
@@ -200,7 +200,7 @@ The required property can be set while creating or modifying VMs in the vSphere
|
||||
1. For each VM navigate to the tab **VM Options** and click on **Edit Configuration**.
|
||||
2. Add the parameter `disk.EnableUUID` with a value of **TRUE**.
|
||||
|
||||
|
||||
{{< img "/img/rke/vsphere-advanced-parameters.png" "vsphere-advanced-parameters">}}
|
||||
|
||||
#### Using the GOVC CLI tool
|
||||
|
||||
@@ -222,7 +222,7 @@ When creating new clusters in Rancher using vSphere node templates, you can conf
|
||||
|
||||
4. Enter `disk.enableUUID` as key with a value of **TRUE**.
|
||||
|
||||
|
||||
{{< img "/img/rke/vsphere-nodedriver-enable-uuid.png" "vsphere-nodedriver-enable-uuid">}}
|
||||
|
||||
5. Click **Create** or **Save**.
|
||||
|
||||
|
||||
@@ -25,7 +25,257 @@ You can use RKE to [restore your cluster from backup]({{<baseurl>}}/rke/latest/e
|
||||
|
||||
# Example Scenarios
|
||||
|
||||
<<<<<<< Updated upstream
|
||||
These [example scenarios]({{<baseurl>}}/rke/latest/en/etcd-snapshots/example-scenarios) for backup and restore are different based on your version of RKE.
|
||||
=======
|
||||
### IAM Support for Storing Snapshots in S3
|
||||
In addition to API access keys, RKE supports using IAM roles for S3 authentication. The cluster etcd nodes must be assigned an IAM role that has read/write access to the designated backup bucket on S3. Also, the nodes must have network access to the S3 endpoint specified.
|
||||
|
||||
To give an application access to S3, refer to the AWS documentation on [Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)
|
||||
|
||||
### Local One-Time Snapshot Example
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-save --config cluster.yml --name snapshot-name
|
||||
```
|
||||
|
||||
The snapshot is saved in `/opt/rke/etcd-snapshots`
|
||||
|
||||
### One-Time Snapshots uploaded to S3 Example
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-save --config cluster.yml --name snapshot-name \
|
||||
--s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
|
||||
--bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
|
||||
```
|
||||
|
||||
The snapshot is saved in `/opt/rke/etcd-snapshots` as well as uploaded to the S3 backend.
|
||||
|
||||
## Recurring Snapshots
|
||||
|
||||
To schedule automatic recurring etcd snapshots, you can enable the `etcd-snapshot` service with [extra configuration options the etcd service](#options-for-the-etcd-snapshot-service). `etcd-snapshot` runs in a service container alongside the `etcd` container. By default, the `etcd-snapshot` service takes a snapshot for every node that has the `etcd` role and stores them to local disk in `/opt/rke/etcd-snapshots`. If you set up the [options for S3](#options-for-the-etcd-snapshot-service), the snapshot will also be uploaded to the S3 backend.
|
||||
|
||||
Prior to v0.2.0, along with the snapshots, RKE saves a backup of the certificates, i.e. a file named `pki.bundle.tar.gz`, in the same location. The snapshot and pki bundle file are required for the restore process in versions prior to v0.2.0.
|
||||
|
||||
When a cluster is launched with the `etcd-snapshot` service enabled, you can view the `etcd-rolling-snapshots` logs to confirm backups are being created automatically.
|
||||
|
||||
```
|
||||
$ docker logs etcd-rolling-snapshots
|
||||
|
||||
time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
|
||||
time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
|
||||
time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:41:16Z_etcd" runtime=92.880112ms
|
||||
time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
|
||||
time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
|
||||
```
|
||||
|
||||
### Options for the `Etcd-Snapshot` Service
|
||||
|
||||
Depending on your version of RKE, the options used to configure recurring snapshots may be different.
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
|Option|Description| S3 Specific |
|
||||
|---|---| --- |
|
||||
|**interval_hours**| The duration in hours between recurring backups. This supercedes the `creation` option and will override it if both are specified.| |
|
||||
|**retention**| The number of snapshots to retain before rotation. This supercedes the `retention` option and will override it if both are specified.| |
|
||||
|**bucket_name**| S3 bucket name where backups will be stored| * |
|
||||
|**access_key**| S3 access key with permission to access the backup bucket.| * |
|
||||
|**secret_key** |S3 secret key with permission to access the backup bucket.| * |
|
||||
|**region** |S3 region for the backup bucket. This is optional.| * |
|
||||
|**endpoint** |S3 regions endpoint for the backup bucket.| * |
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
s3backupconfig:
|
||||
access_key: S3_ACCESS_KEY
|
||||
secret_key: S3_SECRET_KEY
|
||||
bucket_name: s3-bucket-name
|
||||
region: ""
|
||||
endpoint: s3.amazonaws.com
|
||||
```
|
||||
|
||||
#### Prior to v0.2.0
|
||||
|
||||
|Option|Description|
|
||||
|---|---|
|
||||
|**Snapshot**|By default, the recurring snapshot service is disabled. To enable the service, you need to define it as part of `etcd` and set it to `true`.|
|
||||
|**Creation**|By default, the snapshot service will take snapshots every 5 minutes (`5m0s`). You can change the time between snapshots as part of the `creation` directive for the `etcd` service.|
|
||||
|**Retention**|By default, all snapshots are saved for 24 hours (`24h`) before being deleted and purged. You can change how long to store a snapshot as part of the `retention` directive for the `etcd` service.|
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
snapshot: true
|
||||
creation: 5m0s
|
||||
retention: 24h
|
||||
```
|
||||
|
||||
## Etcd Disaster Recovery
|
||||
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot. RKE also removes the old `etcd` container before creating a new `etcd` cluster using the snapshot that you have chosen.
|
||||
|
||||
>**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, you should back up any important data in your cluster.
|
||||
|
||||
The snapshot used to restore your etcd cluster can either be stored locally in `/opt/rke/etcd-snapshots` or from a S3 compatible backend. The S3 backend option is available as of v0.2.0.
|
||||
|
||||
### Options for `rke etcd snapshot-restore`
|
||||
|
||||
| Option | Description | S3 Specific |
|
||||
| --- | --- | ---|
|
||||
| `--name` value | Specify snapshot name | |
|
||||
| `--config` value | Specify an alternate cluster YAML file (default: "cluster.yml") [$RKE_CONFIG] | |
|
||||
| `--s3` | Enabled backup to s3 |* |
|
||||
| `--s3-endpoint` value | Specify s3 endpoint url (default: "s3.amazonaws.com") | * |
|
||||
| `--access-key` value | Specify s3 accessKey | *|
|
||||
| `--secret-key` value | Specify s3 secretKey | *|
|
||||
| `--bucket-name` value | Specify s3 bucket name | *|
|
||||
| `--region` value | Specify the s3 bucket location (optional) | *|
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
|
||||
|
||||
### Example of Restoring from a Local Snapshot
|
||||
|
||||
When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-restore --config cluster.yml --name mysnapshot
|
||||
```
|
||||
|
||||
### Example of Restoring from a Snapshot in S3
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
> **Note:** Ensure your `cluster.rkestate` is present before starting the restore, as this contains your certificate data for the cluster
|
||||
|
||||
When restoring etcd from a snapshot located in S3, the command needs the S3 information in order to connect to the S3 backend and retrieve the snapshot.
|
||||
|
||||
```shell
|
||||
$ rke etcd snapshot-restore --config cluster.yml --name snapshot-name \
|
||||
--s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
|
||||
--bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
|
||||
```
|
||||
> **Note:** if you were restoring a cluster that had rancher installed the UI should start-up after a few minutes; you don't need to re-run helm.
|
||||
|
||||
### Example Scenario of restoring from a Local Snapshot
|
||||
|
||||
In this example, the Kubernetes cluster was deployed on two AWS nodes.
|
||||
|
||||
| Name | IP | Role |
|
||||
|:-----:|:--------:|:----------------------:|
|
||||
| node1 | 10.0.0.1 | [controlplane, worker] |
|
||||
| node2 | 10.0.0.2 | [etcd] |
|
||||
|
||||
### Back up the `etcd` cluster
|
||||
|
||||
Take a local snapshot of the Kubernetes cluster. As of v0.2.0, you can also upload this snapshot directly to a S3 backend with the [S3 options](#options-for-rke-etcd-snapshot-save).
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
|
||||
```
|
||||
|
||||
{{< img "/img/rke/rke-etcd-backup.png" "etcd snapshot">}}
|
||||
|
||||
|
||||
### Store the Snapshot Externally in S3
|
||||
|
||||
As of v0.2.0, this step is no longer required, as RKE can upload and download snapshots automatically from S3 by adding in [S3 options](#options-for-rke-etcd-snapshot-save) when running the `rke etcd snapshot-save` command.
|
||||
|
||||
After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistence place. One of the options is to save the backup and `pki.bundle.tar.gz` file on a S3 bucket or tape backup.
|
||||
|
||||
> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process.
|
||||
|
||||
```
|
||||
# If you're using an AWS host and have the ability to connect to S3
|
||||
root@node2:~# s3cmd mb s3://rke-etcd-backup
|
||||
root@node2:~# s3cmd /opt/rke/etcd-snapshots/snapshot.db /opt/rke/etcd-snapshots/pki.bundle.tar.gz s3://rke-etcd-backup/
|
||||
```
|
||||
|
||||
### Place the backup on a new node
|
||||
|
||||
To simulate the failure, let's power down `node2`.
|
||||
|
||||
```
|
||||
root@node2:~# poweroff
|
||||
```
|
||||
|
||||
| Name | IP | Role |
|
||||
|:-----:|:--------:|:----------------------:|
|
||||
| node1 | 10.0.0.1 | [controlplane, worker] |
|
||||
| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
|
||||
| node3 | 10.0.0.3 | [etcd] |
|
||||
| | | |
|
||||
|
||||
|
||||
Before restoring etcd and running `rke up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`. As of v0.2.0, you can directly retrieve the snapshot from S3 when running the restore command, so this step is for users who stored the snapshot externally without using the integrated S3 options.
|
||||
|
||||
```
|
||||
# Make a Directory
|
||||
root@node3:~# mkdir -p /opt/rke/etcdbackup
|
||||
# Get the Backup from S3
|
||||
root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcd-snapshots/snapshot.db
|
||||
# Get the pki bundle from S3, only needed prior to v0.2.0
|
||||
root@node3:~# s3cmd get s3://rke-etcd-backup/pki.bundle.tar.gz /opt/rke/etcd-snapshots/pki.bundle.tar.gz
|
||||
```
|
||||
|
||||
### Restore `etcd` on the new node from the backup
|
||||
|
||||
Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
- address: 10.0.0.1
|
||||
hostname_override: node1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- worker
|
||||
# - address: 10.0.0.2
|
||||
# hostname_override: node2
|
||||
# user: ubuntu
|
||||
# role:
|
||||
# - etcd
|
||||
- address: 10.0.0.3
|
||||
hostname_override: node3
|
||||
user: ubuntu
|
||||
role:
|
||||
- etcd
|
||||
```
|
||||
|
||||
After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup. The snapshot and `pki.bundle.tar.gz` file are expected to be saved at `/opt/rke/etcd-snapshots`.
|
||||
As of v0.2.0, if you want to directly retrieve the snapshot from S3, add in the [S3 options](#options-for-rke-etcd-snapshot-restore).
|
||||
|
||||
> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process as the certificates required to restore are preserved within the `cluster.rkestate`
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
|
||||
```
|
||||
|
||||
Finally, we need to restore the operations on the cluster by making the Kubernetes API point to the new `etcd` by running `rke up` again using the new `cluster.yml`.
|
||||
|
||||
```
|
||||
$ rke up --config cluster.yml
|
||||
```
|
||||
|
||||
Confirm that your Kubernetes cluster is functional by checking the pods on your cluster.
|
||||
|
||||
```
|
||||
> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-65899c769f-kcdpr 1/1 Running 0 17s
|
||||
nginx-65899c769f-pc45c 1/1 Running 0 17s
|
||||
nginx-65899c769f-qkhml 1/1 Running 0 17s
|
||||
```
|
||||
>>>>>>> Stashed changes
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
{{ $img := .Get 0 }}
|
||||
{{ $alt := .Get 1 }}
|
||||
{{ with resources.Get $img }}
|
||||
{{ $thumb20 := .Resize "2000x" }}
|
||||
{{ $thumb16 := .Resize "1600x" }}
|
||||
{{ $thumb12 := .Resize "1200x" }}
|
||||
{{ $thumb10 := .Resize "1000x" }}
|
||||
{{ $thumb8 := .Resize "800x" }}
|
||||
{{ $thumb6 := .Resize "600x" }}
|
||||
{{ $thumb4 := .Resize "400x" }}
|
||||
{{ $thumb2 := .Resize "200x" }}
|
||||
<img
|
||||
srcset="{{ $thumb2.Permalink }} 200w, {{ $thumb4.Permalink }} 400w, {{ $thumb6.Permalink }} 600w, {{ $thumb8.Permalink }} 800w, {{ $thumb10.Permalink }} 1000w, {{ $thumb12.Permalink }} 1200w, {{ $thumb16.Permalink }} 1600w, {{ $thumb20.Permalink }} 2000w"
|
||||
src="{{ .Permalink }}"
|
||||
alt ="{{$alt}}"
|
||||
>
|
||||
{{ end }}
|
||||