mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-11-10 18:50:45 +00:00
Apply Divio and update links
This commit is contained in:
Billy Tat committed
1 parent
94dcf8aa71
commit
331b43a83c
432 files changed
+1995
-1961
No files matched your search
@@ -1,75 +0,0 @@
|
||||
---
|
||||
title: Restoring Backups—Docker Installs
|
||||
shortTitle: Docker Installs
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/single-node-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/single-node-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/docker-restores
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/docker-restores/
|
||||
---
|
||||
|
||||
If you encounter a disaster scenario, you can restore your Rancher Server to your most recent backup.
|
||||
|
||||
## Before You Start
|
||||
|
||||
During restore of your backup, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (`<EXAMPLE>`). Here's an example of a command with a placeholder:
|
||||
|
||||
```
|
||||
docker run --volumes-from <RANCHER_CONTAINER_NAME> -v $PWD:/backup \
|
||||
busybox sh -c "rm /var/lib/rancher/* -rf && \
|
||||
tar pzxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>"
|
||||
```
|
||||
|
||||
In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are environment variables for your Rancher deployment.
|
||||
|
||||
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
|
||||
|
||||
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code><RANCHER_CONTAINER_TAG></code> and <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||
|
||||
|
||||
| Placeholder | Example | Description |
|
||||
| -------------------------- | -------------------------- | --------------------------------------------------------- |
|
||||
| `<RANCHER_CONTAINER_TAG>` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | The name of your Rancher container. |
|
||||
| `<RANCHER_VERSION>` | `v2.0.5` | The version number for your Rancher backup. |
|
||||
| `<DATE>` | `9-27-18` | The date that the data container or backup was created. |
|
||||
<br/>
|
||||
|
||||
You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
|
||||
|
||||
## Restoring Backups
|
||||
|
||||
Using a [backup]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/) that you created earlier, restore Rancher to its last known healthy state.
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher Server.
|
||||
|
||||
1. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_NAME>` with the name of your Rancher container.
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
1. Move the backup tarball that you created during completion of [Creating Backups—Docker Installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/) onto your Rancher Server. Change to the directory that you moved it to. Enter `dir` to confirm that it's there.
|
||||
|
||||
If you followed the naming convention we suggested in [Creating Backups—Docker Installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/), it will have a name similar to `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`.
|
||||
|
||||
1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
|
||||
|
||||
>**Warning!** This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
|
||||
|
||||
```
|
||||
docker run --volumes-from <RANCHER_CONTAINER_NAME> -v $PWD:/backup \
|
||||
busybox sh -c "rm /var/lib/rancher/* -rf && \
|
||||
tar pzxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz"
|
||||
```
|
||||
|
||||
**Step Result:** A series of commands should run.
|
||||
|
||||
1. Restart your Rancher Server container, replacing the placeholder. It will restart using your backup data.
|
||||
|
||||
```
|
||||
docker start <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
1. Wait a few moments and then open Rancher in a web browser. Confirm that the restore succeeded and that your data is restored.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: Restoring Rancher Installed on a K3s Kubernetes Cluster
|
||||
shortTitle: K3s Installs
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k3s-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k8s-restore/k3s-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/k3s-restore/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k3s-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/k3s-restore
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/k3s-restore/
|
||||
---
|
||||
|
||||
When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data.
|
||||
|
||||
The database administrator will need to back up the external database, or restore it from a snapshot or dump.
|
||||
|
||||
We recommend configuring the database to take recurring snapshots.
|
||||
|
||||
### Creating Snapshots and Restoring Databases from Snapshots
|
||||
|
||||
For details on taking database snapshots and restoring your database from them, refer to the official database documentation:
|
||||
|
||||
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
|
||||
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
|
||||
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
|
||||
@@ -9,8 +9,8 @@ aliases:
|
||||
---
|
||||
If you lose the data on your Rancher Server, you can restore it if you have backups stored in a safe location.
|
||||
|
||||
- [Restoring backups for Rancher installed with Docker](./docker-restores)
|
||||
- [Restoring backups for Rancher installed on an RKE Kubernetes cluster](./rke-restore)
|
||||
- [Restoring backups for Rancher installed on a K3s Kubernetes cluster](./k3s-restore)
|
||||
- [Restoring backups for Rancher installed with Docker](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
|
||||
- [Restoring backups for Rancher installed on an RKE Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)
|
||||
- [Restoring backups for Rancher installed on a K3s Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-k3s-installed-rancher.md)
|
||||
|
||||
If you are looking to restore your [Rancher launched Kubernetes cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/), please refer to [this section]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/restoring-etcd/).
|
||||
If you are looking to restore your [Rancher launched Kubernetes cluster](../../pages-for-subheaders/launch-kubernetes-with-rancher.md), please refer to [this section](../../how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md).
|
||||
@@ -1,141 +0,0 @@
|
||||
---
|
||||
title: Restoring Backups—Kubernetes installs
|
||||
shortTitle: RKE Installs
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/ha-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/ha-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k8s-restore/rke-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/rke-restore/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/rke-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/rke-restore
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/
|
||||
---
|
||||
|
||||
This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster.
|
||||
This will restore the Kubernetes configuration and the Rancher database and state.
|
||||
|
||||
> **Note:** This document covers clusters set up with RKE >= v0.2.x, for older RKE versions refer to the [RKE Documentation]({{<baseurl>}}/rke/latest/en/etcd-snapshots/restoring-from-backup).
|
||||
|
||||
## Restore Outline
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Preparation](#1-preparation)
|
||||
- [2. Place Snapshot](#2-place-snapshot)
|
||||
- [3. Configure RKE](#3-configure-rke)
|
||||
- [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
It is advised that you run the restore from your local host or a jump box/bastion where your cluster yaml, rke statefile, and kubeconfig are stored. You will need [RKE]({{<baseurl>}}/rke/latest/en/installation/) and [kubectl]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/kubectl/) CLI utilities installed locally.
|
||||
|
||||
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. We recommend that you start with fresh nodes and a clean state. For clarification on the requirements, review the [Installation Requirements](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation/requirements/).
|
||||
|
||||
Alternatively you can re-use the existing nodes after clearing Kubernetes and Rancher configurations. This will destroy the data on these nodes. See [Node Cleanup]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) for the procedure.
|
||||
|
||||
You must restore each of your etcd nodes to the same snapshot. Copy the snapshot you're using from one of your nodes to the others before running the `etcd snapshot-restore` command.
|
||||
|
||||
> **IMPORTANT:** Before starting the restore make sure all the Kubernetes services on the old cluster nodes are stopped. We recommend powering off the nodes to be sure.
|
||||
|
||||
### 2. Place Snapshot
|
||||
|
||||
As of RKE v0.2.0, snapshots could be saved in an S3 compatible backend. To restore your cluster from the snapshot stored in S3 compatible backend, you can skip this step and retrieve the snapshot in [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster). Otherwise, you will need to place the snapshot directly on one of the etcd nodes.
|
||||
|
||||
Pick one of the clean nodes that will have the etcd role assigned and place the zip-compressed snapshot file in `/opt/rke/etcd-snapshots` on that node.
|
||||
|
||||
> **Note:** Because of a current limitation in RKE, the restore process does not work correctly if `/opt/rke/etcd-snapshots` is a NFS share that is mounted on all nodes with the etcd role. The easiest options are to either keep `/opt/rke/etcd-snapshots` as a local folder during the restore process and only mount the NFS share there after it has been completed, or to only mount the NFS share to one node with an etcd role in the beginning.
|
||||
|
||||
### 3. Configure RKE
|
||||
|
||||
Use your original `rancher-cluster.yml` and `rancher-cluster.rkestate` files. If they are not stored in a version control system, it is a good idea to back them up before making any changes.
|
||||
|
||||
```
|
||||
cp rancher-cluster.yml rancher-cluster.yml.bak
|
||||
cp rancher-cluster.rkestate rancher-cluster.rkestate.bak
|
||||
```
|
||||
|
||||
If the replaced or cleaned nodes have been configured with new IP addresses, modify the `rancher-cluster.yml` file to ensure the address and optional internal_address fields reflect the new addresses.
|
||||
|
||||
> **IMPORTANT:** You should not rename the `rancher-cluster.yml` or `rancher-cluster.rkestate` files. It is important that the filenames match each other.
|
||||
|
||||
### 4. Restore the Database and bring up the Cluster
|
||||
|
||||
You will now use the RKE command-line tool with the `rancher-cluster.yml` and the `rancher-cluster.rkestate` configuration files to restore the etcd database and bring up the cluster on the new nodes.
|
||||
|
||||
> **Note:** Ensure your `rancher-cluster.rkestate` is present in the same directory as the `rancher-cluster.yml` file before starting the restore, as this file contains the certificate data for the cluster.
|
||||
|
||||
#### Restoring from a Local Snapshot
|
||||
|
||||
When restoring etcd from a local snapshot, the snapshot is assumed to be located on the target node in the directory `/opt/rke/etcd-snapshots`.
|
||||
|
||||
```
|
||||
rke etcd snapshot-restore --name snapshot-name --config ./rancher-cluster.yml
|
||||
```
|
||||
|
||||
> **Note:** The --name parameter expects the filename of the snapshot without the extension.
|
||||
|
||||
#### Restoring from a Snapshot in S3
|
||||
|
||||
_Available as of RKE v0.2.0_
|
||||
|
||||
When restoring etcd from a snapshot located in an S3 compatible backend, the command needs the S3 information in order to connect to the S3 backend and retrieve the snapshot.
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-restore --config ./rancher-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 \
|
||||
--folder folder-name # Available as of v2.3.0
|
||||
```
|
||||
|
||||
#### Options for `rke etcd snapshot-restore`
|
||||
|
||||
S3 specific options are only available for RKE v0.2.0+.
|
||||
|
||||
| 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 | *|
|
||||
| `--folder` value | Specify s3 folder in the bucket name _Available as of v2.3.0_ | *|
|
||||
| `--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) |
|
||||
|
||||
#### Testing the Cluster
|
||||
|
||||
Once RKE completes it will have created a credentials file in the local directory. Configure `kubectl` to use the `kube_config_rancher-cluster.yml` credentials file and check on the state of the cluster. See [Installing and Configuring kubectl]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/kubectl/#configuration) for details.
|
||||
|
||||
#### Check Kubernetes Pods
|
||||
|
||||
Wait for the pods running in `kube-system`, `ingress-nginx` and the `rancher` pod in `cattle-system` to return to the `Running` state.
|
||||
|
||||
> **Note:** `cattle-cluster-agent` and `cattle-node-agent` pods will be in an `Error` or `CrashLoopBackOff` state until Rancher server is up and the DNS/Load Balancer have been pointed at the new cluster.
|
||||
|
||||
```
|
||||
kubectl get pods --all-namespaces
|
||||
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
cattle-system cattle-cluster-agent-766585f6b-kj88m 0/1 Error 6 4m
|
||||
cattle-system cattle-node-agent-wvhqm 0/1 Error 8 8m
|
||||
cattle-system rancher-78947c8548-jzlsr 0/1 Running 1 4m
|
||||
ingress-nginx default-http-backend-797c5bc547-f5ztd 1/1 Running 1 4m
|
||||
ingress-nginx nginx-ingress-controller-ljvkf 1/1 Running 1 8m
|
||||
kube-system canal-4pf9v 3/3 Running 3 8m
|
||||
kube-system cert-manager-6b47fc5fc-jnrl5 1/1 Running 1 4m
|
||||
kube-system kube-dns-7588d5b5f5-kgskt 3/3 Running 3 4m
|
||||
kube-system kube-dns-autoscaler-5db9bbb766-s698d 1/1 Running 1 4m
|
||||
kube-system metrics-server-97bc649d5-6w7zc 1/1 Running 1 4m
|
||||
kube-system tiller-deploy-56c4cf647b-j4whh 1/1 Running 1 4m
|
||||
```
|
||||
|
||||
#### Finishing Up
|
||||
|
||||
Rancher should now be running and available to manage your Kubernetes clusters.
|
||||
> **IMPORTANT:** Remember to save your updated RKE config (`rancher-cluster.yml`) state file (`rancher-cluster.rkestate`) and `kubectl` credentials (`kube_config_rancher-cluster.yml`) files in a safe place for future maintenance for example in a version control system.
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Rolling back to v2.0.0-v2.1.5"
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/v2.0-v2.1/
|
||||
---
|
||||
|
||||
> Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved here and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
If you are rolling back to versions in either of these scenarios, you must follow some extra instructions in order to get your clusters working.
|
||||
|
||||
- Rolling back from v2.1.6+ to any version between v2.1.0 - v2.1.5 or v2.0.0 - v2.0.10.
|
||||
- Rolling back from v2.0.11+ to any version between v2.0.0 - v2.0.10.
|
||||
|
||||
Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321), special steps are necessary if the user wants to roll back to a previous version of Rancher where this vulnerability exists. The steps are as follows:
|
||||
|
||||
1. Record the `serviceAccountToken` for each cluster. To do this, save the following script on a machine with `kubectl` access to the Rancher management plane and execute it. You will need to run these commands on the machine where the rancher container is running. Ensure JQ is installed before running the command. The commands will vary depending on how you installed Rancher.
|
||||
|
||||
**Rancher Installed with Docker**
|
||||
```
|
||||
docker exec <NAME OF RANCHER CONTAINER> kubectl get clusters -o json | jq '[.items[] | select(any(.status.conditions[]; .type == "ServiceAccountMigrated")) | {name: .metadata.name, token: .status.serviceAccountToken}]' > tokens.json
|
||||
```
|
||||
|
||||
**Rancher Installed on a Kubernetes Cluster**
|
||||
```
|
||||
kubectl get clusters -o json | jq '[.items[] | select(any(.status.conditions[]; .type == "ServiceAccountMigrated")) | {name: .metadata.name, token: .status.serviceAccountToken}]' > tokens.json
|
||||
```
|
||||
|
||||
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
|
||||
|
||||
3. Rollback Rancher following the [normal instructions]({{<baseurl>}}/rancher/v2.0-v2.4/en/upgrades/rollbacks/).
|
||||
|
||||
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
|
||||
|
||||
5. Apply the backed up tokens based on how you installed Rancher.
|
||||
|
||||
**Rancher Installed with Docker**
|
||||
|
||||
Save the following script as `apply_tokens.sh` to the machine where the Rancher docker container is running. Also copy the `tokens.json` file created previously to the same directory as the script.
|
||||
```
|
||||
set -e
|
||||
|
||||
tokens=$(jq .[] -c tokens.json)
|
||||
for token in $tokens; do
|
||||
name=$(echo $token | jq -r .name)
|
||||
value=$(echo $token | jq -r .token)
|
||||
|
||||
docker exec $1 kubectl patch --type=merge clusters $name -p "{\"status\": {\"serviceAccountToken\": \"$value\"}}"
|
||||
done
|
||||
```
|
||||
the script to allow execution (`chmod +x apply_tokens.sh`) and execute the script as follows:
|
||||
```
|
||||
./apply_tokens.sh <DOCKER CONTAINER NAME>
|
||||
```
|
||||
After a few moments the clusters will go from Unavailable back to Available.
|
||||
|
||||
**Rancher Installed on a Kubernetes Cluster**
|
||||
|
||||
Save the following script as `apply_tokens.sh` to a machine with kubectl access to the Rancher management plane. Also copy the `tokens.json` file created previously to the same directory as the script.
|
||||
```
|
||||
set -e
|
||||
|
||||
tokens=$(jq .[] -c tokens.json)
|
||||
for token in $tokens; do
|
||||
name=$(echo $token | jq -r .name)
|
||||
value=$(echo $token | jq -r .token)
|
||||
|
||||
kubectl patch --type=merge clusters $name -p "{\"status\": {\"serviceAccountToken\": \"$value\"}}"
|
||||
done
|
||||
```
|
||||
Set the script to allow execution (`chmod +x apply_tokens.sh`) and execute the script as follows:
|
||||
```
|
||||
./apply_tokens.sh
|
||||
```
|
||||
After a few moments the clusters will go from `Unavailable` back to `Available`.
|
||||
|
||||
6. Continue using Rancher as normal.
|
||||
Reference in new issue
Block a user