diff --git a/config/containers/logging/configure.md b/config/containers/logging/configure.md
index 0469b28334..80c24e5cb5 100644
--- a/config/containers/logging/configure.md
+++ b/config/containers/logging/configure.md
@@ -82,13 +82,13 @@ To find the current logging driver for a running container, if the daemon
 is using the `json-file` logging driver, run the following `docker inspect`
 command, substituting the container name or ID for `<CONTAINER>`:
 
-```bash
 {% raw %}
+```bash
 $ docker inspect -f '{{.HostConfig.LogConfig.Type}}' <CONTAINER>
 
 json-file
-{% endraw %}
 ```
+{% endraw %}
 
 ## Configure the delivery mode of log messages from container to log driver
 
diff --git a/config/containers/logging/splunk.md b/config/containers/logging/splunk.md
index 7376f63183..93983f2a7d 100644
--- a/config/containers/logging/splunk.md
+++ b/config/containers/logging/splunk.md
@@ -83,8 +83,8 @@ The path to the root certificate and Common Name is specified using an HTTPS
 scheme. This is used for verification. The `SplunkServerDefaultCert` is
 automatically generated by Splunk certificates.
 
-```bash
 {% raw %}
+```bash
 $ docker run --log-driver=splunk \
            --log-opt splunk-token=176FCEBF-4CF5-4EDF-91BC-703796522D20 \
            --log-opt splunk-url=https://splunkhost:8088 \
@@ -96,8 +96,8 @@ $ docker run --log-driver=splunk \
            --env "TEST=false" \
            --label location=west \
        your/application
-{% endraw %}
 ```
+{% endraw %}
 
 The `splunk-url` for Splunk instances hosted on Splunk Cloud is in a format
 like `https://http-inputs-XXXXXXXX.splunkcloud.com` and does not include a
diff --git a/datacenter/dtr/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md b/datacenter/dtr/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
index f73ace09dc..a874e32bfe 100644
--- a/datacenter/dtr/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
+++ b/datacenter/dtr/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
@@ -49,8 +49,8 @@ DTR replica to check the DTR internal state.
 Use SSH to log into a node that is running a DTR replica, and run the following
 commands:
 
-```bash
 {% raw %}
+```bash
 # REPLICA_ID will be the replica ID for the current node.
 REPLICA_ID=$(docker ps -lf name='^/dtr-rethinkdb-.{12}$' --format '{{.Names}}' | cut -d- -f3)
 # This command will start a RethinkDB client attached to the database
@@ -59,8 +59,8 @@ docker run -it --rm \
   --net dtr-ol \
   -v dtr-ca-$REPLICA_ID:/ca dockerhubenterprise/rethinkcli:v2.2.0 \
   $REPLICA_ID
-{% endraw %}
 ```
+{% endraw %}
 
 This container connects to the local DTR replica and launches a RethinkDB client 
 that can be used to inspect the contents of the DB. RethinkDB 
diff --git a/datacenter/dtr/2.3/guides/admin/backups-and-disaster-recovery.md b/datacenter/dtr/2.3/guides/admin/backups-and-disaster-recovery.md
index 655c5c7812..2d397e440a 100644
--- a/datacenter/dtr/2.3/guides/admin/backups-and-disaster-recovery.md
+++ b/datacenter/dtr/2.3/guides/admin/backups-and-disaster-recovery.md
@@ -66,12 +66,11 @@ you can backup the images by using ssh to log into a node where DTR is running,
 and creating a tar archive of the [dtr-registry volume](../architecture.md):
 
 ```none
-{% raw %}
 sudo tar -cf {{ image_backup_file }} \
-$(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<replica-id>))
-{% endraw %}
+  {% raw %}$(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<replica-id>)){% endraw %}
 ```
 
+
 If you're using a different storage backend, follow the best practices
 recommended for that system.
 
diff --git a/datacenter/dtr/2.3/guides/admin/configure/external-storage/index.md b/datacenter/dtr/2.3/guides/admin/configure/external-storage/index.md
index dd3a2d9d29..e2735bb182 100644
--- a/datacenter/dtr/2.3/guides/admin/configure/external-storage/index.md
+++ b/datacenter/dtr/2.3/guides/admin/configure/external-storage/index.md
@@ -51,16 +51,16 @@ same images.
 To check how much space your images are taking in the local filesystem, you
 can ssh into the node where DTR is deployed and run:
 
-```
 {% raw %}
+```
 # Find the path to the volume
 docker volume inspect dtr-registry-<replica-id>
 
 # Check the disk usage
 sudo du -hs \
 $(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<dtr-replica>))
-{% endraw %}
 ```
