Skip to content

Provide a 1-liner setup for `agentk`

Release notes

Integrating your Kubernetes cluster with GitLab provides many benefits from flawless deployments to insights into pod logs. Until now, setting up these integrations required multiple steps going through multiple UIs and services. Using the GitLab Kubernetes Agent, we've made the setup process a few clicks and a 1-liner command that users can apply directly in their clusters. Try it out now!

Problem to solve

As a Platform Engineer, I want to be able to use some sort of command-like tool to easily install the most update, or specific versions, of agentk in my cloud, without having to always recur to the GitLab documentation to copy/paste that whole manifest.yaml. I should be able to also completely configure this package to my needs.

As a Gitlab's Software Engineer in Test, I want to install agentk during my E2E tests without having to duplicate the agentk install manifest from the docs, so we have a SSOT and the QA copy of the manifest doesn't get drifted.

Intended users

User experience goal

The user should be able to easily install the agent with just a couple command lines.

Proposal

The agent token creation flow should result in a view showing a 1-liner that can be applied directly in a cluster.

  • user navigates to the agent list page and registers a new agent OR
  • user navigates to agent token page and creates a token, THEN
  1. user copies the one liner with all the values pre-filled
  2. user pastes the one liner (ideally piping straight to kubectl apply -f --)
  3. the agent gets installed, and if the user is still on any related screen in GitLab (such as the page they copied the on-liner from), then they get live feedback that the connection is now active

The one liner is the final kubernetes manifest that can be applied directly with kubectl apply. See #292935 (comment 496558163)

We can ship the following lists in multiple iterations.

The 1-liner should

  • use the official kpt/kustomize based package,
  • take as input arguments
    • agent token
    • kas-address
    • namespace (optional)
  • output a kubernetes manifest yaml that creates the necessary secret and deploys the agent

The 1-liner should

  • accept
    • a personal access token
    • a gitlab agent configuration endpoint
    • kas-address
    • namespace (optional)
  • register the agent, create a token, and output a kubernetes manifest yaml that creates the necessary secret and deploys the agent

The 1-liner could

  • output the final, customized kpt project to be submitted to version control

The 1-liner may

  • support a committed configuration as code version
  • support kpt package update gitlab-agent --strategy resource-merge

Further details

We expect to have:

  • Easier maintainability of docs
  • Easier maintainability of tests
  • Better user experience when installing agentk

Permissions and Security

Documentation

Change the current docs to prefer this method. Leave the current install methods as advanced or step by step installation instructions.

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Viktor Nagy (GitLab)