Skip to content
This repository has been archived by the owner on May 9, 2023. It is now read-only.

Commit

Permalink
Merge pull request #223 from triggermesh/mattray-patch-1
Browse files Browse the repository at this point in the history 
Spelling and grammar fixes
  • Loading branch information
@mattray
mattray authored Sep 16, 2021
2 parents f4d6f35 + adff343 commit 7be2b2d
Showing 1 changed file with 17 additions and 17 deletions.
34 changes: 17 additions & 17 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ tm deploy service foobar \
--wait
```

or deploy service straight from Go source using Openfaas runtime
or deploy service straight from Go source using OpenFaaS runtime
```
tm deploy service bar \
-f https://github.com/golang/example \
Expand Down Expand Up @@ -73,7 +73,7 @@ make test

## AWS Lambda

With triggermesh CLI you can easily deploy AWS Lambda functions on Kuberentes:
With the TriggerMesh CLI you can easily deploy AWS Lambda functions on Kubernetes:

Prepare local source for Golang function

Expand Down Expand Up @@ -103,7 +103,7 @@ func main() {
EOF
```

Deploy function using Go Knative lambda runtime
Deploy function using Go Knative Lambda Runtime

```
tm deploy service go-lambda -f . --runtime https://raw.githubusercontent.com/triggermesh/knative-lambda-runtime/master/go/runtime.yaml --wait
Expand All @@ -116,16 +116,16 @@ curl http://go-lambda.default.dev.triggermesh.io --data '{"Name": "Foo"}'
"Hello Foo!"
```

[Here](https://github.com/triggermesh/knative-lambda-runtime) you can find more information about Knative lambda runtimes
[Here](https://github.com/triggermesh/knative-lambda-runtime) you can find more information about Knative Lambda Runtimes


## Deployment pipelines

_This feature is only available for Github.com repositories at the moment_

With Triggermesh CLI you can create fully functional deployment pipeline of existing git repository with a single command. In example below we're assuming that you have an access to k8s cluster with knative and tekton pipelines installed. If you use Triggermesh cloud you should not worry about requirements; platform is ready to go.
With TriggerMesh CLI you can create fully functional deployment pipeline of existing git repository with a single command. In example below we're assuming that you have an access to Kubernetes cluster with Knative and Tekton pipelines installed. If you use TriggerMesh Cloud you should not worry about requirements; platform is ready to go.

As a first step, you should create new public repository in Github.com which we will use in our example. After the empty repository has been created, we need to push sample AWS Lambda project to it:
As a first step, you should create new public repository in GitHub.com which we will use in our example. After the empty repository has been created, we need to push sample AWS Lambda project to it:

```
tm generate python foo
Expand All @@ -142,21 +142,21 @@ Now that we have repository with Python project, let's create build pipeline:
```
tm push | kubectl apply -f -
```
-this command creates several knative and tekton components:
-this command creates several Knative and Tekton components:

1. Tekton task with `tm` image to build AWS Lambda project using [KLR](https://github.com/triggermesh/knative-lambda-runtime)
1. Tekton taskrun to initiate project build and corresponding pipelineresource with source URL
1. Triggermesh Github custom "third-party" containersource that allows to track events on Github repositories*
1. Triggermesh Aktion [transceiver](https://github.com/triggermesh/aktion/tree/master/cmd/transceiver) and its configmap to create new taskruns on incoming events from Github containersource
1. TriggerMesh GitHub custom "third-party" containersource that allows to track events on GitHub repositories*
1. TriggerMesh Aktion [transceiver](https://github.com/triggermesh/aktion/tree/master/cmd/transceiver) and its configmap to create new taskruns on incoming events from GitHub containersource


\* our Github containersource is aimed at simplifying event tracking and based on periodic Github API requests (one request per minute). As a result, you don't need to create and store any tokens. Downside of this approach is that containersource have requests rate limitation (60 requests per hour) and it doesn't work with private repositories. Both of these limitation can be bypassed by providing Github personal access token in push command parameter: `tm push --token <TOKEN>`
\* our GitHub containersource is aimed at simplifying event tracking and based on periodic GitHub API requests (one request per minute). As a result, you don't need to create and store any tokens. Downside of this approach is that containersource have requests rate limitation (60 requests per hour) and it doesn't work with private repositories. Both of these limitations can be bypassed by providing GitHub personal access token in push command parameter: `tm push --token <TOKEN>`

After few minutes you should be able to see new Knative service deployed in cluster. Any commits will trigger new build and deploy so that new function will reflect all code changes.

### Docker registry

Docker images are used to run functions code in Knative services. This means that image registry is important part of service deployment scheme. Depending on type of service, Knative controller may either only pull or also push service image from and to registry. Triggermesh CLI provides simple configuration interface to setup registry address and user access credentials.
Docker images are used to run functions code in Knative services. This means that image registry is important part of service deployment scheme. Depending on type of service, Knative controller may either only pull or also push service image from and to registry. TriggerMesh CLI provides simple configuration interface to setup registry address and user access credentials.

#### Service from pre-build image

Expand All @@ -174,7 +174,7 @@ If pre-built image stored in **private** registry, you must specify access crede
tm set registry-auth foo-registry
```

You will be asked to enter registry address, username and password - they will saved to k8s secret and used to pull images deployed under you service account.
You will be asked to enter a registry address, username, and password - they will be saved to k8s secret and be used to pull images deployed under your service account.

Besides pulling, this secret may be used to push new images for service deployment based on function source code and build template. Name of one particular k8s secret should be passed to deployment command to make CLI work with private registry:

Expand All @@ -191,7 +191,7 @@ If user whose credentials are specified in `foo-registry` have "write" permissio

#### Gitlab CI registry

Triggermesh CLI can be used as deployment step in Gitlab CI pipeline, but considering [tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/) security policy, user must manually create CI deployment token as described [here](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token).
TriggerMesh CLI can be used as deployment step in GitLab CI pipeline, but considering [tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/) security policy, user must manually create CI deployment token as described [here](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token).
Deployment token must have registry read permission and should be valid for as long as the service expected to be active. If token is created, `tm` deployment step must include following commands:

```
Expand All @@ -202,11 +202,11 @@ script:
...
```
After this, you may pass `--registry-secret gitlab-registry` parameter to `tm deploy` command (or in [serverless.yml](https://gitlab.com/knative-examples/functions/blob/master/serverless.yaml#L6)) so that Knative could authenticate against Gitlab registry.
Gitlab registry doesn't provide permanent read-write token that can be used in CI, but it has job-specific `CI_JOB_TOKEN` with "write" permission which is valid only while CI job running and `CI_DEPLOY_PASSWORD` with read permission which we created before. Considering this, we can see that CLI `set registry-auth` command supports `--push` and `--pull` flags that indicates which secret must be used to push image and which for "pull" operations only. Resulting images will be stored under `registry.gitlab.com/username/project/function_name` path
GitLab registry doesn't provide permanent read-write token that can be used in CI, but it has job-specific `CI_JOB_TOKEN` with "write" permission which is valid only while CI job running and `CI_DEPLOY_PASSWORD` with read permission which we created before. Considering this, we can see that CLI `set registry-auth` command supports `--push` and `--pull` flags that indicates which secret must be used to push image and which for "pull" operations only. Resulting images will be stored under `registry.gitlab.com/username/project/function_name` path

### Custom registry name

While using a username as a registry identifier (docker.io/username) is a common practice, in some cases we must be able to use different values for an authentication and in destination URL (for example, [gcr.io](https://cloud.google.com/container-registry/docs/advanced-authentication#linux-macos)). Triggermesh CLI `set registry-auth` command provides such ability by exposing an optional `--project` argument which will be used as a part of the image URL instead of the username:
While using a username as a registry identifier (docker.io/username) is a common practice, in some cases we must be able to use different values for an authentication and in destination URL (for example, [gcr.io](https://cloud.google.com/container-registry/docs/advanced-authentication#linux-macos)). TriggerMesh CLI `set registry-auth` command provides such ability by exposing an optional `--project` argument which will be used as a part of the image URL instead of the username:

```
TOKEN=$(gcloud auth print-access-token)
Expand All @@ -221,7 +221,7 @@ As a result, Knative service image will be pushed to `eu.gcr.io/my-org/my-projec

ECR is a specific case of the custom registry destination with an additional requirement - a repository must be created before pushing the image. Thus, service deployment steps should be slightly altered:

1. Create ECR repository in `<project>/<service>` format where "project" is an arbitrary identifier for the service (e.g. namespace) and "service" is the name of the service that is being deployed (in the example below it is `python-test`).
1. Create ECR repository in `<project>/<service>` format where "project" is an arbitrary identifier for the service (e.g., namespace) and "service" is the name of the service that is being deployed (in the example below it is `python-test`).
1. Retrieve ECR token:
```
TOKEN=$(aws ecr get-login-password --region <region>)
Expand All @@ -243,7 +243,7 @@ ECR is a specific case of the custom registry destination with an additional req

#### Unauthenticated registry

Besides hosted registries, triggermesh CLI may work with unauthenticated registries which does not require setting access credentials. For such cases, you may simply add `--registry-host` argument to deployment command with registry domain name parameter and resulting image will be pushed to `registry-host/namespace/service_name` URL
Besides hosted registries, the TriggerMesh CLI may work with unauthenticated registries which do not require setting access credentials. For such cases, you may simply add `--registry-host` argument to the deployment command with registry domain name parameter and the resulting image will be pushed to `registry-host/namespace/service_name` URL

### How-To

Expand Down

0 comments on commit 7be2b2d

Please sign in to comment.