Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
f6115a0f2c
commit
85e524e496
|
|
@ -13,4 +13,6 @@ Use the following resources to find the appropriate labels:
|
|||
- https://about.gitlab.com/handbook/product/categories/features/
|
||||
-->
|
||||
|
||||
/label ~"type::feature" ~feature::addition ~"group::" ~"section::" ~"Category:" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"
|
||||
/label ~"group::" ~"section::" ~"Category::"
|
||||
/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
|
||||
/label ~"type::feature" ~"feature::addition" ~documentation
|
||||
|
|
|
|||
|
|
@ -52,4 +52,7 @@ Use the following resources to find the appropriate labels:
|
|||
- https://about.gitlab.com/handbook/product/categories/features/
|
||||
-->
|
||||
|
||||
/label ~"type::feature" ~"group::" ~"section::" ~"Category::" ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate" ~documentation ~direction
|
||||
/label ~"type::feature"
|
||||
/label ~"group::" ~"section::" ~"Category::"
|
||||
/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
|
||||
/label ~documentation ~direction
|
||||
|
|
|
|||
|
|
@ -118,6 +118,6 @@ Use the following resources to find the appropriate labels:
|
|||
- https://gitlab.com/gitlab-org/gitlab/-/labels
|
||||
- https://about.gitlab.com/handbook/product/categories/features/
|
||||
-->
|
||||
/label ~devops:: ~group: ~Category:
|
||||
/label ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
|
||||
/label ~"group::" ~"section::" ~"Category::"
|
||||
/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
|
||||
/label ~"type::feature" ~documentation ~direction
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
<script>
|
||||
import { GlBadge, GlTab, GlTabs } from '@gitlab/ui';
|
||||
import { s__ } from '~/locale';
|
||||
import { __, s__ } from '~/locale';
|
||||
import environmentAppQuery from '../graphql/queries/environment_app.query.graphql';
|
||||
import pollIntervalQuery from '../graphql/queries/poll_interval.query.graphql';
|
||||
import EnvironmentFolder from './new_environment_folder.vue';
|
||||
|
|
@ -17,6 +17,11 @@ export default {
|
|||
apollo: {
|
||||
environmentApp: {
|
||||
query: environmentAppQuery,
|
||||
variables() {
|
||||
return {
|
||||
scope: this.scope,
|
||||
};
|
||||
},
|
||||
pollInterval() {
|
||||
return this.interval;
|
||||
},
|
||||
|
|
@ -29,10 +34,13 @@ export default {
|
|||
i18n: {
|
||||
newEnvironmentButtonLabel: s__('Environments|New environment'),
|
||||
reviewAppButtonLabel: s__('Environments|Enable review app'),
|
||||
available: __('Available'),
|
||||
stopped: __('Stopped'),
|
||||
},
|
||||
modalId: 'enable-review-app-info',
|
||||
data() {
|
||||
return { interval: undefined, isReviewAppModalVisible: false };
|
||||
const scope = new URLSearchParams(window.location.search).get('scope') || 'available';
|
||||
return { interval: undefined, scope, isReviewAppModalVisible: false };
|
||||
},
|
||||
computed: {
|
||||
canSetupReviewApp() {
|
||||
|
|
@ -71,11 +79,25 @@ export default {
|
|||
},
|
||||
};
|
||||
},
|
||||
stoppedCount() {
|
||||
return this.environmentApp?.stoppedCount;
|
||||
},
|
||||
},
|
||||
methods: {
|
||||
showReviewAppModal() {
|
||||
this.isReviewAppModalVisible = true;
|
||||
},
|
||||
setScope(scope) {
|
||||
this.scope = scope;
|
||||
this.$apollo.queries.environmentApp.stopPolling();
|
||||
this.$nextTick(() => {
|
||||
if (this.interval) {
|
||||
this.$apollo.queries.environmentApp.startPolling(this.interval);
|
||||
} else {
|
||||
this.$apollo.queries.environmentApp.refetch({ scope });
|
||||
}
|
||||
});
|
||||
},
|
||||
},
|
||||
};
|
||||
</script>
|
||||
|
|
@ -90,22 +112,32 @@ export default {
|
|||
<gl-tabs
|
||||
:action-secondary="addEnvironment"
|
||||
:action-primary="openReviewAppModal"
|
||||
sync-active-tab-with-query-params
|
||||
query-param-name="scope"
|
||||
@primary="showReviewAppModal"
|
||||
>
|
||||
<gl-tab>
|
||||
<gl-tab query-param-value="available" @click="setScope('available')">
|
||||
<template #title>
|
||||
<span>{{ __('Available') }}</span>
|
||||
<span>{{ $options.i18n.available }}</span>
|
||||
<gl-badge size="sm" class="gl-tab-counter-badge">
|
||||
{{ availableCount }}
|
||||
</gl-badge>
|
||||
</template>
|
||||
<environment-folder
|
||||
v-for="folder in folders"
|
||||
:key="folder.name"
|
||||
class="gl-mb-3"
|
||||
:nested-environment="folder"
|
||||
/>
|
||||
</gl-tab>
|
||||
<gl-tab query-param-value="stopped" @click="setScope('stopped')">
|
||||
<template #title>
|
||||
<span>{{ $options.i18n.stopped }}</span>
|
||||
<gl-badge size="sm" class="gl-tab-counter-badge">
|
||||
{{ stoppedCount }}
|
||||
</gl-badge>
|
||||
</template>
|
||||
</gl-tab>
|
||||
</gl-tabs>
|
||||
<environment-folder
|
||||
v-for="folder in folders"
|
||||
:key="folder.name"
|
||||
class="gl-mb-3"
|
||||
:nested-environment="folder"
|
||||
/>
|
||||
</div>
|
||||
</template>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
query getEnvironmentApp {
|
||||
environmentApp @client {
|
||||
query getEnvironmentApp($scope: String) {
|
||||
environmentApp(scope: $scope) @client {
|
||||
availableCount
|
||||
stoppedCount
|
||||
environments
|
||||
reviewApp
|
||||
stoppedCount
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ const mapEnvironment = (env) => ({
|
|||
|
||||
export const resolvers = (endpoint) => ({
|
||||
Query: {
|
||||
environmentApp(_context, _variables, { cache }) {
|
||||
return axios.get(endpoint, { params: { nested: true } }).then((res) => {
|
||||
environmentApp(_context, { scope }, { cache }) {
|
||||
return axios.get(endpoint, { params: { nested: true, scope } }).then((res) => {
|
||||
const interval = res.headers['poll-interval'];
|
||||
|
||||
if (interval) {
|
||||
cache.writeQuery({ query: pollIntervalQuery, data: { interval } });
|
||||
cache.writeQuery({ query: pollIntervalQuery, data: { interval: parseFloat(interval) } });
|
||||
} else {
|
||||
cache.writeQuery({ query: pollIntervalQuery, data: { interval: undefined } });
|
||||
}
|
||||
|
|
|
|||
|
|
@ -142,7 +142,14 @@ export default {
|
|||
return !this.$options.rolloutPercentageRegex.test(percentage);
|
||||
}),
|
||||
onFormStrategyChange(strategy, index) {
|
||||
const currentUserListId = this.filteredStrategies[index]?.userList?.id;
|
||||
const newUserListId = strategy?.userList?.id;
|
||||
|
||||
Object.assign(this.filteredStrategies[index], strategy);
|
||||
|
||||
if (currentUserListId !== newUserListId) {
|
||||
this.formStrategies = [...this.formStrategies];
|
||||
}
|
||||
},
|
||||
},
|
||||
};
|
||||
|
|
|
|||
|
|
@ -4,15 +4,15 @@ group: Configure
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Install the Kubernetes Agent Server (KAS) **(FREE SELF)**
|
||||
# Install the GitLab Agent Server (KAS) **(FREE SELF)**
|
||||
|
||||
> [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
|
||||
|
||||
The Kubernetes Agent Server (KAS) is a GitLab backend service dedicated to
|
||||
managing [Kubernetes Agents](../../user/clusters/agent/index.md).
|
||||
The GitLab Agent Server (KAS) is a GitLab backend service dedicated to
|
||||
managing the [GitLab Agent](../../user/clusters/agent/index.md).
|
||||
|
||||
The KAS is already installed and available in GitLab.com under `wss://kas.gitlab.com`.
|
||||
See [how to use GitLab.com's KAS](../../user/clusters/agent/install/index.md#set-up-the-kubernetes-agent-server).
|
||||
See [how to use GitLab.com's KAS](../../user/clusters/agent/install/index.md#set-up-the-agent-server).
|
||||
This document describes how to install a KAS for GitLab self-managed instances.
|
||||
|
||||
## Installation options
|
||||
|
|
@ -29,7 +29,7 @@ You can also opt to use an [external KAS](#use-an-external-kas-installation).
|
|||
|
||||
For [Omnibus](https://docs.gitlab.com/omnibus/) package installations:
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` to enable the Kubernetes Agent Server:
|
||||
1. Edit `/etc/gitlab/gitlab.rb` to enable the Agent Server:
|
||||
|
||||
```ruby
|
||||
gitlab_kas['enable'] = true
|
||||
|
|
|
|||
|
|
@ -1057,9 +1057,9 @@ For Omnibus GitLab installations, GitLab Monitor logs are in `/var/log/gitlab/gi
|
|||
|
||||
For Omnibus GitLab installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/`.
|
||||
|
||||
## GitLab Kubernetes Agent Server
|
||||
## GitLab Agent Server
|
||||
|
||||
For Omnibus GitLab installations, GitLab Kubernetes Agent Server logs are
|
||||
For Omnibus GitLab installations, GitLab Agent Server logs are
|
||||
in `/var/log/gitlab/gitlab-kas/`.
|
||||
|
||||
## Praefect Logs
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ group: Global Search
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Troubleshooting Elasticsearch
|
||||
# Troubleshooting Elasticsearch **(PREMIUM SELF)**
|
||||
|
||||
To install and configure Elasticsearch, and for common and known issues,
|
||||
visit the [administrator documentation](../../integration/elasticsearch.md).
|
||||
|
|
|
|||
|
|
@ -470,12 +470,12 @@ Example of response
|
|||
}
|
||||
```
|
||||
|
||||
## Get Kubernetes Agents by `CI_JOB_TOKEN` **(PREMIUM)**
|
||||
## Get GitLab Agent by `CI_JOB_TOKEN` **(PREMIUM)**
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324269) in GitLab 13.11.
|
||||
|
||||
Retrieve the job that generated the `CI_JOB_TOKEN`, along with a list of allowed GitLab
|
||||
Kubernetes Agents.
|
||||
Retrieve the job that generated the `CI_JOB_TOKEN`, along with a list of allowed
|
||||
[agents](../user/clusters/agent/index.md).
|
||||
|
||||
```plaintext
|
||||
GET /job/allowed_agents
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: 'GitLab to Kubernetes communication'
|
|||
# GitLab to Kubernetes communication **(FREE)**
|
||||
|
||||
The goal of this document is to define how GitLab can communicate with Kubernetes
|
||||
and in-cluster services through the GitLab Kubernetes Agent.
|
||||
and in-cluster services through the GitLab Agent.
|
||||
|
||||
## Challenges
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ are stored on the GitLab side and this is yet another security concern for our c
|
|||
For more discussion on these issues, read
|
||||
[issue #212810](https://gitlab.com/gitlab-org/gitlab/-/issues/212810).
|
||||
|
||||
## GitLab Kubernetes Agent epic
|
||||
## GitLab Agent epic
|
||||
|
||||
To address these challenges and provide some new features, the Configure group
|
||||
is building an active in-cluster component that inverts the
|
||||
|
|
@ -62,12 +62,12 @@ The customer does not need to provide any credentials to GitLab, and
|
|||
is in full control of what permissions the agent has.
|
||||
|
||||
For more information, visit the
|
||||
[GitLab Kubernetes Agent repository](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) or
|
||||
[GitLab Agent repository](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) or
|
||||
[the epic](https://gitlab.com/groups/gitlab-org/-/epics/3329).
|
||||
|
||||
### Request routing
|
||||
|
||||
Agents connect to the server-side component called GitLab Kubernetes Agent Server
|
||||
Agents connect to the server-side component called GitLab Agent Server
|
||||
(`gitlab-kas`) and keep an open connection that waits for commands. The
|
||||
difficulty with the approach is in routing requests from GitLab to the correct agent.
|
||||
Each cluster may contain multiple logical agents, and each may be running as multiple
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ graph LR
|
|||
Geo -- TCP 22 --> SSH
|
||||
Geo -- TCP 5432 --> PostgreSQL
|
||||
Runner{{GitLab Runner}} -- TCP 443 --> HTTP
|
||||
K8sAgent{{GitLab Kubernetes Agent}} -- TCP 443 --> HTTP
|
||||
K8sAgent{{GitLab Agent}} -- TCP 443 --> HTTP
|
||||
|
||||
%% GitLab Application Suite
|
||||
subgraph GitLab
|
||||
|
|
@ -157,7 +157,7 @@ graph LR
|
|||
Puma["Puma (GitLab Rails)"]
|
||||
Puma <--> Registry
|
||||
GitLabWorkhorse[GitLab Workhorse] <--> Puma
|
||||
GitLabKas[GitLab Kubernetes Agent Server] --> GitLabWorkhorse
|
||||
GitLabKas[GitLab Agent Server] --> GitLabWorkhorse
|
||||
GitLabPages[GitLab Pages] --> GitLabWorkhorse
|
||||
Mailroom
|
||||
Sidekiq
|
||||
|
|
@ -349,7 +349,7 @@ Component statuses are linked to configuration documentation for each component.
|
|||
| [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE |
|
||||
| [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | ⚙ | ⚙ | ❌ | ❌ | ✅ | ❌ | ⚙ | EE Only |
|
||||
| [GitLab Pages](#gitlab-pages) | Hosts static websites | ⚙ | ⚙ | ❌ | ❌ | ✅ | ⚙ | ⚙ | CE & EE |
|
||||
| [GitLab Kubernetes Agent](#gitlab-kubernetes-agent) | Integrate Kubernetes clusters in a cloud-native way | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only |
|
||||
| [GitLab Agent](#gitlab-agent) | Integrate Kubernetes clusters in a cloud-native way | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only |
|
||||
| [GitLab self-monitoring: Alertmanager](#alertmanager) | Deduplicates, groups, and routes alerts from Prometheus | ⚙ | ⚙ | ✅ | ⚙ | ✅ | ❌ | ❌ | CE & EE |
|
||||
| [GitLab self-monitoring: Grafana](#grafana) | Metrics dashboard | ✅ | ✅ | ⚙ | ⤓ | ✅ | ❌ | ⚙ | CE & EE |
|
||||
| [GitLab self-monitoring: Jaeger](#jaeger) | View traces generated by the GitLab instance | ❌ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | CE & EE |
|
||||
|
|
@ -499,14 +499,14 @@ Geo is a premium feature built to help speed up the development of distributed t
|
|||
|
||||
GitLab Exporter is a process designed in house that allows us to export metrics about GitLab application internals to Prometheus. You can read more [in the project's README](https://gitlab.com/gitlab-org/gitlab-exporter).
|
||||
|
||||
#### GitLab Kubernetes Agent
|
||||
#### GitLab Agent
|
||||
|
||||
- [Project page](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent)
|
||||
- Configuration:
|
||||
- [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/kas/index.html)
|
||||
|
||||
[GitLab Kubernetes Agent](../user/clusters/agent/index.md) is an active in-cluster
|
||||
The [GitLab Agent](../user/clusters/agent/index.md) is an active in-cluster
|
||||
component for solving GitLab and Kubernetes integration tasks in a secure and
|
||||
cloud-native way.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,66 +4,44 @@ group: unassigned
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Documentation process
|
||||
# How to update GitLab documentation
|
||||
|
||||
The process for creating and maintaining GitLab product documentation allows
|
||||
anyone to contribute a merge request or create an issue for GitLab
|
||||
documentation.
|
||||
|
||||
Documentation updates relating to new features or feature enhancements must
|
||||
use the [feature workflow process](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change) described in the GitLab Handbook.
|
||||
|
||||
## Who updates the docs?
|
||||
|
||||
*Anyone* can contribute! You can create a merge request for documentation when:
|
||||
Anyone can contribute to the GitLab documentation! You can create a merge request for documentation when:
|
||||
|
||||
- You find errors or other room for improvement in existing documentation.
|
||||
- You have an idea for all-new documentation that would help a GitLab user or administrator to
|
||||
accomplish their work with GitLab.
|
||||
|
||||
## Documentation labels
|
||||
|
||||
Regardless of the type of issue or merge request, certain labels are required when documentation
|
||||
is added or updated. The following are added by the issue or merge request author:
|
||||
|
||||
- An appropriate [type label](../contributing/issue_workflow.md#type-labels).
|
||||
- The [stage label](../contributing/issue_workflow.md#stage-labels) and
|
||||
[group label](../contributing/issue_workflow.md#group-labels). For example, `~devops::create` and
|
||||
`~group::source code`.
|
||||
- The `~documentation` [specialization label](../contributing/issue_workflow.md#specialization-labels).
|
||||
|
||||
The following are also added by members of the Technical Writing team:
|
||||
|
||||
- A documentation [scoped label](../../user/project/labels.md#scoped-labels) with the
|
||||
`docs::` prefix. For example, `~docs::improvement`.
|
||||
- The `~Technical Writing` [team label](../contributing/issue_workflow.md#team-labels).
|
||||
|
||||
Documentation changes that are not associated with the release of a new or updated feature
|
||||
do not take the `~"type::feature"` label, but still need the `~documentation` label.
|
||||
|
||||
They may include:
|
||||
|
||||
- Documentation created or updated to improve accuracy, completeness, ease of use, or any reason
|
||||
other than a [feature change](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change).
|
||||
- Addressing gaps in existing documentation, or making improvements to existing documentation.
|
||||
- Work on special projects related to the documentation.
|
||||
If you are working on a feature or enhancement, use the
|
||||
[feature workflow process described in the GitLab Handbook](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change).
|
||||
|
||||
## How to update the docs
|
||||
|
||||
To update GitLab documentation:
|
||||
If you are not a GitLab team member, or do not have the Developer role for the GitLab repository, to update GitLab documentation:
|
||||
|
||||
1. Either:
|
||||
- Click the **Edit this Page** link at the bottom of any page on <https://docs.gitlab.com>.
|
||||
- Navigate to one of the repositories and documentation paths listed on the
|
||||
[GitLab Documentation guidelines](index.md) page.
|
||||
1. Follow the described standards and processes listed on the page, including:
|
||||
- The [Structure and template](structure.md) page.
|
||||
- The [Style Guide](styleguide/index.md).
|
||||
- The [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/).
|
||||
1. Follow the [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
|
||||
1. Select an issue you'd like to work on.
|
||||
- You don't need an issue to open a merge request.
|
||||
- For a Hackathon, in the issue, in a comment, mention the person who opened the issue and ask for the issue to be assigned to you.
|
||||
To be fair to other contributors, if you see someone has already asked to work on the issue, choose another issue.
|
||||
If you are looking for issues to work on and don't see any that suit you, you can always fix [Vale](testing.md#vale) issues.
|
||||
1. Go to the [GitLab repository](https://gitlab.com/gitlab-org/gitlab).
|
||||
1. In the top-right, select **Fork**. Forking makes a copy of the repository on GitLab.com.
|
||||
1. In your fork, find the documentation page by going to the `\doc` directory.
|
||||
1. If you know Git, make your changes and open a merge request.
|
||||
If not, follow these steps:
|
||||
1. In the top right, select **Edit**, make the changes, and **Save**.
|
||||
1. From the left menu, select **Merge requests**.
|
||||
1. For the source branch, select your fork and branch. If you did not create a branch, select `master`.
|
||||
For the target branch, select the [GitLab repository](https://gitlab.com/gitlab-org/gitlab) `master` branch.
|
||||
1. For the commit message, use 3-5 words, start with a capital letter, and do not end with a period.
|
||||
1. Select **Commit changes**. A merge request opens.
|
||||
1. Select the **Documentation** template. In the description, write a brief summary of the changes and link to the related issue, if there is one.
|
||||
|
||||
NOTE:
|
||||
Work in a fork if you do not have the Developer role in the GitLab project.
|
||||
If you need help while working on the page, view:
|
||||
|
||||
- The [Style Guide](styleguide/index.md).
|
||||
- The [Word list](styleguide/word_list.md)
|
||||
- The [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/).
|
||||
|
||||
### Ask for help
|
||||
|
||||
|
|
@ -83,6 +61,22 @@ To identify someone who can help you:
|
|||
|
||||
If you are a member of the GitLab Slack workspace, you can request help in `#docs`.
|
||||
|
||||
## Documentation labels
|
||||
|
||||
When you author an issue or merge request, you must add these labels:
|
||||
|
||||
- A [type label](../contributing/issue_workflow.md#type-labels).
|
||||
- A [stage label](../contributing/issue_workflow.md#stage-labels) and [group label](../contributing/issue_workflow.md#group-labels).
|
||||
For example, `~devops::create` and `~group::source code`.
|
||||
- A `~documentation` [specialization label](../contributing/issue_workflow.md#specialization-labels).
|
||||
|
||||
A member of the Technical Writing team adds these labels:
|
||||
|
||||
- A [documentation scoped label](../../user/project/labels.md#scoped-labels) with the
|
||||
`docs::` prefix. For example, `~docs::improvement`.
|
||||
- The [`~Technical Writing` team label](../contributing/issue_workflow.md#team-labels).
|
||||
- A type label: either `~"type::feature"` or `~"type::maintenance"`.
|
||||
|
||||
### Reviewing and merging
|
||||
|
||||
Anyone with the [Maintainer role](../../user/permissions.md) to the relevant GitLab project can
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ When implementing new features, please refer to these existing features to avoid
|
|||
- [Custom Dashboards](../operations/metrics/dashboards/index.md#add-a-new-dashboard-to-your-project): `.gitlab/dashboards/`.
|
||||
- [Issue Templates](../user/project/description_templates.md#create-an-issue-template): `.gitlab/issue_templates/`.
|
||||
- [Merge Request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
|
||||
- [GitLab Kubernetes Agents](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
|
||||
- [GitLab Agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
|
||||
- [CODEOWNERS](../user/project/code_owners.md#set-up-code-owners): `.gitlab/CODEOWNERS`.
|
||||
- [Route Maps](../ci/review_apps/#route-maps): `.gitlab/route-map.yml`.
|
||||
- [Customize Auto DevOps Helm Values](../topics/autodevops/customize.md#customize-values-for-helm-chart): `.gitlab/auto-deploy-values.yaml`.
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ if you need help finding the correct person or labels:
|
|||
| GitLab Compose Kit | [Issuer Tracker](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/issues) |
|
||||
| GitLab Container Registry | [Issue Tracker](https://gitlab.com/gitlab-org/container-registry) |
|
||||
| GitLab Elasticsearch Indexer | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer/-/issues) |
|
||||
| GitLab Kubernetes Agent (KAS) | [Issue Tracker](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues) |
|
||||
| GitLab Agent Server (KAS) | [Issue Tracker](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues) |
|
||||
| GitLab Pages | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-pages/-/issues) |
|
||||
| GitLab Quality Images | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-build-images/-/issues) |
|
||||
| GitLab Shell | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-shell/-/issues) |
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ file, and include the token Base64 encoded in a `secret_token` parameter
|
|||
or in the `Gitlab-Shared-Secret` header.
|
||||
|
||||
NOTE:
|
||||
The internal API used by GitLab Pages, and GitLab Kubernetes Agent Server (`kas`) uses JSON Web Token (JWT)
|
||||
The internal API used by GitLab Pages, and GitLab Agent Server (`kas`) uses JSON Web Token (JWT)
|
||||
authentication, which is different from GitLab Shell.
|
||||
|
||||
## Git Authentication
|
||||
|
|
@ -400,13 +400,13 @@ Example response:
|
|||
}
|
||||
```
|
||||
|
||||
## Kubernetes agent endpoints
|
||||
## GitLab Agent endpoints
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41045) in GitLab 13.4.
|
||||
> - This feature is not deployed on GitLab.com
|
||||
> - It's not recommended for production use.
|
||||
|
||||
The following endpoints are used by the GitLab Kubernetes Agent Server (`kas`)
|
||||
The following endpoints are used by the GitLab Agent Server (`kas`)
|
||||
for various purposes.
|
||||
|
||||
These endpoints are all authenticated using JWT. The JWT secret is stored in a file
|
||||
|
|
@ -414,11 +414,11 @@ specified in `config/gitlab.yml`. By default, the location is in the root of the
|
|||
GitLab Rails app in a file called `.gitlab_kas_secret`.
|
||||
|
||||
WARNING:
|
||||
The Kubernetes agent is under development and is not recommended for production use.
|
||||
The GitLab Agent is under development and is not recommended for production use.
|
||||
|
||||
### Kubernetes agent information
|
||||
### GitLab Agent information
|
||||
|
||||
Called from GitLab Kubernetes Agent Server (`kas`) to retrieve agent
|
||||
Called from GitLab Agent Server (`kas`) to retrieve agent
|
||||
information for the given agent token. This returns the Gitaly connection
|
||||
information for the agent's project in order for `kas` to fetch and update
|
||||
the agent's configuration.
|
||||
|
|
@ -434,9 +434,9 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" \
|
|||
--header "Authorization: Bearer <agent token>" "http://localhost:3000/api/v4/internal/kubernetes/agent_info"
|
||||
```
|
||||
|
||||
### Kubernetes agent project information
|
||||
### GitLab Agent project information
|
||||
|
||||
Called from GitLab Kubernetes Agent Server (`kas`) to retrieve project
|
||||
Called from GitLab Agent Server (`kas`) to retrieve project
|
||||
information for the given agent token. This returns the Gitaly
|
||||
connection for the requested project. GitLab `kas` uses this to configure
|
||||
the agent to fetch Kubernetes resources from the project repository to
|
||||
|
|
@ -460,9 +460,9 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" \
|
|||
--header "Authorization: Bearer <agent token>" "http://localhost:3000/api/v4/internal/kubernetes/project_info?id=7"
|
||||
```
|
||||
|
||||
### Kubernetes agent usage metrics
|
||||
### GitLab Agent usage metrics
|
||||
|
||||
Called from GitLab Kubernetes Agent Server (`kas`) to increase the usage
|
||||
Called from GitLab Agent Server (`kas`) to increase the usage
|
||||
metric counters.
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
|
|
@ -481,9 +481,9 @@ curl --request POST --header "Gitlab-Kas-Api-Request: <JWT token>" --header "Con
|
|||
--data '{"gitops_sync_count":1}' "http://localhost:3000/api/v4/internal/kubernetes/usage_metrics"
|
||||
```
|
||||
|
||||
### Kubernetes agent alert metrics
|
||||
### GitLab Agent alert metrics
|
||||
|
||||
Called from GitLab Kubernetes Agent Server (KAS) to save alerts derived from Cilium on Kubernetes
|
||||
Called from GitLab Agent Server (KAS) to save alerts derived from Cilium on Kubernetes
|
||||
Cluster.
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
|
|
@ -505,7 +505,7 @@ curl --request POST --header "Gitlab-Kas-Api-Request: <JWT token>" \
|
|||
|
||||
### Create Starboard vulnerability
|
||||
|
||||
Called from the GitLab Kubernetes Agent Server (`kas`) to create a security vulnerability
|
||||
Called from the GitLab Agent Server (`kas`) to create a security vulnerability
|
||||
from a Starboard vulnerability report. This request is idempotent. Multiple requests with the same data
|
||||
create a single vulnerability.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Some components (documented on the GitLab Operator doc) are not supported yet.
|
|||
|
||||
## Deploy to and integrate with OpenShift from GitLab
|
||||
|
||||
Deploying custom or COTS applications on top of OpenShift from GitLab is supported using [the GitLab Kubernetes Agent](../../user/clusters/agent/index.md).
|
||||
Deploying custom or COTS applications on top of OpenShift from GitLab is supported using [the GitLab Agent](../../user/clusters/agent/index.md).
|
||||
|
||||
## Use OpenShift to run a GitLab Runner Fleet
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Auto DevOps **(FREE)**
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38366) in GitLab 11.0.
|
||||
> - Support for the GitLab Kubernetes Agent was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299350) in GitLab 14.5.
|
||||
> - Support for the GitLab Agent was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299350) in GitLab 14.5.
|
||||
|
||||
GitLab Auto DevOps is a collection of pre-configured features and integrations
|
||||
that work together to support your software delivery process.
|
||||
|
|
|
|||
|
|
@ -635,7 +635,7 @@ ciliumNetworkPolicy:
|
|||
#### Enabling Alerts
|
||||
|
||||
You can also enable alerts. Network policies with alerts are considered only if
|
||||
[GitLab Kubernetes Agent](../../user/clusters/agent/index.md)
|
||||
[Agent](../../user/clusters/agent/index.md)
|
||||
has been integrated.
|
||||
|
||||
You can enable alerts as follows:
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ To integrate GitLab with security scanners other than those listed here, see
|
|||
You can use cluster image scanning through the following methods:
|
||||
|
||||
- [The cluster image scanning analyzer](#use-the-cluster-image-scanning-analyzer)
|
||||
- [The GitLab Kubernetes agent](#cluster-image-scanning-with-the-gitlab-kubernetes-agent)
|
||||
- [The GitLab Agent](#cluster-image-scanning-with-the-gitlab-agent)
|
||||
|
||||
## Use the cluster image scanning analyzer
|
||||
|
||||
|
|
@ -274,26 +274,22 @@ Here's an example cluster image scanning report:
|
|||
}
|
||||
```
|
||||
|
||||
## Cluster image scanning with the GitLab Kubernetes Agent
|
||||
## Cluster image scanning with the GitLab Agent
|
||||
|
||||
You can use the [GitLab Kubernetes Agent](../../clusters/agent/index.md) to
|
||||
You can use the [GitLab Agent](../../clusters/agent/index.md) to
|
||||
scan images from within your Kubernetes cluster and record the vulnerabilities in GitLab.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- [Starboard Operator](https://aquasecurity.github.io/starboard/v0.10.3/operator/installation/kubectl/)
|
||||
installed and configured in your cluster.
|
||||
- [GitLab Kubernetes Agent](../../clusters/agent/install/index.md)
|
||||
- [GitLab Agent](../../clusters/agent/install/index.md)
|
||||
set up in GitLab, installed in your cluster, and configured using a configuration repository.
|
||||
|
||||
### Configuration
|
||||
|
||||
The GitLab Kubernetes agent begins to run cluster image scanning once the `cluster_image_scanning`
|
||||
directive is added to your Kubernetes Agent configuration repository.
|
||||
|
||||
See the [Kubernetes agent configuration repository](../../clusters/agent/repository.md#scan-your-container-images-for-vulnerabilities)
|
||||
reference to learn more about the cluster image scanning configuration options for the
|
||||
GitLab Kubernetes agent.
|
||||
The Agent runs the cluster image scanning once the `cluster_image_scanning`
|
||||
directive is added to your [Agent's configuration repository](../../clusters/agent/repository.md#scan-your-container-images-for-vulnerabilities).
|
||||
|
||||
## Security Dashboard
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ at the bottom of the editor.
|
|||
You can use policy alerts to track your policy's impact. Alerts are only available if you've
|
||||
[installed](../../clusters/agent/repository.md)
|
||||
and [configured](../../clusters/agent/install/index.md#create-an-agent-record-in-gitlab)
|
||||
a Kubernetes Agent for this project.
|
||||
an agent for this project.
|
||||
|
||||
There are two ways to create policy alerts:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Only CI/CD jobs set in the configuration project can access one of the configure
|
|||
|
||||
## Prerequisites
|
||||
|
||||
- A running [`kas` instance](install/index.md#set-up-the-kubernetes-agent-server).
|
||||
- A running [`kas` instance](install/index.md#set-up-the-agent-server).
|
||||
- A [configuration repository](install/index.md#define-a-configuration-repository) with an Agent config file
|
||||
installed (`.gitlab/agents/<agent-name>/config.yaml`).
|
||||
- An [Agent record](install/index.md#create-an-agent-record-in-gitlab).
|
||||
|
|
|
|||
|
|
@ -4,15 +4,16 @@ group: Configure
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# GitLab Kubernetes Agent **(FREE)**
|
||||
# GitLab Agent for Kubernetes **(FREE)**
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223061) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
|
||||
> - Support for `grpcs` [introduced](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/7) in GitLab 13.6.
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) in GitLab 13.10, KAS became available on GitLab.com under `wss://kas.gitlab.com` through an Early Adopter Program.
|
||||
> - Introduced in GitLab 13.11, the GitLab Kubernetes Agent became available to every project on GitLab.com.
|
||||
> - The GitLab Kubernetes Agent was [moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
|
||||
> - Introduced in GitLab 13.11, the GitLab Agent became available to every project on GitLab.com.
|
||||
> - The GitLab Agent was [moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
|
||||
> - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab Agent for Kubernetes" in GitLab 14.6.
|
||||
|
||||
The [GitLab Kubernetes Agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) ("Agent", for short)
|
||||
The [GitLab Agent for Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) ("Agent", for short)
|
||||
is an active in-cluster component for connecting Kubernetes clusters to GitLab safely to support cloud-native deployment, management, and monitoring.
|
||||
|
||||
The Agent is installed into the cluster through code, providing you with a fast, safe, stable, and scalable solution.
|
||||
|
|
@ -38,7 +39,7 @@ the all-in-one DevOps platform for your product and your team.
|
|||
|
||||
## Agent's features
|
||||
|
||||
By using the GitLab Kubernetes Agent, you can:
|
||||
By using the Agent, you can:
|
||||
|
||||
- Connect GitLab with a Kubernetes cluster behind a firewall or a
|
||||
Network Address Translation (NAT).
|
||||
|
|
@ -53,7 +54,7 @@ from GitLab CI/CD jobs while keeping the cluster's APIs safe and unexposed
|
|||
to the internet.
|
||||
- [Deploy the GitLab Runner in a Kubernetes cluster](https://docs.gitlab.com/runner/install/kubernetes-agent.html).
|
||||
|
||||
See the [GitLab Kubernetes Agent roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329) to track its development.
|
||||
See the [Agent roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329) to track its development.
|
||||
|
||||
To contribute to the Agent, see the [Agent's development documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/doc).
|
||||
|
||||
|
|
@ -68,7 +69,7 @@ sequenceDiagram
|
|||
participant D as Developer
|
||||
participant A as Application code repository
|
||||
participant M as Manifest repository
|
||||
participant K as Kubernetes Agent
|
||||
participant K as GitLab Agent
|
||||
participant C as Agent configuration repository
|
||||
loop Regularly
|
||||
K-->>C: Grab the configuration
|
||||
|
|
@ -85,7 +86,7 @@ For more details, refer to our [architecture documentation](https://gitlab.com/g
|
|||
|
||||
## Install the Agent in your cluster
|
||||
|
||||
See how to [install the GitLab Kubernetes Agent in your cluster](install/index.md).
|
||||
See how to [install the Agent in your cluster](install/index.md).
|
||||
|
||||
## GitOps deployments **(PREMIUM)**
|
||||
|
||||
|
|
@ -133,7 +134,7 @@ with the following differences:
|
|||
- When you define a configuration repository, you must do so with [Cilium settings](repository.md#surface-network-security-alerts-from-cluster-to-gitlab).
|
||||
- You do not need to specify the `gitops` configuration section.
|
||||
|
||||
## Remove the GitLab Kubernetes Agent
|
||||
## Remove an agent
|
||||
|
||||
1. Get the `<cluster-agent-id>` and the `<cluster-agent-token-id>` from a query in the interactive GraphQL explorer.
|
||||
For GitLab.com, go to <https://gitlab.com/-/graphql-explorer> to open GraphQL Explorer.
|
||||
|
|
@ -183,7 +184,7 @@ For self-managed GitLab instances, go to `https://gitlab.example.com/-/graphql-e
|
|||
}
|
||||
```
|
||||
|
||||
1. Delete the GitLab Kubernetes Agent in your cluster:
|
||||
1. Delete the Agent in your cluster:
|
||||
|
||||
```shell
|
||||
kubectl delete -n gitlab-kubernetes-agent -f ./resources.yml
|
||||
|
|
@ -191,14 +192,14 @@ For self-managed GitLab instances, go to `https://gitlab.example.com/-/graphql-e
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
If you face any issues while using GitLab Kubernetes Agent, you can read the
|
||||
service logs with the following command
|
||||
If you face any issues while using the Agent, read the
|
||||
service logs with the following command:
|
||||
|
||||
```shell
|
||||
kubectl logs -f -l=app=gitlab-kubernetes-agent -n gitlab-kubernetes-agent
|
||||
```
|
||||
|
||||
GitLab administrators can additionally view the [Kubernetes Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
|
||||
GitLab administrators can additionally view the [GitLab Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
|
||||
|
||||
### Agent logs
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ group: Configure
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Install the GitLab Kubernetes Agent **(FREE)**
|
||||
# Install the GitLab Agent **(FREE)**
|
||||
|
||||
> [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
|
||||
|
||||
To get started with the GitLab Kubernetes Agent, install it in your cluster.
|
||||
To get started with the Agent, install it in your cluster.
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
|
|
@ -17,9 +17,9 @@ Pre-requisites:
|
|||
|
||||
## Installation steps
|
||||
|
||||
To install the [GitLab Kubernetes Agent](../index.md) in your cluster:
|
||||
To install the [Agent](../index.md) in your cluster:
|
||||
|
||||
1. [Set up the Kubernetes Agent Server](#set-up-the-kubernetes-agent-server) for your GitLab instance.
|
||||
1. [Set up the Agent Server](#set-up-the-agent-server) for your GitLab instance.
|
||||
1. [Define a configuration repository](#define-a-configuration-repository).
|
||||
1. [Create an Agent record in GitLab](#create-an-agent-record-in-gitlab).
|
||||
1. [Install the Agent into the cluster](#install-the-agent-into-the-cluster).
|
||||
|
|
@ -28,13 +28,13 @@ To install the [GitLab Kubernetes Agent](../index.md) in your cluster:
|
|||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a GitLab 14.2 [walking-through video](https://www.youtube.com/watch?v=XuBpKtsgGkE) with this process.
|
||||
|
||||
### Set up the Kubernetes Agent Server
|
||||
### Set up the Agent Server
|
||||
|
||||
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.10, the GitLab Kubernetes Agent Server (KAS) became available on GitLab.com under `wss://kas.gitlab.com`.
|
||||
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.10, the Agent Server (KAS) became available on GitLab.com under `wss://kas.gitlab.com`.
|
||||
|
||||
To use the KAS:
|
||||
|
||||
- If you are a self-managed user, follow the instructions to [install the Kubernetes Agent Server](../../../../administration/clusters/kas.md).
|
||||
- If you are a self-managed user, follow the instructions to [install the Agent Server](../../../../administration/clusters/kas.md).
|
||||
- If you are a GitLab.com user, when you [set up the configuration repository](#define-a-configuration-repository) for your agent, use `wss://kas.gitlab.com` as the `--kas-address`.
|
||||
|
||||
### Define a configuration repository
|
||||
|
|
@ -76,7 +76,7 @@ gitops:
|
|||
- glob: '/**/*.{yaml,yml,json}'
|
||||
```
|
||||
|
||||
All the options for the [Kubernetes Agent configuration repository](../repository.md) are documented separately.
|
||||
All the options for the [Agent configuration repository](../repository.md) are documented separately.
|
||||
|
||||
### Create an Agent record in GitLab
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ To perform a one-liner installation, run the command below. Make sure to replace
|
|||
|
||||
- `your-agent-token` with the token received from the previous step (identified as `secret` in the JSON output).
|
||||
- `gitlab-kubernetes-agent` with the namespace you defined in the previous step.
|
||||
- `wss://kas.gitlab.example.com` with the configured access of the Kubernetes Agent Server (KAS). For GitLab.com users, the KAS is available under `wss://kas.gitlab.com`.
|
||||
- `wss://kas.gitlab.example.com` with the configured access of the Agent Server (KAS). For GitLab.com users, the KAS is available under `wss://kas.gitlab.com`.
|
||||
- `--agent-version=vX.Y.Z` with the latest released patch version matching your GitLab installation's major and minor versions. For example, for GitLab v13.9.0, use `--agent-version=v13.9.1`. You can find your GitLab version under the "Help/Help" menu.
|
||||
|
||||
```shell
|
||||
|
|
@ -151,7 +151,7 @@ Kubernetes resources required for the Agent to be installed. You can modify this
|
|||
example [`resources.yml` file](#example-resourcesyml-file) in the following ways:
|
||||
|
||||
- Replace `namespace: gitlab-kubernetes-agent` with `namespace: <YOUR-DESIRED-NAMESPACE>`.
|
||||
- You can configure `kas-address` (Kubernetes Agent Server) in several ways.
|
||||
- You can configure `kas-address` (Agent Server) in several ways.
|
||||
The agent can use the WebSockets or gRPC protocols to connect to the Agent Server.
|
||||
Select the option appropriate for your cluster configuration and GitLab architecture:
|
||||
- The `wss` scheme (an encrypted WebSockets connection) is specified by default
|
||||
|
|
@ -334,7 +334,7 @@ data:
|
|||
|
||||
## Example projects
|
||||
|
||||
The following example projects can help you get started with the Kubernetes Agent.
|
||||
The following example projects can help you get started with the Agent.
|
||||
|
||||
- [Configuration repository](https://gitlab.com/gitlab-org/configure/examples/kubernetes-agent)
|
||||
- This basic GitOps example deploys NGINX: [Manifest repository](https://gitlab.com/gitlab-org/configure/examples/gitops-project)
|
||||
|
|
@ -342,18 +342,18 @@ The following example projects can help you get started with the Kubernetes Agen
|
|||
## View installed Agents
|
||||
|
||||
Users with at least the [Developer](../../../permissions.md) can access the user interface
|
||||
for the GitLab Kubernetes Agent at **Infrastructure > Kubernetes clusters**, under the
|
||||
for the Agent at **Infrastructure > Kubernetes clusters**, under the
|
||||
**Agent** tab. This page lists all registered agents for the current project,
|
||||
and the configuration directory for each agent:
|
||||
|
||||
|
||||
|
||||
|
||||
Additional management interfaces are planned for the GitLab Kubernetes Agent.
|
||||
Additional management interfaces are planned for the GitLab Agent.
|
||||
[Provide more feedback in the related epic](https://gitlab.com/groups/gitlab-org/-/epics/4739).
|
||||
|
||||
## Upgrades and version compatibility
|
||||
|
||||
The GitLab Kubernetes Agent is comprised of two major components: `agentk` and `kas`.
|
||||
The Agent is comprised of two major components: `agentk` and `kas`.
|
||||
As we provide `kas` installers built into the various GitLab installation methods, the required `kas` version corresponds to the GitLab `major.minor` (X.Y) versions.
|
||||
|
||||
At the same time, `agentk` and `kas` can differ by 1 minor version in either direction. For example,
|
||||
|
|
|
|||
|
|
@ -4,20 +4,20 @@ group: Configure
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
|
||||
---
|
||||
|
||||
# Kubernetes Agent configuration repository **(FREE)**
|
||||
# Agent configuration repository **(FREE)**
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.7.
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the Kubernetes Agent became available on GitLab.com.
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the GitLab Agent became available on GitLab.com.
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0, the `resource_inclusions` and `resource_exclusions` attributes were removed and `reconcile_timeout`, `dry_run_strategy`, `prune`, `prune_timeout`, `prune_propagation_policy`, and `inventory_policy` attributes were added.
|
||||
> - The `ci_access` attribute was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.
|
||||
> - The GitLab Kubernetes Agent was [moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
|
||||
> - The GitLab Agent was [moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
|
||||
|
||||
WARNING:
|
||||
This feature might not be available to you. Check the **version history** note above for details.
|
||||
|
||||
The [GitLab Kubernetes Agent integration](index.md) supports hosting your configuration for
|
||||
multiple GitLab Kubernetes Agents in a single repository. These agents can be running
|
||||
in the same cluster or in multiple clusters, and potentially with more than one Agent per cluster.
|
||||
The [GitLab Agent](index.md) supports hosting your configuration for
|
||||
multiple agents in a single repository. These agents can be running
|
||||
in the same cluster or in multiple clusters, and potentially with more than one agent per cluster.
|
||||
|
||||
The Agent bootstraps with the GitLab installation URL and an authentication token,
|
||||
and you provide the rest of the configuration in your repository, following
|
||||
|
|
@ -128,7 +128,7 @@ operations. If such functionality is needed, you may use multiple agents reading
|
|||
manifests from the same repository.
|
||||
|
||||
Ensure not to specify "overlapping" globs to avoid synchronizing the same files more than once.
|
||||
This is detected by the GitLab Kubernetes Agent and leads to an error.
|
||||
This is detected by the Agent and leads to an error.
|
||||
|
||||
INCORRECT - both globs match `*.yaml` files in the root directory:
|
||||
|
||||
|
|
@ -385,7 +385,7 @@ In this example, the following resources are scanned:
|
|||
|
||||
## Debugging
|
||||
|
||||
To debug the cluster-side component (`agentk`) of the GitLab Kubernetes Agent, set the log
|
||||
To debug the cluster-side component (`agentk`) of the Agent, set the log
|
||||
level according to the available options:
|
||||
|
||||
- `off`
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ to automate this step.
|
|||
|
||||
Prometheus and Elastic Stack cluster integrations can only be enabled for clusters [connected through cluster certificates](../project/clusters/add_existing_cluster.md).
|
||||
|
||||
To enable Prometheus for your cluster connected through the [GitLab Kubernetes Agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
|
||||
To enable Prometheus for your cluster connected through the [GitLab Agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
|
||||
|
||||
There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab Kubernetes Agent.
|
||||
There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab Agent.
|
||||
Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for updates.
|
||||
|
||||
## Prometheus cluster integration
|
||||
|
|
@ -44,7 +44,7 @@ Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for up
|
|||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. However, you can **still use** Prometheus
|
||||
for Kubernetes clusters connected to GitLab through the
|
||||
[GitLab Kubernetes Agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
|
||||
[Agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
|
||||
|
||||
You can integrate your Kubernetes cluster with
|
||||
[Prometheus](https://prometheus.io/) for monitoring key metrics of your
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
The cluster management project was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To manage cluster applications, use the [GitLab Kubernetes Agent](agent/index.md)
|
||||
To manage cluster applications, use the [GitLab Agent](agent/index.md)
|
||||
with the [Cluster Management Project Template](management_project_template.md).
|
||||
|
||||
A project can be designated as the management project for a cluster.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25318) in GitLab 12.10 with Helmfile support via Helm v2.
|
||||
> - Helm v2 support was [dropped](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63577) in GitLab 14.0. Use Helm v3 instead.
|
||||
> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab Kubernetes Agent in GitLab 14.5.
|
||||
> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab Agent in GitLab 14.5.
|
||||
|
||||
Use a repository to install, manage, and deploy clusters applications through code.
|
||||
|
||||
|
|
@ -31,10 +31,10 @@ you can manage cluster applications with [Helm v3](https://helm.sh/).
|
|||
- An `applications` directory with a `helmfile.yaml` configured for each
|
||||
application available in the template.
|
||||
|
||||
## Use the Kubernetes Agent with the Cluster Management Project Template
|
||||
## Use the Agent with the Cluster Management Project Template
|
||||
|
||||
To use a new project created from the Cluster Management Project Template
|
||||
with a cluster connected to GitLab through the [GitLab Kubernetes Agent](agent/index.md),
|
||||
with a cluster connected to GitLab through the [GitLab Agent](agent/index.md),
|
||||
you have two options:
|
||||
|
||||
- [Use one single project](#single-project) to configure the Agent and manage cluster applications.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
|
||||
use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
Similar to [project-level](../../project/clusters/index.md) and
|
||||
[instance-level](../../instance/clusters/index.md) Kubernetes clusters,
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
The [certificate-based Kubernetes integration with GitLab](../index.md)
|
||||
was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)
|
||||
in GitLab 14.5. To connect your clusters, use the [GitLab Kubernetes Agent](../../../clusters/agent/index.md).
|
||||
in GitLab 14.5. To connect your clusters, use the [GitLab Agent](../../../clusters/agent/index.md).
|
||||
|
||||
<!-- TBA: (We need to resolve https://gitlab.com/gitlab-org/gitlab/-/issues/343660 before adding this line)
|
||||
If you don't have a cluster yet, create one and connect it to GitLab through the Agent.
|
||||
|
|
|
|||
|
|
@ -9,10 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0.
|
||||
|
||||
An inventory object is a `ConfigMap` object for keeping track of the set of objects applied to a cluster.
|
||||
When you remove objects from a manifest repository, GitLab Kubernetes Agent uses a corresponding inventory object to
|
||||
When you remove objects from a manifest repository, the Agent uses a corresponding inventory object to
|
||||
prune (delete) objects from the cluster.
|
||||
|
||||
The GitLab Kubernetes Agent creates an inventory object for each manifest project specified in the
|
||||
The Agent creates an inventory object for each manifest project specified in the
|
||||
`gitops.manifest_projects` configuration section. The inventory object has to be stored somewhere in the cluster.
|
||||
The default behavior is:
|
||||
|
||||
|
|
@ -20,10 +20,10 @@ The default behavior is:
|
|||
explicitly, the inventory object is stored in the `default` namespace.
|
||||
- The `name` is generated from the numeric project ID of the manifest project and the numeric agent ID.
|
||||
|
||||
This way the GitLab Kubernetes Agent constructs the name and local where the inventory object is
|
||||
This way the Agent constructs the name and local where the inventory object is
|
||||
stored in the cluster.
|
||||
|
||||
The GitLab Kubernetes Agent cannot locate the existing inventory object if you:
|
||||
The Agent cannot locate the existing inventory object if you:
|
||||
|
||||
- Change `gitops.manifest_projects[].default_namespace` parameter.
|
||||
- Move manifests into another project.
|
||||
|
|
@ -57,13 +57,13 @@ metadata:
|
|||
|
||||
## Using GitOps with pre-existing Kubernetes objects
|
||||
|
||||
The GitLab Kubernetes Agent treats manifest files in the manifest repository as the source of truth. When it applies
|
||||
The Agent treats manifest files in the manifest repository as the source of truth. When it applies
|
||||
objects from the files to the cluster, it tracks them in an inventory object. If an object already exists,
|
||||
GitLab Kubernetes Agent behaves differently based on the `gitops.manifest_projects[].inventory_policy` configuration.
|
||||
The Agent behaves differently based on the `gitops.manifest_projects[].inventory_policy` configuration.
|
||||
Check the table below with the available options and when to use them.
|
||||
|
||||
`inventory_policy` value | Description |
|
||||
------------------------ | ------------------------------------------------------------------------------------------- |
|
||||
`must_match` | This is the default policy. A live object must have the `config.k8s.io/owning-inventory` annotation set to the same value as the `cli-utils.sigs.k8s.io/inventory-id` label on the corresponding inventory object to be updated. Object is not updated and an error is reported if the values don't match or the object doesn't have the annotation. |
|
||||
`adopt_if_no_inventory` | This mode allows to "adopt" an object if it doesn't have the `config.k8s.io/owning-inventory` annotation. Use this mode if you want to start managing existing objects using the GitOps feature. Once all objects have been "adopted", we recommend you to put the setting back into the default `must_match` mode to avoid any unexpected adoptions. |
|
||||
`adopt_all` | This mode allows to "adopt" an object even if it has the `config.k8s.io/owning-inventory` annotation set to a different value. This mode can be useful if you want to migrate a set of objects from one agent to another one or from some other tool to the GitLab Kubernetes Agent. Once all objects have been "adopted", we recommend you to put the setting back into the default `must_match` mode to avoid any unexpected adoptions. |
|
||||
`adopt_all` | This mode allows to "adopt" an object even if it has the `config.k8s.io/owning-inventory` annotation set to a different value. This mode can be useful if you want to migrate a set of objects from one agent to another one or from some other tool to the Agent. Once all objects have been "adopted", we recommend you to put the setting back into the default `must_match` mode to avoid any unexpected adoptions. |
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Kubernetes clusters **(FREE)**
|
||||
|
||||
To connect clusters to GitLab, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
To connect clusters to GitLab, use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
## Certificate-based Kubernetes integration (DEPRECATED)
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ It had the following issues:
|
|||
- Users were constantly reporting issues with features based on this model.
|
||||
|
||||
For this reason, we started to build features based on a new model, the
|
||||
[GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
[GitLab Agent](../../clusters/agent/index.md).
|
||||
Maintaining both methods in parallel caused a lot of confusion
|
||||
and significantly increased the complexity to use, develop, maintain, and
|
||||
document them. For this reason, we decided to deprecate them to focus on the
|
||||
|
|
@ -38,7 +38,7 @@ Follow this [epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)
|
|||
for updates.
|
||||
|
||||
You can find technical information about why we moved away from cluster certificates into
|
||||
the Kubernetes Agent model on the [Agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
|
||||
the GitLab Agent model on the [Agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
|
||||
|
||||
## Deprecated features
|
||||
|
||||
|
|
|
|||
|
|
@ -30,11 +30,11 @@ Learn more about how GitLab can help you run [Infrastructure as Code](iac/index.
|
|||
## Integrated Kubernetes management
|
||||
|
||||
The GitLab integration with Kubernetes helps you to install, configure, manage, deploy, and troubleshoot
|
||||
cluster applications. With the GitLab Kubernetes Agent, you can connect clusters behind a firewall,
|
||||
cluster applications. With the GitLab Agent, you can connect clusters behind a firewall,
|
||||
have real-time access to API endpoints, perform pull-based or push-based deployments for production
|
||||
and non-production environments, and much more.
|
||||
|
||||
Learn more about the [GitLab Kubernetes Agent](../clusters/agent/index.md).
|
||||
Learn more about the [GitLab Agent](../clusters/agent/index.md).
|
||||
|
||||
## Runbooks in GitLab
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
|
||||
use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
Similar to [project-level](../../project/clusters/index.md)
|
||||
and [group-level](../../group/clusters/index.md) Kubernetes clusters,
|
||||
|
|
|
|||
|
|
@ -89,6 +89,10 @@ You can authenticate using:
|
|||
- A [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `read_registry` and `write_registry`.
|
||||
- A [group deploy token](../../../user/project/deploy_tokens/index.md#group-deploy-token) with the scope set to `read_registry` and `write_registry`.
|
||||
|
||||
Users accessing the Dependency Proxy with a personal access token or username and password require
|
||||
at least [Guest membership](../../permissions.md#group-members-permissions)
|
||||
to the group they pull images from.
|
||||
|
||||
#### SAML SSO
|
||||
|
||||
When [SSO enforcement](../../group/saml_sso/index.md#sso-enforcement)
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Kubernetes Service (EKS).
|
|||
## Connect an existing EKS cluster
|
||||
|
||||
If you already have an EKS cluster and want to connect it to GitLab,
|
||||
use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
## Create a new EKS cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To connect your cluster to GitLab, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md)
|
||||
To connect your cluster to GitLab, use the [GitLab Agent](../../clusters/agent/index.md)
|
||||
instead.
|
||||
|
||||
If you have an existing Kubernetes cluster, you can add it to a project, group,
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ hosted on Google Kubernetes Engine (GKE).
|
|||
## Connect an existing GKE cluster
|
||||
|
||||
If you already have a GKE cluster and want to connect it to GitLab,
|
||||
use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
## Create a new GKE cluster from GitLab
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ supports connecting existing clusters using the certificate-based connection met
|
|||
|
||||
## Add existing cluster
|
||||
|
||||
As of GitLab 14.0, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md)
|
||||
As of GitLab 14.0, use the [GitLab Agent](../../clusters/agent/index.md)
|
||||
to connect your cluster to GitLab.
|
||||
|
||||
Alternatively, you can [add an existing cluster](add_existing_cluster.md)
|
||||
|
|
@ -57,7 +57,7 @@ through the certificate-based method, but we don't recommend using this method f
|
|||
|
||||
## Configure your cluster
|
||||
|
||||
As of GitLab 14.0, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md)
|
||||
As of GitLab 14.0, use the [GitLab Agent](../../clusters/agent/index.md)
|
||||
to configure your cluster.
|
||||
|
||||
## Disable a cluster
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To connect your cluster to GitLab, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md)
|
||||
To connect your cluster to GitLab, use the [GitLab Agent](../../clusters/agent/index.md)
|
||||
instead.
|
||||
|
||||
When creating a cluster in GitLab, you are asked if you would like to create either:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To connect your cluster to GitLab, use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
To connect your cluster to GitLab, use the [GitLab Agent](../../clusters/agent/index.md).
|
||||
To deploy with the Agent, use the [CI/CD Tunnel](../../clusters/agent/ci_cd_tunnel.md).
|
||||
|
||||
A Kubernetes cluster can be the destination for a deployment job. If
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To connect your cluster to GitLab, use the [GitLab Kubernetes Agent](../../../user/clusters/agent/index.md).
|
||||
To connect your cluster to GitLab, use the [GitLab Agent](../../../user/clusters/agent/index.md).
|
||||
To manage applications, use the [Cluster Project Management Template](../../../user/clusters/management_project_template.md).
|
||||
|
||||
You can choose to allow GitLab to manage your cluster for you. If your cluster
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)
|
||||
in GitLab 14.5. To connect clusters to GitLab, use the
|
||||
[GitLab Kubernetes Agent](../../clusters/agent/index.md).
|
||||
[GitLab Agent](../../clusters/agent/index.md).
|
||||
|
||||
[Project-level](../../infrastructure/clusters/connect/index.md#cluster-levels-deprecated) Kubernetes clusters
|
||||
allow you to connect a Kubernetes cluster to a project in GitLab.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
WARNING:
|
||||
Using multiple Kubernetes clusters for a single project **with cluster
|
||||
certificates** was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
|
||||
To connect clusters to GitLab, use the [GitLab Kubernetes Agent](../../../user/clusters/agent/index.md).
|
||||
To connect clusters to GitLab, use the [GitLab Agent](../../../user/clusters/agent/index.md).
|
||||
|
||||
You can associate more than one Kubernetes cluster to your
|
||||
project. That way you can have different clusters for different environments,
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
NOTE:
|
||||
In GitLab 14.5, using a certificate to connect GitLab to a Kubernetes cluster is [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
|
||||
You can continue using Container Host Security, even though it relies on this certificate-based
|
||||
method. The work to allow all aspects of Container Host Security to function through the [GitLab Kubernetes Agent](../../../../clusters/agent/index.md)
|
||||
method. The work to allow all aspects of Container Host Security to function through the [GitLab Agent](../../../../clusters/agent/index.md)
|
||||
instead of the certificate-based method can be tracked [in this GitLab issue](https://gitlab.com/gitlab-org/gitlab/-/issues/299350).
|
||||
|
||||
Container Host Security in GitLab provides Intrusion Detection and Prevention capabilities that can
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
NOTE:
|
||||
In GitLab 14.5, using a certificate to connect GitLab to a Kubernetes cluster is [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
|
||||
You can continue using Container Network Security, even though it relies on this certificate-based
|
||||
method. The work to allow all aspects of Container Network Security to function through the [GitLab Kubernetes Agent](../../../../clusters/agent/index.md)
|
||||
method. The work to allow all aspects of Container Network Security to function through the [GitLab Agent](../../../../clusters/agent/index.md)
|
||||
instead of the certificate-based method can be tracked [in this GitLab issue](https://gitlab.com/gitlab-org/gitlab/-/issues/299350) and [this GitLab Epic](https://gitlab.com/groups/gitlab-org/-/epics/7057).
|
||||
|
||||
Container Network Security in GitLab provides basic firewall functionality by leveraging Cilium
|
||||
|
|
|
|||
|
|
@ -23,9 +23,10 @@ describe('~/frontend/environments/graphql/resolvers', () => {
|
|||
describe('environmentApp', () => {
|
||||
it('should fetch environments and map them to frontend data', async () => {
|
||||
const cache = { writeQuery: jest.fn() };
|
||||
mock.onGet(ENDPOINT, { params: { nested: true } }).reply(200, environmentsApp, {});
|
||||
const scope = 'available';
|
||||
mock.onGet(ENDPOINT, { params: { nested: true, scope } }).reply(200, environmentsApp, {});
|
||||
|
||||
const app = await mockResolvers.Query.environmentApp(null, null, { cache });
|
||||
const app = await mockResolvers.Query.environmentApp(null, { scope }, { cache });
|
||||
expect(app).toEqual(resolvedEnvironmentsApp);
|
||||
expect(cache.writeQuery).toHaveBeenCalledWith({
|
||||
query: pollIntervalQuery,
|
||||
|
|
@ -34,11 +35,12 @@ describe('~/frontend/environments/graphql/resolvers', () => {
|
|||
});
|
||||
it('should set the poll interval when there is one', async () => {
|
||||
const cache = { writeQuery: jest.fn() };
|
||||
const scope = 'stopped';
|
||||
mock
|
||||
.onGet(ENDPOINT, { params: { nested: true } })
|
||||
.onGet(ENDPOINT, { params: { nested: true, scope } })
|
||||
.reply(200, environmentsApp, { 'poll-interval': 3000 });
|
||||
|
||||
await mockResolvers.Query.environmentApp(null, null, { cache });
|
||||
await mockResolvers.Query.environmentApp(null, { scope }, { cache });
|
||||
expect(cache.writeQuery).toHaveBeenCalledWith({
|
||||
query: pollIntervalQuery,
|
||||
data: { interval: 3000 },
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
import Vue from 'vue';
|
||||
import Vue, { nextTick } from 'vue';
|
||||
import VueApollo from 'vue-apollo';
|
||||
import { mountExtended } from 'helpers/vue_test_utils_helper';
|
||||
import createMockApollo from 'helpers/mock_apollo_helper';
|
||||
import waitForPromises from 'helpers/wait_for_promises';
|
||||
import { s__ } from '~/locale';
|
||||
import { __, s__ } from '~/locale';
|
||||
import EnvironmentsApp from '~/environments/components/new_environments_app.vue';
|
||||
import EnvironmentsFolder from '~/environments/components/new_environment_folder.vue';
|
||||
import { resolvedEnvironmentsApp, resolvedFolder } from './graphql/mock_data';
|
||||
|
|
@ -17,7 +17,10 @@ describe('~/environments/components/new_environments_app.vue', () => {
|
|||
|
||||
const createApolloProvider = () => {
|
||||
const mockResolvers = {
|
||||
Query: { environmentApp: environmentAppMock, folder: environmentFolderMock },
|
||||
Query: {
|
||||
environmentApp: environmentAppMock,
|
||||
folder: environmentFolderMock,
|
||||
},
|
||||
};
|
||||
|
||||
return createMockApollo([], mockResolvers);
|
||||
|
|
@ -34,6 +37,16 @@ describe('~/environments/components/new_environments_app.vue', () => {
|
|||
apolloProvider,
|
||||
});
|
||||
|
||||
const createWrapperWithMocked = async ({ provide = {}, environmentsApp, folder }) => {
|
||||
environmentAppMock.mockReturnValue(environmentsApp);
|
||||
environmentFolderMock.mockReturnValue(folder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({ apolloProvider, provide });
|
||||
|
||||
await waitForPromises();
|
||||
await nextTick();
|
||||
};
|
||||
|
||||
beforeEach(() => {
|
||||
environmentAppMock = jest.fn();
|
||||
environmentFolderMock = jest.fn();
|
||||
|
|
@ -44,13 +57,10 @@ describe('~/environments/components/new_environments_app.vue', () => {
|
|||
});
|
||||
|
||||
it('should show all the folders that are fetched', async () => {
|
||||
environmentAppMock.mockReturnValue(resolvedEnvironmentsApp);
|
||||
environmentFolderMock.mockReturnValue(resolvedFolder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({ apolloProvider });
|
||||
|
||||
await waitForPromises();
|
||||
await Vue.nextTick();
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: resolvedEnvironmentsApp,
|
||||
folder: resolvedFolder,
|
||||
});
|
||||
|
||||
const text = wrapper.findAllComponents(EnvironmentsFolder).wrappers.map((w) => w.text());
|
||||
|
||||
|
|
@ -59,64 +69,91 @@ describe('~/environments/components/new_environments_app.vue', () => {
|
|||
});
|
||||
|
||||
it('should show a button to create a new environment', async () => {
|
||||
environmentAppMock.mockReturnValue(resolvedEnvironmentsApp);
|
||||
environmentFolderMock.mockReturnValue(resolvedFolder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({ apolloProvider });
|
||||
|
||||
await waitForPromises();
|
||||
await Vue.nextTick();
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: resolvedEnvironmentsApp,
|
||||
folder: resolvedFolder,
|
||||
});
|
||||
|
||||
const button = wrapper.findByRole('link', { name: s__('Environments|New environment') });
|
||||
expect(button.attributes('href')).toBe('/environments/new');
|
||||
});
|
||||
|
||||
it('should not show a button to create a new environment if the user has no permissions', async () => {
|
||||
environmentAppMock.mockReturnValue(resolvedEnvironmentsApp);
|
||||
environmentFolderMock.mockReturnValue(resolvedFolder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({
|
||||
apolloProvider,
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: resolvedEnvironmentsApp,
|
||||
folder: resolvedFolder,
|
||||
provide: { canCreateEnvironment: false, newEnvironmentPath: '' },
|
||||
});
|
||||
|
||||
await waitForPromises();
|
||||
await Vue.nextTick();
|
||||
|
||||
const button = wrapper.findByRole('link', { name: s__('Environments|New environment') });
|
||||
expect(button.exists()).toBe(false);
|
||||
});
|
||||
|
||||
it('should show a button to open the review app modal', async () => {
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: resolvedEnvironmentsApp,
|
||||
folder: resolvedFolder,
|
||||
});
|
||||
|
||||
const button = wrapper.findByRole('button', { name: s__('Environments|Enable review app') });
|
||||
button.trigger('click');
|
||||
|
||||
await nextTick();
|
||||
|
||||
expect(wrapper.findByText(s__('ReviewApp|Enable Review App')).exists()).toBe(true);
|
||||
});
|
||||
|
||||
it('should not show a button to open the review app modal if review apps are configured', async () => {
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: {
|
||||
...resolvedEnvironmentsApp,
|
||||
reviewApp: { canSetupReviewApp: false },
|
||||
},
|
||||
folder: resolvedFolder,
|
||||
});
|
||||
await waitForPromises();
|
||||
await nextTick();
|
||||
|
||||
const button = wrapper.findByRole('button', { name: s__('Environments|Enable review app') });
|
||||
expect(button.exists()).toBe(false);
|
||||
});
|
||||
|
||||
it('should show tabs for available and stopped environmets', async () => {
|
||||
await createWrapperWithMocked({
|
||||
environmentsApp: resolvedEnvironmentsApp,
|
||||
folder: resolvedFolder,
|
||||
});
|
||||
|
||||
const [available, stopped] = wrapper.findAllByRole('tab').wrappers;
|
||||
|
||||
expect(available.text()).toContain(__('Available'));
|
||||
expect(available.text()).toContain(resolvedEnvironmentsApp.availableCount);
|
||||
expect(stopped.text()).toContain(__('Stopped'));
|
||||
expect(stopped.text()).toContain(resolvedEnvironmentsApp.stoppedCount);
|
||||
});
|
||||
|
||||
it('should change the requested scope on tab change', async () => {
|
||||
environmentAppMock.mockReturnValue(resolvedEnvironmentsApp);
|
||||
environmentFolderMock.mockReturnValue(resolvedFolder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({ apolloProvider });
|
||||
|
||||
await waitForPromises();
|
||||
await Vue.nextTick();
|
||||
|
||||
const button = wrapper.findByRole('button', { name: s__('Environments|Enable review app') });
|
||||
button.trigger('click');
|
||||
|
||||
await Vue.nextTick();
|
||||
|
||||
expect(wrapper.findByText(s__('ReviewApp|Enable Review App')).exists()).toBe(true);
|
||||
});
|
||||
|
||||
it('should not show a button to open the review app modal if review apps are configured', async () => {
|
||||
environmentAppMock.mockReturnValue({
|
||||
...resolvedEnvironmentsApp,
|
||||
reviewApp: { canSetupReviewApp: false },
|
||||
await nextTick();
|
||||
const stopped = wrapper.findByRole('tab', {
|
||||
name: `${__('Stopped')} ${resolvedEnvironmentsApp.stoppedCount}`,
|
||||
});
|
||||
environmentFolderMock.mockReturnValue(resolvedFolder);
|
||||
const apolloProvider = createApolloProvider();
|
||||
wrapper = createWrapper({ apolloProvider });
|
||||
|
||||
stopped.trigger('click');
|
||||
|
||||
await nextTick();
|
||||
await waitForPromises();
|
||||
await Vue.nextTick();
|
||||
|
||||
const button = wrapper.findByRole('button', { name: s__('Environments|Enable review app') });
|
||||
expect(button.exists()).toBe(false);
|
||||
expect(environmentAppMock).toHaveBeenCalledWith(
|
||||
expect.anything(),
|
||||
{ scope: 'stopped' },
|
||||
expect.anything(),
|
||||
expect.anything(),
|
||||
);
|
||||
});
|
||||
});
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ RSpec.describe MetricsServer do # rubocop:disable RSpec/FilePath
|
|||
let(:prometheus_config) { ::Prometheus::Client::Configuration.new }
|
||||
let(:metrics_dir) { Dir.mktmpdir }
|
||||
let(:settings_double) { double(:settings, sidekiq_exporter: {}) }
|
||||
let!(:old_metrics_dir) { ::Prometheus::Client.configuration.multiprocess_files_dir }
|
||||
|
||||
subject(:metrics_server) { described_class.new('fake', metrics_dir, true)}
|
||||
|
||||
|
|
@ -43,8 +44,11 @@ RSpec.describe MetricsServer do # rubocop:disable RSpec/FilePath
|
|||
end
|
||||
|
||||
after do
|
||||
Gitlab::Metrics.reset_registry!
|
||||
|
||||
::Prometheus::CleanupMultiprocDirService.new.execute
|
||||
Dir.rmdir(metrics_dir)
|
||||
::Prometheus::Client.configuration.multiprocess_files_dir = old_metrics_dir
|
||||
end
|
||||
|
||||
it 'configures ::Prometheus::Client' do
|
||||
|
|
|
|||
Loading…
Reference in New Issue