argocd-autopilot
terraform-aws-eks-blueprints
argocd-autopilot | terraform-aws-eks-blueprints | |
---|---|---|
22 | 39 | |
843 | 2,509 | |
2.4% | 2.9% | |
7.6 | 9.1 | |
9 days ago | 5 days ago | |
Go | HCL | |
Apache License 2.0 | 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
terraform-aws-eks-blueprints
-
I am afraid to spin up an EKS instance using AWS provider
Have you checked out this repo https://github.com/aws-ia/terraform-aws-eks-blueprints
-
Deploy Secure Spring Boot Microservices on Amazon EKS Using Terraform and Kubernetes
Now that you have the networking part done, you can build configurations for the EKS cluster and its add-ons. You will use the terraform-aws-modules to create the EKS cluster and eks_blueprints module from terraform-aws-eks-blueprintsto configure EKS add-ons.
-
Enabling GPU Nodes for PyTorch Workloads on EKS with Autoscaling
## (https://github.com/aws-ia/terraform-aws-eks-blueprints) ## ... [other Terraform code] ## Cluster Configuration module "eks" { # ... [other configuration] self_managed_node_groups = { gpu_node_group = { node_group_name = "gpu-node-group" ami_type = "AL2_x86_64_GPU" capacity_type = "ON_DEMAND" instance_types = [ "g4dn.xlarge", "g4dn.2xlarge", ] # ... [other configuration] taints = { dedicated = { key = "nvidia.com/gpu" value = "true" effect = "NO_SCHEDULE" } } # ... [other configuration] } } }
- Why is there no consistency in the EKS examples.
-
Is there any advantage to running Karpenter and CordDNS in Fargate?
Here is the link: https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/karpenter/main.tf
- Need suggestions for managing eks terraform module
-
What's everyone's favorite EKS Terraform module these days?
Anyone using eks blueprints or cloudposse's module?
- How are most EKS clusters deployed?
-
Ideal setup for EKS deployment?
Take a look at the EKS Blueprints for Terraform as a place to start. I know the team is working on their v5 release which should be a solid improvement. https://github.com/aws-ia/terraform-aws-eks-blueprints/milestone/1
-
How do you initially upload your docker image to an ECR
Take a look at the EKS Blueprints for Terraform v5 rewrite for more details. However, EKS Blueprints for Terraform (v4 as it is today) is pretty darn good _if_ you just want to manage basic charst like load balancer controller and Karpenter. It provisions IAM Roles and Policies along with Helm charts all in one easy set-up. It's just not something I'd want to touch with more complex use cases and we'll see how the EKS Blueprints team does with the v5 rewrite - their direction looks reasonable, but Terraform just isn't really designed for the problem it's trying to solve there, so it's going to be somewhat clunky one way or another.
What are some alternatives?
argocd-example-apps - Example Apps to Demonstrate Argo CD
terraform-aws-eks - Terraform module to create AWS Elastic Kubernetes (EKS) resources πΊπ¦
argo-cd - Declarative Continuous Deployment for Kubernetes
cdk-eks-blueprints - AWS Quick Start Team
argocd-image-updater - Automatic container image update for Argo CD
eksctl - The official CLI for Amazon EKS
Helm-Chart-Boilerplates - Example implementations of the universal helm charts
terraform-aws-ecs-container-definition - Terraform module to generate well-formed JSON documents (container definitions) that are passed to the aws_ecs_task_definition Terraform resource
website - π Source code for OpenGitOps website
terraform-aws-eks-cloudwatch-logs - Terraform module for deploying AWS Fluent Bit as a daemonSet to send logs to CloudWatch Logs aws-for-fluent-bit inside a pre-existing EKS cluster.
HomeBrew - πΊ The missing package manager for macOS (or Linux)
terraform-aws-eks-cluster - Terraform module for provisioning an EKS cluster