Requirements
Garden Enterprise is a self-hosted distribution of Garden Cloud that includes additional enterprise features. It is distributed via Replicated and installed into your infrastructure with a single command using Replicated's KOTS kubectl plugin.
Below you'll find an overview of the requirements for installing Garden Enterprise. Some sections will link to more detailed and use case specific guides.
The Garden Enterprise License will be delivered to you prior to the installation. It is then uploaded via the Replicated admin console, a web application that runs on localhost, during the initial set up.
Garden Enterprise runs in a Kubernetes cluster and is installed via the kots kubectl plugin. The container images for the system services are pulled from a private registry that’s set up automatically during the installation process.
The cluster:
- Must be version 1.16 or higher.
- Should generally have at least 3 worker nodes, minimum 4 vCPUs and 16GB RAM each. The ideal size and number of nodes depends on whether Garden Enterprise is used to run workflows or not, and if so, how many concurrent workflows are expected to be running at a given time.
- When using workflows, it’s advisable to raise the node size by 2-4x relative to the minimum size. See below for a note on workflow runners’ resource usage. Ideally, use auto-scaling on the worker nodes to handle load bursts if you expect to be running a large number of concurrent workflows concurrent workflows.
- Should have 20 GB of persistent storage.
The workflow runners are only used if Garden Enterprise is used to run workflows on VCS events. They are ephemeral pods that are spun up on VCS events, and that run workflows via Garden Core. These pods are isolated in their own namespace with limited permissions.
Note that several workflow runners can run at the same time (due to multiple inbound VCS events) and resource usage depends on the size of the project in question.
Garden Enterprise requires access to a PostgreSQL database. The database:
- Must run PostgreSQL version 11 or higher.
- Must be accessible from the Garden Enterprise API service.
- Should have at least a 40GB storage capacity.
- Should have at least 1 vCPU and 2 GB RAM.
- Must have the
uuid-osspextension installed.
The bulk of database operations are caused by events and log entries that are streamed from Garden Core. This happens when:
- A logged in user runs a Garden command
- Garden is run from CI where a personal access token has been set
- A workflow runner runs a workflow when triggered by VCS events
Therefore, database load is mostly determined by Garden Core usage from authenticated actors.
We generally recommend a managed cloud service where possible, e.g. AWS’ RDS, GCP’s Cloud SQL or Azure’s Database for PostgreSQL.
Most cloud managed databases will have the required settings out of the box, but you can refer to our PostgreSQL Configuration guide for the exact configuration details.
Please refer to the database section of our Environment Configuration guide for the exact values you need to have at hand during the installation.
Garden Enterprise bundles Vault by default and the following only applies for customers that want to manage their own Vault instances.
If you prefer to manage your own Vault, the Vault server instance (or instances):
- Must be accessible from the API service over HTTP(s).
Please refer to the Vault section of our Environment Configuration guide for the exact values you need to have at hand during the installation.
If you choose to bundle Vault with Garden Enterprise, you will need to create a cloud KMS Key which is used during the Vault auto-unseal process.
Please refer to the Vault section of our Environment Configuration guide for the exact values you need to have at hand during the installation.
You will need to set up a load balancer or an ingress controller for your Garden Enterprise cluster and point a DNS record to it. The connection must be over HTTPs and you must have the hostname at hand during installation.
In general, there's a single entrypoint to Garden Enterprise, but you can optionally expose some of the monitoring services as well.
For more information on the monitoring services that Garden Enterprise optionally bundles, see this guide.
Garden Enterprise connects to your VCS provider so that can you import your Garden projects. We currently support GitHub (.com or Enterprise) and GitLab (.com or self-managed). Garden Enterprise also uses your VCS provider as an authentication provider. Other SSO implementations are possible but evaluated on a case-by-case basis. Furthermore, GitHub or GitLab can be optionally used to enable Garden Enterprise to run workflows on VCS events.
Therefore, you'll need to configure GitHub or GitLab to work with Garden Enterprise. You'll find detailed instructions for GitHub here and for GitLab here.
Please refer to the VCS section of our Environment Configuration guide for the exact values you need to have at hand during the installation.
During the installation you will need to provide a public/private key pair. This is used for signing JSON Web Tokens and authenticating against Vault instance.
You can use the following command to generate a self-signed public/private key pair:
openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
KOTS Kubectl Plugin
You'll need the kots kubectl plugin for installing and updating Garden Enterprise. You can install it by running the following command:
curl https://kots.io/install | bash
Vault CLI
If you choose to bundle Vault with Garden Enterprise, you'll also need the Hashicorp Vault CLI during the installation process. It's used when initializing Vault for the first time. You can download it from here.
Before installing Garden Enterprise, we highly recommend that you look at our Environment Configuration guide. It contains a list of all the configuration options for Garden Enterprise and the values you need to have at hand during the installation (e.g. database host name, GitHub/GitLab IDs, etc).
Last modified 4mo ago