diff options
Diffstat (limited to 'doc/user/project')
| -rw-r--r-- | doc/user/project/clusters/index.md | 29 | ||||
| -rw-r--r-- | doc/user/project/clusters/serverless/img/function-execution.png | bin | 0 -> 223762 bytes | |||
| -rw-r--r-- | doc/user/project/clusters/serverless/img/serverless-page.png | bin | 11829 -> 194708 bytes | |||
| -rw-r--r-- | doc/user/project/clusters/serverless/index.md | 107 | ||||
| -rw-r--r-- | doc/user/project/img/releases.png | bin | 0 -> 43612 bytes | |||
| -rw-r--r-- | doc/user/project/releases.md | 12 | ||||
| -rw-r--r-- | doc/user/project/repository/index.md | 2 |
7 files changed, 101 insertions, 49 deletions
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index db48388e90d..6bdafc60949 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -254,15 +254,19 @@ install it manually. GitLab provides a one-click install for various applications which can be added directly to your configured cluster. Those applications are needed for [Review Apps](../../../ci/review_apps/index.md) and -[deployments](../../../ci/environments.md). +[deployments](../../../ci/environments.md). You can install them after you +[create a cluster](#adding-and-creating-a-new-gke-cluster-via-gitlab). + +To see a list of available applications to install: + +1. Navigate to your project's **Operations > Kubernetes**. +1. Select your cluster. + +Install Helm Tiller first because it's used to install other applications. NOTE: **Note:** -With the exception of Knative, the applications will be installed in a dedicated namespace called -`gitlab-managed-apps`. In case you have added an existing Kubernetes cluster -with Tiller already installed, you should be careful as GitLab cannot -detect it. In this event, installing Tiller via the applications will -result in the cluster having it twice. This can lead to confusion during -deployments. +As of GitLab 11.6, Helm Tiller will be upgraded to the latest version supported +by GitLab before installing any of the applications. | Application | GitLab version | Description | Helm Chart | | ----------- | :------------: | ----------- | --------------- | @@ -274,9 +278,14 @@ deployments. | [JupyterHub](http://jupyter.org/) | 11.0+ | [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user service for managing notebooks across a team. [Jupyter Notebooks](https://jupyter-notebook.readthedocs.io/en/latest/) provide a web-based interactive programming environment used for data analysis, visualization, and machine learning. We use a [custom Jupyter image](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile) that installs additional useful packages on top of the base Jupyter. You will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/amit1rrr/rubix). More information on creating executable runbooks can be found in [our Nurtch documentation](runbooks/index.md#nurtch-executable-runbooks). **Note**: Authentication will be enabled for any user of the GitLab server via OAuth2. HTTPS will be supported in a future release. | [jupyter/jupyterhub](https://jupyterhub.github.io/helm-chart/) | | [Knative](https://cloud.google.com/knative) | 11.5+ | Knative provides a platform to create, deploy, and manage serverless workloads from a Kubernetes cluster. It is used in conjunction with, and includes [Istio](https://istio.io) to provide an external IP address for all programs hosted by Knative. You will be prompted to enter a wildcard domain where your applications will be exposed. Configure your DNS server to use the external IP address for that domain. For any application created and installed, they will be accessible as `<program_name>.<kubernetes_namespace>.<domain_name>`. This will require your kubernetes cluster to have [RBAC enabled](#role-based-access-control-rbac). | [knative/knative](https://storage.googleapis.com/triggermesh-charts) -NOTE: **Note:** -As of GitLab 11.6 Helm Tiller will be upgraded to the latest version supported -by GitLab before installing any of the above applications. +With the exception of Knative, the applications will be installed in a dedicated +namespace called `gitlab-managed-apps`. + +CAUTION: **Caution:** +If you have an existing Kubernetes cluster with Tiller already installed, +you should be careful as GitLab cannot detect it. In this case, installing +Tiller via the applications will result in the cluster having it twice, which +can lead to confusion during deployments. ## Getting the external IP address diff --git a/doc/user/project/clusters/serverless/img/function-execution.png b/doc/user/project/clusters/serverless/img/function-execution.png Binary files differnew file mode 100644 index 00000000000..93b0b6d802d --- /dev/null +++ b/doc/user/project/clusters/serverless/img/function-execution.png diff --git a/doc/user/project/clusters/serverless/img/serverless-page.png b/doc/user/project/clusters/serverless/img/serverless-page.png Binary files differindex 5d808fc2d4f..960d6e736d6 100644 --- a/doc/user/project/clusters/serverless/img/serverless-page.png +++ b/doc/user/project/clusters/serverless/img/serverless-page.png diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index c1f2e844362..a423212a879 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -1,9 +1,7 @@ # Serverless > Introduced in GitLab 11.5. - -CAUTION: **Caution:** -Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/#alpha). +> Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/#alpha). Run serverless workloads on Kubernetes using [Knative](https://cloud.google.com/knative/). @@ -31,13 +29,13 @@ To run Knative on Gitlab, you will need: external IP address for all the applications served by Knative. You will be prompted to enter a wildcard domain where your applications will be served. Configure your DNS server to use the external IP address for that domain. -1. **`gitlab-ci.yml`:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) +1. **`.gitlab-ci.yml`:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to build the application and the [TriggerMesh CLI](https://github.com/triggermesh/tm) to simplify the deployment of knative services and functions. -1. **`serverless.yml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yml` file +1. **`serverless.yaml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yaml` file will contain the information for all the functions being hosted in the repository as well as a reference to the runtime being used. -1. **`Dockerfile`:** Knative requires a `Dockerfile` in order to build your application. It should be included +1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications): Knative requires a `Dockerfile` in order to build your application. It should be included at the root of your project's repo and expose port `8080`. ## Installing Knative via GitLab's Kubernetes integration @@ -75,13 +73,18 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22. > Introduced in GitLab 11.6. -Using functions is useful for initiating, responding, or triggering independent +Using functions is useful for dealing with independent events without needing to maintain a complex unified infrastructure. This allows you to focus on a single task that can be executed/scaled automatically and independently. -In order to deploy functions to your Knative instance, the following templates must be present: +Currently the following [runtimes](https://gitlab.com/triggermesh/runtimes) are offered: + +- node.js +- kaniko + +In order to deploy functions to your Knative instance, the following files must be present: -1. `gitlab-ci.yml`: This template allows to define the stage, environment, and +1. `.gitlab-ci.yml`: This template allows to define the stage, environment, and image to be used for your functions. It must be included at the root of your repository: ```yaml @@ -91,17 +94,22 @@ In order to deploy functions to your Knative instance, the following templates m functions: stage: deploy environment: test - image: gcr.io/triggermesh/tm:v0.0.6 + image: gcr.io/triggermesh/tm:v0.0.7 script: - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" - tm -n "$KUBE_NAMESPACE" --registry-host "$CI_REGISTRY_IMAGE" deploy --wait ``` -2. `serverless.yml`: This template contains the metadata for your functions, - such as name, runtime, and environment. It must be included at the root of your repository: + The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters. + +2. `serverless.yaml`: This file contains the metadata for your functions, + such as name, runtime, and environment. It must be included at the root of your repository. The following is a sample `echo` function which shows the required structure for the file. + + NOTE: **Note:** + The file extension for the `serverless.yaml` file must be specified as `.yaml` in order to the file to be parsed properly. Specifying the extension as `.yml` will not work. ```yaml - service: knative-test + service: my-functions description: "Deploying functions from GitLab using Knative" provider: @@ -111,27 +119,51 @@ In order to deploy functions to your Knative instance, the following templates m FOO: BAR functions: - container: - handler: simple - description: "knative canonical sample" - runtime: https://gitlab.com/triggermesh/runtimes/raw/master/kaniko.yaml + echo: + handler: echo + runtime: https://gitlab.com/triggermesh/runtimes/raw/master/nodejs.yaml + description: "echo function using node.js runtime" buildargs: - - DIRECTORY=simple - environment: - SIMPLE_MSG: Hello - - nodejs: - handler: nodejs - runtime: https://gitlab.com/triggermesh/runtimes/raw/master/nodejs.yaml - description: "nodejs fragment" - buildargs: - - DIRECTORY=nodejs + - DIRECTORY=echo environment: - FUNCTION: nodejs + FUNCTION: echo ``` -After the templates have been created, each function must be defined as a single -file in your repository. Committing a function to your project will result in a + +The `serverless.yaml` file contains three sections with distinct parameters: + +### `service` + +| Parameter | Description | +|-----------|-------------| +| `service` | Name for the Knative service which will serve the function. | +| `description` | A short description of the `service`. | + + +### `provider` + +| Parameter | Description | +|-----------|-------------| +| `name` | Indicates which provider is used to execute the `serverless.yaml` file. In this case, the TriggerMesh `tm` CLI. | +| `registry-secret` | Indicates which registry will be used to store docker images. The sample function is using the GitLab Registry (`gitlab-registry`). A different registry host may be specified using `registry` key in the `provider` object. If changing the default, update the permission and the secret value on the `gitlab-ci.yml` file | +| `environment` | Includes the environment variables to be passed as part of function execution for **all** functions in the file, where `FOO` is the variable name and `BAR` are he variable contents. You may replace this with you own variables. | + +### `functions` + +In the `serverless.yaml` example above, the function name is `echo` and the subsequent lines contain the function attributes. + + +| Parameter | Description | +|-----------|-------------| +| `handler` | The function's file name. In the example above, both the function name and the handler are the same. | +| `runtime` | The runtime to be used to execute the function. | +| `description` | A short description of the function. | +| `buildargs` | Pointer to the function file in the repo. In the sample the function is located in the `echo` directory. | +| `environment` | Sets an environment variable for the specific function only. | + +After the `gitlab-ci.yml` template has been added and the `serverless.yaml` file has been +created, each function must be defined as a single file in your repository. Committing a +function to your project will result in a CI pipeline being executed which will deploy each function as a Knative service. Once the deploy stage has finished, additional details for the function will appear under **Operations > Serverless**. @@ -149,6 +181,10 @@ The function details can be retrieved directly from Knative on the cluster: kubectl -n "$KUBE_NAMESPACE" get services.serving.knative.dev ``` +The sample function can now be triggered from any HTTP client using a simple `POST` call. + + + Currently, the Serverless page presents all functions available in all clusters registered for the project with Knative installed. ## Deploying Serverless applications @@ -190,17 +226,12 @@ deploy: ## Deploy the application with Knative -With all the pieces in place, you can create a new CI pipeline to deploy the Knative application. Navigate to -**CI/CD > Pipelines** and click the **Run Pipeline** button at the upper-right part of the screen. Then, on the -Pipelines page, click **Create pipeline**. +With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to +**CI/CD > Pipelines** and click the most recent pipeline. ## Obtain the URL for the Knative deployment -There are two ways to obtain the URL for the Knative deployment. - -### Using the CI/CD deployment job output - -Once all the stages of the pipeline finish, click the **deploy** stage. +Use the CI/CD deployment job output to obtain the deployment URL. Once all the stages of the pipeline finish, click the **deploy** stage.  diff --git a/doc/user/project/img/releases.png b/doc/user/project/img/releases.png Binary files differnew file mode 100644 index 00000000000..aec1db89a75 --- /dev/null +++ b/doc/user/project/img/releases.png diff --git a/doc/user/project/releases.md b/doc/user/project/releases.md new file mode 100644 index 00000000000..8dad4240c91 --- /dev/null +++ b/doc/user/project/releases.md @@ -0,0 +1,12 @@ +# Releases + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/41766) in GitLab 11.7. + +Releases mark specific points in a project's development history, communicate +information about the type of change, and deliver on prepared, often compiled, +versions of the software to be reused elsewhere. Currently, releases can only be +created through the API. + +Navigate to **Project > Releases** in order to see the list of releases of a project. + + diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md index 1710bba2fd0..fac5975a0dc 100644 --- a/doc/user/project/repository/index.md +++ b/doc/user/project/repository/index.md @@ -29,7 +29,7 @@ You can either use the user interface (UI), or connect your local computer with GitLab [through the command line](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project). To configure [GitLab CI/CD](../../../ci/README.md) to build, test, and deploy -you code, add a file called [.`gitlab-ci.yml`](../../../ci/quick_start/README.md) +you code, add a file called [`.gitlab-ci.yml`](../../../ci/quick_start/README.md) to your repository's root. **From the user interface:** |
