argocd-autopilot
Helm-Chart-Boilerplates
Our great sponsors
argocd-autopilot | Helm-Chart-Boilerplates | |
---|---|---|
22 | 12 | |
840 | 8 | |
3.5% | - | |
7.8 | 0.0 | |
7 days ago | over 1 year ago | |
Go | Makefile | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
argocd-autopilot
- Setup Argocd-Autopilot from scratch
-
Is there a better way?
# get the nodes in the cluster data "proxmox_virtual_environment_nodes" "proxmox_nodes" {} # VM Definition resource "proxmox_virtual_environment_vm" "example" { count = var.vm_count name = count.index + 1 <= var.vm_masters ? "${var.vm_name}-master-${format("%02d", count.index + 1)}" : "${var.vm_name}-worker-${format("%02d", count.index - (var.vm_masters - 1))}" node_name = data.proxmox_virtual_environment_nodes.proxmox_nodes.names[count.index % length(data.proxmox_virtual_environment_nodes.proxmox_nodes.names)] vm_id = count.index + 1 <= var.vm_masters ? var.vm_proxmox_id + count.index : var.vm_proxmox_id + count.index + (var.vm_proxmox_id_offset - var.vm_masters) tags = sort(concat(var.vm_proxmox_tags, [count.index + 1 <= var.vm_masters ? "master" : "worker"] )) agent { enabled = true trim = true } cpu { sockets = var.vm_sockets cores = var.vm_cores } memory { dedicated = count.index + 1 <= var.vm_masters ? var.vm_mem_master : var.vm_mem_worker } disk { interface = "scsi0" datastore_id = var.clone_target_local ? var.clone_target_datastore_local : var.clone_target_datastore_nfs ssd = true size = count.index + 1 <= var.vm_masters ? var.vm_disk_size_master : var.vm_disk_size_worker iothread = true discard = "on" } network_device { model = "virtio" mac_address = count.index + 1 <= var.vm_masters ? "${var.net_mac_address_base}AA:${format("%02d", count.index)}" : "${var.net_mac_address_base}BB:${format("%02d", count.index - var.vm_masters)}" # vlan_id = var.net_vlan_id # Not needed since using dedicated interface bridge = var.net_bridge } serial_device {} # clone information clone { vm_id = var.clone_target_local ? var.clone_vm_id + (count.index % var.vm_masters) : var.clone_vm_id datastore_id = var.clone_target_local ? var.clone_target_datastore_local : var.clone_target_datastore_nfs node_name = var.clone_target_local ? data.proxmox_virtual_environment_nodes.proxmox_nodes.names[count.index % length(data.proxmox_virtual_environment_nodes.proxmox_nodes.names)]: data.proxmox_virtual_environment_nodes.proxmox_nodes.names[0] } # had to add a wait for agent to come alive provisioner "remote-exec" { inline = [ "sudo cloud-init status --wait", "sudo systemctl start qemu-guest-agent", ] connection { type = "ssh" agent = false port = 22 host = element(element(self.ipv4_addresses, index(self.network_interface_names, "eth0")), 0) private_key = file(var.public_key_path) user = var.vm_username } } } # Create file for ansible inventory resource "local_file" "k3s_file" { content = templatefile( "${path.module}/templates/inventory_ansible.tftpl", { ansible_masters = "${join("\n", [for vm in slice(proxmox_virtual_environment_vm.example, 0, var.vm_masters) : join("", [vm.ipv4_addresses[1][0] ])])}" ansible_nodes = "${join("\n", [for vm in slice(proxmox_virtual_environment_vm.example, var.vm_masters , var.vm_count) : join("", [vm.ipv4_addresses[1][0] ])])}" } ) filename = "${path.module}/../ansible-k3s/inventory/k3s-cluster/hosts.ini" } #connecting to the Ansible control node and call ansible playbook to build the k3s cluster resource "null_resource" "call-ansible" { provisioner "local-exec" { command = "ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook ${path.module}/../ansible-k3s/site.yml -i ${path.module}/../ansible-k3s/inventory/k3s-cluster/hosts.ini" } depends_on = [ local_file.k3s_file ] } #Copy the kubectl file locally so we can issue commands against the cluster resource "null_resource" "copy-kubeconfig" { provisioner "local-exec" { command = "scp -o 'StrictHostKeyChecking no' seb@${proxmox_virtual_environment_vm.example[0].ipv4_addresses[1][0]}:~/.kube/config ~/.kube/config " } depends_on = [ null_resource.call-ansible ] } #bootstrap the cluster with argocd-autopilot resource "null_resource" "argocd-autopilot" { provisioner "local-exec" { command = ( var.first_install ? "argocd-autopilot repo bootstrap --repo ${var.github_repo} -t ${var.github_token} --app https://github.com/argoproj-labs/argocd-autopilot/manifests/ha" : "argocd-autopilot repo bootstrap --recover --app ${var.github_repo}.git/bootstrap/argo-cd" ) } depends_on = [ null_resource.copy-kubeconfig ] }
- Setting up ArgoCD from scratch
-
Declarative GitOps for...my ArgoCD itself?
I use Argo CD Autopilot which bootstraps Argo CD in a self-managing structure. If nothing else, copy the repo structure https://github.com/argoproj-labs/argocd-autopilot
-
How to Install and Upgrade Argo CD
We use the same approach internally and we fully open-sourced our solution at https://argocd-autopilot.readthedocs.io/en/stable/
- Argocd kustomize repository structure
-
Argo CD for Beginners 🐙
I recommend utilising Autopilot a companion project that not only installs Argo CD but also commits all configurations to git so Argo CD can maintain itself using GitOps.
-
ArgoCD installation
Check https://argocd-autopilot.readthedocs.io/en/stable/ It is an installer that does exactly that. It installs ArgoCD, sets it up to manage itself and offers a suggested bootstrap for your applications
-
How to set up a repo of repos for argo gitops?
Checkout the ArgoCD autopilot if you're using kustomize rather than helm
- Suggestion for Gitlab pipelines with ArgoCD
Helm-Chart-Boilerplates
-
Dedpulication standards of Helm Charts values file for a global chart with subcharts for our app. What's the right way to only need to specify a value once?
I would point you to what I call the "Universal Helm Charts" and some examples of how to use them.
-
Monitoring many cluster k8s
Shameless Plug: Here's one of my dashboards I made for Ingress-Nginx, which is my recommended border router/gateway into all the services. It adds deep robust metrics and configurability, and if you've got years of experience with Nginx also, it allows you rich complex customization via nginx's configuration structure via kubernetes annotations. Besides that I have open-source helm charts which are easy to use, boilerplates showing how to use them, a volume autoscaler to automatically resize your disks as they get full, and a blog where I share various of my experience which is a companion blog to my upcoming book of the same name. Hope this helps! Feel free to ask if you have any further questions.
-
Best way of managing Helm?
Here is an example of a repo that uses an sub-chart: https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-apache-with-configmap-template/deployment
-
Helm makes it overly complex, or is it just me?
Use multi-values files with helm ALWAYS. Allowing an env-specific overlay to tweak your default values files. See: https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-echoserver/deployment/boilerplate-echoserver
-
The Helmet is a Helm Library Chart that defines many chart templates like Deployment, Service, Ingress, etc which can used in other application charts.
Helm charts - https://github.com/DevOps-Nirvana/Universal-Kubernetes-Helm-Charts Example using helm charts as sub charts - https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-echoserver
- How do you guys manage your deployment pipelines?
-
Monthly 'Shameless Self Promotion' thread - 2023/01
Helm Chart Boilerplates are examples of usage of the above Universal Helm Charts to help people understand how to use them more, a stop-gap until I add more documentation
- Deploying with Helm - extra manifests?
-
Creating Kubernetes Templates
Helm Chart Usage Boilerplates (Examples of using these helm chart)
-
Use Kubernetes to load test my product.
To help you on deploying your service, I've created open source generic/universal Helm Charts to make it easy to do the above. Here are the Universal Helm Charts and here's some boilerplate examples of using them. These built-in have support for HPAs, services, ingresses, etc, making it as easy as autoscaling.enable: true I haven't gotten around to documenting the helm charts yet, but there's lots of comments in the values.yaml file explaining everything.
What are some alternatives?
argocd-example-apps - Example Apps to Demonstrate Argo CD
Universal-Kubernetes-Helm-Charts - Some universal helm charts used for deploying services onto Kubernetes. All-in-one best-practices
argo-cd - Declarative Continuous Deployment for Kubernetes
helm-charts - A collection of Helm charts
argocd-image-updater - Automatic container image update for Argo CD
helmfile - Declaratively deploy your Kubernetes manifests, Kustomize configs, and Charts as Helm releases. Generate all-in-one manifests for use with ArgoCD.
website - 🌐 Source code for OpenGitOps website
Kubernetes-Volume-Autoscaler - Autoscaling volumes for Kubernetes (with the help of Prometheus)
HomeBrew - 🍺 The missing package manager for macOS (or Linux)
eksctl - The official CLI for Amazon EKS
gitops-workloads-demo - Demonstrate how Argo ApplicationSets work
featbit - A feature flags service written in .NET