/config tier 1 refresh

content/config/containers/live-restore.md

@@ -1,9 +1,9 @@
 ---
-description: How to keep containers running when the daemon isn't available.
+description: Learn how to keep containers running when the daemon isn't available
 keywords: docker, upgrade, daemon, dockerd, live-restore, daemonless container
-title: Keep containers alive during daemon downtime
+title: Live restore
 aliases:
-- /engine/admin/live-restore/
+  - /engine/admin/live-restore/
 ---
 
 By default, when the Docker daemon terminates, it shuts down running containers.
@@ -14,15 +14,15 @@ or upgrades.
 
 > **Note**
 >
-> Live restore is not supported on Windows containers, but it does work for
+> Live restore isn't supported for Windows containers, but it does work for
 > Linux containers running on Docker Desktop for Windows.
 
 ## Enable live restore
 
 There are two ways to enable the live restore setting to keep containers alive
 when the daemon becomes unavailable. **Only do one of the following**.
 
-* Add the configuration to the daemon configuration file. On Linux, this
+- Add the configuration to the daemon configuration file. On Linux, this
   defaults to `/etc/docker/daemon.json`. On Docker Desktop for Mac or Docker
   Desktop for Windows, select the Docker icon from the task bar, then click
   **Settings** -> **Docker Engine**.
@@ -40,12 +40,11 @@ when the daemon becomes unavailable. **Only do one of the following**.
     `systemd`, then use the command `systemctl reload docker`. Otherwise, send a
     `SIGHUP` signal to the `dockerd` process.
 
-* If you prefer, you can start the `dockerd` process manually with the
-  `--live-restore` flag. This approach is not recommended because it does not
+- If you prefer, you can start the `dockerd` process manually with the
+  `--live-restore` flag. This approach isn't recommended because it doesn't
   set up the environment that `systemd` or another process manager would use
   when starting the Docker process. This can cause unexpected behavior.
 
-
 ## Live restore during upgrades
 
 Live restore allows you to keep containers running across Docker daemon updates,
@@ -54,12 +53,12 @@ major (`YY.MM`) daemon upgrades.
 
 If you skip releases during an upgrade, the daemon may not restore its
 connection to the containers. If the daemon can't restore the connection, it
-cannot manage the running containers and you must stop them manually.
+can't manage the running containers and you must stop them manually.
 
 ## Live restore upon restart
 
 The live restore option only works to restore containers if the daemon options,
-such as bridge IP addresses and graph driver, did not change. If any of these
+such as bridge IP addresses and graph driver, didn't change. If any of these
 daemon-level configuration options have changed, the live restore may not work
 and you may need to manually stop the containers.
 
@@ -71,12 +70,12 @@ data. The default buffer size is 64K. If the buffers fill, you must restart
 the Docker daemon to flush them.
 
 On Linux, you can modify the kernel's buffer size by changing
-`/proc/sys/fs/pipe-max-size`. You cannot modify the buffer size on Docker Desktop for
+`/proc/sys/fs/pipe-max-size`. You can't modify the buffer size on Docker Desktop for
 Mac or Docker Desktop for Windows.
 
-## Live restore and swarm mode
+## Live restore and Swarm mode
 
-The live restore option only pertains to standalone containers, and not to swarm
-services. Swarm services are managed by swarm managers. If swarm managers are
-not available, swarm services continue to run on worker nodes but cannot be
-managed until enough swarm managers are available to maintain a quorum.
+The live restore option only pertains to standalone containers, and not to Swarm
+services. Swarm services are managed by Swarm managers. If Swarm managers are
+not available, Swarm services continue to run on worker nodes but can't be
+managed until enough Swarm managers are available to maintain a quorum.

content/config/containers/logging/_index.md

@@ -1,19 +1,19 @@
 ---
-description: How to write to and view a container's logs
+description: Learn how to write to, view, and configure a container's logs
 keywords: docker, logging
 title: View container logs
 aliases:
-- /engine/admin/logging/
-- /engine/admin/logging/view_container_logs/
+  - /engine/admin/logging/
+  - /engine/admin/logging/view_container_logs/
 ---
 
 The `docker logs` command shows information logged by a running container. The
 `docker service logs` command shows information logged by all containers
-participating in a service. The information that is logged and the format of the
+participating in a service. The information that's logged and the format of the
 log depends almost entirely on the container's endpoint command.
 
 By default, `docker logs` or `docker service logs` shows the command's output
-just as it would appear if you ran the command interactively in a terminal. UNIX
+just as it would appear if you ran the command interactively in a terminal. Unix
 and Linux commands typically open three I/O streams when they run, called
 `STDIN`, `STDOUT`, and `STDERR`. `STDIN` is the command's input stream, which
 may include input from the keyboard or input from another command. `STDOUT` is
@@ -50,4 +50,4 @@ its errors to `/proc/self/fd/2` (which is `STDERR`). See the
 ## Next steps
 
 - Configure [logging drivers](configure.md).
-- Write a [Dockerfile](../../../engine/reference/builder.md).
+- Write a [Dockerfile](../../../engine/reference/builder.md).

content/config/containers/logging/awslogs.md

@@ -1,10 +1,10 @@
 ---
-description: Describes how to use the Amazon CloudWatch Logs logging driver.
+description: Learn how to use the Amazon CloudWatch Logs logging driver with Docker Engine
 keywords: AWS, Amazon, CloudWatch, logging, driver
 title: Amazon CloudWatch Logs logging driver
 aliases:
