Merge pull request #102880 from dlepow/acifresh1

[ACI Freshness] Liveness/readiness probes

Author: GitHubber17

articles/container-instances/container-instances-liveness-probe.md

@@ -2,7 +2,7 @@
 title: Set up liveness probe on container instance
 description: Learn how to configure liveness probes to restart unhealthy containers in Azure Container Instances
 ms.topic: article
-ms.date: 06/08/2018
+ms.date: 01/30/2020
 ---
 # Configure liveness probes
 
@@ -57,41 +57,41 @@ az container create --resource-group myResourceGroup --name livenesstest -f live
 
 ### Start command
 
-The deployment defines a starting command to be run when the container first starts running, defined by the `command` property, which accepts an array of strings. In this example, it will start a bash session and create a file called `healthy` within the `/tmp` directory by passing this command:
+The deployment includes a `command` property defining a starting command that runs when the container first starts running. This property accepts an array of strings. This command simulates the container entering an unhealthy state.
+
+First, it starts a bash session and creates a file called `healthy` within the `/tmp` directory. It then sleeps for 30 seconds before deleting the file, then enters a 10-minute sleep:
 
 ```bash
 /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
 ```
 
- It will then sleep for 30 seconds before deleting the file, then enters a 10-minute sleep.
-
 ### Liveness command
 
-This deployment defines a `livenessProbe` that supports an `exec` liveness command that acts as the liveness check. If this command exits with a non-zero value, the container will be killed and restarted, signaling the `healthy` file could not be found. If this command exits successfully with exit code 0, no action will be taken.
+This deployment defines a `livenessProbe` that supports an `exec` liveness command that acts as the liveness check. If this command exits with a non-zero value, the container is killed and restarted, signaling the `healthy` file could not be found. If this command exits successfully with exit code 0, no action is taken.
 
 The `periodSeconds` property designates the liveness command should execute every 5 seconds.
 
 ## Verify liveness output
 
-Within the first 30 seconds, the `healthy` file created by the start command exists. When the liveness command checks for the `healthy` file's existence, the status code returns a zero, signaling success, so no restarting occurs.
+Within the first 30 seconds, the `healthy` file created by the start command exists. When the liveness command checks for the `healthy` file's existence, the status code returns 0, signaling success, so no restarting occurs.
 
-After 30 seconds, the `cat /tmp/healthy` will begin to fail, causing unhealthy and killing events to occur.
+After 30 seconds, the `cat /tmp/healthy` command begins to fail, causing unhealthy and killing events to occur.
 
 These events can be viewed from the Azure portal or Azure CLI.
 
 ![Portal unhealthy event][portal-unhealthy]
 
-By viewing the events in the Azure portal, events of type `Unhealthy` will be triggered upon the liveness command failing. The subsequent event will be of type `Killing`, signifying a container deletion so a restart can begin. The restart count for the container increments each time this event  occurs.
+By viewing the events in the Azure portal, events of type `Unhealthy` are triggered upon the liveness command failing. The subsequent event is of type `Killing`, signifying a container deletion so a restart can begin. The restart count for the container increments each time this event occurs.
 
-Restarts are completed in-place so resources like public IP addresses and node-specific contents will be preserved.
+Restarts are completed in-place so resources like public IP addresses and node-specific contents are preserved.
 
 ![Portal restart counter][portal-restart]
 
-If the liveness probe continuously fails and triggers too many restarts, your container will enter an exponential back off delay.
+If the liveness probe continuously fails and triggers too many restarts, your container enters an exponential back-off delay.
 
 ## Liveness probes and restart policies
 
-Restart policies supersede the restart behavior triggered by liveness probes. For example, if you set a `restartPolicy = Never` *and* a liveness probe, the container group will not restart because of a failed liveness check. The container group will instead adhere to the container group's restart policy of `Never`.
+Restart policies supersede the restart behavior triggered by liveness probes. For example, if you set a `restartPolicy = Never` *and* a liveness probe, the container group will not restart because of a failed liveness check. The container group instead adheres to the container group's restart policy of `Never`.
 
 ## Next steps
 

articles/container-instances/container-instances-readiness-probe.md

@@ -2,7 +2,7 @@
 title: Set up readiness probe on container instance
 description: Learn how to configure a probe to ensure containers in Azure Container Instances receive requests only when they are ready
 ms.topic: article
-ms.date: 10/17/2019
+ms.date: 01/30/2020
 ---
 
 # Configure readiness probes
@@ -18,7 +18,7 @@ Azure Container Instances also supports [liveness probes](container-instances-li
 
 ## YAML configuration
 
-As an example, create a `readiness-probe.yaml` file with the following snippet that includes a readiness probe. This file defines a container group that consists of a container running a small web app. The app is deployed from the public `mcr.microsoft.com/azuredocs/aci-helloworld` image. This container app is also demonstrated in quickstarts such as [Deploy a container instance in Azure using the Azure CLI](container-instances-quickstart.md).
+As an example, create a `readiness-probe.yaml` file with the following snippet that includes a readiness probe. This file defines a container group that consists of a container running a small web app. The app is deployed from the public `mcr.microsoft.com/azuredocs/aci-helloworld` image. This containerized app is also demonstrated in [Deploy a container instance in Azure using the Azure CLI](container-instances-quickstart.md) and other quickstarts.
 
 ```yaml
 apiVersion: 2018-10-01
@@ -58,7 +58,9 @@ type: Microsoft.ContainerInstance/containerGroups
 
 ### Start command
 
-The YAML file includes a starting command to be run when the container starts, defined by the `command` property that accepts an array of strings. This command simulates a time when the web app runs but the container isn't ready. First, it starts a shell session and runs a `node` command to start the web app. It also starts a command to sleep for 240 seconds, after which it creates a file called `ready` within the `/tmp` directory:
+The deployment includes a `command` property defining a starting command that runs when the container first starts running. This property accepts an array of strings. This command simulates a time when the web app runs but the container isn't ready. 
+
+First, it starts a shell session and runs a `node` command to start the web app. It also starts a command to sleep for 240 seconds, after which it creates a file called `ready` within the `/tmp` directory:
 
 ```console
 node /usr/src/app/index.js & (sleep 240; touch /tmp/ready); wait