Cloud Deployment
This document describes how to deploy a guardian instance on one of the three major cloud providers using Kubernetes.
Last updated
This document describes how to deploy a guardian instance on one of the three major cloud providers using Kubernetes.
Last updated
This document provides a comprehensive guide for deploying the platform on various cloud providers, including AWS, GCP, and Azure. The guide focuses on using Rancher as the cluster management tool, making it applicable to a wide range of cloud providers supported by Rancher, as well as on-premises and hybrid cloud deployments.
NOTE: The contents of this guide has been written and tested using Guardian 2.14.2 and Rancher 2.7, the latest stable version at writing time. The guide might not be applicable to different versions, specially major versions.
To begin the Rancher deployment process, the first step is setting up a Rancher server. We'll assume the Rancher server will be created in the same cloud provider as the Guardian instance, but it's important to note that this is not mandatory. Alternatively, you can use a Rancher container distribution and run it locally, enabling you to deploy the Guardian instance to any cloud provider. However, having the Rancher server running in the cloud will be beneficial for future cluster management and monitoring.
Rancher deployment on AWS: Follow this official guide to deploy Rancher 2.7 on AWS
Rancher deployment on GCP: Follow this official guide to deploy Rancher 2.7 on GCP
Rancher deployment on Azure: Follow this official guide to deploy Rancher 2.7 on Azure
Once you have your Rancher server up and running, you can access it through the web interface, and you should see something like this:
You should be able to log in with the credentials you created during the installation process. Once you're logged in, you'll be able to manage your clusters and deploy new ones on any cloud provider. Additionally, you'll see a couple of default clusters created by Rancher, one of them is the local cluster, which is the one where Rancher is running, and the other one is the sandbox cluster, which is a cluster created by Rancher to test deployments and other features.
After setting up your Rancher server successfully, the next step is to deploy a Kubernetes cluster on your preferred cloud provider. In this guide, we will utilize the managed Kubernetes solutions offered by cloud providers. However, you also have the option to deploy a cluster using VMs, a different distribution like k3s, or even use the Rancher-provided sandbox cluster if you do not intend to use it for production workloads. At the moment of writing this document, the recommended Kubernetes version for AWS and Azure is 1.25, and 1.26 for GCP.
Cluster deployment on AWS EKS: Follow this official guide to deploy an EKS cluster
Cluster deployment on GCP GKE: Follow this official guide to deploy a GKE cluster
Cluster deployment on Azure AKS: Follow this official guide to deploy an AKS cluster
After the cluster is created, you'll be able to navigate to the cluster management section to see details for the cluster like nodes. In that section you can edit the cluster configuration, add nodes, etc.
You can also explore the cluster by clicking on the cluster name on the left side menu. In this view you can list and create all resources in the cluster, including namespaces, controller, access permissions, services, helm applications, monitoring, etc. From now on we'll focus on this "exploration view", which is the one you'll use to deploy the Guardian components.
An important part of the Rancher UI is the top header, specially the namespace dropdown. This dropdown allows you to select the namespace where you want to deploy the manifests. By default, Rancher will create a namespace named default, but you can create as many namespaces as you want. Get familiar with this dropdown and check it to see the selected namespace before panicking if you don't see the resources you expect to see under any section.
Once you have your cluster up and running, you can start deploying the different Guardian components. Not all of them are mandatory, and some of them can be replaced by managed services outside of the cluster. There is a dedicated section on this document with details about the different types of services and the deployment options for external services.
For this guide we've divided the different manifests into several folders, which name is prefixed by a number, this is to indicate the order in which they should be deployed. The reason for this is that some of the components depend on others, so we need to deploy them in the right order to avoid errors and to ease service discovery.
The first component we need to deploy is the Nginx ingress controller. This component is used to expose the different services to the outside world. You can find more details about this component in the official documentation, but for this guide we're going to use the default configuration.
Complete information about this topic can be found in this link, but here is a summary for the installation steps for the cloud providers referred on this document.
AWS
GCP
Azure
After this step is completed you should see a Load Balancer service created in your cluster with a external IP address where you'll have access to Guardian once it is deployed. You can check the status of the service by running the following command:
You can also find the load balancer using your cloud privider console. The domain name configuration and, DNS records and TLS certificates with SSL termination on the load balancer are out of the scope of this document.
Simply run the following commands to deploy the manifests. You can find more details about the different components below, in the manifests folder structure section.
To use a namespace different than default one, you need to add the --namespace <namespace> flag to the commands above. And create the namespace before running the commands.
PRO-TIP: if you plan to use the web ui, this command executed locally may help to deploy all manifests on a single shot by coping in your clipboard a huge text with all the manifests content together:
find k8s-manifests -type f | sort | xargs cat | pbcopyfor macos, orfind k8s-manifests -type f | sort | xargs cat | xsel -bfor linux users.
1-config
This folder contains configuration manifests that are required for the rest of the components to work. You can find more details about the configuration in the relevant section fo the documentation, but for the demonstration of this document, the only important file is 0-general-config.yaml, which contains the configuration for the different services. You can edit this file to change the configuration of the services. The rest of the files are related to the specific settings each individual service can override, based on the multi-environment feature.
Multi-environment feature settings
The key settings to turn on the multi-environment feature are GUARDIAN_ENV and OVERRIDE. The first one is used to indicate the environment name, and the second one is used to indicate if the service should override the default configuration or not. If the service is not overriding the default configuration, it will use the default one. If the service is overriding the default configuration, it will use the configuration defined in the service manifest.
NOTE: when using the multi-environment feature, each service will try to read its config file from a file named
.env.gateway.${GUARDIAN_ENV}, that file is not mounted in the manifests, so you'll need to update the corresponding controller manifests and re-deploy them, and deploy before the new configSet. See below a simplified example: