gitops-bridge-dev / gitops-bridge Goto Github PK

View Code? Open in Web Editor NEW

220.0 220.0 66.0 734 KB

License: Apache License 2.0

Shell 5.25% HCL 92.03% TypeScript 2.72%

gitops-bridge's People

Contributors

Stargazers

Watchers

gitops-bridge's Issues

[Discussion] EKS Pod Identity

I'll start with a controversial statement - Since EKS Pod Identity has been launched at re:invent 2023 the value add for creating IRSA roles, passing those IAM roles through to ArgoCD and down into ServiceAccount annotations seems to have diminished.

Is this a fair read on the situation? It's removed the chicken and egg situation I once faced and why I assumed this repository came to exist in the first place.

Open to thoughts on the matter and hopefully start some discourse as someone who has adopted the patterns in this repository and found them to be the only way to make IRSA truly usable in my organisation - but my eyes are on the future and simplification where possible.

rename example hello-world to getting-started

refactor metadata for gitops_bridge_url

make it shorter names
add base path metadata

Feature: Flux Terraform

Add FluxCD Terraform examples

Question about this pattern and ordered application set

Hi @csantanapr, thanks a lot for this org -- I'm trying out the gitops bridge pattern for bootstrapping Kubeflow (see tf module, and fork of your control plane.

I can see that this stuff is quite bleeding edge so I'm trying to find practical workarounds in places.

One of the first issues I've noticed is that I'd like these applicationsets to sync in order (i.e. so that istio webhook works before we try creating pods in the mesh). If sync waves doesn't work reliably I may enforce dependencies with terraform instead.

Are you aware of any inherent argo limitations here? or do you have any other pointers to those interested in feeding terraform outputs into K8s systems in this way?

Thanks again!

edit:

Another thing I've been wondering is: What is the benefit of passing cluster variables to argo via the cluster secret, as opposed to having some helm-based App of Apps, where cluster variables can be passed to child apps via helm values?

Hub-spoke example extended to cross account access between accounts

Context: https://github.com/gitops-bridge-dev/gitops-bridge/tree/main/argocd/iac/terraform/examples/eks/multi-cluster/hub-spoke

Thanks for updating the multi-cluster examples to include EKS Pod Association, it's been a great simplification and improvement.

I'm currently working me way trying to bend this example into a cross account example internally for a tech demo, where as OIDC was little more forgiving cross account due to not needing to do Role Chaining.

This is less a request more an issue to track if anyone else is doing this and to open up some discussion on implementation details, perhaps with a hope to contributing an example back to this repository.

cert-manager didn't provision for the hello-world example

Presumed this line enable_cert_manager = true would direct ArgoCD to install cert-manager, just like this line enable_metrics_server = true would install metrics-server via ArgoCD.

Not sure if this is a bug, the cert-manager didn't get provision but the metrics-server did. Wonder after assigning the merged addons to the metadata, how does ArgoCD knows which addon to install from the repo?

move terraform bridge modules to separate git repos

helm_release and kubernetes_secret_v1 always update in-place

Hey all,

First, thank you for the work on this module, it's been really helpful and the examples are very useful too.

