Skip to main content

High availability

The Knocknoc Server can be deployed in various ways to match your high-availability needs and deployment models.

Ultimately the Knocknoc solution comprises these three components:

  • Server
  • Database
  • Orchestration Agent(s)

The Server (web-app) can be deployed:

  • Single node - Web and DB running on a single host. This is ok for smaller deployments or where VM-layer or other failover techniques are used and deemed sufficient. Vertically scaling is required.
  • Shared-primary - Multiple web-apps are running with a "single" database backend, which is operating on one of the web nodes but made externally-accessible. A load balancer manages web-traffic, with database replication occurring between the primary node and a secondary/backup node. Knocknoc has out of the box support to "externalise" the database to achieve this.
Multi-node - Multiple web-apps are running with a "single" database backend source (see below). that is not running on one of the web nodes. This could be a dedicated database host or a DBaaS service like Amazon RDS etc. Horizontal web-tier scaling canmeans behot/hot enjoyed.access. An external HTTP load-balancer/WAF is typically deployed to maintain web state and handle automated failover based on availability or performance. "All in one" - Web and DB running on a single host, optionally with an Agent installed locally operating in reverse-proxy mode. A simple yet powerful Knocknoc server is introduced to an environment providing reverse-proxy HTTP/TCP in-line protection, along with Agents orchestrating external systems and on-prem or public-cloud control layers. This is ok for isolated  deployments where VM-layer or other failover techniques are used and deemed sufficient.

The Database (Postgres) can be deployed:

  • On-host (with the Server), which would rely on VM failover along with the Web tier.
  • On-host with externalised access,access, where a primary node exists and secondary node(s) read/write from the primary - with manual or automated failover. See automated failover options below.
  • UsingDBaaS using an external database source such as hosted Postgres, Amazon RDS/Postgres, Microsoft Azure/Postgres, Google CloudSQL/Postgres, Digital Ocean/Heroku or others.

Agent high-availability:

    The Orchestration Agents can be deployed in multiple ways and locations, depending on the system(s) they are orchestrating. It is recommended they be deployed alongside the assets being orchestrated. They do not require Server->Agent network access, rather the Agents subscribe to the Server for instruction. This is covered in more detail in the Agent documentation. Agents must connect to each web front-end providing access to users, to ensure prompt login updates. Where multiple web-nodes are utilized, the Agent configuration is set to connect to each of these. You do not need to run multiple Agents to connect to the multiple servers, an Agent is multi-server aware. Where multiple Agents are running, they are all assigned grant jobs - ensuring the grant/revoke process is performed regardless of the Agents state.

     

    "All in one" mode with reverse-proxy:

      Web and DB running on a single host, with an Agent installed locally operating in reverse-proxy mode. This introduces the Knocknoc capability "in a box" to an environment providing reverse-proxy HTTP/TCP in-line protection, along with Agents orchestrating external systems, on-prem host-firewalls or public-cloud control layers. This is good for isolated  deployments where VM-layer or other failover techniques are used and deemed sufficient.


      Single node deployment

      Following the default Server installation guide will deploy the Web application and Postgres database on a single node. Postgres is installed locally and external access to this database is denied.


      Externalizing a single/primary node

      After deployment, a single-node installation can be converted into a multi-node database source, allowing other web-nodes to read/write from this web + database node. 

      This can be achieved by utilizing the Knocker command "exposedb", or adjusting Postgres manually.

      Using Knocker

      Using the "knocker exposedb --init" feature on the primary system will: a) configure Postgres to bind to 0.0.0.0:5432, b) create a user and a random password, c) link the user/permissions to the existing database using the connection string in your knocknoc config, d) output the results for easy consumption.

      $ sudo /opt/knocknoc/knocker/knocker exposedb --init

      Copy the relevant connection string output, this will be needed when configuring additional web nodes.

      You then must use the --add feature to add trusted IP address sources that are allowed to connect to Postgres, an additional allow-listing security feature. These can be listed with --list or removed with --remove.

      $ sudo /opt/knocknoc/knocker/knocker exposedb --add "203.0.113.7/32"

      You are now ready to configure the secondary web-node(s) which will connect to this database. Note these secondary nodes need to be added using the above --add IP address allowlisting command, otherwise they cannot connect to the database you have now externalized.

      Installing Knocknoc web on additional nodes

      On the secondary web-node(s), when installing Knocknoc choose option 3 at the database-source question stage. Option 3 connects this newly installed Knocknoc web-instance to an existing remote Knocknoc database. Whereas option 1 is new local database install and option 2 is a "new" external database source such as a fresh Postgres as-a-service source.

      At installation you can bind Knocknoc to an external IP or 0.0.0.0 (on port 8756), use HAProxy locally set up with Knocker, or otherwise integrate your load-balancer how you see fit to distribute inbound traffic across the multiple web-nodes. Persistence is typically managed by a cookie introduced and managed by the load-balancer, as per standard practice.

      If Knocknoc cannot access the remote database, you may need to use --add <host's IP address> as above.

      $ sudo /opt/knocknoc/knocker/knocker exposedb
