Containers APIv1beta1

Scaleway Containers is a Container As A Service product which gives users the ability to deploy atomic serverless workloads and only pay for resources used while containers are running.

It provides many advantages, such as:

• Containers are only executed when a event is triggered, which allows users to save money while code is not running
• Auto-Scalability:
  • Automated Scaling up and down based on user configuration (e.g. min: 0, max: 100 replicas of my container).
  • Automated Scaling to zero when container is not executed, which saves some money for the user and save Computing resources for the cloud provider.
• Scale only the endpoint

• Fully isolated environments
• Scaling to zero (save money and computing resources while code is not executed)
• High Availability and Scalability (Automated and configurable, each container may scale automatically according to incoming workloads)
• Multiple event sources:
  • HTTP (request on our Gateway will execute the container)
  • CRON (time-based job, runs according to configurable cron schedule)
• Integrated with the Scaleway Container Registry product
  • Deploy any docker image from one of your registry namespace

This page focuses on working with the Scaleway API, for detailed informations about containers you can dive into the Scaleway Documentation for Containers.

A Container in Scaleway Containers consists of multiple components:

• Environment Variables: You may configure specific environment variables (Database host/credentials for example) which are safely encrypted in our Database, and will be mounted inside your containers. Note that environment variables set at Namespace level will also be mounted (in every container). Environment variables written at container level override the ones set at namespace level (if two env var have the same name for example).
• Docker Image
• Resources: users may decide how much computing resources to allocate to each container -> Memory Limit (in MB). We will then allocate the right amount of CPU based on Memory Limit choice. The right choice for your container's resources is very important, as you will be billed based on compute usage over time and the number of Containers executions.

Representation of given CPU resources based on configured Memory Limit (in MB) for a container:

Where 560mCPU accounts roughly for half of one CPU power of a Scaleway General Purpose instance.

A CRON is a type of event which triggers a Scaleway Container, it is an add-on to your container.

CRONs inside Scaleway Containers have the following properties:

• schedule: UNIX Formatted CRON schedule. Your container will be executed based on this schedule. For example, 5 4 * * 0 means execute my container at "04:05 AM" on each Sunday (see this page from Ubuntu's official documentation). The timezone is UTC+0.
• args: JSON Object passed to your container. You can use this property to define data that will be passed to your container's event.body object. For Containers, you might handle these arguments as the HTTP Request's Body.

Under the hood, CRON Triggers are Kubernetes JOBs sending HTTP POST requests to your container.

Whether you decide to use Serverless Framework or directly our API, you'll need your Scaleway Project ID and a Scaleway Project API Key.

• Install curl
• Install jq will make it easier to manage JSON output from our APIs

To call Scaleway API, you need an X-Auth-Token. If you don't have one yet, you can create it on the credentials page of your Scaleway account (must be done via web interface).

In order to retrieve your project ID and your API Key, you must go to your console's credentials page:

• Login/Register to Scaleway console
• Go to your credentials management page
• Retrieve your project ID and generate a token (see following picture):
• Retrieve your token's secret key:

Then, export then as variables to use them with curl:

The following sections explain how to use our API, with a tutorial and the auto-generated API documentation. However, we developed a Serverless Framework plugin enabling users to deploy their serverless workloads much more easily with a single serverless deploy command. No magic there, it's just a nice tool calling our API.

If what you are looking for is an easy way to deploy your code, you may prefer Serverless Framework.

Below, you will find a step-by-step guide on how to create a namespace, configure and deploy containers, and trigger your containers via HTTP and CRON.

Customize the name and set your project ID

Copy the id field of the response to use at the next steps. For the sake of simplicity we will save the ID to a variable, which we will use in the following examples:

To destroy a namespace (along with all containers and crons) use the following call:

We suppose you already have a working image here. It can be anything which listens on a env variable \$PORT variable. Note that we run your container as user 1000, not root, so it must be runnable under these conditions.

To push your image, we invite you to check the container registry documentation.

To retrieve the containers output logs:

By default new containers are public meaning that no credentials are required to invoke them.

A container can be private or public. This can be configured through the privacy parameter.

Calling a private container without authentication will return HTTP code 403.

To get all tokens associated with a container:

Note that tokens can only be read at creation time, and are not stored, hence they can't be retrieved if lost.

To generate a token for a container:

expire_at is optional, and in this example is set to 90 days from today (see EXPIRE_AT). If you don't set expire_at, your token will never expire.

To revoke a token you need to delete it:

A private container will:

• Reject a call without an X-Auth-Token header, returning HTTP status Code 403
• Validate the token before invoking your code if it is provided via the X-Auth-Token header

For example, to execute a private container by providing a token using curl, you may run the following command:

Containers output logs can be retrieved from the endpoint GET /logs. You need to pass its ID as an container_id parameter.

Get the namespace associated with the given id.

Update the space associated with the given id.

Delete the namespace associated with the given id.

Get the container associated with the given id.

Update the container associated with the given id.

Delete the container associated with the given id.

Deploy a container associated with the given id.

Get the cron associated with the given id.

Update the cron associated with the given id.

Delete the cron associated with the given id.