diff options
Diffstat (limited to 'doc/user/clusters/agent/ci_cd_workflow.md')
| -rw-r--r-- | doc/user/clusters/agent/ci_cd_workflow.md | 55 |
1 files changed, 30 insertions, 25 deletions
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md index 7a3c09687a5..454be3c53c7 100644 --- a/doc/user/clusters/agent/ci_cd_workflow.md +++ b/doc/user/clusters/agent/ci_cd_workflow.md @@ -58,7 +58,8 @@ Authorization configuration can take one or two minutes to propagate. ### Authorize the agent to access your projects -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327850) in GitLab 14.4. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327850) in GitLab 14.4. +> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/346566) to remove hierarchy restrictions in GitLab 15.6. To authorize the agent to access the GitLab project where you keep Kubernetes manifests: @@ -72,7 +73,7 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma - id: path/to/project ``` - - The Kubernetes projects must be in the same group hierarchy as the project where the agent's configuration is. + - Authorized projects must have the same root group as the agent's configuration project. - You can install additional agents into the same cluster to accommodate additional hierarchies. - You can authorize up to 100 projects. @@ -81,7 +82,8 @@ Choose the context to run `kubectl` commands from your CI/CD scripts. ### Authorize the agent to access projects in your groups -> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3. +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3. +> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/346566) to remove hierarchy restrictions in GitLab 15.6. To authorize the agent to access all of the GitLab projects in a group or subgroup: @@ -95,7 +97,7 @@ To authorize the agent to access all of the GitLab projects in a group or subgro - id: path/to/group/subgroup ``` - - The Kubernetes projects must be in the same group hierarchy as the project where the agent's configuration is. + - Authorized groups must have the same root group as the agent's configuration project. - You can install additional agents into the same cluster to accommodate additional hierarchies. - All of the subgroups of an authorized group also have access to the same agent (without being specified individually). - You can authorize up to 100 groups. @@ -125,6 +127,30 @@ deploy: If you are not sure what your agent's context is, open a terminal and connect to your cluster. Run `kubectl config get-contexts`. +### Environments that use Auto DevOps + +If Auto DevOps is enabled, you must define the CI/CD variable `KUBE_CONTEXT`. +Set the value of `KUBE_CONTEXT` to the context of the agent you want Auto DevOps to use: + +```yaml +deploy: + variables: + KUBE_CONTEXT: <path_to_agent_config_repository>:<agent_name> +``` + +You can assign different agents to separate Auto DevOps jobs. For instance, +Auto DevOps can use one agent for `staging` jobs, and another agent for `production` jobs. +To use multiple agents, define an [environment-scoped CI/CD variable](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) +for each agent. For example: + +1. Define two variables named `KUBE_CONTEXT`. +1. For the first variable: + 1. Set the `environment` to `staging`. + 1. Set the value to the context of your staging agent. +1. For the second variable: + 1. Set the `environment` to `production`. + 1. Set the value to the context of your production agent. + ### Environments with both certificate-based and agent-based connections When you deploy to an environment that has both a @@ -156,20 +182,6 @@ deploy: # ... rest of your job configuration ``` -### Using the agent with Auto DevOps - -If Auto DevOps is enabled, you must define the `KUBE_CONTEXT` CI/CD variable. Set the value of `KUBE_CONTEXT` to the context of the agent you want to use in your Auto DevOps pipeline jobs (`<PATH_TO_AGENT_CONFIG_REPOSITORY>:<AGENT_NAME>`). - -You can also use different agents for different Auto DevOps jobs. For instance, you can use one agent for `staging` jobs and a different agent for `production` jobs. To use multiple agents, define a unique CI/CD variable for each agent. - -For example: - -1. Add two [environment-scoped CI/CD variables](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) and name both `KUBE_CONTEXT`. -1. Set the `environment` of the first variable to `staging`. Set the value of the variable to `<PATH_TO_AGENT_CONFIGURATION_PROJECT>:<STAGING_AGENT_NAME>`. -1. Set the `environment` of the second variable to `production`. Set the value of the variable to `<PATH_TO_AGENT_CONFIGURATION_PROJECT>:<PRODUCTION_AGENT_NAME>`. - -When the `staging` job runs, it will connect to the cluster via the agent named `<STAGING_AGENT_NAME>`, and when the `production` job runs it will connect to the cluster via the agent named `<PRODUCTION_AGENT_NAME>`. - ## Restrict project and group access by using impersonation **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345014) in GitLab 14.5. @@ -281,13 +293,6 @@ See the [official Kubernetes documentation for details](https://kubernetes.io/do ## Troubleshooting -### `kubectl` commands not supported - -The commands `kubectl exec`, `kubectl cp`, `kubectl attach`, `kubectl run --attach=true` and `kubectl port-forward` are not supported. -Anything that uses these API endpoints does not work, because they use the deprecated -SPDY protocol. -[An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/346248) to add support for these commands. - ### Grant write permissions to `~/.kube/cache` Tools like `kubectl`, Helm, `kpt`, and `kustomize` cache information about |