This script "externalizes" your local database, allowing you to run multiple Knocknoc web-app servers utilizing this database.

Running --init re-configures your local Postgres database service to listen externally, creates a user login/password, and
adds (or removes) IP addresses to the trusted Postgres list - allowing external webapps to connect to the Knocknoc database.


Usage:
  sudo /opt/knocknoc/knocker/knocker exposedb [--init | --add <CIDR> | --remove <CIDR> | --list] [--conn URI]

Options:
  --init             Initialize/expose the database for external access
  --add <CIDR>       Add access rule to pg_hba.conf for the specified CIDR (e.g., 192.168.1.0/24)
  --remove <CIDR>    Remove access rule from pg_hba.conf for the specified CIDR
  --list             List all IP addresses currently allowed to access the database
  --conn <URI>       Optional: PostgreSQL connection string (default value is taken from your '/opt/knocknoc/etc/knocknoc.conf')
  -h, --help         Show this help text

Examples:
  # Initialize/expose database for external access
  sudo /opt/knocknoc/knocker/knocker exposedb --init

  # Add/remove access rules for a CIDR
  sudo /opt/knocknoc/knocker/knocker exposedb --add "203.0.113.7/32"
  sudo /opt/knocknoc/knocker/knocker exposedb --remove "203.0.113.7/32"

  # List all allowed IP addresses
  sudo /opt/knocknoc/knocker/knocker exposedb --list

  # If using a non-default connection string/config location
  sudo /opt/knocknoc/knocker/knocker exposedb --init --conn "postgres://user:pass@host:5432/dbname"
  sudo /opt/knocknoc/knocker/knocker exposedb --add "1.2.3.4/32" --conn "postgres://user:pass@host:5432/dbname"

      Install Knocknoc on the secondary web-node(s), opt for a directly-accessible knocknoc (bind 0.0.0.0:8756) and select option 3 for database configuration:

       _  ___   _  ___   ____ _  ___   _  ___   ____
| |/ / \ | |/ _ \ / ___| |/ / \ | |/ _ \ / ___|
| ' /|  \| | | | | |   | ' /|  \| | | | | |
| . \| |\  | |_| | |___| . \| |\  | |_| | |___
|_|\_\_| \_|\___/ \____|_|\_\_| \_|\___/ \____|

Please answer the following questions to configure Knocknoc correctly. (No existing configuration detected, starting fresh)
Please refer to https://docs.knocknoc.io/ if you need more help.

Enter IP and port to listen on (default: 127.0.0.1:8756): 0.0.0.0:8756

If you're running behind a reverse-proxy, set the trusted forwarders.
Default is safe if not. You can adjust this later, see Server Install on https://docs.knocknoc.io
Enter TrustedForwarders (default: 127.0.0.1/32): 192.168.100.1/32

Knocknoc stores its data in PostgreSQL, and you can choose how to configure the database.
You have three options:
  1) Use a local PostgreSQL installation (default)
  2) Use a new external or preconfigured PostgreSQL database
  3) This Server is a web node only, use pre-existing external Knocknoc database

Option 1, 2, or 3? (default is 1): 3

Enter pre-existing external Knocknoc database connection string: postgres://knocknoc:random-password@10.64.11.1:5432/knocknoc

      Back to top