diff options
Diffstat (limited to 'doc/user/project')
| -rw-r--r-- | doc/user/project/clusters/add_eks_clusters.md | 8 | ||||
| -rw-r--r-- | doc/user/project/clusters/add_remove_clusters.md | 17 | ||||
| -rw-r--r-- | doc/user/project/clusters/runbooks/index.md | 4 | ||||
| -rw-r--r-- | doc/user/project/clusters/serverless/aws.md | 8 | ||||
| -rw-r--r-- | doc/user/project/clusters/serverless/index.md | 49 |
5 files changed, 41 insertions, 45 deletions
diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md index b2eb1c51745..5a05b32af0b 100644 --- a/doc/user/project/clusters/add_eks_clusters.md +++ b/doc/user/project/clusters/add_eks_clusters.md @@ -65,7 +65,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance: 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy: 1. From the left panel, select **Policies**. 1. Click **Create Policy**, which opens a new window. - 1. Select the **JSON** tab, and paste in the following snippet in place of the existing content: + 1. Select the **JSON** tab, and paste the following snippet in place of the + existing content. These permissions give GitLab the ability to create + resources, but not delete them: ```json { @@ -112,9 +114,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance: } ``` - NOTE: **Note:** - These permissions give GitLab the ability to create resources, but not delete them. - This means that if an error is encountered during the creation process, changes will + If an error is encountered during the creation process, changes will not be rolled back and you must remove resources manually. You can do this by deleting the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md index d961e4bafa3..094f4bcf6ba 100644 --- a/doc/user/project/clusters/add_remove_clusters.md +++ b/doc/user/project/clusters/add_remove_clusters.md @@ -44,6 +44,8 @@ Before [adding a Kubernetes cluster](#create-new-cluster) using GitLab, you need ## Access controls +> - Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5. + When creating a cluster in GitLab, you are asked if you would like to create either: - A [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) @@ -55,9 +57,6 @@ GitLab creates the necessary service accounts and privileges to install and run a `gitlab` service account with `cluster-admin` privileges is created in the `default` namespace to manage the newly created cluster. -NOTE: **Note:** -Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5. - The first time you install an application into your cluster, the `tiller` service account is created with `cluster-admin` privileges in the `gitlab-managed-apps` namespace. This service account is used by Helm to @@ -152,11 +151,12 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level ## Add existing cluster -If you have an existing Kubernetes cluster, you can add it to a project, group, or instance. +If you have an existing Kubernetes cluster, you can add it to a project, group, +or instance. -NOTE: **Note:** -Kubernetes integration is not supported for arm64 clusters. See the issue -[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) for details. +Kubernetes integration isn't supported for arm64 clusters. See the issue +[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) +for details. ### Existing Kubernetes cluster @@ -191,7 +191,6 @@ To add a Kubernetes cluster to your project, group, or instance: kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode ``` - NOTE: **Note:** If the command returns the entire certificate chain, you must copy the Root CA certificate and any intermediate certificates at the bottom of the chain. A chain file has following structure: @@ -321,7 +320,7 @@ integration to work properly.  -NOTE: **Note:** +CAUTION: **Caution:** Disabling RBAC means that any application running in the cluster, or user who can authenticate to the cluster, has full API access. This is a [security concern](index.md#security-implications), and may not be desirable. diff --git a/doc/user/project/clusters/runbooks/index.md b/doc/user/project/clusters/runbooks/index.md index 360b02efb69..c1e4e821efd 100644 --- a/doc/user/project/clusters/runbooks/index.md +++ b/doc/user/project/clusters/runbooks/index.md @@ -115,9 +115,7 @@ the components outlined above and the pre-loaded demo runbook. VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value ``` -1. To configure the operation of a runbook, create and configure variables: - - NOTE: **Note:** +1. To configure the operation of a runbook, create and configure variables. For this example, we are using the **Run SQL queries in Notebook** section in the sample runbook to query a PostgreSQL database. The first four lines of the following code block define the variables that are required for this query to function: diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md index d662dc4f715..29058456271 100644 --- a/doc/user/project/clusters/serverless/aws.md +++ b/doc/user/project/clusters/serverless/aws.md @@ -136,8 +136,8 @@ This example code does the following: In order to interact with your AWS account, the GitLab CI/CD pipelines require both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be defined in your GitLab settings under **Settings > CI/CD > Variables**. For more information please see [Create a custom variable in the UI](../../../../ci/variables/README.md#create-a-custom-variable-in-the-ui). -NOTE: **Note:** - The AWS credentials you provide must include IAM policies that provision correct access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources. + The AWS credentials you provide must include IAM policies that provision correct + access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources. #### Deploying your function @@ -154,9 +154,7 @@ endpoints: #### Manually testing your function Running the following `curl` command should trigger your function. - -NOTE: **Note:** -Your URL should be the one retrieved from the GitLab deploy stage log. +Your URL should be the one retrieved from the GitLab deploy stage log: ```shell curl https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index 1157c2c5632..d70d4e26ee0 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -75,8 +75,8 @@ To run Knative on GitLab, you will need: ## Installing Knative via GitLab's Kubernetes integration -NOTE: **Note:** -The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB memory. **RBAC must be enabled.** +The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB +memory. **RBAC must be enabled.** 1. [Add a Kubernetes cluster](../add_remove_clusters.md). 1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with @@ -99,22 +99,19 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.  -NOTE: **Note:** You can deploy either [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications) -on a given project but not both. The current implementation makes use of a `serverless.yml` file to signal a FaaS project. +on a given project, but not both. The current implementation makes use of a +`serverless.yml` file to signal a FaaS project. ## Using an existing installation of Knative > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0. -NOTE: **Note:** -The "invocations" monitoring feature of GitLab serverless will not work when +The _invocations_ monitoring feature of GitLab serverless won't work when adding an existing installation of Knative. -It is also possible to use GitLab Serverless with an existing Kubernetes -cluster which already has Knative installed. - -You must do the following: +It's also possible to use GitLab Serverless with an existing Kubernetes cluster +which already has Knative installed. You must do the following: 1. Follow the steps to [add an existing Kubernetes @@ -453,16 +450,16 @@ To run a function locally: > Introduced in GitLab 11.5. +12345678901234567890123456789012345678901234567890123456789012345678901234567890 Serverless applications are an alternative to [serverless functions](#deploying-functions). -They are useful in scenarios where an existing runtime does not meet the needs of an application, -such as one written in a language that has no runtime available. Note though that serverless -applications should be stateless! - -NOTE: **Note:** -You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started. +They're useful in scenarios where an existing runtime does not meet the needs of +an application, such as one written in a language that has no runtime available. +Note though that serverless applications should be stateless. -Add the following `.gitlab-ci.yml` to the root of your repository -(you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above): +You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) +to get started. Add the following `.gitlab-ci.yml` to the root of your repository +(you may skip this step if you've previously cloned the previously mentioned, +sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)): ```yaml include: @@ -561,14 +558,18 @@ Or: ## Enabling TLS for Knative services -By default, a GitLab serverless deployment will be served over `http`. In order to serve over `https` you -must manually obtain and install TLS certificates. +By default, a GitLab serverless deployment will be served over `http`. To serve +over `https`, you must manually obtain and install TLS certificates. -The simplest way to accomplish this is to -use [Certbot to manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates). Certbot is a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS. +12345678901234567890123456789012345678901234567890123456789012345678901234567890 +The simplest way to accomplish this is to use Certbot to +[manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates). +Certbot is a free, open source software tool for automatically using Let’s Encrypt +certificates on manually-administrated websites to enable HTTPS. -NOTE: **Note:** -The instructions below relate to installing and running Certbot on a Linux server that has Python 3 installed and may not work on other operating systems or with other versions of Python. +The following instructions relate to installing and running Certbot on a Linux +server that has Python 3 installed, and may not work on other operating systems +or with other versions of Python. 1. Install Certbot by running the [`certbot-auto` wrapper script](https://certbot.eff.org/docs/install.html#certbot-auto). |