-- /engine/reference/logging/awslogs/
-- /engine/admin/logging/awslogs/
+  - /engine/reference/logging/awslogs/
+  - /engine/admin/logging/awslogs/
 ---
 
 The `awslogs` logging driver sends container logs to
@@ -51,7 +51,7 @@ myservice:
     options:
       awslogs-region: us-east-1
 ```
-          
+
 ## Amazon CloudWatch Logs options
 
 You can add logging options to the `daemon.json` to set Docker-wide defaults,
@@ -108,7 +108,7 @@ specified, the container ID is used as the log stream.
 
 ### awslogs-create-group
 
-Log driver returns an error by default if the log group does not exist. However, you can set the
+Log driver returns an error by default if the log group doesn't exist. However, you can set the
 `awslogs-create-group` to `true` to automatically create the log group as needed.
 The `awslogs-create-group` option defaults to `false`.
 
@@ -128,7 +128,7 @@ $ docker run \
 
 ### awslogs-datetime-format
 
-The `awslogs-datetime-format` option defines a multiline start pattern in [Python
+The `awslogs-datetime-format` option defines a multi-line start pattern in [Python
 `strftime` format](https://strftime.org). A log message consists of a line that
 matches the pattern and any following lines that don't match the pattern. Thus
 the matched line is the delimiter between log messages.
@@ -141,18 +141,17 @@ single entry.
 This option always takes precedence if both `awslogs-datetime-format` and
 `awslogs-multiline-pattern` are configured.
 
-
 > **Note**
 >
-> Multiline logging performs regular expression parsing and matching of all log
+> Multi-line logging performs regular expression parsing and matching of all log
 > messages, which may have a negative impact on logging performance.
 
 Consider the following log stream, where new log messages start with a
 timestamp:
 
 ```console
 [May 01, 2017 19:00:01] A message was logged
-[May 01, 2017 19:00:04] Another multiline message was logged
+[May 01, 2017 19:00:04] Another multi-line message was logged
 Some random message
 with some random words
 [May 01, 2017 19:01:32] Another message was logged
@@ -178,7 +177,7 @@ This parses the logs into the following CloudWatch log events:
 [May 01, 2017 19:00:01] A message was logged
 
 # Second event
-[May 01, 2017 19:00:04] Another multiline message was logged
+[May 01, 2017 19:00:04] Another multi-line message was logged
 Some random message
 with some random words
 
@@ -189,7 +188,7 @@ with some random words
 The following `strftime` codes are supported:
 
 | Code | Meaning                                                          | Example  |
-|:-----|:-----------------------------------------------------------------|:---------|
+| :--- | :--------------------------------------------------------------- | :------- |
 | `%a` | Weekday abbreviated name.                                        | Mon      |
 | `%A` | Weekday full name.                                               | Monday   |
 | `%w` | Weekday as a decimal number where 0 is Sunday and 6 is Saturday. | 0        |
@@ -212,23 +211,24 @@ The following `strftime` codes are supported:
 
 ### awslogs-multiline-pattern
 
-The `awslogs-multiline-pattern` option defines a multiline start pattern using a
+The `awslogs-multiline-pattern` option defines a multi-line start pattern using a
 regular expression. A log message consists of a line that matches the pattern
 and any following lines that don't match the pattern. Thus the matched line is
 the delimiter between log messages.
 
 This option is ignored if `awslogs-datetime-format` is also configured.
 
-> **Note**:
-> Multiline logging performs regular expression parsing and matching of all log
+> **Note**
+>
+> Multi-line logging performs regular expression parsing and matching of all log
 > messages. This may have a negative impact on logging performance.
 
 Consider the following log stream, where each log message should start with the
 pattern `INFO`:
 
 ```console
 INFO A message was logged
-INFO Another multiline message was logged
+INFO Another multi-line message was logged
      Some random message
 INFO Another message was logged
 ```
@@ -251,7 +251,7 @@ This parses the logs into the following CloudWatch log events:
 INFO A message was logged
 
 # Second event
-INFO Another multiline message was logged
+INFO Another multi-line message was logged
      Some random message
 
 # Third event
@@ -273,22 +273,21 @@ If not specified, the container ID is used as the log stream.
 
 > **Note**
 >
-> The CloudWatch log API does not support `:` in the log name. This can cause
+> The CloudWatch log API doesn't support `:` in the log name. This can cause
 > some issues when using the `{{ .ImageName }}` as a tag,
-> since a docker image has a format of `IMAGE:TAG`, such as `alpine:latest`.
+> since a Docker image has a format of `IMAGE:TAG`, such as `alpine:latest`.
 > Template markup can be used to get the proper format. To get the image name
 > and the first 12 characters of the container ID, you can use:
-> 
-> 
+>
 > ```bash
 > --log-opt tag='{{ with split .ImageName ":" }}{{join . "_"}}{{end}}-{{.ID}}'
 > ```
-> 
+>
 > the output is something like: `alpine_latest-bf0072049c76`
 
 ### awslogs-force-flush-interval-seconds
 
-The `awslogs` driver periodically flushs logs to CloudWatch.
+The `awslogs` driver periodically flushes logs to CloudWatch.
 
 The `awslogs-force-flush-interval-seconds` option changes log flush interval seconds.
 
@@ -319,13 +318,10 @@ and `logs:PutLogEvents` actions, as shown in the following example.
   "Version": "2012-10-17",
   "Statement": [
     {
-      "Action": [
-        "logs:CreateLogStream",
-        "logs:PutLogEvents"
-      ],
+      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
       "Effect": "Allow",
       "Resource": "*"
     }
   ]
 }
-```
+```