+{% endraw %}
 
 ## NFS
 
diff --git a/datacenter/dtr/2.3/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md b/datacenter/dtr/2.3/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
index 6098b6a428..17ea68a2b7 100644
--- a/datacenter/dtr/2.3/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
+++ b/datacenter/dtr/2.3/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
@@ -49,8 +49,8 @@ DTR replica to check the DTR internal state.
 Use SSH to log into a node that is running a DTR replica, and run the following
 commands:
 
-```bash
 {% raw %}
+```bash
 # REPLICA_ID will be the replica ID for the current node.
 REPLICA_ID=$(docker ps -lf name='^/dtr-rethinkdb-.{12}$' --format '{{.Names}}' | cut -d- -f3)
 # This command will start a RethinkDB client attached to the database
@@ -59,8 +59,8 @@ docker run -it --rm \
   --net dtr-ol \
   -v dtr-ca-$REPLICA_ID:/ca dockerhubenterprise/rethinkcli:v2.2.0 \
   $REPLICA_ID
-{% endraw %}
 ```
+{% endraw %}
 
 This container connects to the local DTR replica and launches a RethinkDB client 
 that can be used to inspect the contents of the DB. RethinkDB 
diff --git a/datacenter/dtr/2.4/guides/admin/backups-and-disaster-recovery.md b/datacenter/dtr/2.4/guides/admin/backups-and-disaster-recovery.md
index 6b3b2b2bcf..109f4fbf80 100644
--- a/datacenter/dtr/2.4/guides/admin/backups-and-disaster-recovery.md
+++ b/datacenter/dtr/2.4/guides/admin/backups-and-disaster-recovery.md
@@ -67,7 +67,7 @@ and creating a tar archive of the [dtr-registry volume](../architecture.md):
 
 ```none
 sudo tar -cf {{ image_backup_file }} \
-{% raw %}$(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<replica-id>)){% endraw %}
+  {% raw %}$(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<replica-id>)){% endraw %}
 ```
 
 If you're using a different storage backend, follow the best practices
diff --git a/datacenter/dtr/2.4/guides/admin/configure/external-storage/index.md b/datacenter/dtr/2.4/guides/admin/configure/external-storage/index.md
index dd3a2d9d29..e2735bb182 100644
--- a/datacenter/dtr/2.4/guides/admin/configure/external-storage/index.md
+++ b/datacenter/dtr/2.4/guides/admin/configure/external-storage/index.md
@@ -51,16 +51,16 @@ same images.
 To check how much space your images are taking in the local filesystem, you
 can ssh into the node where DTR is deployed and run:
 
-```
 {% raw %}
+```
 # Find the path to the volume
 docker volume inspect dtr-registry-<replica-id>
 
 # Check the disk usage
 sudo du -hs \
 $(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<dtr-replica>))
-{% endraw %}
 ```
+{% endraw %}
 
 ## NFS
 
diff --git a/datacenter/dtr/2.4/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md b/datacenter/dtr/2.4/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
index ae8fb87fa9..ebafe1c0d0 100644
--- a/datacenter/dtr/2.4/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
+++ b/datacenter/dtr/2.4/guides/admin/monitor-and-troubleshoot/troubleshoot-with-logs.md
@@ -49,13 +49,13 @@ DTR replica to check the DTR internal state.
 Use SSH to log into a node that is running a DTR replica, and run the following
 commands:
 
-```bash
 {% raw %}
+```bash
 # This command will start a RethinkDB client attached to the database
 # on the current node.
 docker exec -it $(docker ps -q --filter name=dtr-rethinkdb) rethinkcli
-{% endraw %}
 ```
+{% endraw %}
 
 RethinkDB stores data in different databases that contain multiple tables. The `rethinkcli`
 tool launches an interactive prompt where you can run RethinkDB
diff --git a/datacenter/ucp/2.0/guides/access-ucp/cli-based-access.md b/datacenter/ucp/2.0/guides/access-ucp/cli-based-access.md
index 13b3092a4f..2d0e382a5d 100644
--- a/datacenter/ucp/2.0/guides/access-ucp/cli-based-access.md
+++ b/datacenter/ucp/2.0/guides/access-ucp/cli-based-access.md
@@ -56,12 +56,12 @@ To verify a client certificate bundle has been loaded and the client is
 successfully communicating with UCP, look for `ucp` in the `Server Version`
 returned by `docker version`.
 
-```bash
 {% raw %}
