Port DTR user topics to template (#404)

datacenter/dtr/2.5/guides/architecture.md

@@ -4,7 +4,7 @@ description: Learn about the architecture of Docker Trusted Registry.
 keywords: registry, dtr, architecture
 ui_tabs:
 - version: dtr-2.5
-  orhigher: false
+  orlower: true
 next_steps:
 - path: admin/install/system-requirements/
   title: System requirements

datacenter/dtr/2.5/guides/user/access-dtr/configure-your-notary-client.md

@@ -2,8 +2,13 @@
 title: Configure your Notary client
 description: Learn how to configure your Notary client to push and pull images from Docker Trusted Registry.
 keywords: registry, notary, trust
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 The Docker CLI client makes it easy to sign images but to streamline that
 process it generates a set of private and public keys that are not tied
 to your UCP account. This means that you'll be able to push and sign images to
@@ -131,3 +136,5 @@ notary key list
 ```
 
 The key you've imported should be listed with the role `delegation`.
+
+{% endif %}

datacenter/dtr/2.5/guides/user/access-dtr/index.md

@@ -2,8 +2,16 @@
 title: Configure your Docker Engine
 description: Learn how to configure your Docker Engine to push and pull images from Docker Trusted Registry.
 keywords: registry, TLS, certificates
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: use-a-cache/
+  title: Use a cache
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 By default Docker Engine uses TLS when pushing and pulling images to an
 image registry like Docker Trusted Registry.
 
@@ -11,8 +19,8 @@ If DTR is using the default configurations or was configured to use self-signed
 certificates, you need to configure your Docker Engine to trust DTR. Otherwise,
 when you try to log in, push to, or pull images from DTR, you'll get an error:
 
-```none
-$ docker login dtr.example.org
+```bash
+docker login dtr.example.org
 
 x509: certificate signed by unknown authority
 ```
@@ -52,22 +60,22 @@ After adding the CA certificate to Windows, restart Docker for Windows.
 
 ```bash
 # Download the DTR CA certificate
-$ sudo curl -k https://<dtr-domain-name>/ca -o /usr/local/share/ca-certificates/<dtr-domain-name>.crt
+sudo curl -k https://<dtr-domain-name>/ca -o /usr/local/share/ca-certificates/<dtr-domain-name>.crt
 # Refresh the list of certificates to trust
-$ sudo update-ca-certificates
+sudo update-ca-certificates
 # Restart the Docker daemon
-$ sudo service docker restart
+sudo service docker restart
 ```
 
 ### RHEL/ CentOS
 
 ```bash
 # Download the DTR CA certificate
-$ sudo curl -k https://<dtr-domain-name>/ca -o /etc/pki/ca-trust/source/anchors/<dtr-domain-name>.crt
+sudo curl -k https://<dtr-domain-name>/ca -o /etc/pki/ca-trust/source/anchors/<dtr-domain-name>.crt
 # Refresh the list of certificates to trust
-$ sudo update-ca-trust
+sudo update-ca-trust
 # Restart the Docker daemon
-$ sudo /bin/systemctl restart docker.service
+sudo /bin/systemctl restart docker.service
 ```
 
 ### Boot2Docker
@@ -116,6 +124,4 @@ DTR.
 docker login dtr.example.org
 ```
 
-## Where to go next
-
-* [Use a cache](use-a-cache.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/access-dtr/use-a-cache.md

@@ -2,8 +2,13 @@
 title: Use a cache
 description: Learn how to configure your Docker Trusted Registry account to pull images from a cache for faster download times.
 keywords: registry, cache
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 Docker Trusted Registry can be configured to have one or more caches. This
 allows you to choose from which cache to pull images from for faster
 download times.
@@ -15,3 +20,5 @@ and check the **Content Cache** options.
 ![](../../images/use-a-cache-1.png){: .with-border}
 
 Once you save, your images are pulled from the cache instead of the central DTR.
+
+{% endif %}

datacenter/dtr/2.5/guides/user/access-tokens.md

@@ -5,10 +5,9 @@ description: Learn how to create and manage your personal DTR access tokens to s
 keywords: dtr, security, access tokens
 ui_tabs:
   - version: dtr-2.5
-    orhigher: true
+    orlower: true
 ---
 
-{% if include.ui %}
 {% if include.version=="dtr-2.5" %}
 
 Docker Trusted Registry allows you to issue access tokens so that you can
@@ -34,20 +33,19 @@ purpose for the token. Administrators can also create tokens for other users.
 Once the token is created you won’t be able to see it again, but you can
 rename it if needed.
 
-{% endif %}
-{% endif %}
-
 ## Use the access token
 
 You can use an access token in any place that requires your DTR password.
 As an example you can use access tokens to login in from your Docker CLI client:
 
-```
+```bash
 docker login dtr.example.org --username <username> --password <token>
 ```
 
 To use the DTR API to list the repositories your user has access to:
 
-```
+```bash
 curl --silent --insecure --user <username>:<token> dtr.example.org/api/v0/repositories
 ```
+
+{% endif %}

datacenter/dtr/2.5/guides/user/create-and-manage-webhooks.md

@@ -2,8 +2,16 @@
 title: Manage webhooks
 description: Learn how to create, configure, and test webhooks in Docker Trusted Registry.
 keywords: registry, webhooks
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: create-promotion-policies/
+  title: Create promotion policies
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 DTR has webhooks so that you can run custom logic when an event happens. This
 lets you build complex CI and CD pipelines with your Docker images.
 
@@ -19,7 +27,7 @@ information about the event. Once everything is set up, click **Test** for
 DTR to send a JSON payload to the URL you set up, so that you can validate
 that the integration is working. You'll get an event that looks like this:
 
-```
+```json
 {
   "contents": {
     "architecture": "amd64",
@@ -43,6 +51,4 @@ the event is triggered.
 
 ![](../images/manage-webhooks-2.png){: .with-border}
 
-## Where to go next
-
-* [Create deployment policies](create-deployment-policies.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/create-promotion-policies.md

@@ -4,8 +4,13 @@ description: Learn how to create a promotion policies that can automatically
   promote an image to production if it passes all tests and doesn't have
   vulnerabilities.
 keywords: registry, promotion, pipeline
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 Once you've made changes to your application and want to make them available
 to your users, you typically push an image to DTR, or have a CI/CD pipeline
 that does it for you. A team responsible for QA will notice you've pushed
@@ -97,3 +102,5 @@ A repository admin can define the promotion policies, and only
 allow access to push to the first repository in that pipeline. Once users push
 to the fist repository, the image gets promoted to the other repositories as
 long as it satisfies the promotion policies.
+
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/delete-images.md

@@ -2,8 +2,13 @@
 title: Delete images
 description: Learn how to delete images from Docker Trusted Registry.
 keywords: registry, delete
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 To delete an image, go to the **DTR web UI**, and navigate to the image
 **repository** you want to delete. In the **Tags** tab, select all the image
 tags you want to delete, and click the **Delete** button.
@@ -13,3 +18,5 @@ tags you want to delete, and click the **Delete** button.
 You can also delete all image versions, by deleting the repository. For that,
 in the image **repository**, navigate to the **Settings** tab, and click the
 **Delete** button.
+
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/index.md

@@ -2,8 +2,16 @@
 title: Create a repository
 description: Learn how to create new repositories in Docker Trusted Registry.
 keywords: registry, repository
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: pull-and-push-images/
+  title: Pull and push images
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 Since DTR is secure by default, you need to create the image repository before
 being able to push the image to DTR.
 
@@ -32,6 +40,4 @@ When creating a repository in DTR, the full name of the repository becomes
 `<dtr-domain-name>/<user-or-org>/<repository-name>`. In this example, the full
 name of our repository will be `dtr.example.org/dave.lauper/golang`.
 
-## Where to go next
-
-* [Pull and push images](pull-and-push-images.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/prevent-tags-from-being-overwritten.md

@@ -3,8 +3,16 @@ title: Prevent tags from being overwritten
 description: Learn how to make your tags immutable and don't allow users to
   overwrite a tag if it already exists
 keywords: registry, immutable
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: sign-images/
+  title: Sign images
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 {% assign domain="dtr.example.org" %}
 {% assign org="library" %}
 {% assign repo="wordpress" %}
@@ -31,11 +39,9 @@ To make tags immutable, in the **DTR web UI**, navigate to the
 From now on, users will get an error message when trying to push a tag
 that already exists:
 
-```none
+```bash
 docker push {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
 unknown: tag={{ tag }} cannot be overwritten because {{ domain }}/{{ org }}/{{ repo }} is an immutable repository
 ```
 
-## Where to go next
-
-* [Sign images](sign-images/index.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/pull-and-push-images.md

@@ -2,8 +2,16 @@
 title: Pull and push images
 description: Learn how to pull and push images to Docker Trusted Registry.
 keywords: registry, push, pull
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: delete-images/
+  title: Delete images
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 {% assign domain="dtr.example.org" %}
 {% assign org="library" %}
 {% assign repo="wordpress" %}
@@ -34,8 +42,8 @@ Click on the repository to see its details.
 To pull the {{ tag }} tag of the {{ org }}/{{ repo }} image, run:
 
 ```bash
-$ docker login {{ domain }}
-$ docker pull {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
+docker login {{ domain }}
+docker pull {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
 ```
 
 ## Push an image
@@ -52,10 +60,10 @@ from, and where it will be pushed to.
 
 ```bash
 # Pull from Docker Hub the {{ tag }} tag of the {{ repo }} image
-$ docker pull {{ repo }}:{{ tag }}
+docker pull {{ repo }}:{{ tag }}
 
 # Tag the {{ repo }}:{{ tag }} image with the full repository name we've created in DTR
-$ docker tag {{ repo }}:{{ tag }} {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
+docker tag {{ repo }}:{{ tag }} {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
 ```
 
 ### Push the image
@@ -64,8 +72,8 @@ Now that you have tagged the image, you only need to authenticate and push the
 image to DTR.
 
 ```bash
-$ docker login {{ domain }}
-$ docker push {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
+docker login {{ domain }}
+docker push {{ domain }}/{{ org }}/{{ repo }}:{{ tag }}
 ```
 
 Go back to the **DTR web UI** to validate that the tag was successfully pushed.
@@ -92,10 +100,8 @@ push the Windows base layers to DTR.
 To configure Docker to always push Windows layers to DTR, add the following
 to your `C:\ProgramData\docker\config\daemon.json` configuration file:
 
-```
+```json
 "allow-nondistributable-artifacts": ["<dtr-domain>:<dtr-port>"]
 ```
 
-## Where to go next
-
-* [Delete images](delete-images.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/scan-images-for-vulnerabilities.md

@@ -2,8 +2,13 @@
 title: Scan images for vulnerabilities
 description: Learn how to scan your Docker images for vulnerabilities.
 keywords: registry, scan, vulnerability
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 [![Image Security Scanning](../../images/scanning_video.png)](https://www.youtube.com/watch?v=121poCB0Nn8 "Images Security Scanning"){: target="_blank" ._}
 
 Docker Trusted Registry can scan images in your repositories to verify that they
@@ -154,3 +159,5 @@ components that provide the same functionality. When you have updated the source
 code, run a build to create a new image, tag the image, and push the updated
 image to your DTR instance. You can then re-scan the image to confirm that you
 have addressed the vulnerabilities.
+
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/sign-images/delegate-image-signing.md

@@ -2,8 +2,16 @@
 title: Delegate image signing
 description: Learn how to grant permission for others to sign images in Docker Trusted Registry.
 keywords: registry, sign, trust
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: manage-trusted-repositories/
+  title: Manage trusted repositories
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 Instead of signing all the images yourself, you can delegate that task
 to other users.
 
@@ -51,7 +59,7 @@ UCP requires that you delegate trust to two different roles:
 
 In this example we'll delegate trust to `targets/releases` and `targets/qa`:
 
-```none
+```bash
 # Delegate trust, and add that public key with the role targets/releases
 notary delegation add --publish \
   dtr.example.org/dev/nginx targets/releases \
@@ -67,6 +75,4 @@ Now members from the QA team just have to [configure their Notary CLI client
 with UCP private keys](../../access-dtr/configure-your-notary-client.md)
 to be able to [push and sign images](index.md) into the `dev/nginx` repository.
 
-## Where to go next
-
-* [Manage trusted repositories](manage-trusted-repositories.md)
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/sign-images/index.md

@@ -2,8 +2,13 @@
 title: Sign an image
 description: Learn how to sign the images you push to Docker Trusted Registry.
 keywords: registry, sign, trust
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 By default, when you push an image to DTR, the Docker CLI client doesn't
 sign the image.
 
@@ -15,7 +20,7 @@ you created, or a forged one.
 
 To sign an image, you can run:
 
-```none
+```bash
 export DOCKER_CONTENT_TRUST=1
 docker push <dtr-domain>/<repository>/<image>:<tag>
 ```
@@ -96,7 +101,7 @@ UCP requires that you delegate trust to two different roles:
 
 In this example we'll delegate trust to `targets/releases` and `targets/admin`:
 
-```none
+```bash
 # Delegate trust, and add that public key with the role targets/releases
 notary delegation add --publish \
   dtr.example.org/dev/nginx targets/releases \
@@ -168,3 +173,5 @@ signed. For each repository there are four files.
 | `timestamp.json` | Has data about the digest, size, and version number for the snapshot.json file. This data is signed by the timestamp key. |
 
 [Learn more about trust metadata](/notary/service_architecture.md).
+
+{% endif %}

datacenter/dtr/2.5/guides/user/manage-images/sign-images/manage-trusted-repositories.md

@@ -2,8 +2,18 @@
 title: Manage trusted repositories
 description: Learn how to use the Notary CLI client to manage trusted repositories
 keywords: dtr, trust, notary, security
+ui_tabs:
+  - version: dtr-2.5
+    orlower: true
+next_steps:
+- path: /notary/advanced_usage/
+  title: Learn more about Notary
+- path: /notary/service_architecture/
+  title: Notary architecture
 ---
 
+{% if include.version=="dtr-2.5" %}
+
 Once you
 [configure the Notary CLI client](../../access-dtr/configure-your-notary-client.md),
 you can use it to manage your private keys, list trust data from any repository
@@ -14,8 +24,8 @@ keys if a private key has been compromised.
 
 List the trust data for a repository by running:
 
-```none
-$ notary list <dtr_url>/<account>/<repository>
+```bash
+notary list <dtr_url>/<account>/<repository>
 ```
 
 You can get one of the following errors, or a list with the images that have
@@ -32,7 +42,7 @@ been signed:
 There's two ways to initialize trust data for a repository. You can either
 sign and push an image to that repository:
 
-```none
+```bash
 export DOCKER_CONTENT_TRUST=1
 docker push <dtr_url>/<account>/<repository>
 ```
@@ -50,19 +60,19 @@ You can manage the changes that are staged by running:
 
 ```bash
 # Check what changes are staged
-$ notary status <dtr_url>/<account>/<repository>
+notary status <dtr_url>/<account>/<repository>
 
 # Unstage a specific change
-$ notary status <dtr_url>/<account>/<repository> --unstage 0
+notary status <dtr_url>/<account>/<repository> --unstage 0
 
 # Alternatively, unstage all changes
-$ notary status <dtr_url>/<account>/<repository> --reset
+notary status <dtr_url>/<account>/<repository> --reset
 ```
 
 When you're ready to publish your changes to the Notary server, run:
 
 ```bash
-$ notary publish <dtr_url>/<account>/<repository>
+notary publish <dtr_url>/<account>/<repository>
 ```
 
 ## Delete trust data
@@ -71,7 +81,7 @@ Administrator users can remove all signatures from a trusted repository by
 running:
 
 ```bash
-$ notary delete <dtr_url>/<account>/<repository> --remote
+notary delete <dtr_url>/<account>/<repository> --remote
 ```
 
 If you don't include the `--remote` flag, Notary deletes local cached content
@@ -84,13 +94,13 @@ The Notary CLI client manages the keys used to sign the image metadata. To
 list all the keys managed by the Notary CLI client, run:
 
 ```bash
-$ notary key list
+notary key list
 ```
 
 To change the passphrase used to encrypt one of the keys, run:
 
 ```bash
-$ notary key passwd <key_id>
+notary key passwd <key_id>
 ```
 
 ## Rotate keys
@@ -102,7 +112,7 @@ For keys that are kept offline and managed by the Notary CLI client, such the
 keys with the root, targets, and snapshot roles, you can rotate them with:
 
 ```bash
-$ notary key rotate <dtr_url>/<account>/<repository> <key_role>
+notary key rotate <dtr_url>/<account>/<repository> <key_role>
 ```
 
 The Notary CLI client generates a new key for the role you specified, and
@@ -115,7 +125,7 @@ You can also rotate keys that are stored in the Notary server, such as the keys
 with the snapshot or timestamp role. For that, run:
 
 ```bash
-$ notary key rotate <dtr_url>/<account>/<repository> <key_role> --server-managed
+notary key rotate <dtr_url>/<account>/<repository> <key_role> --server-managed
 ```
 
 ## Manage keys for delegation roles
@@ -124,17 +134,17 @@ To delegate image signing to other UCP users, get the `cert.pem` file that's
 included in their client bundle and run:
 
 ```bash
-$ notary delegation add -p <dtr_url>/<account>/<repository> targets/<role> --all-paths user1.pem user2.pem
+notary delegation add -p <dtr_url>/<account>/<repository> targets/<role> --all-paths user1.pem user2.pem
 ```
 
 You can also remove keys from a delegation role:
 
 ```bash
 # Remove the given keys from a delegation role
-$ notary delegation remove -p <dtr_url>/<account>/<repository> targets/<role> <keyID1> <keyID2>
+notary delegation remove -p <dtr_url>/<account>/<repository> targets/<role> <keyID1> <keyID2>
 
 # Alternatively, you can remove keys from all delegation roles
-$ notary delegation purge <dtr_url>/<account>/<repository> --key <keyID1> --key <keyID2>
+notary delegation purge <dtr_url>/<account>/<repository> --key <keyID1> --key <keyID2>
 ```
 
 ## Troubleshooting
@@ -146,7 +156,4 @@ Usually most problems are fixed by ensuring you're communicating with the
 correct Notary server, using the `-s` flag, and that you're using the correct
 directory where your private keys are stored, with the `-d` flag.
 
-## Where to go next
-
-* [Learn more about Notary](/notary/advanced_usage.md)
-* [Notary architecture](/notary/service_architecture.md)
+{% endif %}