diff --git a/.markdownlint.yaml b/.markdownlint.yaml new file mode 100644 index 000000000..51f4cf9cd --- /dev/null +++ b/.markdownlint.yaml @@ -0,0 +1,26 @@ +# This is a configuration file for the markdownlint. You can use this file to overwrite the default settings. +# MD013 is set to false by default because many files include lines longer than the conventional 80 character limit +MD013: false +# Disable the Multiple headings with the same content rule +MD024: false +# MD029 is set to false because it generated some issues with longer lists +MD029: false +# MD044 is used to set capitalization for particular words. You can determine whether it should be used also for code blocks and HTML elements +MD044: + code_blocks: false + html_elements: false + names: + - Kyma + - Kubernetes + - ConfigMap + - CronJob + - CustomResourceDefinition + - Ingress + - Node + - PodPreset + - Pod + - ProwJob + - Secret + - ServiceBinding + - ServiceClass + - ServiceInstance \ No newline at end of file diff --git a/.markdownlintignore b/.markdownlintignore new file mode 100644 index 000000000..578db9cb3 --- /dev/null +++ b/.markdownlintignore @@ -0,0 +1 @@ +_sidebar.md \ No newline at end of file diff --git a/docs/contributor/03-10-scripts-not-working.md b/docs/contributor/03-10-scripts-not-working.md index bab3ce794..568eeaa21 100644 --- a/docs/contributor/03-10-scripts-not-working.md +++ b/docs/contributor/03-10-scripts-not-working.md @@ -16,4 +16,4 @@ Install [Kyma CLI manually](https://github.com/kyma-project/cli#installation) an ```bash export KYMA=$(which kyma) - ``` \ No newline at end of file + ``` diff --git a/docs/contributor/04-10-testing-strategy.md b/docs/contributor/04-10-testing-strategy.md index 5395bfa0d..d6ac9cc93 100644 --- a/docs/contributor/04-10-testing-strategy.md +++ b/docs/contributor/04-10-testing-strategy.md @@ -20,4 +20,4 @@ Each pull request to the repository triggers the following CI/CD jobs that verif ## CI/CD Jobs Running on a Schedule -- `Markdown / link-check` - Runs Markdown link check every day at 05:00 AM. \ No newline at end of file +- `Markdown / link-check` - Runs Markdown link check every day at 05:00 AM. diff --git a/docs/user/00-10-from-code-to-function.md b/docs/user/00-10-from-code-to-function.md index 99625c8f2..33f8b5ec4 100644 --- a/docs/user/00-10-from-code-to-function.md +++ b/docs/user/00-10-from-code-to-function.md @@ -14,4 +14,4 @@ Functions support multiple languages by using the underlying execution environme You can also choose where you want to keep your Function's source code and dependencies. You can either place them directly in the Function CR under the **spec.source** and **spec.deps** fields as an **inline Function**, or store the code and dependencies in a public or private Git repository (**Git Functions**). Choosing the second option ensures your Function is versioned and gives you more development freedom in the choice of a project structure or an IDE. > [!TIP] -> Read more about [Git Functions](technical-reference/07-40-git-source-type.md). \ No newline at end of file +> Read more about [Git Functions](technical-reference/07-40-git-source-type.md). diff --git a/docs/user/00-20-configure-serverless.md b/docs/user/00-20-configure-serverless.md index 6d256a8d5..c047046b9 100644 --- a/docs/user/00-20-configure-serverless.md +++ b/docs/user/00-20-configure-serverless.md @@ -5,19 +5,20 @@ The Serverless module has its own operator (Serverless operator). It watches the Serverless custom resource (CR) and reconfigures (reconciles) the Serverless workloads. The Serverless CR becomes an API to configure the Serverless module. You can use it to: - - enable or disable the internal Docker registry - - configure the external Docker registry - - override endpoint for traces collected by the Serverless Functions - - override endpoint for eventing - - override the target CPU utilization percentage - - override the Function requeue duration - - override the Function build executor arguments - - override the Function build max simultaneous jobs - - override the healthz liveness timeout - - override the Function request body limit - - override the Function timeout - - override the default build Job preset - - override the default runtime Pod preset + +- enable or disable the internal Docker registry +- configure the external Docker registry +- override endpoint for traces collected by the Serverless Functions +- override endpoint for eventing +- override the target CPU utilization percentage +- override the Function requeue duration +- override the Function build executor arguments +- override the Function build max simultaneous jobs +- override the healthz liveness timeout +- override the Function request body limit +- override the Function timeout +- override the default build Job preset +- override the default runtime Pod preset The default configuration of the Serverless Module is following: @@ -37,7 +38,7 @@ By default, Serverless uses PersistentVolume (PV) as the internal registry to st If you use Serverless for production purposes, it is recommended that you use an external registry, such as Docker Hub, Artifact Registry, or Azure Container Registry (ACR). -Follow these steps to use the external Docker registry in Serverless: +Follow these steps to use the external Docker registry in Serverless: 1. Create a Secret in the `kyma-system` namespace with the required data (`username`, `password`, `serverAddress`, and `registryAddress`): @@ -71,6 +72,7 @@ Examples: ### **Artifact Registry** To learn how to set up authentication for Docker with Artifact Registry, visit the [Artifact Registry documentation](https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key). + ```bash kubectl create secret generic my-registry-config \ --namespace kyma-system \ @@ -102,8 +104,8 @@ To learn how to authenticate with ACR, visit the [ACR documentation](https://lea dockerRegistry: secretName: my-registry-config ``` -The URL of the currently used Docker registry is visible in the Serverless CR status. +The URL of the currently used Docker registry is visible in the Serverless CR status. ## Configure Trace Endpoint @@ -150,7 +152,8 @@ By default, the Function associated with the default configuration will be reque ## Configure the Function Build Executor Arguments -Use this label to choose the [arguments](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#additional-flags) passed to the Function build executor, for example: +Use this label to choose the [arguments](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#additional-flags) passed to the Function build executor, for example: + - `--insecure` - executor operates in an insecure mode - `--skip-tls-verify` - executor skips the TLS certificate verification - `--skip-unused-stages` - executor skips any stages that aren't used for the current execution @@ -202,7 +205,7 @@ By default, the maximum execution time limit for a Function is set to `180` seco ## Configure the Default Build Job Preset -You can configure the default build Job preset to be used. +You can configure the default build Job preset to be used. ```yaml spec: diff --git a/docs/user/00-30-development-toolkit.md b/docs/user/00-30-development-toolkit.md index 85c391501..e5e105a39 100644 --- a/docs/user/00-30-development-toolkit.md +++ b/docs/user/00-30-development-toolkit.md @@ -7,7 +7,7 @@ To start developing your first Functions, you need: - [**Docker**](https://www.docker.com/) as the container runtime - [**kubectl**](https://kubernetes.io/docs/reference/kubectl/kubectl/), the Kubernetes command-line tool, for running commands against clusters - Development environment of your choice: - - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them in the clusters - - **Node.js** or **Python** - - **IDE** as the source code editor - - **Kyma dashboard** to manage Functions and related workloads through the graphical user interface \ No newline at end of file + - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them in the clusters + - **Node.js** or **Python** + - **IDE** as the source code editor + - **Kyma dashboard** to manage Functions and related workloads through the graphical user interface diff --git a/docs/user/00-40-security-considerations.md b/docs/user/00-40-security-considerations.md index 527e318be..2a0023f0f 100644 --- a/docs/user/00-40-security-considerations.md +++ b/docs/user/00-40-security-considerations.md @@ -16,4 +16,5 @@ To eliminate potential security risks when using Functions, bear in mind these f - Source code of all Functions within this namespace - Internal Docker registry that contains Function images - - Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces) \ No newline at end of file + - Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces) + \ No newline at end of file diff --git a/docs/user/00-50-limitations.md b/docs/user/00-50-limitations.md index ce54bc49d..907d52af6 100644 --- a/docs/user/00-50-limitations.md +++ b/docs/user/00-50-limitations.md @@ -1,23 +1,27 @@ # Serverless Limitations ## Controller Limitations + Serverless controller does not serve time-critical requests from users. It reconciles Function custom resources (CR), stored at the Kubernetes API Server, and has no persistent state on its own. -Serverless controller doesn't build or serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. It schedules (build-time) jobs to build the Function Docker image and (runtime) Pods to serve them once they are built. +Serverless controller doesn't build or serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. It schedules (build-time) jobs to build the Function Docker image and (runtime) Pods to serve them once they are built. Refer to the [architecture](technical-reference/04-10-architecture.md) diagram for more details. Having this in mind Serverless Controller does not require horizontal scaling. It scales vertically up to the `160Mi` of memory and `500m` of CPU time. ## Limitation for the Number of Functions -There is no upper limit of Functions that can be run on Kyma (similar to Kubernetes workloads in general). Once a user defines a Function, its build jobs and runtime Pods will always be requested by Serverless controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the node auto-scaling capabilities) and their computational capacity. -## Build Phase Limitation: +There is no upper limit of Functions that can be run on Kyma (similar to Kubernetes workloads in general). Once a user defines a Function, its build jobs and runtime Pods will always be requested by Serverless controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the Node auto-scaling capabilities) and their computational capacity. + +## Build Phase Limitation + The time necessary to build Function depends on: - - selected [build profile](technical-reference/07-80-available-presets.md#build-jobs-resources) that determines the requested resources (and their limits) for the build phase - - number and size of dependencies that must be downloaded and bundled into the Function image - - cluster Nodes specification (see the note with reference specification at the end of this document) + +- selected [build profile](technical-reference/07-80-available-presets.md#build-jobs-resources) that determines the requested resources (and their limits) for the build phase +- number and size of dependencies that must be downloaded and bundled into the Function image +- cluster Nodes specification (see the note with reference specification at the end of this document) @@ -42,6 +46,7 @@ The shortest build time (the limit) is approximately 15 seconds and requires no Running multiple Function build jobs at once (especially with no limits) may drain the cluster resources. To mitigate such risk, there is an additional limit of 5 simultaneous Function builds. If a sixth one is scheduled, it is built once there is a vacancy in the build queue. ## Runtime Phase Limitations + In the runtime, the Functions serve user-provided logic wrapped in the WEB framework (`express` for Node.js and `bottle` for Python). Taking the user logic aside, those frameworks have limitations and depend on the selected [runtime profile](technical-reference/07-80-available-presets.md#functions-resources) and the Kubernetes nodes specification (see the note with reference specification at the end of this document). The following describes the response times of the selected runtime profiles for a "Hello World" Function requested at 50 requests/second. This describes the overhead of the serving framework itself. Any user logic added on top of that will add extra milliseconds and must be profiled separately. @@ -68,7 +73,6 @@ The following describes the response times of the selected runtime profiles for Obviously, the bigger the runtime profile, the more resources are available to serve the response quicker. Consider these limits of the serving layer as a baseline - as this does not take your Function logic into account. - ### Scaling Function runtime Pods can be scaled horizontally from zero up to the limits of the available resources at the Kubernetes worker nodes. @@ -78,5 +82,5 @@ See the [Use external scalers](tutorials/01-130-use-external-scalers.md) tutoria Serverless comes with an in-cluster Docker registry for the Function images. For more information on the Docker registry configuration, visit [Serverless configuration](00-20-configure-serverless.md#configure-docker-registry). -> [!NOTE] -> All measurements were done on Kubernetes with five AWS worker nodes of type `m5.xlarge` (four CPU 3.1 GHz x86_64 cores, 16 GiB memory). \ No newline at end of file +> [!NOTE] +> All measurements were done on Kubernetes with five AWS worker nodes of type `m5.xlarge` (four CPU 3.1 GHz x86_64 cores, 16 GiB memory). diff --git a/docs/user/08-10-best-practices.md b/docs/user/08-10-best-practices.md index 3e6a3568e..83c725ee1 100644 --- a/docs/user/08-10-best-practices.md +++ b/docs/user/08-10-best-practices.md @@ -5,7 +5,6 @@ Kyma Serverless introduces a [Function](resources/06-10-function-cr.md) CustomResourceDefinition (CRD) as an extension to the Kubernetes API server. Defining a Function in Kyma essentially means creating a new instance of the Function custom resource (CR). However, the content of the Function CR specification may become quite long. It consists of the code (or Git reference to the code), dependencies, runtime specification, build-time specification, etc. Additionally, there are other CRs that are relevant for a Function developer - that is, [APIRule](https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-custom-resources/apix-01-apirule/) (defining how Function is exposed to the outside world), [Subscription](https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-custom-resources/evnt-01-subscription/) (defining which CloudEvents should trigger a Function), and others. - All of that can be easily managed using the following best practices for the Function development. You will find recommendations that will be helpful for you at any stage of your development journey. ## Use UI to Explore @@ -19,7 +18,7 @@ Get started with [Function UI](tutorials/01-10-create-inline-function.md) ## Use Kyma CLI for Better Development Experience -Defining your Function from the Kyma dashboard is very quick and easy, but it might not be enough to satisfy your needs as a developer. To code and test more complex cases, you may want to write your Function in your favorite IDE or run and debug the Function on your local machine, before actually deploying in Kyma runtime. Also, you might want to avoid recreating the same Functions manually from the UI on a different environment. In the end, having deployable artifacts is more desirable. This is where Kyma CLI comes in handy, as it enables you to keep your Function's code and configuration in the form of a workspace. +Defining your Function from the Kyma dashboard is very quick and easy, but it might not be enough to satisfy your needs as a developer. To code and test more complex cases, you may want to write your Function in your favorite IDE or run and debug the Function on your local machine, before actually deploying in Kyma runtime. Also, you might want to avoid recreating the same Functions manually from the UI on a different environment. In the end, having deployable artifacts is more desirable. This is where Kyma CLI comes in handy, as it enables you to keep your Function's code and configuration in the form of a workspace. Initialize a scaffold for a brand new Function using the `kyma init function` command or fetch the current state of an existing Function deployed in your Kyma runtime using `kyma sync function`. Focus on the Function code and develop it from your favorite IDE. Configure your Functions directly in the [`config.yaml` manifest file](technical-reference/07-60-function-configuration-file.md) @@ -36,10 +35,9 @@ Kyma CLI helps you run your code locally with a single `kyma run function` comma Having written and tested your Function locally, simply deploy it to the Kyma runtime with the `kyma apply function` command, used in the folder of your Function's workspace. The command reads the files, translates them to the Kubernetes manifests, and deploys the Function. - ## Deploy Using CI/CD -Kyma dashboard helps you get started. Kyma CLI helps you iterate and develop Functions. +Kyma dashboard helps you get started. Kyma CLI helps you iterate and develop Functions. But at the end of the day, you may want an automated deployment of your application, where Functions are just part of it. It all comes down to the deployment the Kubernetes applications on different Kyma runtimes in a GitOps fashion. For the sake of simplicity, the deployment approach for Functions should not differ from the deployment of the other Kubernetes workloads, ConfigMaps, or Secrets. @@ -57,7 +55,7 @@ Deploy everything in a consistent way either using CI/CD or GitOps operators (fo > [!NOTE] > Kyma Functions come in two types: `git` and `inline`. For the [Git type](tutorials/01-11-create-git-function.md), you configure a Git repository as a source of your Function code instead of creating it `inline`. -Thus, you can skip rendering the Kubernetes manifests and deploying them each time you made a change in the Function code or dependencies. Simply push the changes to the referenced Git repository, and the Serverless controller will rebuild the Function deployed in your Kyma runtime. +Thus, you can skip rendering the Kubernetes manifests and deploying them each time you made a change in the Function code or dependencies. Simply push the changes to the referenced Git repository, and the Serverless controller will rebuild the Function deployed in your Kyma runtime. Have a look at this [example](https://github.com/kyma-project/serverless/tree/main/examples/incluster_eventing) that illustrates how you can set up your Git project. Mind the `k8s resources` folder with the YAML manifests to be pushed to the Kubernetes API server (for example, using kubectl in our CI/CD or GitOps) and the `src` folder containing the Functions' source code. They are pulled directly by Kyma Serverless to build new Function images whenever the source content changes in the Git repository. diff --git a/docs/user/README.md b/docs/user/README.md index 5f7116e53..4b1374c24 100644 --- a/docs/user/README.md +++ b/docs/user/README.md @@ -1,4 +1,4 @@ -# Serverless module +# Serverless Module ## What is serverless? @@ -24,7 +24,7 @@ Serverless in Kyma is an area that: Serverless in Kyma allows you to reduce the implementation and operation effort of an application to the absolute minimum. It provides a platform to run lightweight Functions in a cost-efficient and scalable way using JavaScript and Node.js. Serverless in Kyma relies on Kubernetes resources like [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Services](https://kubernetes.io/docs/concepts/services-networking/service/) and [HorizontalPodAutoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) for deploying and managing Functions and [Kubernetes Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) for creating Docker images. -## Serverless module +## Serverless Module The Serverless module allows you to install, uninstall and configure Kyma's Serverless on your Kubernetes cluster, using Serverless Operator. @@ -32,7 +32,7 @@ The Serverless module allows you to install, uninstall and configure Kyma's Serv When you enable the Serverless module, Serverless Operator takes care of installation and configuration of Serverless on your cluster. It manages the Serverless lifecycle based on the dedicated Serverless custom resource (CR). -## Useful links +## Useful Links If you want to perform some simple and more advanced tasks, check the [Serverless tutorials](tutorials/README.md). @@ -40,4 +40,4 @@ To troubleshoot Serverless-related issues, see the [troubleshooting guides](trou To analyze Function specification and configuration files and to understand technicalities behind Serverless implementation, visit [technical reference](technical-reference/README.md). -For more information on the Serverless custom resources, see [Resources](resources/README.md) \ No newline at end of file +For more information on the Serverless custom resources, see [Resources](resources/README.md). diff --git a/docs/user/resources/06-20-serverless-cr.md b/docs/user/resources/06-20-serverless-cr.md index 802d0ce0a..103c89044 100644 --- a/docs/user/resources/06-20-serverless-cr.md +++ b/docs/user/resources/06-20-serverless-cr.md @@ -1,6 +1,4 @@ ---- -title: Serverless ---- +# Serverless The `serverlesses.operator.kyma-project.io` CustomResourceDefinition (CRD) is a detailed description of the Serverless configuration that you want to install on your cluster. To get the up-to-date CRD and show the output in the YAML format, run this command: @@ -82,7 +80,6 @@ For details, see the [Serverless specification file](https://github.com/kyma-pro | **defaultBuildJobPreset** | string | Configures the default build Job preset to be used | | **defaultRuntimePodPreset** | string | Configures the default runtime Pod preset to be used | - **Status:** | Parameter | Type | Description | @@ -115,8 +112,7 @@ For details, see the [Serverless specification file](https://github.com/kyma-pro Processing of a Serverless CR can succeed, continue, or fail for one of these reasons: - -# Serverless CR Conditions +## Serverless CR Conditions This section describes the possible states of the Serverless CR. Three condition types, `Installed`, `Configured` and `Deleted`, are used. @@ -131,4 +127,4 @@ This section describes the possible states of the Serverless CR. Three condition | 6 | Error | Installed | false | InstallationErr | Deployment error | | 8 | Deleting | Deleted | unknown | Deletion | Deletion in progress | | 9 | Deleting | Deleted | true | Deleted | Serverless module deleted | -| 10 | Error | Deleted | false | DeletionErr | Deletion failed | \ No newline at end of file +| 10 | Error | Deleted | false | DeletionErr | Deletion failed | diff --git a/docs/user/resources/README.md b/docs/user/resources/README.md index dea62e719..847fa413c 100644 --- a/docs/user/resources/README.md +++ b/docs/user/resources/README.md @@ -1,3 +1,3 @@ # Resources -In this section, you can find the custom resources (CR) used in the Serverless module. \ No newline at end of file +In this section, you can find the custom resources (CR) used in the Serverless module. diff --git a/docs/user/technical-reference/04-10-architecture.md b/docs/user/technical-reference/04-10-architecture.md index 5d668b36b..d13ae3669 100644 --- a/docs/user/technical-reference/04-10-architecture.md +++ b/docs/user/technical-reference/04-10-architecture.md @@ -4,10 +4,9 @@ Serverless relies heavily on Kubernetes resources. It uses [Deployments](https:/ ![Serverless architecture](../../assets/svls-architecture.svg) -> [!WARNING] +> [!WARNING] > Serverless imposes some requirements on the setup of namespaces. For example, if you apply custom [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) for a new namespace, they must be higher than or equal to the limits for building Jobs' resources. - 1. Create a Function either through the UI or by applying a Function custom resource (CR). This CR contains the Function definition (business logic that you want to execute) and information on the environment on which it should run. 2. Before the Function can be saved or modified, it is first updated and then verified by the defaulting and validation webhooks respectively. @@ -26,4 +25,4 @@ Serverless relies heavily on Kubernetes resources. It uses [Deployments](https:/ 9. FC creates a HorizontalPodAutoscaler that automatically scales the number of Pods in the Deployment based on the observed CPU utilization. -10. FC waits for the Deployment to become ready. \ No newline at end of file +10. FC waits for the Deployment to become ready. diff --git a/docs/user/technical-reference/04-20-internal-registry.md b/docs/user/technical-reference/04-20-internal-registry.md index 193794255..3257f2aa0 100644 --- a/docs/user/technical-reference/04-20-internal-registry.md +++ b/docs/user/technical-reference/04-20-internal-registry.md @@ -17,6 +17,6 @@ See the following diagram to learn how it works: 5. The Kubernetes DNS service resolves the name and provides the IP of the internal Docker registry. > [!NOTE] -> kubelet cannot resolve the in-cluster URL. That's why Serverless uses the NodePort service. +> kubelet cannot resolve the in-cluster URL. That's why Serverless uses the NodePort service. -The NodePort service routing assures that the pull request reaches the internal Docker registry regardless of whether it is from a different node. \ No newline at end of file +The NodePort service routing assures that the pull request reaches the internal Docker registry regardless of whether it is from a different node. diff --git a/docs/user/technical-reference/05-20-env-variables.md b/docs/user/technical-reference/05-20-env-variables.md index cc80593ae..d5574c221 100644 --- a/docs/user/technical-reference/05-20-env-variables.md +++ b/docs/user/technical-reference/05-20-env-variables.md @@ -72,7 +72,6 @@ To configure the Function with the Node.js runtime, override the default values | **REQ_MB_LIMIT** | Specifies the payload body size limit in megabytes. | Number | `1` | | **KYMA_INTERNAL_LOGGER_ENABLED** | Enables the default HTTP request logger which uses the standard Apache combined log output. To enable it, set its value to `true`. | Boolean | `false` | - See the example of a Function with these environment variables set: ```yaml @@ -104,7 +103,7 @@ To configure a Function with the Python runtime, override the default values of | Environment variable | Description | Unit | Default value | | -------------------------------- |---------------------------------------------------------------------------------------------------------------------------- | ------- | --------------- | - **FUNC_MEMFILE_MAX**|for the HTTP request body in bytes. | Number | `100*1024*1024` | | +|**FUNC_MEMFILE_MAX**|for the HTTP request body in bytes. | Number | `100*1024*1024` | | | **CHERRYPY_NUMTHREADS** | Specifies the number of requests that can be handled in parallel | Number | `50` | | **KYMA_INTERNAL_LOGGER_ENABLED** | Enables the default HTTP request logger which uses the standard Apache combined log output. To enable it, set its value to `true`. | Boolean | `false` | diff --git a/docs/user/technical-reference/07-40-git-source-type.md b/docs/user/technical-reference/07-40-git-source-type.md index 18820759d..fe63ee7d8 100644 --- a/docs/user/technical-reference/07-40-git-source-type.md +++ b/docs/user/technical-reference/07-40-git-source-type.md @@ -27,4 +27,5 @@ You can have various setups for your Function's Git source with different: - Function's rebuild triggers - To define whether the Function Controller must monitor a given branch or commit in the Git repository to rebuild the Function upon their changes, use the **spec.source.gitRepository.reference** parameter in the Function CR. \ No newline at end of file + To define whether the Function Controller must monitor a given branch or commit in the Git repository to rebuild the Function upon their changes, use the **spec.source.gitRepository.reference** parameter in the Function CR. + \ No newline at end of file diff --git a/docs/user/technical-reference/07-70-function-specification.md b/docs/user/technical-reference/07-70-function-specification.md index be3bca3d7..442a9d50b 100644 --- a/docs/user/technical-reference/07-70-function-specification.md +++ b/docs/user/technical-reference/07-70-function-specification.md @@ -7,10 +7,11 @@ With the Serverless module, you can create Functions in both Node.js and Python. Function's code is represented by a handler that is a method that processes events. When your Function is invoked, it runs this handler method to process a given request and return a response. All Functions have a predefined signature with elements common for all available runtimes: + - Functions' code must be introduced by the `main` handler name. - Functions must accept two arguments that are passed to the Function handler: - - `event` - - `context` + - `event` + - `context` See these signatures for each runtime: @@ -97,7 +98,6 @@ See the detailed descriptions of these fields: | **tracer** | Fully configured OpenTelemetry [tracer](https://opentelemetry.io/docs/reference/specification/trace/api/#tracer) object that allows you to communicate with the user-defined trace backend service to share tracing data. For more information on how to use the tracer object see [Customize Function traces](../tutorials/01-100-customize-function-traces.md) | | **extensions** | JSON object that can contain event payload, a Function's incoming request, or an outgoing response | - ### Event Object SDK The `event` object is extended by methods making some operations easier. You can use every method by providing `event.{FUNCTION_NAME(ARGUMENTS...)}`. @@ -228,7 +228,7 @@ You can use a custom runtime image to override the existing one. Your image must - Fetch sources from the path under the `KUBELESS_INSTALL_VOLUME` environment - Security support. Kyma runtimes are secure by default. You only need to protect your images. -> [!NOTE] +> [!NOTE] > For better understanding, you can look at the [main Docker files](../../../config/serverless/templates/runtimes.yaml). They are responsible for building the final image based on the `base_image` argument. You, as a user, can override it and what we are doing in [this tutorial](../tutorials/01-110-override-runtime-image.md). Every Function's Pods container has the same system environments, which helps you configure the Functions server. For more information, read the [Environment variables](05-20-env-variables.md) page. diff --git a/docs/user/technical-reference/07-80-available-presets.md b/docs/user/technical-reference/07-80-available-presets.md index 5448cd70c..588eb8cbb 100644 --- a/docs/user/technical-reference/07-80-available-presets.md +++ b/docs/user/technical-reference/07-80-available-presets.md @@ -7,7 +7,7 @@ Function's resources and replicas as well as resources for image-building Jobs a ## Usage -If you want to apply values from a preset to a single Function, override the existing values for a given preset in the Function CR: First, remove the relevant fields from the Function CR and then, add the relevant preset labels. +If you want to apply values from a preset to a single Function, override the existing values for a given preset in the Function CR: First, remove the relevant fields from the Function CR and then, add the relevant preset labels. For example, to modify the default values for **buildResources**, remove all its entries from the Function CR and add an appropriate **serverless.kyma-project.io/build-resources-preset: {PRESET}** label to the Function CR. diff --git a/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md b/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md index afc371ed1..077b02817 100644 --- a/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md +++ b/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md @@ -18,7 +18,7 @@ As a workaround, increase the default capacity up to a maximum of 100 GB by edit kubectl edit pvc -n kyma-system serverless-docker-registry ``` -2. Change the value of **spec.resources.requests.storage** to higher, such as 30 GB, to increase the PVC capacity: +2. Change the value of **spec.resources.requests.storage** to higher, such as 30 GB, to increase the PVC capacity: ```yaml ... @@ -62,6 +62,6 @@ To do this, follow these steps: 3. Search for the `serverless-docker-registry` PVC again to check that the capacity was resized: - ```bash - kubectl get pvc serverless-docker-registry -n kyma-system - ``` \ No newline at end of file + ```bash + kubectl get pvc serverless-docker-registry -n kyma-system + ``` diff --git a/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md b/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md index 90f09e62c..aee50fe99 100644 --- a/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md +++ b/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md @@ -5,42 +5,48 @@ There are rare cases, for some k3d versions and configurations, where users experience Functions failing to be built. Your Function cannot be built and you get the following output: -``` -$ kubectl get functions.serverless.kyma-project.io nyfun -NAME CONFIGURED BUILT RUNNING RUNTIME VERSION AGE -myfun True False nodejs20 1 3h15m -``` + + ```bash + $ kubectl get functions.serverless.kyma-project.io nyfun + NAME CONFIGURED BUILT RUNNING RUNTIME VERSION AGE + myfun True False nodejs20 1 3h15m + ``` + Additionally, the Function build job shows the following error, meaning that your host k3d environment is likely to experience the problem: -``` -$ kubectl logs myfun-build-zqhk8-7xl6h -kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue -``` + + ```bash + $ kubectl logs myfun-build-zqhk8-7xl6h + kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue + ``` ## Cause This problem originates in [kaniko](https://github.com/GoogleContainerTools/kaniko) - the container image build tool used in Kyma. kaniko is designed to be run in a container and this is how it is executed in Kyma (as build jobs). kaniko has a detection mechanism to verify whether the build is actually executed in a container and fails in case it is not. -This detection mechanism has issues and in some circumstances (that is, hosts with cgroups in version 2 or other, not yet clearly identified) it shows a false positive result. +This detection mechanism has issues and in some circumstances (that is, hosts with cgroups in version 2 or other, not yet clearly identified) it shows a false positive result. Related issues: - - https://github.com/kyma-project/kyma/issues/13051 - - https://github.com/GoogleContainerTools/kaniko/issues/1592 - + +- https://github.com/kyma-project/kyma/issues/13051 +- https://github.com/GoogleContainerTools/kaniko/issues/1592 + ## Remedy You can force kaniko to skip the verification by overriding the kaniko execution arguments with the `--force` flag. Introduce a file with overrides, for example `my-overrides.yaml`. -```yaml -serverless: - containers: - manager: - envs: - functionBuildExecutorArgs: - value: --insecure,--skip-tls-verify,--skip-unused-stages,--log-format=text,--cache=true,--use-new-run,--compressed-caching=false,--force -``` + + ```yaml + serverless: + containers: + manager: + envs: + functionBuildExecutorArgs: + value: --insecure,--skip-tls-verify,--skip-unused-stages,--log-format=text,--cache=true,--use-new-run,--compressed-caching=false,--force + ``` Use the file to override the default configuration while deploying Kyma on your k3d instance: -```bash -kyma deploy --values-file my-overrides.yaml -``` + + ```bash + kyma deploy --values-file my-overrides.yaml + ``` diff --git a/docs/user/troubleshooting-guides/03-50-serverless-periodically-restaring.md b/docs/user/troubleshooting-guides/03-50-serverless-periodically-restaring.md index 956b29736..029a6ab12 100644 --- a/docs/user/troubleshooting-guides/03-50-serverless-periodically-restaring.md +++ b/docs/user/troubleshooting-guides/03-50-serverless-periodically-restaring.md @@ -1,6 +1,5 @@ # Serverless Periodically Restarting - ## Symptom When reconciling Git-sourced Functions, Serverless restarts every 10 minutes. @@ -11,4 +10,4 @@ Function Controller is polling for changes in referenced Git repositories. If yo ## Remedy -Avoid using multi-repositories or large repositories to source your git Functions. Using small, dedicated Function repositories decreases the CPU and I/O resources used to check out Git sources, and hence improves the stability of Function Controller. \ No newline at end of file +Avoid using multi-repositories or large repositories to source your git Functions. Using small, dedicated Function repositories decreases the CPU and I/O resources used to check out Git sources, and hence improves the stability of Function Controller. diff --git a/docs/user/troubleshooting-guides/README.md b/docs/user/troubleshooting-guides/README.md index 37c4d15d9..7c26f1045 100644 --- a/docs/user/troubleshooting-guides/README.md +++ b/docs/user/troubleshooting-guides/README.md @@ -2,4 +2,4 @@ The troubleshooting guides aim to identify the most common recurring problems the users face, as well as the most suitable solutions to these problems. -If you can't find a solution, don't hesitate to create a [GitHub](https://github.com/kyma-project/kyma/issues) issue or reach out to our [Slack channel](https://kyma-community.slack.com/) to get direct support from the community. \ No newline at end of file +If you can't find a solution, don't hesitate to create a [GitHub](https://github.com/kyma-project/kyma/issues) issue or reach out to our [Slack channel](https://kyma-community.slack.com/) to get direct support from the community. diff --git a/docs/user/tutorials/01-10-create-inline-function.md b/docs/user/tutorials/01-10-create-inline-function.md index 5610e7ac4..bb7bacb6a 100644 --- a/docs/user/tutorials/01-10-create-inline-function.md +++ b/docs/user/tutorials/01-10-create-inline-function.md @@ -19,11 +19,11 @@ You can create a Function with Kyma dashboard, Kyma CLI, or kubectl: > [!NOTE] > Kyma dashboard uses Busola, which is not installed by default. Follow the [installation instructions](https://github.com/kyma-project/busola/blob/main/docs/install-kyma-dashboard-manually.md). -1. Create a namespace or select one from the drop-down list in the top navigation panel. +1. Create a namespace or select one from the drop-down list in the top navigation panel. -2. Go to **Workloads** > **Functions** and select **Create Function**. +2. Go to **Workloads** > **Functions** and select **Create Function**. -3. In the dialog box, provide the Function's name or click on **Generate**. +3. In the dialog box, provide the Function's name or click on **Generate**. > [!NOTE] > The **Node.js Function** preset is selected by default. It means that the selected runtime is `Node.js`, and the **Source** code is autogenerated. You can choose the Python runtime by clicking on the **Choose preset** button. @@ -40,20 +40,21 @@ You can create a Function with Kyma dashboard, Kyma CLI, or kubectl: }, }; ``` + The dialog box closes. Wait for the **Status** field to change into `RUNNING`, confirming that the Function was created successfully. 1. If you decide to modify it, click **Edit** and confirm changes afterward by selecting the **Update** button. You will see the message at the bottom of the screen confirming the Function was updated. #### **Kyma CLI** -1. Export these variables: +1. Export these variables: ```bash export NAME={FUNCTION_NAME} export NAMESPACE={FUNCTION_NAMESPACE} ``` -2. Create your local development workspace. +2. Create your local development workspace. a. Create a new folder to keep the Function's code and configuration in one place: @@ -68,7 +69,7 @@ The dialog box closes. Wait for the **Status** field to change into `RUNNING`, c kyma init function --name $NAME --namespace $NAMESPACE ``` -3. Code and configure. +3. Code and configure. Open the workspace in your favorite IDE. If you have Visual Studio Code installed, run the following command from the terminal in your workspace folder: @@ -78,7 +79,7 @@ The dialog box closes. Wait for the **Status** field to change into `RUNNING`, c It's time to inspect the code and the `config.yaml` file. Feel free to adjust the "Hello World" sample code. -4. Deploy and verify. +4. Deploy and verify. a. Call the `apply` command from the workspace folder. It will build the container and run it on the Kyma runtime pointed by your current KUBECONFIG file: @@ -101,14 +102,14 @@ The dialog box closes. Wait for the **Status** field to change into `RUNNING`, c #### **kubectl** -1. Export these variables: +1. Export these variables: ```bash export NAME={FUNCTION_NAME} export NAMESPACE={FUNCTION_NAMESPACE} ``` -2. Create a Function CR that specifies the Function's logic: +2. Create a Function CR that specifies the Function's logic: ```bash cat < **Functions** > **Create Function**. -4. Provide or generate the Function's name. +4. Provide or generate the Function's name. 5. Go to **Advanced**, change **Source Type** from **Inline** to **Git Repository**. - + 6. Choose `JavaScript` from the **Language** dropdown and select the proper runtime. 7. Click on the **Git Repository** section and enter the following values: @@ -52,9 +52,9 @@ You can create a Function either with kubectl or Kyma dashboard: - **Base Dir**:`orders-service/function` - **Reference**:`main` - > [!NOTE] + > [!NOTE] > If you want to connect a secured repository instead of a public one, toggle the **Auth** switch. In the **Auth** section, choose **Secret** from the list and choose the preferred type. - + 8. Click **Create**. After a while, a message confirms that the Function has been created. @@ -75,7 +75,7 @@ You can create a Function either with kubectl or Kyma dashboard: - Basic authentication (username and password or token) to this repository in the same namespace as the Function: - 1. Generate a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) and copy it. + 1. Generate a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) and copy it. 2. Create a Secret containg your username and the generated token. ```bash @@ -84,12 +84,14 @@ You can create a Function either with kubectl or Kyma dashboard: - SSH key: - 1. Generate a new SSH key pair (private and public). Follow [this tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) to learn how to do it. Alternatively, you can use the existing pair. + 1. Generate a new SSH key pair (private and public). Follow [this tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) to learn how to do it. Alternatively, you can use the existing pair. 2. Install the generated private key in Kyma, as a Kubernetes Secret that lives in the same namespace as your Function. + ```bash kubectl -n $NAMESPACE create secret generic git-creds-ssh --from-file=key={PATH_TO_THE_FILE_WITH_PRIVATE_KEY} ``` - 3. Configure the public key in GitHub. Follow the steps described in [this tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). + + 3. Configure the public key in GitHub. Follow the steps described in [this tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). > [!NOTE] > Read more about the [supported authentication methods](../technical-reference/07-40-git-source-type.md). @@ -123,7 +125,7 @@ You can create a Function either with kubectl or Kyma dashboard: type: # "basic" or "key" secretName: # "git-creds-basic" or "git-creds-key" ``` - + > [!NOTE] > To avoid performance degradation caused by large Git repositories and large monorepos, [Function Controller](../resources/06-10-function-cr.md#related-resources-and-components) implements a configurable backoff period for the source checkout based on `APP_FUNCTION_REQUEUE_DURATION`. If you want to allow the controller to perform the source checkout with every reconciliation loop, disable the backoff period by marking the Function CR with the annotation `serverless.kyma-project.io/continuousGitCheckout: true` diff --git a/docs/user/tutorials/01-120-inject-envs.md b/docs/user/tutorials/01-120-inject-envs.md index 440e9515d..abe22e6c2 100644 --- a/docs/user/tutorials/01-120-inject-envs.md +++ b/docs/user/tutorials/01-120-inject-envs.md @@ -37,6 +37,7 @@ kubectl create secret generic my-secret --from-literal secret-env="I come from s ``` 4. Define environment variables as part of the Function configuration file. Modify `config.yaml` with the following: + ```yaml name: my-function namespace: default @@ -57,7 +58,9 @@ kubectl create secret generic my-secret --from-literal secret-env="I come from s name: my-secret key: secret-env ``` + 5. Use injected environment variables in the handler file. Modify `handler.js` with the following: + ```js module.exports = { main: function (event, context) { diff --git a/docs/user/tutorials/01-130-use-external-scalers.md b/docs/user/tutorials/01-130-use-external-scalers.md index 983cd7759..198933765 100644 --- a/docs/user/tutorials/01-130-use-external-scalers.md +++ b/docs/user/tutorials/01-130-use-external-scalers.md @@ -190,6 +190,6 @@ Follow these steps: scaled-function serverless.kyma-project.io/v1alpha2.Function scaled-function 1 5 prometheus True True Unknown 4m15s ``` -Check out this [example](https://github.com/kyma-project/keda-manager/tree/main/examples/scale-to-zero-with-keda) to see how to use Kyma Serverless and Eventing in combination with Keda to accomplish scaling to zero. +Check out this [example](https://github.com/kyma-project/keda-manager/tree/main/examples/scale-to-zero-with-keda) to see how to use Kyma Serverless and Eventing in combination with Keda to accomplish scaling to zero. diff --git a/docs/user/tutorials/01-140-use-secret-mounts.md b/docs/user/tutorials/01-140-use-secret-mounts.md index 55077eac5..c0a5de595 100644 --- a/docs/user/tutorials/01-140-use-secret-mounts.md +++ b/docs/user/tutorials/01-140-use-secret-mounts.md @@ -31,7 +31,7 @@ Follow these steps: kubectl -n $NAMESPACE create secret generic $SECRET_NAME \ --from-literal=$SECRET_DATA_KEY={SECRET_DATA_VALUE} ``` - + 3. Create your Function with `secretMounts`: ```bash @@ -106,16 +106,18 @@ Follow these steps: 6. Next steps: Now you can edit the Secret and see if the Function returns the new value from the Secret. - + To edit your Secret, use: + ```bash kubectl -n $NAMESPACE edit secret $SECRET_NAME ``` - + To encode values used in `data` from the Secret, use `base64`, for example: + ```bash echo -n '{NEW_SECRET_DATA_VALUE}' | base64 ``` - Calling the Function again (using `curl`) must return `{NEW_SECRET_DATA_VALUE}`. + Calling the Function again (using `curl`) must return `{NEW_SECRET_DATA_VALUE}`. Note that the Secret propagation may take some time, and the call may initially return the old value. diff --git a/docs/user/tutorials/01-20-expose-function.md b/docs/user/tutorials/01-20-expose-function.md index 9841614e4..053fff64d 100644 --- a/docs/user/tutorials/01-20-expose-function.md +++ b/docs/user/tutorials/01-20-expose-function.md @@ -14,7 +14,7 @@ Read also about [Function’s specification](../technical-reference/07-70-functi ## Prerequisites - [Existing Function](01-10-create-inline-function.md) -- [API Gateway component installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/02-install-kyma/#install-specific-components) +- [API Gateway component installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/02-install-kyma/#install-specific-components) ## Steps @@ -57,6 +57,7 @@ You can expose a Function with Kyma dashboard, Kyma CLI, or kubectl: export NAME={FUNCTION_NAME} export NAMESPACE={NAMESPACE_NAME} ``` + > [!NOTE] > The Function takes the name from the Function CR name. The APIRule CR can have a different name but for the purpose of this tutorial, all related resources share a common name defined under the **NAME** variable. 2. Download the latest configuration of the Function from the cluster. This way, you update the local `config.yaml` file with the Function's code. diff --git a/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md b/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md index ddd6d8e9d..d6ef52499 100644 --- a/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md +++ b/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md @@ -36,7 +36,7 @@ Follow these steps: The `init` command creates these files in your workspace folder: - - `config.yaml` with the Function's configuration + - `config.yaml` with the Function's configuration > [!NOTE] > See the detailed description of all fields available in the [`config.yaml` file](../technical-reference/07-60-function-configuration-file.md). diff --git a/docs/user/tutorials/01-40-debug-function.md b/docs/user/tutorials/01-40-debug-function.md index 558be92fa..99067a9a8 100644 --- a/docs/user/tutorials/01-40-debug-function.md +++ b/docs/user/tutorials/01-40-debug-function.md @@ -3,6 +3,7 @@ This tutorial shows how to use an external IDE to debug a Function in Kyma CLI. ## Steps + Learn how to debug a Function with Visual Studio Code for Node.js or Python, or GoLand: @@ -14,6 +15,7 @@ Learn how to debug a Function with Visual Studio Code for Node.js or Python, or 3. In the `.vscode` directory, create the `launch.json` file with the following content: For Node.js: + ```json { "version": "0.2.0", @@ -33,7 +35,9 @@ Learn how to debug a Function with Visual Studio Code for Node.js or Python, or ] } ``` + For Python: + ```json { "version": "0.2.0", @@ -58,6 +62,7 @@ Learn how to debug a Function with Visual Studio Code for Node.js or Python, or ``` 4. Run the Function with the `--debug` flag. + ```bash kyma run function --debug ``` @@ -70,6 +75,7 @@ Learn how to debug a Function with Visual Studio Code for Node.js or Python, or - Host: `localhost` - Port: `9229` 4. Run the Function with the `--debug` flag. + ```bash kyma run function --debug ``` diff --git a/docs/user/tutorials/01-50-sync-function-with-gitops.md b/docs/user/tutorials/01-50-sync-function-with-gitops.md index 14aabcba8..1a21e66bd 100644 --- a/docs/user/tutorials/01-50-sync-function-with-gitops.md +++ b/docs/user/tutorials/01-50-sync-function-with-gitops.md @@ -44,6 +44,7 @@ These sections will lead you through the whole installation, configuration, and ```bash kubectl apply -f https://raw.githubusercontent.com/kyma-project/serverless/main/components/serverless/config/crd/bases/serverless.kyma-project.io_functions.yaml ``` + 4. Run this command to make sure the CRs are applied: ```bash @@ -69,7 +70,7 @@ These sections will lead you through the whole installation, configuration, and This command will download the following files to your workspace folder: - - `config.yaml` with the Function's configuration + - `config.yaml` with the Function's configuration - `handler.py` with the Function's code and the simple "Hello World" logic - `requirements.txt` with an empty file for your Function's custom dependencies @@ -170,6 +171,7 @@ In this section, you will create a sample inline Function. ```bash git clone https://github.com/${GH_USER}/${GH_REPO}.git ``` + > [!NOTE] > You can also clone the repository using SSH. To do that, you need to [generate a new SSH key and add it to the ssh-agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent). @@ -212,6 +214,7 @@ In this section, you will create a sample inline Function. ```bash kubectl get functions ``` + You can see that Flux synchronized the resource and the new Function CR was added to your cluster. ## Reverting Feature diff --git a/docs/user/tutorials/01-60-set-external-registry.md b/docs/user/tutorials/01-60-set-external-registry.md index 0abc182b5..e257e6861 100644 --- a/docs/user/tutorials/01-60-set-external-registry.md +++ b/docs/user/tutorials/01-60-set-external-registry.md @@ -240,6 +240,5 @@ Deploy Kyma with different configuration for Docker registry . Run: kyma deploy --values-file docker-registry-overrides.yaml ``` -> [!NOTE] +> [!NOTE] > To learn more, read about [changing Kyma configuration](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/03-change-kyma-config-values). - diff --git a/docs/user/tutorials/01-90-set-asynchronous-connection.md b/docs/user/tutorials/01-90-set-asynchronous-connection.md index 29992247b..840d27124 100644 --- a/docs/user/tutorials/01-90-set-asynchronous-connection.md +++ b/docs/user/tutorials/01-90-set-asynchronous-connection.md @@ -9,7 +9,6 @@ This tutorial shows only one possible use case. There are many more use cases on ## Prerequisites - - [Kyma CLI](https://github.com/kyma-project/cli) - [Eventing and Istio components installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/02-install-kyma/#install-specific-components) @@ -33,7 +32,7 @@ This tutorial shows only one possible use case. There are many more use cases on The `init` command creates these files in your workspace folder: - - `config.yaml` with the Function's configuration + - `config.yaml` with the Function's configuration > [!NOTE] > See the detailed description of all fields available in the [`config.yaml` file](../technical-reference/07-60-function-configuration-file.md). @@ -84,6 +83,7 @@ This tutorial shows only one possible use case. There are many more use cases on return data } ``` + The `sap.kyma.custom.acme.payload.sanitised.v1` is a sample event type that the emitter Function declares when publishing events. You can choose a different one that better suits your use case. Keep in mind the constraints described on the [Event names](https://kyma-project.io/docs/kyma/latest/05-technical-reference/evnt-01-event-names/) page. The receiver subscribes to the event type to consume the events. The event object provides convenience functions to build and publish events. To send the event, build the Cloud Event. To learn more, read [Function's specification](../technical-reference/07-70-function-specification.md#event-object-sdk). In addition, your **eventOut.source** key must point to `“kyma”` to use Kyma in-cluster Eventing. @@ -94,6 +94,7 @@ This tutorial shows only one possible use case. There are many more use cases on ```bash kyma apply function ``` + Your Function is now built and deployed in Kyma runtime. Kyma exposes it through the APIRule. The incoming payloads are processed by your emitter Function. It then sends the sanitized content to the workload that subscribes to the selected event type. In our case, it's the receiver Function. 5. Test the first Function. Send the payload and see if your HTTP traffic is accepted: @@ -107,9 +108,11 @@ This tutorial shows only one possible use case. There are many more use cases on ### Create the Receiver Function 1. Go to your `receiver` folder and run Kyma CLI `init` command to initialize the scaffold for your second Function: + ```bash kyma init function ``` + The `init` command creates the same files as in the `emitter` folder. 2. In the `config.yaml` file, configure event types your Function will subscribe to: @@ -129,14 +132,15 @@ This tutorial shows only one possible use case. There are many more use cases on schemaVersion: v1 ``` -3. Apply your receiver Function: +3. Apply your receiver Function: ```bash kyma apply function ``` - + The Function is configured, built, and deployed in Kyma runtime. The Subscription becomes active and all events with the selected type are processed by the Function. -### Test the whole setup +### Test the Whole Setup + Send a payload to the first Function. For example, use the POST request mentioned above. As the Functions are joined by the in-cluster Eventing, the payload is processed in sequence by both of your Functions. In the Function's logs, you can see that both sanitization logic (using the first Function) and the storing logic (using the second Function) are executed. diff --git a/docs/user/tutorials/README.md b/docs/user/tutorials/README.md index d9cfb8a9d..9edc9149d 100644 --- a/docs/user/tutorials/README.md +++ b/docs/user/tutorials/README.md @@ -1,3 +1,3 @@ # Tutorials -This section will help you understand how the Serverless Function works and how to use it in different scenarios. You can also learn how to set and switch a Docker registry. \ No newline at end of file +This section will help you understand how the Serverless Function works and how to use it in different scenarios. You can also learn how to set and switch a Docker registry. diff --git a/markdown_heading_capitalization.js b/markdown_heading_capitalization.js new file mode 100644 index 000000000..7077d5c16 --- /dev/null +++ b/markdown_heading_capitalization.js @@ -0,0 +1,31 @@ +// This file is used to trigger the custom rule that checks if all markdown headings (words longer than 4 characters) are written in the title case. To run this check, you must include the check in the markdownlint command. +// For example, if you want to run the check on the `docs` folder, run the following command: `markdownlint -r ./markdown_heading_capitalization.js docs/`. +module.exports = [{ + "names": [ "custom/capitalize-headings" ], + "description": "Heading words longer than 4 characters should be capitalized", + "tags": [ "formatting" ], + "function": function rule(params, onError) { + params.tokens.filter(function filterToken(token) { + return token.type === "heading_open"; + }).forEach(function forToken(heading) { + var headingTokenContent = heading.line.trim(); + var wordsInHeading = headingTokenContent.split(' '); + + for (var i = 0; i < wordsInHeading.length; i++) { + if (wordsInHeading[i].length > 4 && wordsInHeading[i] && + wordsInHeading[i].charAt(0) !== wordsInHeading[i].charAt(0).toUpperCase()) { + var capitalizedWord = wordsInHeading[i].charAt(0).toUpperCase() + wordsInHeading[i].slice(1); + var detailMessage = "Change " + "'" + wordsInHeading[i] + "'" + " to " + "'" + capitalizedWord + "'"; + + onError({ + "lineNumber": heading.lineNumber, + "detail": detailMessage, + "context": headingTokenContent, // Show the whole heading as context + "range": [headingTokenContent.indexOf(wordsInHeading[i]), wordsInHeading[i].length] // Underline the word which needs a change + }); + } + } + }); + } + }]; + \ No newline at end of file