Update install.md to include alpine 3.19

.github/pull_request_template.md

@@ -19,20 +19,18 @@ Closes #ISSUE
 
 ### Checklist
 
-Before creating a PR, run through this checklist and mark each as complete.
-
-- [ ] I have read the [contributing guidelines](/CONTRIBUTING.md)
-- [ ] I have signed the [F5 Contributor License Agreement (CLA)](https://github.com/f5/.github/blob/main/CLA/cla-markdown.md)
-- [ ] If applicable, I have added tests that prove my fix is effective or that my feature works
-- [ ] If applicable, I have checked that any relevant tests pass after adding my changes
-- [ ] I have updated any relevant documentation ([`README.md`](/README.md) and [`CHANGELOG.md`](/CHANGELOG.md))
-- [ ] I have rebased my branch onto main
-- [ ] I will ensure my PR is targeting the main branch and pulling from my branch from my own fork
-- [ ] If the change involves:
-  - Code
-  - Anything that resembles Personally identifying information (PII)
-    - Make sure to use placeholders such as `<username>` in place of PII
-  - URLs (watch for [typosquatting](https://support.microsoft.com/en-us/topic/what-is-typosquatting-54a18872-8459-4d47-b3e3-d84d9a362eb0))
-  - Significant new/revised content
-
-  In these cases, the change will require at least two (2) approvals before merging
+Before merging a pull request, run through this checklist and mark each as complete.
+
+- [] I have read the [contributing guidelines](/CONTRIBUTING.md)
+- [] I have signed the [F5 Contributor License Agreement (CLA)](https://github.com/f5/.github/blob/main/CLA/cla-markdown.md)
+- [] I have ensured that documentation content adheres to [the style guide](/templates/style-guide.md)
+- [] If the change involves potentially sensitive changes, I have assessed the possible impact
+- [] If applicable, I have added tests that prove my fix is effective or that my feature works
+- [] If applicable, I have checked that any relevant tests pass after adding my changes
+- [] I have updated any relevant documentation ([`README.md`](/README.md) and [`CHANGELOG.md`](/CHANGELOG.md))
+- [] I have rebased my branch onto main
+- [] I will ensure my PR is targeting the main branch and pulling from my branch from my own fork
+
+Potentially sensitive changes include anything involving code, personally identify information (PII), live URLs or significant amounts of new or revised documentation.
+
+Please refer to [our style guide](/templates/style-guide.md) for guidance about placeholder content.

.github/workflows/daily-deploy.yml

@@ -8,7 +8,7 @@ on:
         - cron: '0 1 * * *'
 jobs:
     trigger:
-        uses: nginxinc/docs/.github/workflows/build-push.yml@main
+        uses: nginx/documentation/.github/workflows/build-push.yml@main
         with:
             environment: "prod"
         secrets:

.github/workflows/linkchecker.yml

@@ -31,7 +31,7 @@ env:
     --ignore-url ^https://lightstep.com --ignore-url ^https://www.owasp.org/ --ignore-url ^https://www.maxmind.com --ignore-url ^https://www.splunk.com/
     --ignore-url ^https://oauth2.googleapis.com --ignore-url ^https://openidconnect.googleapis.com --ignore-url ^https://www.base64url.com/
     --ignore-url ^https://go.googlesource.com/ --ignore-url ^https://go.googlesource.com/sync --ignore-url ^https://linkerd.io/2.13/
-    --ignore-url ^http://www.redirectpage.com/
+    --ignore-url ^http://www.redirectpage.com/ --ignore-url ^https://www.gnu.org/
     --ignore-url ^https://\([a-zA-Z0-9-]+\).nginx.com/nginx-ingress-controller/css
     --ignore-url ^https://\([a-zA-Z0-9-]+\).nginx.com/nginxaas/azure/css
     --ignore-url ^https://\([a-zA-Z0-9-]+\).nginx.com/nginx-gateway-fabric/css

config/_default/config.toml

@@ -7,14 +7,15 @@ pygmentsUseClasses = true
 enableGitInfo = true
 
 [permalinks]
+  amplify = '/nginx-amplify/:sections[1:]/:filename'
   controller = '/nginx-controller/:sections[1:]/:filename'
+  mesh = '/nginx-service-mesh/:sections[1:]/:filename'
   modsec-waf = '/nginx-waf/:sections[1:]/:filename'
   nap-dos = '/nginx-app-protect-dos/:sections[1:]/:filename'
   nap-waf = '/nginx-app-protect-waf/:sections[1:]/:filename'
-  nms = '/nginx-management-suite/:sections[1:]/:filename'
-  amplify = '/nginx-amplify/:sections[1:]/:filename'
-  mesh = '/nginx-service-mesh/:sections[1:]/:filename'
+  ngf = '/nginx-gateway-fabric/:sections[1:]/:filename'
   nim = '/nginx-instance-manager/:sections[1:]/:filename'
+  nms = '/nginx-management-suite/:sections[1:]/:filename'
 
 [caches]
   [caches.modules]
@@ -36,7 +37,7 @@ enableGitInfo = true
   buildtype = "webdocs"
   RSSLink = "/index.xml"
   author = "NGINX Inc." # add your company name
-  github = "nginxinc" # add your github profile name
+  github = "nginx" # add your github profile name
   twitter = "@nginx" # add your twitter profile
   noindex_kinds = [
     "taxonomy",

content/includes/licensing-and-reporting/log-location-and-monitoring.md

@@ -0,0 +1,33 @@
+---
+docs:
+---
+
+Monitor the [NGINX error log](https://nginx.org/en/docs/ngx_core_module.html#error_log), typically located at `/var/log/nginx/error.log`, for subscription-related issues — such as failed usage reports or approaching license expirations — to catch problems early and keep your subscription compliant.
+
+<br>
+
+Examples of subscription-related log entries include:
+
+- **Failure to upload usage reports**:
+
+  ``` text
+  [error] 36387#36387: server returned 500 for <fqdn>:<port> during usage report
+  [error] 36528#36528: <fqdn>:<port> could not be resolved (host not found) during usage report
+  [error] 36619#36619: connect() failed (111: Connection refused) for <fqdn>:<port> during usage report
+  [error] 38888#88: server returned 401 for <ip_address>:443 during usage report
+  ```
+
+- **License approaching expiration**:
+
+  ``` text
+  [warn] license will expire in 14 days
+  ```
+
+- **License expiration**:
+
+  ``` text
+  [alert] license expiry; grace period will end in 89 days
+  [emerg] license expired
+  ```
+
+  {{<important>}}When a license expires, NGINX Plus stops processing traffic.{{</important>}}

content/includes/nap-waf/config/v5/build-nginx-image-oss/build-alpine.md

@@ -1,7 +1,7 @@
 ```dockerfile
 # syntax=docker/dockerfile:1
 
-# Supported OS_VER's are 3.16/3.17
+# Supported OS_VER's are 3.16/3.17/3.19
 ARG OS_VER="3.17"
 
 # Base image
@@ -33,4 +33,4 @@ STOPSIGNAL SIGQUIT
 
 # Set default command
 CMD ["nginx", "-g", "daemon off;"]
-```
+```

content/includes/nap-waf/config/v5/build-nginx-image-plus/build-alpine.md

@@ -1,7 +1,7 @@
 ```dockerfile
 # syntax=docker/dockerfile:1
 
-# Supported OS_VER's are 3.16/3.17
+# Supported OS_VER's are 3.16/3.17/3.19
 ARG OS_VER="3.17"
 
 # Base image
@@ -29,4 +29,4 @@ STOPSIGNAL SIGQUIT
 
 # Set default command
 CMD ["nginx", "-g", "daemon off;"]
-```
+```

content/includes/ngf/index.md

@@ -0,0 +1,3 @@
+---
+headless: true
+---

content/includes/ngf/installation/delay-pod-termination/delay-pod-termination-overview.md

@@ -0,0 +1,9 @@
+---
+docs: "DOCS-1441"
+---
+
+To avoid client service interruptions when upgrading NGINX Gateway Fabric, you can configure [`PreStop` hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) to delay terminating the NGINX Gateway Fabric pod, allowing the pod to complete certain actions before shutting down. This ensures a smooth upgrade without any downtime, also known as a zero downtime upgrade.
+
+For an in-depth explanation of how Kubernetes handles pod termination, see the [Termination of Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) topic on their official website.
+
+{{<note>}}Keep in mind that NGINX won't shut down while WebSocket or other long-lived connections are open. NGINX will only stop when these connections are closed by the client or the backend. If these connections stay open during an upgrade, Kubernetes might need to shut down NGINX forcefully. This sudden shutdown could interrupt service for clients.{{</note>}}

content/includes/ngf/installation/delay-pod-termination/termination-grace-period.md

@@ -0,0 +1,9 @@
+---
+docs: "DOCS-1440"
+---
+
+Set `terminationGracePeriodSeconds` to a value that is equal to or greater than the `sleep` duration specified in the `preStop` hook (default is `30`). This setting prevents Kubernetes from terminating the pod before before the `preStop` hook has completed running.
+
+   ```yaml
+   terminationGracePeriodSeconds: 50
+   ```

content/includes/ngf/installation/expose-nginx-gateway-fabric.md

@@ -0,0 +1,53 @@
+---
+title: "Expose NGINX Gateway Fabric"
+weight: 300
+docs: "DOCS-1427"
+---
+
+There are two options for accessing NGINX Gateway Fabric depending on the type of LoadBalancer service you chose during installation:
+
+- If the LoadBalancer type is `NodePort`, Kubernetes will randomly allocate two ports on every node of the cluster.
+  To access the NGINX Gateway Fabric, use an IP address of any node of the cluster along with the two allocated ports.
+
+  {{<tip>}} Read more about the type NodePort in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport). {{</tip>}}
+
+- If the LoadBalancer type is `LoadBalancer`:
+
+  - For GCP or Azure, Kubernetes will allocate a cloud load balancer for load balancing the NGINX Gateway Fabric pods.
+    Use the public IP of the load balancer to access NGINX Gateway Fabric.
+  - For AWS, Kubernetes will allocate a Network Load Balancer (NLB) in TCP mode with the PROXY protocol enabled to pass
+    the client's information (the IP address and the port).
+
+  Use the public IP of the load balancer to access NGINX Gateway Fabric. To get the public IP which is reported in the `EXTERNAL-IP` column:
+
+  - For GCP or Azure, run:
+
+    ```shell
+    kubectl get svc nginx-gateway -n nginx-gateway
+    ```
+
+  - In AWS, the NLB (Network Load Balancer) DNS (directory name system) name will be reported by Kubernetes instead of a public IP. To get the DNS name, run:
+
+    ```shell
+    kubectl get svc nginx-gateway -n nginx-gateway
+    ```
+
+    {{< note >}} We recommend using the NLB DNS whenever possible, but for testing purposes, you can resolve the DNS name to get the IP address of the load balancer:
+
+  ```shell
+  nslookup <dns-name>
+  ```
+
+    {{< /note >}}
+
+  {{<tip>}} Learn more about type LoadBalancer in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer).
+
+  For AWS, additional options regarding an allocated load balancer are available, such as its type and SSL
+  termination. Read the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) to learn more.
+  {{</tip>}}
+
+{{<important>}}By default Helm and manifests configure NGINX Gateway Fabric on ports `80` and `443`, affecting any gateway [listeners](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Listener) on these ports. To use different ports, update the configuration. NGINX Gateway Fabric requires a configured [gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/#gateway) resource with a valid listener to listen on any ports.{{</important>}}
+
+NGINX Gateway Fabric uses the created service to update the **Addresses** field in the **Gateway Status** resource. Using a **LoadBalancer** service sets this field to the IP address and/or hostname of that service. Without a service, the pod IP address is used.
+
+This gateway is associated with the NGINX Gateway Fabric through the **gatewayClassName** field. The default installation of NGINX Gateway Fabric creates a **GatewayClass** with the name **nginx**. NGINX Gateway Fabric will only configure gateways with a **gatewayClassName** of **nginx** unless you change the name via the `--gatewayclass` [command-line flag]({{< ref "/ngf/reference/cli-help.md#static-mode">}}).

content/includes/ngf/installation/helm/pulling-the-chart.md

@@ -0,0 +1,12 @@
+---
+docs: "DOCS-1439"
+---
+
+Pull the latest stable release of the NGINX Gateway Fabric chart:
+
+   ```shell
+   helm pull oci://ghcr.io/nginx/charts/nginx-gateway-fabric --untar
+   cd nginx-gateway-fabric
+   ```
+
+   If you want the latest version from the **main** branch, add `--version 0.0.0-edge` to your pull command.

content/includes/ngf/installation/install-gateway-api-experimental-features.md

@@ -0,0 +1,24 @@
+---
+title: "Install NGINX Gateway Fabric with experimental features"
+docs: "DOCS-000"
+---
+
+To use Gateway API experimental resources, the Gateway API resources from the experimental channel must be installed before deploying NGINX Gateway Fabric. Additionally, NGINX Gateway Fabric must have experimental features enabled.
+
+{{< caution >}}As noted in the [Gateway API documentation](https://gateway-api.sigs.k8s.io/guides/#install-experimental-channel), future releases of the Gateway API can include breaking changes to experimental resources and fields. {{</ caution >}}
+
+To install the Gateway API resources from the experimental channel, run the following:
+
+```shell
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/experimental?ref=v1.5.1" | kubectl apply -f -
+```
+
+{{< note >}}If you plan to use the `edge` version of NGINX Gateway Fabric, you can replace the version in `ref` with `main`, for example `ref=main`. {{</ note >}}
+
+To enable experimental features on NGINX Gateway Fabric:
+
+Using Helm: Set `nginxGateway.gwAPIExperimentalFeatures.enable` to true. An example can be found
+in the [Installation with Helm]({{< ref "/ngf/installation/installing-ngf/helm.md#custom-installation-options" >}}) guide.
+
+Using Kubernetes manifests: Add the `--gateway-api-experimental-features` command-line flag to the deployment manifest args.
+An example can be found in the [Installation with Kubernetes manifests]({{< ref "/ngf/installation/installing-ngf/manifests.md#3-deploy-nginx-gateway-fabric" >}}) guide.

content/includes/ngf/installation/install-gateway-api-resources.md

@@ -0,0 +1,24 @@
+---
+docs: "DOCS-1438"
+---
+
+{{< note >}} The [Gateway API resources](https://github.com/kubernetes-sigs/gateway-api) from the standard channel must be installed before deploying NGINX Gateway Fabric. If they are already installed in your cluster, please ensure they are the correct version as supported by the NGINX Gateway Fabric - [see the Technical Specifications](https://github.com/nginx/nginx-gateway-fabric/blob/v1.5.1/README.md#technical-specifications). {{</ note >}}
+
+To install the Gateway API resources, run the following:
+
+```shell
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.5.1" | kubectl apply -f -
+```
+
+{{< note >}} If you plan to use the `edge` version of NGINX Gateway Fabric, you can replace the version in `ref` with `main`, for example `ref=main`. {{</ note >}}
+
+Alternatively, you can install the Gateway API resources from the experimental channel.
+Installing Gateway API resources from the experimental channel includes everything in the standard release channel plus additional experimental resources and fields.
+NGINX Gateway Fabric currently supports a subset of the additional features provided by the experimental channel.
+To install from the experimental channel, run the following:
+
+```shell
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/experimental?ref=v1.5.1" | kubectl apply -f -
+```
+
+{{< note >}} To learn more about what Gateway API resources NGINX Gateway Fabric currently supports, visit our [Gateway API Compatibility]({{< ref "/ngf/overview/gateway-api-compatibility.md" >}}) document. {{</ note >}}

content/includes/ngf/installation/jwt-password-note.md

@@ -0,0 +1,11 @@
+---
+docs: "DOCS-000"
+---
+
+{{< note >}} For security, follow these practices with JSON Web Tokens (JWTs), passwords, and shell history:
+
+1. **JWTs:** JWTs are sensitive information. Store them securely. Delete them after use to prevent unauthorized access.
+
+1. **Shell history:** Commands that include JWTs or passwords are recorded in the history of your shell, in plain text. Clear your shell history after running such commands. For example, if you use bash, you can delete commands in your `~/.bash_history` file. Alternatively, you can run the `history -c` command to erase your shell history.
+
+Follow these practices to help ensure the security of your system and data. {{< /note >}}

content/includes/ngf/installation/nginx-plus/docker-registry-secret.md

@@ -0,0 +1,19 @@
+---
+docs: "DOCS-000"
+---
+
+{{< note >}} If you would rather pull the NGINX Plus image and push to a private registry, you can skip this specific step and instead follow [this step]({{< ref "/ngf/installation/nginx-plus-jwt.md#pulling-an-image-for-local-use" >}}). {{< /note >}}
+
+If the `nginx-gateway` namespace does not yet exist, create it:
+
+```shell
+kubectl create namespace nginx-gateway
+```
+
+Create a Kubernetes `docker-registry` secret type using the contents of the JWT as the username and `none` for password (as the password is not used).  The name of the docker server is `private-registry.nginx.com`.
+
+```shell
+kubectl create secret docker-registry nginx-plus-registry-secret --docker-server=private-registry.nginx.com --docker-username=<JWT Token> --docker-password=none -n nginx-gateway
+```
+
+It is important that the `--docker-username=<JWT Token>` contains the contents of the token and is not pointing to the token itself. When you copy the contents of the JWT, ensure there are no additional characters such as extra whitespaces. This can invalidate the token, causing 401 errors when trying to authenticate to the registry.

content/includes/ngf/installation/nginx-plus/download-jwt.md

@@ -0,0 +1,10 @@
+---
+docs: "DOCS-000"
+---
+
+1. Log in to [MyF5](https://my.f5.com/manage/s/).
+2. Go to **My Products & Plans > Subscriptions** to see your active subscriptions.
+3. Find your NGINX products or services subscription, and select the **Subscription ID** for details.
+4. Download the **JSON Web Token (JWT)** from the subscription page.
+
+{{< note >}} The Connectivity Stack for Kubernetes JWT does not work with NGINX Plus reporting. A regular NGINX Plus instance JWT must be used. {{< /note >}}

content/includes/ngf/installation/nginx-plus/nginx-plus-secret.md

@@ -0,0 +1,13 @@
+---
+docs: "DOCS-000"
+---
+
+Place the JWT in a file called `license.jwt`. Create a Kubernetes Secret using the contents of the JWT file.
+
+```shell
+kubectl create secret generic nplus-license --from-file license.jwt -n nginx-gateway
+```
+
+You can now delete the `license.jwt` file.
+
+If you need to update the JWT at any time, update the `license.jwt` field in the Secret using `kubectl edit` and apply the changes.

content/includes/ngf/installation/uninstall-gateway-api-resources.md

@@ -0,0 +1,17 @@
+---
+docs: "DOCS-1436"
+---
+
+{{<warning>}}This will remove all corresponding custom resources in your entire cluster, across all namespaces. Double-check to make sure you don't have any custom resources you need to keep, and confirm that there are no other Gateway API implementations active in your cluster.{{</warning>}}
+
+To uninstall the Gateway API resources, run the following:
+
+```shell
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.5.1" | kubectl delete -f -
+```
+
+Alternatively, if you installed the Gateway APIs from the experimental channel, run the following:
+
+```shell
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/experimental?ref=v1.5.1" | kubectl delete -f -
+```