+```bash
 $ docker version --format '{{.Server.Version}}'
-{% endraw %}
 ucp/2.0.0
 ```
+{% endraw %}
 
 From now on, when you use the Docker CLI client, it includes your client
 certificates as part of the request to the Docker Engine.
diff --git a/datacenter/ucp/2.1/guides/admin/configure/add-sans-to-cluster.md b/datacenter/ucp/2.1/guides/admin/configure/add-sans-to-cluster.md
index 08c3cf195b..bc4927b778 100644
--- a/datacenter/ucp/2.1/guides/admin/configure/add-sans-to-cluster.md
+++ b/datacenter/ucp/2.1/guides/admin/configure/add-sans-to-cluster.md
@@ -37,12 +37,12 @@ that join the cluster.
 
 You can also do this from the CLI by first running:
 
-```bash
 {% raw %}
+```bash
 $ docker node inspect --format '{{ index .Spec.Labels "com.docker.ucp.SANs" }}' <node-id>
 default-cs,127.0.0.1,172.17.0.1
-{% endraw %}
 ```
+{% endraw %}
 
 This gets the current set of SANs for the given manager node. Append your
 desired SAN to this list. For example, `default-cs,127.0.0.1,172.17.0.1,example.com`.
diff --git a/datacenter/ucp/2.1/guides/admin/manage-users/recover-a-user-password.md b/datacenter/ucp/2.1/guides/admin/manage-users/recover-a-user-password.md
index 5bc08284c0..8ba5eb32bf 100644
--- a/datacenter/ucp/2.1/guides/admin/manage-users/recover-a-user-password.md
+++ b/datacenter/ucp/2.1/guides/admin/manage-users/recover-a-user-password.md
@@ -19,10 +19,10 @@ with administrator credentials to change your password.
 If you're the only administrator, use **ssh** to log in to a manager
 node managed by UCP, and run:
 
-```none
 {% raw %}
+```none
 docker exec -it ucp-auth-api enzi \
   "$(docker inspect --format '{{ index .Args 0 }}' ucp-auth-api)" \
   passwd -i
-{% endraw %}  
 ```
+{% endraw %}
diff --git a/datacenter/ucp/2.1/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md b/datacenter/ucp/2.1/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
index d2ea283886..6acffb25b6 100644
--- a/datacenter/ucp/2.1/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
+++ b/datacenter/ucp/2.1/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
@@ -88,8 +88,8 @@ The examples below assume you are logged in with ssh into a UCP manager node.
 
 ### Check the status of the database
 
-```bash
 {% raw %}
+```bash
 # NODE_ADDRESS will be the IP address of this Docker Swarm manager node
 NODE_ADDRESS=$(docker info --format '{{.Swarm.NodeAddr}}')
 # VERSION will be your most recent version of the docker/ucp-auth image
@@ -97,13 +97,13 @@ VERSION=$(docker image ls --format '{{.Tag}}' docker/ucp-auth | head -n 1)
 # This command will output detailed status of all servers and database tables
 # in the RethinkDB cluster.
 docker run --rm -v ucp-auth-store-certs:/tls docker/ucp-auth:${VERSION} --db-addr=${NODE_ADDRESS}:12383 db-status
-{% endraw %}
 ```
+{% endraw %}
 
 ### Manually reconfigure database replication
 
-```bash
 {% raw %}
+```bash
 # NODE_ADDRESS will be the IP address of this Docker Swarm manager node
 NODE_ADDRESS=$(docker info --format '{{.Swarm.NodeAddr}}')
 # NUM_MANAGERS will be the current number of manager nodes in the cluster
@@ -113,8 +113,8 @@ VERSION=$(docker image ls --format '{{.Tag}}' docker/ucp-auth | head -n 1)
 # This reconfigure-db command will repair the RethinkDB cluster to have a
 # number of replicas equal to the number of manager nodes in the cluster.
 docker run --rm -v ucp-auth-store-certs:/tls docker/ucp-auth:${VERSION} --db-addr=${NODE_ADDRESS}:12383 --debug reconfigure-db --num-replicas ${NUM_MANAGERS} --emergency-repair
-{% endraw %}
 ```
+{% endraw %}
 
 ## Where to go next
 
diff --git a/datacenter/ucp/2.1/guides/user/access-ucp/cli-based-access.md b/datacenter/ucp/2.1/guides/user/access-ucp/cli-based-access.md
index d4c42b5392..e644816d40 100644
--- a/datacenter/ucp/2.1/guides/user/access-ucp/cli-based-access.md
+++ b/datacenter/ucp/2.1/guides/user/access-ucp/cli-based-access.md
@@ -56,12 +56,12 @@ To verify a client certificate bundle has been loaded and the client is
 successfully communicating with UCP, look for `ucp` in the `Server Version`
 returned by `docker version`.
 
