diff --git a/content/rancher/v2.x/en/tasks/workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/_index.md index 9e3ba42efda..6dc192918a7 100644 --- a/content/rancher/v2.x/en/tasks/workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/_index.md @@ -3,44 +3,3 @@ title: Workloads weight: 3675 draft: true --- -Coming Soon - -## Deploying Workloads - -To deploy a workload, navigate to the cluster where you want your workload to be deployed. Select the project, and you'll be automatically brought to the workload page. Click "Deploy". - -On the opened dialog, pick: - -1. Workload name -2. Workload type - Scalable Deployment, StatefulSet, etc - that would suit your application needs. You can read more on the workload types [here] ({{< baseurl >}}/rancher/v2.x/en/concepts/workloads/). -3. A namespace where the application is going to be deployed. -4. The image used for the workload deployment -5. The port mapping to enable access to the application inside and outside of the cluster leveraging Kuberntes services. More details on services types can be found [here] ({{< baseurl >}}/rancher/v2.x/en/concepts/workloads/). - -More parameters like node environment variables, scheduling, healthcheck, volumes can be defined along. More advanced options are made available by clicking "Show advanced options". - -## Upgrading Workloads - -To upgrade the workload, some planning has to be done on a creating stage by picking an Upgrade policy. The options are displayed as radio buttons choice under "Scaling/Upgrade Policy" depending on the workload type. For example, for scalable deployment, you can chose whether you want to stop old pods before deploying new ones, and vice versa, as well as the upgrade batch size. - -Then after the workload is created, and you decide to update the application by clicking "Edit" and modifying workload setting like image/ports, Kuberntes will perform the upgrade recreating underlying pods using the strategy defined during the creation. Note that scaling up the deployment, or updating the upgrade/scaling policy won't result in the pods recreation. - -## Rolling Back Workloads - -Sometimes there is a need to rollback to the previous version of the application - either for debugging purposes, or when something goes wrong with the upgraded version. You can do it by picking "Rollback" action for the desired workload. On the opened dialog, there will be a drop down menu with the previous revisions to pick from (up to 10 revision are kept in the history). Once the revision to rollback to is picked, Rancher UI would present you with the differences between the current revision and the revision you are about to rollback to. You can review the difference, and make the final call by hitting "Rollback". - -## Adding a Sidecar - -Coming Soon - -## Adding Ingress - -Coming Soon - -## Adding a DNS Record - -Coming Soon - -## Adding a Persistent Volume Claim - -Coming Soon diff --git a/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md index 20352fcd0fd..f5ddefcbd67 100644 --- a/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md @@ -3,4 +3,37 @@ title: Deploying Workloads weight: draft: true --- -Coming Soon + +Deploy a workload to run an application in one or more containers. + +1. From the **Global** view, open the project that you want to deploy a workload to. + +1. From the **Workloads** view, click **Deploy**. + +1. Enter a **Name** for the workload. + +1. Select a [workload type]({{< baseurl >}}/rancher/v2.x/en/concepts/workloads/). The workload defaults to a scalable deployment, by can change the workload type by clicking **More options.** + +1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy to the project. During deployment, Rancher pulls this image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears on Docker Hub. + +1. Either select an existing [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), or click **Add to a new namespace** and enter a new namespace. + +1. Click **Add Port** to enter a port mapping, which enables access to the application inside and outside of the cluster . For more information, see [Services]({{< baseurl >}}/rancher/v2.x/en/concepts/workloads/#services). + +1. Configure the remaining options: + + - **Environment Variables** + - **Node Scheduling** + - **Health Check** + - **Volumes** + - **Scaling/Upgrade Policy** + +1. Click **Show Advanced Options** and configure: + - **Command** + - **Networking** + - **Labels & Annotations** + - **Security and Host Config** + +1. Click **Launch**. + +**Result:** The workload is deployed to the chosen namespace. You can view the workload's status from the project's **Workloads** view. \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md index eeb138b53c3..53f8a89ae94 100644 --- a/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md @@ -3,4 +3,13 @@ title: Rolling Back Workloads weight: draft: true --- -Coming Soon + +Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned. + +1. From the **Global** view, open the project running the workload you want to rollback. + +1. Find the workload that you want to rollback and select **Vertical Elipsis (... ) > Rollback**. + +1. Choose the revision that you want to roll back to. Click **Rollback**. + +**Result:** Your workload reverts to the previous version that you chose. Wait a few minutes for the action to complete. diff --git a/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md index de393067376..695217bd4d9 100644 --- a/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md @@ -3,4 +3,20 @@ title: Upgrading Workloads weight: draft: true --- -Coming Soon +When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one. + +1. From the **Global** view, open the project running the workload you want to upgrade. + +1. Find the workload that you want to upgrade and select **Vertical Elipsis (... ) > Edit**. + +1. Update the **Docker Image** to the updated version of the application image on Docker Hub. + +1. Update any other options that you want to change. + +1. Review and edit the workload's **Scaling/Upgrade** policy. + + These options control how the upgrade rolls out to containers that are currently running. For example, for scalable deployments, you can chose whether you want to stop old pods before deploying new ones, or vice versa, as well as the upgrade batch size. + +1. Click **Upgrade**. + +**Result:** The workload begins upgrading its containers, per your specifications. Note that scaling up the deployment or updating the upgrade/scaling policy won't result in the pods recreation.