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
- user copies the one liner with all the values pre-filled
- user pastes the one liner (ideally piping straight to
kubectl apply -f --
) - 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.