-```bash
 {% raw %}
+```bash
 $ docker version --format '{{.Server.Version}}'
-{% endraw %}
 ucp/2.1.0
 ```
+{% endraw %}
 
 From now on, when you use the Docker CLI client, it includes your client
 certificates as part of the request to the Docker Engine.
diff --git a/datacenter/ucp/2.2/guides/access-control/recover-a-user-password.md b/datacenter/ucp/2.2/guides/access-control/recover-a-user-password.md
index 987b15221c..c339738710 100644
--- a/datacenter/ucp/2.2/guides/access-control/recover-a-user-password.md
+++ b/datacenter/ucp/2.2/guides/access-control/recover-a-user-password.md
@@ -23,10 +23,10 @@ with administrator credentials to change your password.
 If you're the only administrator, use **ssh** to log in to a manager
 node managed by UCP, and run:
 
-```none
 {% raw %}
+```none
 docker exec -it ucp-auth-api enzi \
   $(docker inspect --format '{{range .Args}}{{if eq "--db-addr=" (printf "%.10s" .)}}{{.}}{{end}}{{end}}' ucp-auth-api) \
   passwd -i
-{% endraw %}  
 ```
+{% endraw %}
diff --git a/datacenter/ucp/2.2/guides/admin/configure/add-sans-to-cluster.md b/datacenter/ucp/2.2/guides/admin/configure/add-sans-to-cluster.md
index d986478ffb..e0b658ae65 100644
--- a/datacenter/ucp/2.2/guides/admin/configure/add-sans-to-cluster.md
+++ b/datacenter/ucp/2.2/guides/admin/configure/add-sans-to-cluster.md
@@ -36,12 +36,12 @@ that join the swarm.
 
 You can also do this from the CLI by first running:
 
-```bash
 {% raw %}
+```bash
 $ docker node inspect --format '{{ index .Spec.Labels "com.docker.ucp.SANs" }}' <node-id>
 default-cs,127.0.0.1,172.17.0.1
-{% endraw %}
 ```
+{% endraw %}
 
 This will get the current set of SANs for the given manager node. Append your
 desired SAN to this list, for example `default-cs,127.0.0.1,172.17.0.1,example.com`,
diff --git a/datacenter/ucp/2.2/guides/admin/configure/external-auth/enable-ldap-config-file.md b/datacenter/ucp/2.2/guides/admin/configure/external-auth/enable-ldap-config-file.md
index 7d21bcac37..08e9e817dd 100644
--- a/datacenter/ucp/2.2/guides/admin/configure/external-auth/enable-ldap-config-file.md
+++ b/datacenter/ucp/2.2/guides/admin/configure/external-auth/enable-ldap-config-file.md
@@ -23,19 +23,19 @@ $ docker container run --rm {{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_v
 1.  Use the following command to extract the name of the currently active
     configuration from the `ucp-agent` service.
 
-    ```bash
     {% raw %}
+    ```bash
     $ CURRENT_CONFIG_NAME=$(docker service inspect --format '{{ range $config := .Spec.TaskTemplate.ContainerSpec.Configs }}{{ $config.ConfigName }}{{ "\n" }}{{ end }}' ucp-agent | grep 'com.docker.ucp.config-')
-    {% endraw %}
     ```
+    {% endraw %}
 
 2.  Get the current configuration and save it to a TOML file.
 
-    ```bash
     {% raw %}
+    ```bash
     $ docker config inspect --format '{{ printf "%s" .Spec.Data }}' $CURRENT_CONFIG_NAME > config.toml
-    {% endraw %}
     ```
+    {% endraw %}
 
 3.  Use the output of the `example-config` command as a guide to edit your
     `config.toml` file. Under the `[auth]` sections, set `backend = "ldap"`
diff --git a/datacenter/ucp/2.2/guides/admin/configure/ucp-configuration-file.md b/datacenter/ucp/2.2/guides/admin/configure/ucp-configuration-file.md
index dacb6e40e6..3bc0bf6b83 100644
--- a/datacenter/ucp/2.2/guides/admin/configure/ucp-configuration-file.md
+++ b/datacenter/ucp/2.2/guides/admin/configure/ucp-configuration-file.md
@@ -33,14 +33,14 @@ number that increases with each version, like `com.docker.ucp.config-1`. The
 Use the `docker config inspect` command to view the current settings and emit
 them to a file.
 
-```bash
 {% raw %}
