chore(serverless-containers): concept categories test (#5638)

* chore(serverless-containers): concept categories test

* Apply suggestions from code review

Co-authored-by: Benedikt Rollik <[email protected]>

* complete some definition

* Update pages/serverless-containers/concepts.mdx

---------

Co-authored-by: Benedikt Rollik <[email protected]>
Co-authored-by: Océane <[email protected]>

Author: 3 people

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, the `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,34 +77,28 @@ 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
 
 A container image is a file that includes all the requirements and instructions of a complete and executable version of an application.
 
 ## 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 is 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,28 @@ 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.
+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.
 
-## Max scale
+### Logging
 
-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 +159,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,23 +171,14 @@ 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/).
 
 <Message type="note">
 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.
 
 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.
 </Message>
 
-## 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 +209,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 +242,41 @@ 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).
+For Serverless Containers, a trigger is a setting that can start events that automatically interacts your service.
 
-## vCPU
+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.
 
-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.
+### CRON trigger
 
-## vCPU-s
+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.
+
+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 documentation](/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 +285,28 @@ Serverless Containers supports **http1** (default) and **http2** (`h2c`). Use HT
 <Message type="note">
 HTTP/1.0 is not supported. Refer to the [dedicated troubleshooting page](/serverless-containers/troubleshooting/http1-errors/) for more information.
 </Message>
+
+### gRPC
+
+gRPC is supported on Serverless Containers, as long as you have enabled http2 (`h2c`) protocol.
+
+## 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.
+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.