Disclaimer: This is a work in progress, which means things may change as improvements and additions are made. Feel free to try the labs, ideally first locally using KinD
or k3d
or a fresh cloud deployment (if possible). The instruction set has been tested successfully with GKE
, EKS
, and AKS
.
Blog to likely follow, so stay tuned :)
Not officially supported by Solo.io.
This repo is structured using kustomize bases and overlays to foster re-use of configuration where possible.
Overlays do exactly as the name, and layer over base manifests and can additionally provide configuration that can be specific to the cluster using kustomize. A few examples of kustomize options would be adding secrets
and configMaps
using the configMapGenerator
and secretGenerators
built into kustomize. Another being leveraging the patchesStrategicMerge
or patchesJson6902
features which can be pretty powerful.
An few examples of how overlays can be useful:
- reuse base manifest(s) but create overlays for prod, staging, dev, test
- reuse an existing overlay but create different
configmaps
,secrets
,labels
- reuse an existing overlay but patch/add more configuration (i.e. Cloud to On-Prem/OpenShift environments)
- create overlays to organize multi-cloud or multi-cluster configuration
base manifests are organized here. All overlay layers should inherit their configuration from the base manifests. Leave out instance-specific or environment-specific config out of the base manifests such as namespaces as these will be added/patched using overlays.
You can manually deploy any kustomize directory by just using kubectl apply -k </path/to/dir>
An example for deploying the bookinfo-v1
overlay
kubectl apply -k bookinfo/overlay/bookinfo-v1/default/
To view the full configuration of an overlay you can run the command kubectl kustomize </path/to/dir>
An example using the same bookinfo-v1
overlay as above
kubectl kustomize bookinfo/overlay/bookinfo-v1/default/
In addition to the library of applications organized using kustomize, this repo aims to provide a corresponding argocd Application
CRD for each kustomize overlay. Combining the two tools allows us to continue on our GitOps journey by introducing the concept of keeping our deployments in sync with Git through a control loop mechanism.
The labs below provide steps to deploying examples found in our workshops while using this gitops-library as our source of truth for configuration.
- installing argocd
- installing gloo-edge
- installing gloo-mesh
- installing istio
- installing gloo-portal
- Installing argo workflows
If you would like to run through the Gloo Mesh multicluster demo end-to-end, you can do so by running the script
./multi-mesh-demo.sh $LICENSE_KEY
Resource Requirements:
- This demo has been tested on 1x
n2-standard-4
(gke),m5.xlarge
(aws), orStandard_DS3_v2
(azure) instance formgmt
cluster - This demo has been tested on 2x
n2-standard-4
(gke),m5.xlarge
(aws), orStandard_DS3_v2
(azure) instances forcluster1
andcluster2
Note:
- If a license key is not provided, the script will prompt for a valid Gloo Mesh license key
- By default, the script expects to deploy into three clusters named
mgmt
,cluster1
, andcluster2
. This is configurable by changing the variables in themulti-mesh-demo.sh
. A check is done to ensure that the defined contexts exist before proceeding with the installation.
If you would like to run through the Gloo Edge + Gloo Portal single cluster demo end-to-end, you can do so by running the script
./portal-edge-demo.sh $LICENSE_KEY
Resource Requirements:
- This demo has been tested on 1x
n2-standard-4
(gke),m5.xlarge
(aws), orStandard_DS3_v2
(azure) instances
Note:
- If a license key is not provided, the script will prompt for a valid Gloo Edge license key
- The script assumes the current context as the one to be used for deploy. Use
kubectl config use-context <context>
to switch to the proper cluster that you desire - If there is no current-context defined, the script will exit.
Known Issues:
- Currently keycloak oauth redirects will not work properly on a local deployment (i.e. k3d + MetalLB) if there is not a properly accessible
EXTERNAL-IP
(i.e. non-private, non-localhost). Current recommended approach is to run on GKE/EKS to leverage the LoadBalancer integration there
Gloo Edge + Portal Youtube Demo
If you would like to run through the Gloo Edge single cluster demo end-to-end, you can do so by running the script
./edge-demo.sh $LICENSE_KEY
Resource Requirements:
- This demo has been tested on 1x
n2-standard-4
(gke),m5.xlarge
(aws), orStandard_DS3_v2
(azure) instances
Note:
- If a license key is not provided, the script will prompt for a valid Gloo Edge license key
- The script assumes the current context as the one to be used for deploy. Use
kubectl config use-context <context>
to switch to the proper cluster that you desire - If there is no current-context defined, the script will exit.
Known Issues:
- Currently keycloak oauth redirects will not work properly on a local deployment (i.e. k3d + MetalLB) if there is not a properly accessible
EXTERNAL-IP
(i.e. non-private, non-localhost). Current recommended approach is to run on GKE/EKS to leverage the LoadBalancer integration there
Interested in contributing an example configuration to gitops-library? Take a look at the example walkthrough in the CONTRIBUTING.md
for more details on structure and workflow