+```bash
 # CURRENT_CONFIG_NAME will be the name of the currently active UCP configuration
 CURRENT_CONFIG_NAME=$(docker service inspect ucp-agent --format '{{range .Spec.TaskTemplate.ContainerSpec.Configs}}{{if eq "/etc/ucp/ucp.toml" .File.Name}}{{.ConfigName}}{{end}}{{end}}')
 # Collect the current config with `docker config inspect`
 docker config inspect --format '{{ printf "%s" .Spec.Data }}' $CURRENT_CONFIG_NAME > ucp-config.toml
-{% endraw %}
 ```
+{% endraw %}
 
 Edit the file, then use the `docker config create` and `docker service update`
 commands to create and apply the configuration from the file.
diff --git a/datacenter/ucp/2.2/guides/admin/install/architecture-specific-images.md b/datacenter/ucp/2.2/guides/admin/install/architecture-specific-images.md
index 227c66cf18..e23709d053 100644
--- a/datacenter/ucp/2.2/guides/admin/install/architecture-specific-images.md
+++ b/datacenter/ucp/2.2/guides/admin/install/architecture-specific-images.md
@@ -17,9 +17,7 @@ a [UCP support dump](..\..\get-support.md) to use an environment variable
 that indicates the current architecture:
 
 ```bash
-{% raw %}
-[[ $(docker info --format='{{.Architecture}}') == s390x ]] && export _ARCH='-s390x' || export _ARCH=''
-{% endraw %}
+{% raw %}[[ $(docker info --format='{{.Architecture}}') == s390x ]] && export _ARCH='-s390x' || export _ARCH=''{% endraw %}
 
 docker container run --rm \
   --name ucp \
diff --git a/datacenter/ucp/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md b/datacenter/ucp/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
index b7eeba9baf..7cbd05d5e6 100644
--- a/datacenter/ucp/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
+++ b/datacenter/ucp/2.2/guides/admin/monitor-and-troubleshoot/troubleshoot-configurations.md
@@ -91,8 +91,8 @@ The examples below assume you are logged in with ssh into a UCP manager node.
 
 ### Check the status of the database
 
-```bash
 {% raw %}
+```bash
 # NODE_ADDRESS will be the IP address of this Docker Swarm manager node
 NODE_ADDRESS=$(docker info --format '{{.Swarm.NodeAddr}}')
 # VERSION will be your most recent version of the docker/ucp-auth image
@@ -117,13 +117,13 @@ Server Status: [
   }
 ]
 ...
-{% endraw %}
 ```
+{% endraw %}
 
 ### Manually reconfigure database replication
 
-```bash
 {% raw %}
+```bash
 # NODE_ADDRESS will be the IP address of this Docker Swarm manager node
 NODE_ADDRESS=$(docker info --format '{{.Swarm.NodeAddr}}')
 # NUM_MANAGERS will be the current number of manager nodes in the cluster
@@ -140,8 +140,8 @@ time="2017-07-14T20:46:09Z" level=debug msg="Reconfiguring number of replicas to
 time="2017-07-14T20:46:09Z" level=debug msg="(00/16) Emergency Repairing Tables..."
 time="2017-07-14T20:46:09Z" level=debug msg="(01/16) Emergency Repaired Table \"grant_objects\""
 ...
-{% endraw %}
 ```
+{% endraw %}
 
 ## Where to go next
 
diff --git a/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md b/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md
index 67abe1c062..ea5eeae689 100644
--- a/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md
+++ b/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md
@@ -61,9 +61,7 @@ successfully communicating with UCP, look for `ucp` in the `Server Version`
 returned by `docker version`.
 
 ```bash
-{% raw %}
-docker version --format '{{.Server.Version}}'
-{% endraw %}
+{% raw %}docker version --format '{{.Server.Version}}'{% endraw %}
 {{ page.ucp_repo }}/{{ page.ucp_version }}
 ```
 
diff --git a/docker-for-aws/iam-permissions.md b/docker-for-aws/iam-permissions.md
index 29af22b9ac..a3605f1f5a 100644
--- a/docker-for-aws/iam-permissions.md
+++ b/docker-for-aws/iam-permissions.md
@@ -14,8 +14,8 @@ For instructions, see [Link Amazon Web Services to Docker Cloud](/docker-cloud/c
 This feature is called [AWS CloudFormation Service Role](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html?icmpid=docs_cfn_console)
 follow the link for more information.
 
-```none
 {% raw %}
