to build the application and the [TriggerMesh CLI](https://github.com/triggermesh/tm) to simplify the
to build the application and the [TriggerMesh CLI](https://github.com/triggermesh/tm) to simplify the
deployment of knative services and functions.
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
will contain the information for all the functions being hosted in the repository as well as a reference to the
runtime being used.
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`.
at the root of your project's repo and expose port `8080`.
## Installing Knative via GitLab's Kubernetes integration
## Installing Knative via GitLab's Kubernetes integration
...
@@ -75,11 +73,16 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
...
@@ -75,11 +73,16 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
> Introduced in GitLab 11.6.
> 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
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.
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:
image to be used for your functions. It must be included at the root of your repository:
...
@@ -97,11 +100,16 @@ In order to deploy functions to your Knative instance, the following templates m
...
@@ -97,11 +100,16 @@ In order to deploy functions to your Knative instance, the following templates m
2.`serverless.yml`: This template contains the metadata for your functions,
The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters.
such as name, runtime, and environment. It must be included at the root of your repository:
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.
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.
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
Once the deploy stage has finished, additional details for the function will
appear under **Operations > Serverless**.
appear under **Operations > Serverless**.
...
@@ -149,6 +181,10 @@ The function details can be retrieved directly from Knative on the cluster:
...
@@ -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
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.
Currently, the Serverless page presents all functions available in all clusters registered for the project with Knative installed.
## Deploying Serverless applications
## Deploying Serverless applications
...
@@ -190,17 +226,12 @@ deploy:
...
@@ -190,17 +226,12 @@ deploy:
## Deploy the application with Knative
## 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
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 **Run Pipeline** button at the upper-right part of the screen. Then, on the
**CI/CD > Pipelines** and click the most recent pipeline.
Pipelines page, click **Create pipeline**.
## Obtain the URL for the Knative deployment
## Obtain the URL for the Knative deployment
There are two ways to obtain the URL for the Knative deployment.
Use the CI/CD deployment job output to obtain the deployment URL. Once all the stages of the pipeline finish, click the **deploy** stage.
### Using the CI/CD deployment job output
Once all the stages of the pipeline finish, click the **deploy** stage.