I wanted to ask for some help on an issue that i'm running into. I'm currently following the AWS example, which leverages gitops-bridge to provide the metadata between TF and argo. What i'm noticing is that no matter what I do, the helm_release for argo and the kubernetes secret consistently want to update every single time I run TF apply. Here's the exact message:

  # module.eks_cluster.module.gitops_bridge_bootstrap.helm_release.argocd[0] will be updated in-place
  ~ resource "helm_release" "argocd" {
        id                         = "argo-cd"
      ~ metadata                   = [
          - {
              - app_version = "v2.8.2"
              - chart       = "argo-cd"
              - name        = "argo-cd"
              - namespace   = "argocd"
              - revision    = 6
              - values      = jsonencode(
                    {
                      - configs = {
                          - secret = {
                              - argocdServerAdminPassword = "(sensitive value)"
                            }
                        }
                      - server  = {
                          - service = {
                              - type = "LoadBalancer"
                            }
                        }
                    }
                )
              - version     = "5.45.0"
            },
        ] -> (known after apply)
        name                       = "argo-cd"
        # (28 unchanged attributes hidden)

      - set_sensitive {
          # At least one attribute in this block is (or was) sensitive,
          # so its contents will not be displayed.
        }

        # (1 unchanged block hidden)
    }

  # module.eks_cluster.module.gitops_bridge_bootstrap.kubernetes_secret_v1.cluster[0] will be updated in-place
  ~ resource "kubernetes_secret_v1" "cluster" {
        id                             = "argocd/eks-blueprints-green"
        # (4 unchanged attributes hidden)

      ~ metadata {
          ~ annotations      = {
              - "addons_repo_basepath"                         = "argocd/"
              - "addons_repo_path"                             = "argocd/bootstrap/control-plane/addons"
              - "addons_repo_revision"                         = "HEAD"
              - "addons_repo_url"                              = "[email protected]:aws-samples/eks-blueprints-add-ons"
              - "argocd_password"                              = (sensitive value)
              - "argocd_route53_weight"                        = "0"
              - "aws_account_id"                               = "xxxxx"
              - "aws_cloudwatch_metrics_iam_role_arn"          = "arn:aws:iam::xxxxx:role/aws-cloudwatch-metrics-20231107191852092600000027"
              - "aws_cloudwatch_metrics_namespace"             = "amazon-cloudwatch"
              - "aws_cloudwatch_metrics_service_account"       = "aws-cloudwatch-metrics"
              - "aws_cluster_name"                             = "eks-blueprints-green"
              - "aws_for_fluentbit_iam_role_arn"               = "arn:aws:iam::xxxxxxx:role/aws-for-fluent-bit-20231107191852093100000029"
              - "aws_for_fluentbit_log_group_name"             = "/aws/eks/eks-blueprints-green/aws-fluentbit-logs-20231107191821378800000019"
              - "aws_for_fluentbit_namespace"                  = "kube-system"
              - "aws_for_fluentbit_service_account"            = "aws-for-fluent-bit-sa"
              - "aws_load_balancer_controller_iam_role_arn"    = "arn:aws:iam::xxxxxxxx:role/alb-controller-20231107191852090300000024"
              - "aws_load_balancer_controller_namespace"       = "kube-system"
              - "aws_load_balancer_controller_service_account" = "aws-lb-sa"
              - "aws_region"                                   = "us-east-1"
              - "aws_secret_manager_git_private_ssh_key_name"  = "github-blueprint-ssh-key"
              - "aws_vpc_id"                                   = "vpc-0c98bdd52eb907def"
              - "cert_manager_iam_role_arn"                    = "arn:aws:iam::xxxxxxx:role/cert-manager-20231107191852092600000026"
              - "cert_manager_namespace"                       = "cert-manager"
              - "cert_manager_service_account"                 = "cert-manager"
              - "cluster_autoscaler_iam_role_arn"              = "arn:aws:iam::xxxxxxx:role/cluster-autoscaler-20231107204205450400000001"
              - "cluster_autoscaler_namespace"                 = "kube-system"
              - "cluster_autoscaler_service_account"           = "cluster-autoscaler-sa"
              - "cluster_endpoint"                             = "https://xxxxxxxxx.gr7.us-east-1.eks.amazonaws.com"
              - "cluster_name"                                 = "eks-blueprints-green"
              - "ecsfrontend_route53_weight"                   = "0"
              - "eks_cluster_domain"                           = "eks-blueprints.xxxxxxxxx"
              - "env"                                          = "green"
              - "environment"                                  = "eks-blueprints"
              - "external_dns_iam_role_arn"                    = "arn:aws:iam::XXXXX:role/external-dns-20231107191852090600000025"
              - "external_dns_namespace"                       = "external-dns"
              - "external_dns_policy"                          = "sync"
              - "external_dns_service_account"                 = "external-dns-sa"
              - "external_secrets_iam_role_arn"                = "arn:aws:iam::XXXXXX:role/external-secrets-20231107191852089100000023"
              - "external_secrets_namespace"                   = "external-secrets"
              - "external_secrets_service_account"             = "external-secrets-sa"
              - "gitops_workloads_path"                        = "envs/dev"
              - "gitops_workloads_revision"                    = "main"
              - "gitops_workloads_url"                         = "[email protected]:aws-samples/eks-blueprints-workloads"
              - "ingress_type"                                 = "alb"
              - "route53_weight"                               = "0"
            } -> (known after apply)
            name             = "eks-blueprints-green"
            # (5 unchanged attributes hidden)
        }
    }

Plan: 0 to add, 2 to change, 0 to destroy.

Changes to Outputs:
  ~ gitops_metadata   = (sensitive value)

Is there a way to avoid this consistently changing?

add example ack

add example login with github app using dex

Add akuity support

Update argocd-ingress example to work with new argocd helm 6.x

Depends on gitops-bridge-dev/gitops-bridge-argocd-control-plane-template#41

Community Chat?

Hey stumbled on this project when handling the brutal EKS Blueprints 4.x to 5.x migration, just wondered if you had a slack/discord etc for community chat on the concepts proposed and demonstrated here?

It's a fantastic resource so thank you!

Merge metadata into bootstrap module

Update all examples to use a single module
Reference gitops-bridge-dev/gitops-bridge-argocd-bootstrap-terraform#7

add example argocd login with aws cognito

karpenter pattern

Create pattern running karpenter

Maybe try to see if we can run controllers on fargate/serverless (ie coredns, argocd, alb, karpenter)

question: where the crds should be? on addons or workloads

e.g. for karpanter, where provisioners or node templates should be at addons or workloads?
in workloads, implement is simple i think but how or possible to be in addons?

Using gitops-bridge for multiple clusters

Hello,

First of all, congratulations for your talk in Kubecon Chicago, I was there and it was amazing.

I tested gitops-bridge-dev and it works with a new cluster when I installing a new argocd, but I cannot (or I didn't know) how can I use this project to apply in a cluster pointing to a centralized argocd?. Is it possible?

For example, I already have a production argocd (https://myargocd.mydomain) and I want to boostrap a cluster and addons, but not bootstrapping new argocd, just not pointing to in-cluster, but to my centralized argocd.. Can i have this option?

Thanks!

gitops-bridge-dev / gitops-bridge Goto Github PK

gitops-bridge's People

Contributors

Stargazers

Watchers

Forkers

gitops-bridge's Issues

Recommend Projects

Recommend Topics

Recommend Org