+```none
 {
     "Version": "2012-10-17",
     "Statement": [
@@ -343,5 +343,5 @@ follow the link for more information.
         }
     ]
 }
-{% endraw %}
 ```
+{% endraw %}
diff --git a/docker-for-aws/persistent-data-volumes.md b/docker-for-aws/persistent-data-volumes.md
index 2f43af91fd..817914b80c 100644
--- a/docker-for-aws/persistent-data-volumes.md
+++ b/docker-for-aws/persistent-data-volumes.md
@@ -131,15 +131,15 @@ as well.
 The only option available for EFS is `perfmode`. You can set `perfmode` to
 `maxio` for high IO throughput:
 
-```bash
 {% raw %}
+```bash
 $ docker service create \
   --replicas 5 \
   --name ping3 \
   --mount type=volume,volume-driver=cloudstor:aws,source={{.Service.Name}}-{{.Task.Slot}}-vol5,destination=/mydata,volume-opt=perfmode=maxio \
   alpine ping docker.com
-{% endraw %}
 ```
+{% endraw %}
 
 You can also create `shared` Cloudstor volumes using the
 `docker volume create` CLI:
@@ -164,15 +164,15 @@ EBS volumes typically take a few minutes to be created. Besides
 
 Example usage:
 
-```bash
 {% raw %}
+```bash
 $ docker service create \
   --replicas 5 \
   --name ping3 \
   --mount type=volume,volume-driver=cloudstor:aws,source={{.Service.Name}}-{{.Task.Slot}}-vol,destination=/mydata,volume-opt=backing=relocatable,volume-opt=size=25,volume-opt=ebstype=gp2 \
   alpine ping docker.com
-{% endraw %}
 ```
+{% endraw %}
 
 The above example creates and mounts a distinct Cloudstor volume backed by 25 GB EBS
 volumes of type `gp2` for each task of the `ping3` service. Each task mounts its
@@ -210,15 +210,15 @@ mount a unique EFS-backed volume into each task of a service. This is useful if
 you already have too many EBS volumes or want to reduce the amount of time it
 takes to transfer volume data across availability zones.
 
-```bash
 {% raw %}
+```bash
 $ docker service create \
   --replicas 5 \
   --name ping2 \
   --mount type=volume,volume-driver=cloudstor:aws,source={{.Service.Name}}-{{.Task.Slot}}-vol,destination=/mydata \
   alpine ping docker.com
-{% endraw %}
 ```
+{% endraw %}
 
 Here, each task has mounted its own volume at `/mydata/` and the files under
 that mountpoint are unique to that task.
diff --git a/docker-for-azure/persistent-data-volumes.md b/docker-for-azure/persistent-data-volumes.md
index 1e2a6a5532..62e9c026fa 100644
--- a/docker-for-azure/persistent-data-volumes.md
+++ b/docker-for-azure/persistent-data-volumes.md
@@ -76,15 +76,15 @@ create and mount a unique Cloudstor volume for each task in a swarm service.
 
 It is possible to use the templatized notation to indicate to Docker Swarm that a unique Cloudstor volume be created and mounted for each replica/task of a service. This may be useful if the tasks write to the same file under the same path which may lead to corruption in case of shared storage. Example:
 
-```bash
 {% raw %}
+```bash
 $ docker service create \
   --replicas 5 \
   --name ping2 \
   --mount type=volume,volume-driver=cloudstor:azure,source={{.Service.Name}}-{{.Task.Slot}}-vol,destination=/mydata \
   alpine ping docker.com
-{% endraw %}
 ```
+{% endraw %}
 
 A unique volume is created and mounted for each task participating in the
 `ping2` service. Each task mounts its own volume at `/mydata/` and all files
diff --git a/docker-for-ibm-cloud/binding-services.md b/docker-for-ibm-cloud/binding-services.md
index 4e81c781e6..41c393df4f 100644
--- a/docker-for-ibm-cloud/binding-services.md
+++ b/docker-for-ibm-cloud/binding-services.md
@@ -58,8 +58,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
 
 5. Update your service code to use the secret that you created. For example:
 
