Questions when migrating from Certificate to Agent

Infrastructure as Code & Cloud Native
1

So we’re currently using AutoDevops and we have 2x clusters defined in the Group (top level):

  • CI (GKE Staging account) - Env Scope: *
  • Production (GKE Production account) - Env Scope: *production*

I don’t see any mention of environments scopes… how are we meant to re-create the above setup using agents? There appears to be no mention of it at all.

In the help documentation, it recommended that we create a separate “cluster-management” so we placed it at: /our-group/devops/cluster-management and defined an Agent and installed it inside the CI Cluster.

When I go to one of my projects kubernetes tab: /our-group/platform it says that there’s no agent installed… do I need to install an agent for every single project? I don’t see any mention in the docs about group clusters either.

So I googled around a bit and saw something about authorising access to my projects, so I added this:

ci_access:
  projects:
    - id: our-group/platform

But realised that it still said I had no agents.

Also on that note… I really wish YAML would just be dropped for JSON with JSON Schema so I could just browse the possible configuration options without having to crawl through a bible of documentation. I had originally placed ci_access: under gitops: and got no validation or errors whatsoever… just that nothing happened. If it was JSON Schema I could have at least seen where it goes and had it validated inline.

I’ve looked at migrating to Agents a few times and everytime I just have no idea what I’m doing at all.

1 Like
2

This is merely a “me too” post - I’m in a very similar situation as the OP. Watching the thread now, hoping to get some insight on how the feature is supposed to work/be configured.

3

I had some time to play around, and from what I gathered (I think it’s doing what I expect now) you simply need to:

  • install/activate the KAS server component in GitLab
  • connect an agent to/with one project, and install the agent to the cluster
  • configure the agent via a config.yaml in the aforementioned project to allow other projects or groups to access it
  • use kubectl config use-context path/to/the:agent in every job, maybe in the before_script part, that needs to deploy something to a specific cluster

Depending on which context you choose (use-context) in the job you get deployments to your staging or production cluster. So where the environment formerly was magically selected via the Env Scope you now need to explicitly select the context beforehand.

You will not see the agent in all the projects that you allow in the config.yaml, but you sure are able to just use it. Just try it by running a job in your /our-group/platform project looking something like this:

agent-based-clusters:
  image: bitnami/kubectl
  stage: test
  before_script:
    - kubectl config get-contexts