From 67a90e85d4ebf4689fc0574abcb8bb3b1e4cea58 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Wed, 8 Oct 2025 22:24:59 +0200 Subject: [PATCH 1/4] chore(serverless-containers): concept categories test --- pages/serverless-containers/concepts.mdx | 165 ++++++++++-------- pages/serverless-containers/faq.mdx | 8 +- .../how-to/add-trigger-to-a-container.mdx | 2 +- 3 files changed, 95 insertions(+), 80 deletions(-) diff --git a/pages/serverless-containers/concepts.mdx b/pages/serverless-containers/concepts.mdx index 0ee7c68906..d33b3f0510 100644 --- a/pages/serverless-containers/concepts.mdx +++ b/pages/serverless-containers/concepts.mdx @@ -7,11 +7,6 @@ dates: --- import ServerlessConcepts from '@macros/serverless/serverless-concepts.mdx' - -## Arguments - -See [Commands and arguments](#commands-and-arguments) below. - ## Autoscaling Autoscaling refers to the ability of Serverless Containers to automatically adjust the number of instances without manual intervention. @@ -24,6 +19,22 @@ Autoscaling parameters are [min-scale](/serverless-containers/concepts/#min-scal Refer to the [dedicated documentation](/serverless-containers/reference-content/containers-autoscaling/) for more information on autoscaling. +### Min scale + +Customizing the minimum scale for Serverless can help ensure that an instance remains pre-allocated and ready to handle requests, reducing delays associated with [cold starts](#cold-start). However, this setting also impacts the costs of your Serverless Container. + +For **CPU** and **RAM** based autoscaling, min-scale value must be at least `1`. + +### Max scale + +This parameter sets the maximum number of container instances. + +You should adjust it based on your container's traffic spikes, keeping in mind that you may wish to limit the maximum scale to manage costs effectively while provisioning enough containers to handle spikes. + +### Scale to zero + +When provisioned with a [minimum scale](#min-scale) of `0`, Serverless Containers scale down to zero active instances as long as they are not triggered. While idling, they do not consume any resources, which allows to reduce the cost of your infrastructure. + ## Cold start Cold start is the time a Container takes to handle a request when it is called for the first time. @@ -54,6 +65,10 @@ args: ["$(MESSAGE)"] Refer to the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/) for more information on commands and arguments behavior. +### Arguments + +See [Commands and arguments](#commands-and-arguments). + ## Concurrency Concurrency defines the number of simultaneous requests a single instance of your container can handle at the same time. Once the number of incoming requests exceeds this value, your container scales according to your parameters. @@ -62,7 +77,7 @@ Refer to the [dedicated documentation](/serverless-containers/reference-content/ ## Container -A container is a package of software that includes all dependencies: code, runtime, configuration, and system libraries so that it can run on any host system. Scaleway provides custom Docker images that are entirely handled for you in the cloud. +A container is a package of software that includes all dependencies: code, runtime, configuration, and system libraries so that it can run on any host system. ## Container image @@ -70,26 +85,20 @@ A container image is a file that includes all the requirements and instructions ## Container Registry -Container Registry is the place where your images are stored before being deployed. We recommend using Scaleway Container Registry for optimal integration. See the [migration guide](/serverless-containers/api-cli/migrate-external-image-to-scaleway-registry/) for full details. - -## CRON trigger - -A CRON trigger is a mechanism used to automatically invoke a Serverless Container at a specific time on a recurring schedule. - -It works similarly to a traditional Linux [cron job](https://en.wikipedia.org/wiki/Cron), using the `* * * * *` format, and uses the **UTC** time zone. Refer to our [cron schedules reference](/serverless-containers/reference-content/cron-schedules/) for more information. - -## Custom domain - -By default, a generated endpoint is assigned to your Serverless resource. Custom domains allow you to use your own domain - see our [custom domain documentation](/serverless-containers/how-to/add-a-custom-domain-to-a-container) for full details. +Container Registry is the place where your images are stored before being deployed. We recommend using Scaleway Container Registry for optimal integration and performances. See the [migration guide](/serverless-containers/api-cli/migrate-external-image-to-scaleway-registry/) for full details. ## Deployment -Some parameter changes require a new deployment of the container to take effect. The deployment happens without causing downtime, as traffic is switched to the newest version. +Some parameter changes require a new deployment of the container to take effect. The deployment happens without causing downtime, as traffic is switched to the newest version once it's ready. ## Endpoint An endpoint is the URL generated to access your resource. It can be customized with [custom domains](#custom-domain). +### Custom domain + +By default, a generated endpoint is assigned to your Serverless resource. Custom domains allow you to use your own domain - see our [custom domain documentation](/serverless-containers/how-to/add-a-custom-domain-to-a-container) for full details. + ## Environment variables Environment variables are key/value pairs injected into your container. They are useful to share information such as configurations with your container. Environment variables defined at the container level override the ones defined at the namespace level if they have the same name. @@ -98,18 +107,10 @@ Some names are reserved. [See details about reserved names](/serverless-containe ## Ephemeral storage -In addition to vCPU and RAM, Serverless Containers also provide a storage volume for the duration of the task. This storage space allows you to hold the data retrieved by the job, and disappears once the execution is complete. +In addition to vCPU and RAM, Serverless Containers also provide a storage volume for the duration of the task. This storage space allows you to hold data during the life of the Servlerless Container instance and disappears once the execution is complete. The maximum size of the ephemeral storage is tied to the allocated memory. -## GB-s - -Unit used to measure the resource consumption of a container. It reflects the amount of memory consumed over time. - -## gRPC - -gRPC is supported on Serverless Containers, as long as you have enabled http2 (`h2c`) protocol. - ## Health check To determine the status of a container, the default health check automatically checks if basic requirements are met, to define the status as `ready`. You can customize the following elements to better fit your use case: @@ -126,49 +127,26 @@ You can define custom health check rules via the [Scaleway console](/serverless- A Serverless Container instance handles incoming requests based on factors like the request volume, min scale, and max scale parameters. -## JWT Token - -JWT (JSON Web Token) is an access token you can create from the console or API to enable an application to access your private container. [Find out how to secure a container](/serverless-containers/how-to/secure-a-container/#restrict-access-to-your-containers). - ## Load balancing The Serverless infrastructure manages incoming request traffic. In scenarios like sudden traffic spikes or load testing, resources are automatically scaled based on the max scale parameter to handle the load. -## Logging +## Monitoring -Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information. +### Logging -## Max scale - -This parameter sets the maximum number of container instances. You should adjust it based on your container's traffic spikes, keeping in mind that you may wish to limit the maximum scale to manage costs effectively. +Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information. -## Metrics +### Metrics Performance metrics for your Serverless resources are natively available. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information. -## Min scale - -Customizing the minimum scale for Serverless can help ensure that an instance remains pre-allocated and ready to handle requests, reducing delays associated with cold starts. However, this setting also impacts the costs of your Serverless Container. - -## mvCPU - -A [vCPU](#vcpu) (Virtual Central Processing Unit) is equivalent to 1000 mvCPU. - ## Namespace -A namespace is a project that allows you to [group your containers](/serverless-containers/how-to/create-manage-delete-containers-namespace/). +A namespace is a folder with some settings that allows you to [group your containers](/serverless-containers/how-to/create-manage-delete-containers-namespace/). Containers in the same namespace can share environment variables, secrets, and access tokens, defined at the namespace level. -## NATS trigger - -A NATS trigger is a mechanism that connects a container to a [NATS](/nats/concepts/#nats) subject and invokes the container automatically whenever a message is published to the subject. - -For each message that is sent to a NATS subject, the NATS trigger reads the message and invokes the associated container with the message as the input parameter. -The container can then process the message and perform any required actions, such as updating a database or sending a notification. - -Refer to the [dedicated documenation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. - ## Port The port of a containerized application refers to the network port that the application inside the container listens on for incoming requests. @@ -179,6 +157,10 @@ Refer to the [dedicated documentation](/serverless-containers/reference-content/ A container's privacy policy defines whether a container may be invoked anonymously (**public**) or only via an authentication mechanism provided by the [Scaleway API](https://www.scaleway.com/en/developers/api/serverless-containers/#authentication) (**private**). +### JWT Token + +JWT (JSON Web Token) is an access token you can create to enable an application to access your `private` container. [Find out how to restrict access to a container](/serverless-containers/how-to/secure-a-container/#restrict-access-to-your-containers). + ## Private Networks Scaleway Serverless Containers support Private Networks. @@ -187,7 +169,7 @@ Private Networks let you connect Scaleway resources across multiple AZs within t **D**ynamic **H**ost **C**onfiguration **P**rotocol (DHCP) is built into each Private Network, making it easy to manage the private IP addresses of your resources on the network. -Read our dedicated documentation on [creating a Private Network](/vpc/how-to/create-private-network/). +Read our dedicated documentation on [use Private Networks](/serverless-containers/how-to/use-private-networks/). Previously, Private Networks at Scaleway were zoned. Only resources from within one defined AZ could be attached to each network. Now, all Private Networks are regional, and resources from any AZ within that network's region can be attached. "Old" zoned Private Networks have all been automatically migrated to become regional. @@ -195,15 +177,6 @@ Previously, Private Networks at Scaleway were zoned. Only resources from within While DHCP is built into all new Private Networks, it may not be automatically activated for older Private Networks. Check our [migration](/vpc/reference-content/vpc-migration/) documentation for more information. -## Queue trigger - -A queue trigger is a mechanism that connects a container to a queue created with [Scaleway Queues](/queues/concepts/#scaleway-queues), and invokes the container automatically whenever a message is added to the queue. - -For each message that is sent to a queue, the trigger reads the message and invokes the associated container with the message as the input parameter. -The container can then process the message, and perform any required actions, such as updating a database or sending a notification. - -Refer to the [dedicated documenation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. - ## Registry endpoint The registry endpoint parameter is the resource linked to the container image used in your Serverless Container. @@ -234,14 +207,12 @@ A sandbox is an isolation area for your container. Serverless Containers offer t Refer to the [dedicated documentation](/serverless-containers/reference-content/containers-sandbox/) for more information on sandbox environments. -## Scale to zero - -When provisioned with a [minimum scale](#min-scale) of `0`, Serverless Containers scale down to zero active instances as long as they are not triggered. While idling, they do not consume any resources, which allows to reduce the cost of your infrastructure. - ## Secrets Secrets are an extra-secure type of environment variable. They are environment variables that are injected into your container and stored securely, but not displayed in the console after initial validation. Secrets defined at the container level override the ones defined at the namespace level if they have the same name. +Secrets on Serverless Containers are not linked with Secret Manager product yet. + ## Serverless Serverless allows you to deploy your Functions (FaaS) and Containerized Applications (CaaS) in a managed infrastructure. Scaleway ensures the deployment, availability, and scalability of all your projects. @@ -269,18 +240,37 @@ A Serverless Container can have the following statuses: * **Pending**: your resource is under deployment. * **Error**: something went wrong during the deployment process. [Check our troubleshooting documentation](/serverless-containers/troubleshooting/cannot-deploy-image) to solve the issue. -## Terraform/OpenTofu +## Triggers -Terraform/OpenTofu is a tool for managing infrastructure using code. [Read the Terraform/OpenTofu documentation for Serverless Containers](https://registry.terraform.io/providers/scaleway/scaleway/latest/docs/resources/container). +### CRON trigger -## vCPU +A CRON trigger is a mechanism used to automatically invoke a Serverless Container at a specific time on a recurring schedule. -vCPU is the abbreviation for **v**irtual **C**entralized **P**rocessing **U**nit. A vCPU represents a portion or share of the underlying physical CPU assigned to a particular container. -The performance of a vCPU is determined by the percentage of time spent on the physical processor's core. It is possible to allocate different resource allowances on specific vCPUs for specific containers or virtual machines. +It works similarly to a traditional Linux [cron job](https://en.wikipedia.org/wiki/Cron), using the `* * * * *` format, and uses the **UTC** time zone. Refer to our [cron schedules reference](/serverless-containers/reference-content/cron-schedules/) for more information. -## vCPU-s +It allows Serverless Containers to execute scheduled tasks, like managing other resources, generating backups and waking up the Container at specific times. -Unit used to measure the resource consumption of a container. It reflects the amount of vCPU used over time. +### Queue trigger + +A queue trigger is a mechanism that connects a container to a queue created with [Scaleway Queues](/queues/concepts/#scaleway-queues), and invokes the container automatically whenever a message is added to the queue. + +For each message that is sent to a queue, the trigger reads the message and invokes the associated container with the message as the input parameter. +The container can then process the message, and perform any required actions, such as updating a database or sending a notification. + +Refer to the [dedicated documenation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. + +### NATS trigger + +A NATS trigger is a mechanism that connects a container to a [NATS](/nats/concepts/#nats) subject and invokes the container automatically whenever a message is published to the subject. + +For each message that is sent to a NATS subject, the NATS trigger reads the message and invokes the associated container with the message as the input parameter. +The container can then process the message and perform any required actions, such as updating a database or sending a notification. + +Refer to the [dedicated documenation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. + +## Terraform/OpenTofu + +Terraform/OpenTofu is a tool for managing infrastructure using code. [Read the Terraform/OpenTofu documentation for Serverless Containers](https://registry.terraform.io/providers/scaleway/scaleway/latest/docs/resources/container). ## Protocol @@ -289,3 +279,26 @@ Serverless Containers supports **http1** (default) and **http2** (`h2c`). Use HT HTTP/1.0 is not supported. Refer to the [dedicated troubleshooting page](/serverless-containers/troubleshooting/http1-errors/) for more information. + +### gRPC + +gRPC is supported on Serverless Containers, as long as you have enabled http2 (`h2c`) protocol. + +## Units + +### vCPU + +vCPU is the abbreviation for **v**irtual **C**entralized **P**rocessing **U**nit. A vCPU represents a portion or share of the underlying physical CPU assigned to a particular container. +The performance of a vCPU is determined by the percentage of time spent on the physical processor's core. It is possible to allocate different resource allowances on specific vCPUs for specific containers or virtual machines. + +### mvCPU + +A [vCPU](#vcpu) (Virtual Central Processing Unit) is equivalent to 1000 mvCPU. + +### vCPU-s + +Unit used to measure the resource consumption of a container. It reflects the amount of vCPU used over time in seconds. + +### GB-s + +Unit used to measure the RAM consumption of a container. It reflects the amount of memory consumed over time in seconds. diff --git a/pages/serverless-containers/faq.mdx b/pages/serverless-containers/faq.mdx index 6e5b96e9ac..3917d9f188 100644 --- a/pages/serverless-containers/faq.mdx +++ b/pages/serverless-containers/faq.mdx @@ -125,7 +125,7 @@ Refer to the [dedicated documentation](/serverless-containers/reference-content/ ### Which protocols are supported by Serverless Containers? -Serverless Containers support **http1** and **http2**. **http1** is enabled by default, but some services (e.g., gRPC) only support **http2**. +Serverless Containers support **HTTP/1.1** and **HTTP/2**. **HTTP/1.1** is enabled by default, but some services (e.g., gRPC) only support **http2**. You can [modify the protocol](/serverless-containers/how-to/manage-a-container/#manage-a-deployment-from-the-scaleway-container-registry) used by your container from the **Requests tab** of the **Advanced options**. @@ -261,7 +261,7 @@ Yes, you can [redirect all inbound HTTP connections to HTTPS](/serverless-contai ### Can I whitelist the IPs of my containers? -Scaleway Serverless Containers support [Virtual Private Cloud (VPC)](/vpc/) and can be attached to a Private Network, which allows you to securely connect your resources in an isolated environment. Refer to the [dedicated documentation](/serverless-containers/how-to/use-private-networks/) for more information. +Scaleway Serverless Containers supports [Virtual Private Cloud (VPC)](/vpc/) and can be attached to a Private Network, which allows you to securely connect your resources in an isolated environment. Refer to the [dedicated documentation](/serverless-containers/how-to/use-private-networks/) for more information. ### How can I configure access to a Private Network or Virtual Private Cloud (VPC)? @@ -277,6 +277,8 @@ Insufficient vCPU, RAM or ephemeral storage can lead to containers going to erro We recommend you set high values, [use metrics to monitor](/serverless-containers/how-to/monitor-container/) the resource usage of your container, then adjust the values accordingly. +A RAM value too low can lead to restarts of Containers due to out of memory errors. + ## Support and troubleshooting ### Why does my gRPC container not respond? @@ -298,4 +300,4 @@ Ensure that your code avoids heavy computations or long-running initialization a ### Why does my container have an instance running after deployment, even with min-scale 0? -Currently, a new container instance will always start after each deployment, even if there is no traffic and the minimum scale is set to 0. This behavior is not configurable at this time. \ No newline at end of file +Currently, a new container instance will always start after each deployment, even if there is no traffic and the minimum scale is set to 0. This behavior is not configurable at this time. diff --git a/pages/serverless-containers/how-to/add-trigger-to-a-container.mdx b/pages/serverless-containers/how-to/add-trigger-to-a-container.mdx index 544c51077b..2738f5b9cb 100644 --- a/pages/serverless-containers/how-to/add-trigger-to-a-container.mdx +++ b/pages/serverless-containers/how-to/add-trigger-to-a-container.mdx @@ -24,7 +24,7 @@ A trigger can be an HTTP request, a message from a queue or stream, a CRON sched - [Created a queue](/queues/how-to/create-manage-queues/) -You can create triggers on private containers, but to update the privacy of a container from **public** to **private**, you must recreate the existing **Scaleway Queues** and **Scaleway NATS** triggers after the privacy change. We are actively working to make this operation as seamless as possible. +You can create triggers on **private** containers, but to update the privacy of a container from **public** to **private**, you must recreate the existing **Scaleway Queues** and **Scaleway NATS** triggers after the privacy change. We are actively working to make this operation as seamless as possible. From 5d59f3b3f7b16369a4b427a67d698c033e922a98 Mon Sep 17 00:00:00 2001 From: Thomas TACQUET Date: Fri, 10 Oct 2025 09:40:31 +0200 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Benedikt Rollik --- pages/serverless-containers/concepts.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/serverless-containers/concepts.mdx b/pages/serverless-containers/concepts.mdx index d33b3f0510..4391ba3fec 100644 --- a/pages/serverless-containers/concepts.mdx +++ b/pages/serverless-containers/concepts.mdx @@ -23,7 +23,7 @@ Refer to the [dedicated documentation](/serverless-containers/reference-content/ Customizing the minimum scale for Serverless can help ensure that an instance remains pre-allocated and ready to handle requests, reducing delays associated with [cold starts](#cold-start). However, this setting also impacts the costs of your Serverless Container. -For **CPU** and **RAM** based autoscaling, min-scale value must be at least `1`. +For **CPU** and **RAM** based autoscaling, the `min-scale` value must be at least `1`. ### Max scale @@ -89,7 +89,7 @@ Container Registry is the place where your images are stored before being deploy ## Deployment -Some parameter changes require a new deployment of the container to take effect. The deployment happens without causing downtime, as traffic is switched to the newest version once it's ready. +Some parameter changes require a new deployment of the container to take effect. The deployment happens without causing downtime, as traffic is switched to the newest version once it is ready. ## Endpoint From be4c3819c3132a8c9f0cb2cdb3946bdf22e9adca Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Tue, 14 Oct 2025 18:06:15 +0200 Subject: [PATCH 3/4] complete some definition --- pages/serverless-containers/concepts.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/pages/serverless-containers/concepts.mdx b/pages/serverless-containers/concepts.mdx index d33b3f0510..45fc5ae6ad 100644 --- a/pages/serverless-containers/concepts.mdx +++ b/pages/serverless-containers/concepts.mdx @@ -133,6 +133,8 @@ The Serverless infrastructure manages incoming request traffic. In scenarios lik ## Monitoring +Monitoring is the process of continuously collecting and analyzing data about your Serverless applications and infrastructure to ensure they are healthy, performing well, and available. + ### Logging Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information. @@ -242,6 +244,10 @@ A Serverless Container can have the following statuses: ## Triggers +For Serverless Containers, a trigger is a setting that can start events that automatically interacts your service. + +A trigger could be an incoming scheduled HTTP request or a message being published to a queue. When the event occurs, the trigger invokes your service to run its code. + ### CRON trigger A CRON trigger is a mechanism used to automatically invoke a Serverless Container at a specific time on a recurring schedule. @@ -286,6 +292,8 @@ gRPC is supported on Serverless Containers, as long as you have enabled http2 (` ## Units +Units are standardized measures of the computational resources, such as processing power and memory, allocated to run your service. The quantity of units you assign determines your application's performance capacity and directly influences its cost. + ### vCPU vCPU is the abbreviation for **v**irtual **C**entralized **P**rocessing **U**nit. A vCPU represents a portion or share of the underlying physical CPU assigned to a particular container. From 84e00b80ca370f9cb2f8ea119d56b361c7edae1a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oc=C3=A9ane?= Date: Wed, 15 Oct 2025 10:26:01 +0200 Subject: [PATCH 4/4] Update pages/serverless-containers/concepts.mdx --- pages/serverless-containers/concepts.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/serverless-containers/concepts.mdx b/pages/serverless-containers/concepts.mdx index b9e1b20769..a1a74c2b74 100644 --- a/pages/serverless-containers/concepts.mdx +++ b/pages/serverless-containers/concepts.mdx @@ -272,7 +272,7 @@ A NATS trigger is a mechanism that connects a container to a [NATS](/nats/concep For each message that is sent to a NATS subject, the NATS trigger reads the message and invokes the associated container with the message as the input parameter. The container can then process the message and perform any required actions, such as updating a database or sending a notification. -Refer to the [dedicated documenation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. +Refer to the [dedicated documentation](/serverless-containers/how-to/add-trigger-to-a-container/) for more information on how to add triggers to a Serverless Container. ## Terraform/OpenTofu