feat: Restructure how-to section layout, update frontmatter (#2991)

This commit restructures the how-to section, adding a new Traffic
security section and moving the contextually appropriate docs into it.
Subsequent weight changes have been made to re-order pages based on
likelihood of use, and frontmatter data for affected pages have been
updated to contemporary standards.

site/content/how-to/control-plane-configuration.md

@@ -1,8 +1,10 @@
 ---
 title: "Control plane configuration"
-weight: 300
 toc: true
-docs: "DOCS-1416"
+weight: 400
+type: how-to
+product: NGF
+docs: DOCS-1416
 ---
 
 Learn how to dynamically update the NGINX Gateway Fabric control plane configuration.
@@ -11,7 +13,7 @@ Learn how to dynamically update the NGINX Gateway Fabric control plane configura
 
 NGINX Gateway Fabric can dynamically update the control plane configuration without restarting. The control plane configuration is stored in the NginxGateway custom resource, created during the installation of NGINX Gateway Fabric.
 
-NginxGateway is deployed in the same namespace as the controller (Default: `nginx-gateway`). The resource's default name is based on your [installation method]({{<relref "/installation/installing-ngf">}}):
+NginxGateway is deployed in the same namespace as the controller (Default: `nginx-gateway`). The resource's default name is based on your [installation method]({{< relref "/installation/installing-ngf" >}}):
 
 - Helm: `<release-name>-config`
 - Manifests: `nginx-gateway-config`

site/content/how-to/data-plane-configuration.md

@@ -1,8 +1,10 @@
 ---
 title: "Data plane configuration"
-weight: 400
 toc: true
-docs: "DOCS-000"
+weight: 500
+type: how-to
+product: NGF
+docs: DOCS-000
 ---
 
 Learn how to dynamically update the NGINX Gateway Fabric global data plane configuration.

site/content/how-to/monitoring/_index.md

@@ -1,4 +1,4 @@
 ---
 title: "Monitoring and troubleshooting"
-weight: 200
+weight: 300
 ---

site/content/how-to/traffic-management/advanced-routing.md

@@ -1,12 +1,16 @@
 ---
 title: "Application routes using HTTP matching conditions"
-weight: 200
 toc: true
-docs: "DOCS-1422"
+weight: 200
+type: how-to
+product: NGF
+docs: DOCS-1422
 ---
 
 Learn how to deploy multiple applications and HTTPRoutes with request conditions such as paths, methods, headers, and query parameters
 
+---
+
 ## Overview
 
 In this guide we will configure advanced routing rules for multiple applications. These rules will showcase request matching by path, headers, query parameters, and method. For an introduction to exposing your application, we recommend that you follow the [basic guide]({{< relref "/how-to/traffic-management/routing-traffic-to-your-app.md" >}}) first.
@@ -17,6 +21,9 @@ The following image shows the traffic flow that we will be creating with these r
 
 The goal is to create a set of rules that will result in client requests being sent to specific backends based on the request attributes. In this diagram, we have two versions of the `coffee` service. Traffic for v1 needs to be directed to the old application, while traffic for v2 needs to be directed towards the new application. We also have two `tea` services, one that handles GET operations and one that handles POST operations. Both the `tea` and `coffee` applications share the same Gateway.
 
+
+---
+
 ## Before you begin
 
 - [Install]({{< relref "/installation/" >}}) NGINX Gateway Fabric.
@@ -27,7 +34,9 @@ The goal is to create a set of rules that will result in client requests being s
    GW_PORT=<port number>
    ```
 
-{{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}}
+{{< note >}} In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for. {{< /note >}}
+
+---
 
 ## Coffee applications
 
@@ -39,6 +48,8 @@ Begin by deploying the `coffee-v1` and `coffee-v2` applications:
 kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/advanced-routing/coffee.yaml
 ```
 
+---
+
 ### Deploy the Gateway API Resources for the Coffee applications
 
 The [gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) resource is typically deployed by the [cluster operator](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#roles-and-personas_1). To deploy the gateway:
@@ -113,6 +124,8 @@ This HTTPRoute has a few important properties:
 
   If you want both conditions to be required, you can define headers and queryParams in the same match object.
 
+---
+
 ### Send traffic to Coffee
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee applications.
@@ -149,16 +162,22 @@ Server address: 10.244.0.9:8080
 Server name: coffee-v2-68bd55f798-s9z5q
 ```
 
+---
+
 ## Tea applications
 
 Let's deploy a different set of applications now called `tea` and `tea-post`. These applications will have their own set of rules, but will still attach to the same gateway listener as the `coffee` apps.
 
+---
+
 ### Deploy the Tea applications
 
 ```shell
 kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/advanced-routing/tea.yaml
 ```
 
+---
+
 ### Deploy the HTTPRoute for the Tea services
 
 We are reusing the previous gateway for these applications, so all we need to create is the HTTPRoute.
@@ -201,6 +220,8 @@ The properties of this HTTPRoute include:
 - The first rule defines that a POST request to the `/tea` path is routed to the `tea-post` Service.
 - The second rule defines that a GET request to the `/tea` path is routed to the `tea` Service.
 
+---
+
 ### Send traffic to Tea
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our tea applications.
@@ -231,6 +252,7 @@ Server name: tea-post-b59b8596b-g586r
 
 This request should receive a response from the `tea-post` pod. Any other type of method, such as PATCH, will result in a `404 Not Found` response.
 
+---
 
 ## Troubleshooting
 
@@ -334,7 +356,9 @@ If you have any issues while sending traffic, try the following to debug your co
 
   Check for any error messages in the conditions.
 
-## Further reading
+---
+
+## See also
 
 To learn more about the Gateway API and the resources we created in this guide, check out the following Kubernetes documentation resources:
 

site/content/how-to/traffic-management/https-termination.md

@@ -1,16 +1,22 @@
 ---
 title: "HTTPS termination"
-weight: 600
 toc: true
-docs: "DOCS-1421"
+weight: 500
+type: how-to
+product: NGF
+docs: DOCS-1421
 ---
 
 Learn how to terminate HTTPS traffic using NGINX Gateway Fabric.
 
+---
+
 ## Overview
 
 In this guide, we will show how to configure HTTPS termination for your application, using an [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) redirect filter, secret, and [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/).
 
+---
+
 ## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric.
@@ -30,6 +36,8 @@ In this guide, we will show how to configure HTTPS termination for your applicat
 
 {{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}}
 
+---
+
 ## Set up
 
 Create the **coffee** application in Kubernetes by copying and pasting the following block into your terminal:
@@ -88,6 +96,8 @@ NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
 service/coffee       ClusterIP   10.96.189.37   <none>        80/TCP    40s
 ```
 
+---
+
 ## Configure HTTPS termination and routing
 
 For the HTTPS, we need a certificate and key that are stored in a secret. This secret will live in a separate namespace, so we will need a ReferenceGrant in order to access it.
@@ -209,7 +219,9 @@ EOF
 
 The first route issues a `requestRedirect` from the `http` listener on port 80 to `https` on port 443. The second route binds the `coffee` route to the `https` listener.
 
-## Send Traffic
+---
+
+## Send traffic
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee application.
 
@@ -241,7 +253,9 @@ Server address: 10.244.0.6:80
 Server name: coffee-6b8b6d6486-7fc78
 ```
 
-## Further reading
+---
+
+## See also
 
 To learn more about redirects using the Gateway API, see the following resource:
 

site/content/how-to/traffic-management/request-response-headers.md

@@ -1,7 +1,10 @@
 ---
 title: "Modify HTTP request and response headers"
-weight: 500
 toc: true
+weight: 600
+type: how-to
+product: NGF
+docs: DOCS-000
 ---
 
 Learn how to modify the request and response headers of your application using NGINX Gateway Fabric.

site/content/how-to/traffic-management/routing-traffic-to-your-app.md

@@ -1,16 +1,22 @@
 ---
 title: "Routing traffic to applications"
-weight: 100
 toc: true
-docs: "DOCS-1426"
+weight: 100
+type: how-to
+product: NGF
+docs: DOCS-1426
 ---
 
 Learn how to route external traffic to your Kubernetes applications using NGINX Gateway Fabric.
 
+---
+
 ## Overview
 
 You can route traffic to your Kubernetes applications using the Gateway API and NGINX Gateway Fabric. Whether you're managing a web application or a REST backend API, you can use NGINX Gateway Fabric to expose your application outside the cluster.
 
+---
+
 ## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric.
@@ -21,18 +27,22 @@ You can route traffic to your Kubernetes applications using the Gateway API and
    GW_PORT=<port number>
    ```
 
+---
+
 ## Example application
 
 The application we are going to use in this guide is a simple **coffee** application comprised of one service and two pods:
 
-{{<img src="img/route-all-traffic-app.png" alt="">}}
+{{<img src="img/route-all-traffic-app.png" alt="This image shows a single 'coffee' Service connecting to two 'coffee' Pods.">}}
 
 Using this architecture, the **coffee** application is not accessible outside the cluster. We want to expose this application on the hostname "cafe.example.com" so that clients outside the cluster can access it.
 
 Install NGINX Gateway Fabric and create two Gateway API resources: a [gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway) and an [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.HTTPRoute).
 
 Using these resources we will configure a simple routing rule to match all HTTP traffic with the hostname "cafe.example.com" and route it to the **coffee** service.
 
+---
+
 ## Set up
 
 Create the **coffee** application in Kubernetes by copying and pasting the following block into your terminal:
@@ -92,11 +102,13 @@ NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
 service/coffee       ClusterIP   198.51.100.1     <none>        80/TCP    77s
 ```
 
+---
+
 ## Application architecture with NGINX Gateway Fabric
 
 To route traffic to the **coffee** application, we will create a gateway and HTTPRoute. The following diagram shows the configuration we are creating in the next step:
 
-{{<img src="img/route-all-traffic-config.png" alt="Configuration">}}
+{{<img src="img/route-all-traffic-config.png" alt="">}}
 
 We need a gateway to create an entry point for HTTP traffic coming into the cluster. The **cafe** gateway we are going to create will open an entry point to the cluster on port 80 for HTTP traffic.
 
@@ -112,6 +124,8 @@ The **coffee** service is omitted from the diagram above because the NGINX Gatew
 
 See the [roles and personas](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#roles-and-personas_1) Gateway API document for more information on these roles.{{< /note >}}
 
+---
+
 ## Create the Gateway API resources
 
 To create the **cafe** gateway, copy and paste the following into your terminal:
@@ -168,6 +182,8 @@ The [**hostnames**](https://gateway-api.sigs.k8s.io/references/spec/#gateway.net
 
 The [**rules**](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule) field defines routing rules for the HTTPRoute. A rule is selected if the request satisfies one of the rule's **matches**. To forward traffic for all paths to the coffee service we specify a match with the PathPrefix "/" and target the coffee service using the **backendRef** field.
 
+---
+
 ## Test the configuration
 
 To test the configuration, we will send a request to the public IP and port of NGINX Gateway Fabric that you saved in the [Before you begin](#before-you-begin) section and verify that the response comes from one of the **coffee** pods.
@@ -226,6 +242,8 @@ You should receive a 404 Not Found error:
 </html>
 ```
 
+---
+
 ## Troubleshooting
 
 If you have any issues while testing the configuration, try the following to debug your configuration and setup:
@@ -357,11 +375,13 @@ If you have any issues while testing the configuration, try the following to deb
   }
   ```
 
-{{< note >}}The entire configuration is not shown because it is subject to change. Ellipses indicate that there's configuration not shown.{{< /note >}}
+{{< note >}} The entire configuration is not shown because it is subject to change. Ellipses indicate that there's configuration not shown. {{< /note >}}
 
 If your issue persists, [contact us](https://github.com/nginx/nginx-gateway-fabric#contacts).
 
-## Further reading
+---
+
+## See also
 
 To learn more about the Gateway API and the resources we created in this guide, check out the following resources: