From 26cb8a91aa92474b76a2a6420432dcf2eef2be6e Mon Sep 17 00:00:00 2001 From: Yndira-E Date: Tue, 29 Sep 2026 13:00:59 +0200 Subject: [PATCH] docs: replace 11ty shortcodes with Nuxt syntax --- docs/admin/hardening/kubernetes.md | 24 +++++++++---------- docs/device-agent/quickstart.md | 8 +++---- docs/install/docker/README.md | 4 ++-- docs/install/file-storage/README.md | 4 ++-- docs/install/introduction.md | 11 ++------- .../ingress-controller-migration.md | 4 ++-- docs/user/ff-tables.md | 4 ++-- 7 files changed, 26 insertions(+), 33 deletions(-) diff --git a/docs/admin/hardening/kubernetes.md b/docs/admin/hardening/kubernetes.md index 6de56f1e91..a065db01e5 100644 --- a/docs/admin/hardening/kubernetes.md +++ b/docs/admin/hardening/kubernetes.md @@ -16,9 +16,9 @@ meta: This guide walks you through the best ways to secure a Kubernetes cluster running FlowFuse. Locking down your cluster shrinks your attack surface and keeps things contained if a single component gets compromised. These tips work best when implemented together, so roll out as many of them as your environment allows. -{% note %} +::note These are general hardening recommendations. Adapt them to your organisation's security policies and your cluster's specific configuration. -{% endnote %} +:: ## Network Policies @@ -26,17 +26,17 @@ By default, Kubernetes allows unrestricted network traffic between all pods, acr Network Policies let you enforce the principle of least privilege at the network layer: a pod should only be able to talk to the workloads it genuinely needs. Restricting traffic contains lateral movement, so a breach in one component cannot trivially spread to others. -{% warning %} +::warning **Do not treat the policies below as a copy-and-paste solution.** They are illustrative examples, tied to the assumptions of the environment they were written for - namespace names, the ingress controller, the CNI, service ports, which components are deployed, and where operators live. Applied blindly they will either break platform traffic or leave gaps you believe are closed. Network Policies are one of the easiest things in Kubernetes to get subtly wrong: a rule that *looks* correct can silently drop traffic (wrong port direction, Service vs pod port, a missing return path) or silently allow it (an unenforced CNI, an overly broad selector). Implement them deliberately, with a working understanding of how traffic actually flows in your cluster - pod-to-pod, cross-namespace, ingress, egress, and DNS. Roll out one policy at a time, start in a non-production environment, verify each addition against real traffic (and check the affected pods' logs and Service endpoints), and confirm your CNI actually enforces policies before relying on them for security. -{% endwarning %} +:: ### FlowFuse and Network Policies FlowFuse runs the platform (namespace of your choice, selected during Helm chart installation) and the hosted Node-RED instances (configured with the `forge.projectNamespace` Helm chart value) in separate namespaces. If you enforce Network Policies, you must explicitly allow the traffic FlowFuse needs - otherwise the instances cannot reach the platform. See [I use Kubernetes Network Policies, how can I configure them?](../../install/kubernetes/#i-use-kubernetes-network-policies%2C-how-can-i-configure-them%3F) for the required policy. -{% note %} +::note The following examples assume the default namespaces `flowfuse`, as a core application namespace, and `projects` for Hosted Instances namespace. If you have configured different namespaces, replace them accordingly. -{% endnote %} +:: The two namespaces have very different trust levels, so they are hardened differently: @@ -116,9 +116,9 @@ spec: kubernetes.io/metadata.name: flowfuse ``` -{% note %} +::note The Helm chart also ships a `flowforge-database-policy` that permits the core app → database connection when using the embedded database. The `allow-intra-namespace` rule above is a superset of it; keep both if you prefer defence in depth. -{% endnote %} +:: **5. Allow inbound from the EMQX operator** - The MQTT broker cluster is managed by the EMQX operator, which usually runs in its own namespace (`emqx-operator` by default) and polls the broker's management API (port `18083`) to set a pod *readiness gate*. If this is blocked, the check times out, the readiness gate never turns true, the broker pods are marked `NotReady`, their Service endpoints go empty, and every broker client fails to connect with a `503` error response. This rule is required for the operator to manage the broker cluster correctly: @@ -144,9 +144,9 @@ spec: port: 18083 ``` -{% note %} +::note The same pattern applies to any other operator, admission webhook, or metrics controller that must reach pods in this namespace: allow ingress from its namespace, or its readiness/reconcile checks will silently break your Services. If a Service unexpectedly loses its endpoints after applying policies, check the managing controller's logs for connection timeouts. -{% endnote %} +:: ### Hosted Instances namespace (`projects`) @@ -337,9 +337,9 @@ Regular backups protect against data loss from accidental deletion, corruption, - **External / managed database:** use your database provider's backup and point-in-time-recovery features - **Embedded database:** if you use the Helm chart's internal PostgreSQL (`forge.localPostgresql: true`), you can schedule backups with a Kubernetes CronJob running `pg_dump`. A ready-to-use `CronJob` + `PersistentVolumeClaim` example is provided in the installation guide: [How to backup embedded database?](https://flowfuse.com/docs/install/kubernetes/#how-to-backup-embedded-database%3F) -{% warning %} +::warning **Test your restores.** A backup is only useful if it can be restored. Periodically verify that you can restore from a backup into a clean database. -{% endwarning %} +:: ## RBAC (Role-Based Access Control) diff --git a/docs/device-agent/quickstart.md b/docs/device-agent/quickstart.md index c71eb1a016..2552c28853 100644 --- a/docs/device-agent/quickstart.md +++ b/docs/device-agent/quickstart.md @@ -52,13 +52,13 @@ powershell -Command "Start-Process 'powershell' -Verb RunAs" Set-Location $env:USERPROFILE; powershell -c "irm https://flowfuse.github.io/device-agent/get.ps1 | iex"; .\flowfuse-device-agent-installer.exe ``` -{% note %} +::note The installer checks to see if port 1880 is available to use. If it isn't, it will let you know before exiting. This is typically because you already have Node-RED running locally. You can tell the installer to configure its Node-RED to use a different port using the `--port ` argument. Pick a different port, for example `1881` and re-run the above command with `--port 1881` added to the end. -{% endnote %} +:: -{% note %} +::note By default, the installer will use `/opt/flowfuse-device` (Linux/MacOS) or `c:\opt\flowfuse-device` (Windows) as the install location. To use a different location, use the `--dir` option with the install command. For example, `--dir /path/to/custom/location`. -{% endnote %} +:: ## Step 2: Follow the installer prompts diff --git a/docs/install/docker/README.md b/docs/install/docker/README.md index 7ff5acc1cc..19783a6215 100644 --- a/docs/install/docker/README.md +++ b/docs/install/docker/README.md @@ -174,9 +174,9 @@ Proceed to the [next paragraph](#start-flowfuse-platform) to start the platform If you have own TLS certificate, you can use it in FlowFuse platform installation as well. As mentioned before, the certificate must be a wildcard one for the domain you are using. -{% note %} +::note If your TLS certificate is issued by a private Certificate Authority, additional configuration is required so that Hosted Instances trust the CA. See [What additional configuration is required when the TLS certificate is issued by a private Certificate Authority?](#what-additional-configuration-is-required-when-the-tls-certificate-is-issued-by-a-private-certificate-authority%3F) for the step-by-step instructions. -{% endnote %} +:: To configure FlowFuse platform with your certificate, you need to have: * certificate key file diff --git a/docs/install/file-storage/README.md b/docs/install/file-storage/README.md index 50194ee109..09873cb09a 100644 --- a/docs/install/file-storage/README.md +++ b/docs/install/file-storage/README.md @@ -86,9 +86,9 @@ On FlowFuse v2.6.0 or later, the File Storage service is used exclusively for Pe Before FlowFuse v2.6.0, this service was also the primary way to provide persistent storage to Node-RED in container-based environments, in addition to Persistent Context. -{% note %} +::note The File Storage service is only required in Docker or Kubernetes environments. If you are using the LocalFS platform driver, Node-RED already has direct access to the local filesystem. -{% endnote %} +:: ### Configuring diff --git a/docs/install/introduction.md b/docs/install/introduction.md index f38fa1d282..b5854a4bbc 100644 --- a/docs/install/introduction.md +++ b/docs/install/introduction.md @@ -10,10 +10,6 @@ meta: - kubernetes - trial license - deployment models -templateEngineOverride: njk,md -installationServiceHubspot: - formId: "22edc659-d098-4767-aeb1-6480daae41ad" - targetId: "hs-form-installation-service" --- # Installing FlowFuse @@ -44,8 +40,5 @@ for any specific actions required. If you need assistance, request our complimentary Installation Service, and we will help you install FlowFuse. -{% set formId = installationServiceHubspot.formId %} -{% set targetId = installationServiceHubspot.targetId %} -{% set cta = "cta-request-installation-service" %} -{% set reference = "docs-install-intro" %} -{% include "hubspot/hs-form.njk" %} \ No newline at end of file +::HubSpotForm{formId="22edc659-d098-4767-aeb1-6480daae41ad" cta="cta-request-installation-service" reference="docs-install-intro"} +:: \ No newline at end of file diff --git a/docs/install/kubernetes/ingress-controller-migration.md b/docs/install/kubernetes/ingress-controller-migration.md index ca1a911377..916fc8a640 100644 --- a/docs/install/kubernetes/ingress-controller-migration.md +++ b/docs/install/kubernetes/ingress-controller-migration.md @@ -14,12 +14,12 @@ meta: # Ingress Controller Migration -{% note %} +::note This guide should not be treated as a one-size-fits-all solution. Consider it as a blueprint and adapt it to your specific Kubernetes cluster setup. Test the migration in a testing/staging environment before applying it to production. If you have any questions about the migration, please contact [support@flowfuse.com](mailto:support@flowfuse.com). -{% endnote %} +:: This document describes how to migrate a FlowFuse Platform Kubernetes deployment from the NGINX Ingress Controller to Traefik. diff --git a/docs/user/ff-tables.md b/docs/user/ff-tables.md index 6534877553..3b425c5839 100644 --- a/docs/user/ff-tables.md +++ b/docs/user/ff-tables.md @@ -4,9 +4,9 @@ navTitle: FlowFuse Tables # FlowFuse Tables -{% warning %} +::warning This feature is currently in [the beta state](https://flowfuse.com/handbook/engineering/releases/#beta-release). -{% endwarning %} +:: From FlowFuse v2.20.0 Teams (Enterprise teams only) can create a relational database to use to store data.