-   ```none
    {% raw %}
+   ```none
    ...
    // WatsonSecret holds Watson VR service keys
    type WatsonSecret struct {
@@ -82,8 +82,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
    ...
 		   msgQ.Add("api_key", watsonSecrets.APIKey)
    ...
-   {% endraw %}
    ```
+   {% endraw %}
 
 ### Step 2: Build a Docker image
 1. Log in to the registry that you are using to store the image.
@@ -96,8 +96,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
 
    **Example** snippet for a Dockerfile that uses _mmssearch_ service.
 
-   ```none
    {% raw %}
+   ```none
    FROM golang:latest
    WORKDIR /go/src/mmssearch
    COPY . /go/src/mmssearch
@@ -109,8 +109,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
    COPY --from=0 go/src/mmssearch/main .
    CMD ["./main"]
    LABEL version=demo-3
-   {% endraw %}
    ```
+   {% endraw %}
 
 3. Navigate to the directory of the Dockerfile, and build the image. Don't forget the period in the `docker build` command.
 
@@ -141,8 +141,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
    * For the service `environment` field, use a service environment, such as a workspace ID, from the IBM Cloud service that you made before you began.
    * **Example** snippet for a `docker-service.yaml` that uses _mmssearch_ with a Watson secret.
 
-   ```none
    {% raw %}
+   ```none
    mmssearch:
      image: mmssearch:latest
      build: .
@@ -154,8 +154,8 @@ There are three main steps in binding IBM Cloud services to your Docker EE for I
    secrets:
      watson-secret:
      external: true
-   {% endraw %}
    ```
+   {% endraw %}
 
 2. Connect to your cluster by setting the environment variables from the [client certificate bundle that you downloaded](administering-swarms.md#download-client-certificates).
 
diff --git a/docker-for-ibm-cloud/persistent-data-volumes.md b/docker-for-ibm-cloud/persistent-data-volumes.md
index ff4e9f5895..f42f3d7580 100644
--- a/docker-for-ibm-cloud/persistent-data-volumes.md
+++ b/docker-for-ibm-cloud/persistent-data-volumes.md
@@ -63,8 +63,8 @@ If you want to change the default settings for storage type, IOPS, or capacity,
 
     Example output:
 
-    ```bash
     {% raw %}
+    ```bash
     [
       {
           "Driver": "d4ic-volume:latest",
@@ -89,8 +89,8 @@ If you want to change the default settings for storage type, IOPS, or capacity,
                       }
         }
       ]
-      {% endraw %}
       ```
+      {% endraw %}
 
 > File storage provisioning
 >
@@ -110,11 +110,11 @@ Use an existing IBM Cloud infrastructure file storage volume with Docker EE for
 
 2. Retrieve the cluster ID:
 
-   ```bash
    {% raw %}
+   ```bash
    $ docker info --format={{.Swarm.Cluster.ID}}
-   {% endraw %}
    ```
+   {% endraw %}
 
 3. From your browser, log in to your [IBM Cloud infrastructure account](https://control.softlayer.com/) and access the file storage volume that you want to use.
 
diff --git a/docker-for-windows/troubleshoot.md b/docker-for-windows/troubleshoot.md
index 0eaed9f03e..2572dbc28b 100644
--- a/docker-for-windows/troubleshoot.md
+++ b/docker-for-windows/troubleshoot.md
@@ -450,25 +450,25 @@ You can get the container IP address by using [`docker inspect`](/engine/referen
 the command would look like this, using the name we gave to the container
 (`webserver`) instead of the container ID:
 
-```bash
 {% raw %}
+```bash
 $ docker inspect \
   --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
   webserver
-{% endraw %}
 ```
+{% endraw %}
 
 This gives you the IP address of the container, for example:
 
-```bash
 {% raw %}
+```bash
 $ docker inspect \
   --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
   webserver
 
 172.17.0.2
-{% endraw %}
 ```
+{% endraw %}
 
 Now you can connect to the webserver by using `http://172.17.0.2:80` (or simply
 `http://172.17.0.2`, since port `80` is the default HTTP port.)
diff --git a/engine/swarm/admin_guide.md b/engine/swarm/admin_guide.md
index 18dcf2ca70..2acc40e3d4 100644
--- a/engine/swarm/admin_guide.md
+++ b/engine/swarm/admin_guide.md
@@ -160,21 +160,21 @@ for more information.
 From the command line, run `docker node inspect <id-node>` to query the nodes.
 For instance, to query the reachability of the node as a manager:
 
-```bash
 {% raw %}
+```bash
 docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
 reachable
-{% endraw %}
 ```
+{% endraw %}
 
 To query the status of the node as a worker that accept tasks:
 
-```bash
 {% raw %}
+```bash
 docker node inspect manager1 --format "{{ .Status.State }}"
 ready
-{% endraw %}
 ```
+{% endraw %}
 
 From those commands, we can see that `manager1` is both at the status
 `reachable` as a manager and `ready` as a worker.
