Local Stack streamlines the deployment of a multi-node Kubernetes cluster for local dev and testing, and utilizes OLM and ArgoCD to offer a fast, easy, and repeatable process for deploying operators and apps.
- File Structure
- Getting Started
- Prerequisites
- Installing
- How-to
- Fork the local-stack repository
- Connect to the ArgoCD console
- Modify the version of the operators in the deployment
- Create additional applications/deployments
- Cleanup
.
├── argocd
│ ├── applications
│ │ └── application.yaml
│ └── deployments
│ └── deployment
│ └── values.yaml
├── olm
│ ├── crds.yaml
│ └── olm.yaml
├── terraform
│ ├── main.tf
│ └── versions.tf
└── README.md
-
argocd: This folder contains the configuration files for the ArgoCD deployment.
- applications: This folder contains the application.yaml file that defines the application deployment in ArgoCD.
- deployments: This folder contains the deployment folder which in turn contains the values.yaml file that sets the values for the deployment.
-
olm: This folder contains the configuration files for the Operator Lifecycle Manager (OLM).
- crds.yaml: This file contains the Custom Resource Definitions for the OLM.
- olm.yaml: This file contains the configuration for the OLM deployment.
-
terraform: This folder contains the Terraform configuration files for the deployment.
- main.tf: This is the main Terraform configuration file that includes the provider and module configurations.
- versions.tf: This file sets the version constraints for Terraform modules.
- Ensure that you have all the prerequisites installed on your system
- Clone the repository and navigate to the
terraform/
folder - Run Terraform commands (e.g.
terraform init
,terraform plan
, andterraform apply
) to deploy the infrastructure - Verify the deployment by accessing the Argo CD and OLM applications
- Use the
argocd/applications/application.yaml
andargocd/deployments/deployment/values.yaml
files to configure the Argo CD application deployment - Clean up the infrastructure using Terraform commands when necessary.
- Docker installed on your local machine
- Terraform installed on your local machine
- kubectl installed on your local machine
Recommended resources on Docker
- 6 CPUs
- 24GB memory
- 1GB Swap
- Limit disk to 64GB
- Clone the repository
git clone https://github.com/martijngonlag/local-stack.git
- Change into the root of the project
cd local-stack
- Change into the
terraform/
folder and runterraform init
,plan
, andapply
If no changes were made to the repository, then the default setup will deploy a total of 25 resources. They are deployed in the following order:
- Multi-node Kubernetes cluster
- OLM
- ArgoCD
- StreamNative Operators
- Pulsar
In order to utilize ArgoCD (e.g. auto-deploy changes commited to a repository), you need to fork local-stack.
- Navigate to martijngonlag/local-stack
- In the top-right corner of the page, click Fork
- Select an owner for the forked repository
- Optional: Change the name of the fork to distinguish it
- Optional: Add a description of the fork
- Choose whether to copy only the default or all branches to your fork
- Click Create fork
- Clone the forked repository
git clone https://github.com/YOUR-USERNAME/YOUR-FORKED-REPO-NAME
Once you've cloned the forked repository, make sure to update the repoURL
field to the forked repository URL, which can be found in the following files:
argocd/application.yaml
argocd/applications/pulsar.yaml
&argocd/applications/sn-platform.yaml
In order to connect to ArgoCD, follow these steps:
- Run the following command to forward the service port:
kubectl port-forward service/argocd-server 8443:443 -n argocd
- Retrieve the initial admin password using the following command:
kubectl get secret argocd-initial-admin-secret -n argocd --template={{.data.password}} | base64 -D
- Open a web browser and navigate to https://localhost:8443
- Log in using the default username admin and the password obtained in step 2.
You should now be able to access the ArgoCD web interface.
To modify the version of the operators in the deployment, follow these steps, and then re-create the environment. If you have forked this repository, simply commit the changes to your forked repository and ArgoCD should automatically pick them up.
- Open the file
deployments/sn-platform/pulsar-operator.yaml
- Modify the subscription to reflect the desired operator version (change from
stable
)
To modify the version of Pulsar, follow these steps, and then re-create the environment. If you have forked this repository, simply commit the changes to your forked repository and ArgoCD should automatically pick them up.
- Open the respective YAML file in the
deployments/pulsar/
directory for the component you want to modify (bookkeeper, pulsar, pulsar-proxy, or zookeeper). - Modify the desired version of Pulsar in the respective YAML file.
By default, Local Stack deploys the StreamNative Operators and Apache Pulsar. However, the project can easily be adapted to deploy other services. Note that these steps assume you've forked the Local Stack repository.
- Create a copy of
argocd/applications/pulsar.yaml
and name it after your application (e.g.nginx.yaml
), then open it in your favorite text editor and modify the following fields:- Under
metadata
edit thename
field to your application - Under
source
edit thepath
field to your application - Under
source
edit therepoURL
field to your GitHub
- Under
- Create a new folder in
argocd/deployments/
named after your application (e.g.argocd/deployments/nginx/
), and place your deploymentyaml
inside this folder (e.g.argocd/deployments/nginx/nginx.yaml
). Go here for an example of an Nginx deployment. - Run
git add <files>
andgit commit -m "Added nginx as an applicaton to ArgoCD"
.
So long as ArgoCD is already up and running, it should automatically pick up any changes to the repository and deploy shortly after. Otherwise, ArgoCD will automatically
To clean up everything, you can run terraform destroy
in the terraform/
folder. The terraform destroy
command is used to destroy the resources created by Terraform. It will prompt you to confirm the resources that will be destroyed, and after confirming, it will remove all resources created in the current working directory. Note that this action is irreversible and should be used with caution. Before destroying, ensure that you have saved any important information related to the resources being destroyed, and that you understand the consequences of this action.