How to: Task - Deployment
Some bootcamp students have been messing with the `webapp` Deployment for the test environment's webpage in the `default` Namespace, leaving it broken. Please rollback the Deployment to the last fully functional version. Once on the fully functional version, update the Deployment to have a total of 10 Pods, and ensure that the total number of old and new Pods, during a rolling update, do not exceed 13 or go below 7.

Update the Deployment to `nginx:1.22-alpine` to confirm the Pod count stays within these thresholds. Then rollback the Deployment to the fully functional version. Before you leave, set the Replicas to 4, and just to be safe, Annotate all the Pods with `description="Bootcamp Test Env - Please Do Not Change Image!"`.

- Command to setup environment:
  ```sh
  printf '\nlab: environment setup in progress...\n'; echo '{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"labels":{"appid":"webapp"},"name":"webapp"},"spec":{"replicas":2,"revisionHistoryLimit":15,"selector":{"matchLabels":{"appid":"webapp"}},"template":{"metadata":{"labels":{"appid":"webapp"}},"spec":{"volumes":[{"name":"varlog","emptyDir":{}}],"containers":[{"image":"nginx:1.12-alpine","name":"nginx","volumeMounts":[{"name":"varlog","mountPath":"/var/logs"}]}]}}}}' > k8s-task-6.yml; kubectl apply -f k8s-task-6.yml >/dev/null; cp k8s-task-6.yml k8s-task-6-bak.yml; sed -i -e 's/nginx:1.12-alpine/nginx:1.13alpine/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/nginx:1.12-alpine/nginx:1.13alpine/g' k8s-task-6.yml 2>/dev/null; kubectl apply -f k8s-task-6.yml >/dev/null; sleep 1; sed -i -e 's/nginx:1.13alpine/nginx:1.14-alpine/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/nginx:1.13alpine/nginx:1.14-alpine/g' k8s-task-6.yml 2>/dev/null; kubectl apply -f k8s-task-6.yml >/dev/null; sleep 4; sed -i -e 's/nginx:1.14-alpine/nginx:1.15-alpine/g' k8s-task-6.yml 2>/dev/null; sed -i -e 's/\/var\/logs/\/usr\/share\/nginx\/html/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/nginx:1.14-alpine/nginx:1.15-alpine/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/\/var\/logs/\/usr\/share\/nginx\/html/g' k8s-task-6.yml 2>/dev/null; kubectl apply -f k8s-task-6.yml >/dev/null; sleep 2; sed -i -e 's/nginx:1.15-alpine/ngnx:1.16-alpine/g' k8s-task-6.yml 2>/dev/null; sed -i -e 's/\/var\/logs/\/usr\/share\/nginx\/html/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/nginx:1.15-alpine/ngnx:1.16-alpine/g' k8s-task-6.yml 2>/dev/null; sed -i '' 's/\/var\/logs/\/usr\/share\/nginx\/html/g' k8s-task-6.yml 2>/dev/null; kubectl apply -f k8s-task-6.yml >/dev/null; sleep 4; kubectl apply -f k8s-task-6-bak.yml >/dev/null; sleep 4; kubectl rollout undo deploy webapp --to-revision=5 >/dev/null; kubectl delete $(kubectl get rs --sort-by=".spec.replicas" -oname | tail -n1) >/dev/null; rm k8s-task-6.yml k8s-task-6-bak.yml; echo 'lab: environment setup complete!'
  ```
- Command to destroy environment:
  ```sh
  kubectl delete deploy webapp
  ```
hints
hint 1
ReplicaSets store the Pod configuration used by a Deployment.
hint 2
You can reveal more resource details with `kubectl get -owide`. You might be able to find defective Pods/ReplicaSets quicker this way.
hint 3
You will need to review the Deployment's rollout history, see [lab 7.4 - rolling updates](https://github.com/piouson/ckad-bootcamp#lab-74-rolling-updates)
hint 4
You can view more details of a rollout revision with `kubectl rollout history --revision=$REVISION_NUMBER`
hint 5
Did you test that the Pods are serving an actual webpage? This task isn't complete without testing the webpage - Pods in _Running_ state doesn't mean _fully functional_ version.
hint 6
You can test a Pod with `kubectl port-forward`, by creating a temporary Pod `kubectl run --rm -it --image=nginx:alpine -- sh` and running `curl $POD_IP`, etc.
hint 7
Always remember `kubectl explain` when you encounter new requirements. Use this to figure out what rolling update parameters are required.
hint 8
You can update a Deployment's image quickly with `kubectl set image --help`. You're not required to count Pods during rolling update, all should be fine long as you have `maxSurge` and `maxUnavailable` set correctly.
hint 9
Any change that triggers a rollout (changing anything under `deploy.spec.template`) will create a new ReplicaSet which becomes visible with `kubectl rollout history`. \
  Be sure to perform updates one after the other, without batching, as an exam question dictates, especially if the changes trigger a rollout. For example, apply replicas and update strategy change