diff --git a/engine/swarm/ingress.md b/engine/swarm/ingress.md
index 05f944c0bb..5f4825858d 100644
--- a/engine/swarm/ingress.md
+++ b/engine/swarm/ingress.md
@@ -82,13 +82,13 @@ $ docker service update \
 You can use `docker service inspect` to view the service's published port. For
 instance:
 
-```bash
 {% raw %}
+```bash
 $ docker service inspect --format="{{json .Endpoint.Spec.Ports}}" my-web
 
 [{"Protocol":"tcp","TargetPort":80,"PublishedPort":8080}]
-{% endraw %}
 ```
+{% endraw %}
 
 The output shows the `<CONTAINER-PORT>` (labeled `TargetPort`) from the containers and the
 `<PUBLISHED-PORT>` (labeled `PublishedPort`) where nodes listen for requests for the service.
diff --git a/engine/swarm/services.md b/engine/swarm/services.md
index 99cc64ddc4..de3d1544cb 100644
--- a/engine/swarm/services.md
+++ b/engine/swarm/services.md
@@ -961,13 +961,13 @@ Valid placeholders for the Go template are:
 This example sets the template of the created containers based on the
 service's name and the ID of the node where the container is running:
 
-```bash
 {% raw %}
+```bash
 $ docker service create --name hosttempl \
                         --hostname="{{.Node.ID}}-{{.Service.Name}}"\
                          busybox top
-{% endraw %}
 ```
+{% endraw %}
 
 To see the result of using the template, use the `docker service ps` and
 `docker inspect` commands.
@@ -979,11 +979,11 @@ ID            NAME         IMAGE
 wo41w8hg8qan  hosttempl.1  busybox:latest@sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912  2e7a8a9c4da2  Running        Running about a minute ago
 ```
 
-```bash
 {% raw %}
+```bash
 $ docker inspect --format="{{.Config.Hostname}}" hosttempl.1.wo41w8hg8qanxwjwsg4kxpprj
-{% endraw %}
 ```
+{% endraw %}
 
 ## Learn More
 
diff --git a/machine/reference/inspect.md b/machine/reference/inspect.md
index 3823aa6d6c..3be876f69f 100644
--- a/machine/reference/inspect.md
+++ b/machine/reference/inspect.md
@@ -53,12 +53,12 @@ $ docker-machine inspect dev
 For the most part, you can pick out any field from the JSON in a fairly
 straightforward manner.
 
-```none
 {% raw %}
+```none
 $ docker-machine inspect --format='{{.Driver.IPAddress}}' dev
 192.168.5.99
-{% endraw %}
 ```
+{% endraw %}
 
 **Formatting details:**
 
@@ -73,8 +73,8 @@ $ docker-machine inspect --format='{{json .Driver}}' dev-fusion
 While this is usable, it's not very human-readable. For this reason, there is
 `prettyjson`:
 
-```none
 {% raw %}
+```none
 $ docker-machine inspect --format='{{prettyjson .Driver}}' dev-fusion
 {
   "Boot2DockerURL": "",
diff --git a/machine/reference/ls.md b/machine/reference/ls.md
index eac9ae6437..90e5fb5fa8 100644
--- a/machine/reference/ls.md
+++ b/machine/reference/ls.md
@@ -97,21 +97,21 @@ when using the table directive, includes column headers as well.
 The following example uses a template without headers and outputs the `Name` and `Driver` entries separated by a colon
 for all running machines:
 
-```none
 {% raw %}
+```none
 $ docker-machine ls --format "{{.Name}}: {{.DriverName}}"
 default: virtualbox
 ec2: amazonec2
-{% endraw %}
 ```
+{% endraw %}
 
 To list all machine names with their driver in a table format you can use:
 
-```none
 {% raw %}
+```none
 $ docker-machine ls --format "table {{.Name}} {{.DriverName}}"
 NAME     DRIVER
 default  virtualbox
 ec2      amazonec2
+```
 {% endraw %}
-```
\ No newline at end of file
diff --git a/test.md b/test.md
index c238a127c4..5cdb0b434e 100644
--- a/test.md
+++ b/test.md
@@ -658,23 +658,23 @@ we use often.
 The raw markup is needed to keep Liquid from interperting the things with double
 braces as templating language.
 
+{% raw %}
 ```none
 none with raw
-{% raw %}
 $ some command with {{double braces}}
 $ some other command
-{% endraw %}
 ```
+{% endraw %}
 
 ### Raw, Bash
 
+{% raw %}
 ```bash
 bash with raw
-{% raw %}
 $ some command with {{double braces}}
 $ some other command
-{% endraw %}
 ```
+{% endraw %}
 
 ### Bash