Applications and environments

Applications#

An application is the thing you deploy: one codebase, with an environment for each place it runs. You create one in the console under Applications, or let brewless init create it from your project.

An application has a name, a framework and the Scaleway project it runs in. With several projects connected you choose it when you create the application, and it holds for all its environments; see Connecting providers. The framework decides how the application is built, which release commands run and where its schedule is read from. See Frameworks.

Environments#

An environment is one running copy of an application. Production is what your visitors use; staging is a copy where you try a release first.

When you create an environment you choose:

• A kind: production, staging or development.
• A region: the Scaleway region everything of this environment lands in. See Regions.

Each environment has its own container, variables, domains, scaling bounds and releases. Nothing is shared between two environments unless you point them at the same resource yourself.

Note

Every plan has as many environments as you like, production included. Your plan decides how many applications you can have: one without a subscription; see Billing.

Setting an environment up#

A new environment has nothing at your providers yet. On its Resources page, Set up has Brewless make what it needs, in your own accounts. From your project, brewless init does it for the environments it adds, and for one environment later:

brewless provision production

The command asks what the environment should have; the options of provision say the same without questions. Set up in the console asks the same three things: which database (a new one, one that exists already, or none), where jobs wait (in the database, at Scaleway Queues, or nowhere) and whether to make a bucket for files.

This makes, at Scaleway:

• a private registry for your images, when the project has none from Brewless yet;
• a web, a release and a worker container. They are made but not started: they start with your first deploy. Until then they name Brewless's public base image, which Scaleway pulls without a key, so nothing has to be in your registry first;
• a Serverless SQL Database, unless you choose otherwise. It sleeps when nobody asks it anything;
• a queue at Scaleway Queues, when you ask for one;
• a private bucket at Object Storage for the files of your application, when you ask for one;
• the first variables in your own Secret Manager, among them a new application key.

With bunny.net connected it also puts a pull zone in front of the web container, routed through the EU only, that asks the container once more when it does not answer (see When the origin does not answer).

Note

Scaleway does not offer every product in every region. Serverless SQL Database is only in Paris, and Scaleway Queues only in Paris and Amsterdam. Elsewhere, setting up offers a database that exists already or none, and lets jobs wait in the database or nowhere; a choice that cannot be made in the region is refused before anything is made.

Setting up only makes things. What it finds under the same name is used as it is; nothing is changed or removed. If it stops halfway, trying again carries on from what was made.

Note

Your application signs in to its database as an identity of its own, which may use the databases of this project and nothing else. Brewless makes that identity when its key may manage identities (the permission set IAMManager). When it may not, the result names the two variables, DB_USERNAME and DB_PASSWORD. Give the key that right and set the environment up again, or add them yourself before your first deploy. Until your variables name them, a deploy is refused before anything is built. See Variables.

Setting it up again#

An environment Brewless set up can be set up again, with the same command or button. That run uses the choices of the first one, whatever you answer now, and makes only what is missing: the database identity a key without the right could not make, for instance. Your variables keep every value they have. Only a name the first run left for you to set, and that is still missing or empty, gets the value Brewless could now make. That is a new revision of your variables, which reaches the containers with your next deploy.

An environment whose containers were taken over instead of made is not set up again.

A database that exists already#

Instead of a new database you can name one that stands in your Scaleway project, in the region of the environment. It is read and used as it is: nothing about it is changed, and it is listed among the resources of the environment.

• For a Serverless SQL Database the variables point at it, and your application signs in with an identity of its own, as with a new one.
• For a Managed Database the variables hold its address and what it speaks (PostgreSQL or MySQL). Its databases and users are of your own making, so the result names DB_DATABASE, DB_USERNAME and DB_PASSWORD for you to add before your first deploy. When the instance has a public endpoint, that one is used.

Two environments can use the same database.

A queue#

A queue at Scaleway takes a key of its own. Brewless makes one that may send and receive and may not make or remove queues, and keeps it in your Secret Manager. The key that makes the queue exists for that moment only and is removed again. Because Laravel's sqs connection reads the same AWS_* names as its s3 disk, the queue's key is in SQS_ACCESS_KEY_ID and SQS_SECRET_ACCESS_KEY; the brewless/laravel package hands them to the sqs connection.

Note

Scaleway Queues does not answer everything SQS does. Sending and receiving jobs work; asking a queue how many jobs it holds, as Laravel's Queue::size() does, is refused.

A bucket for files#

A container keeps no files of its own between requests. Asked for a bucket, Brewless makes a private one named after the application, the environment and your project, and an identity that may read, write and remove objects in the buckets of this project and may not make or remove a bucket. Scaleway grants this per project, not per bucket. The variables set FILESYSTEM_DISK=s3 and the AWS_* names Laravel's s3 disk reads.

When the key Brewless has may not manage identities, the bucket is still made and the result names AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for you to add.

Until your environment has a domain of its own it answers on the address of the pull zone, or of the web container when there is no pull zone.

From brewless.yml#

brewless deploy sets the environment up from your brewless.yml before it deploys, so a new environment is a few lines in the file:

environments:
  staging:
    kind: staging
    region: fr-par
    database: shop-staging
    queue: sqs
    storage: shop-staging-files

• An environment the file names that does not exist yet is made, with the kind and region of the file; without them it is staging, in Paris.
• database names the database. One that Brewless manages already, also for another application, is linked with a login of the environment's own, as on the Databases page; a new environment is set up first and linked right after. Another one of that name that stands in the region is used as it is; otherwise a Serverless SQL Database of that name is made. storage names the bucket that is made. queue is sqs, database or false.
• Only what the file names is made. An environment the file sets up without a database has none.

For an environment that runs already, the file can add what it does not have yet: a database, a queue at Scaleway Queues or a bucket. Their variables are added to the environment's own, so those have to be kept through Brewless (push them once with brewless env:push). A name your variables have keeps its value, unless it is still the one Brewless gave the environment without that resource, such as QUEUE_CONNECTION=sync before a queue was added. That is a new revision of your variables, which the release of the same deploy takes.

Domains the file names are added after a yes; see Domains.

What stands holds data, so a deploy never switches it for something else. Another region, another kind, another database or bucket, or a queue other than the one the environment was set up with, is refused before anything is made, with what stands. The one switch a deploy makes is queue: sqs for an environment whose jobs waited in its database: that only adds a queue at Scaleway Queues, and QUEUE_CONNECTION becomes sqs when it still says what Brewless set (a value you set yourself stays). Let the jobs in the database finish first: the worker no longer looks there afterwards. false for a database or a bucket lets it go from the environment: the resource itself keeps running at Scaleway, and your variables keep pointing at it until you change them. A key you leave out keeps what stands. brewless plan shows each of these lines before you deploy.

If you have containers at your provider already, adopt them instead.

Resources#

Everything an environment uses at your providers is listed under Resources: containers, databases, buckets, secrets, pull zones and DNS zones.

A database, a bucket or a DNS zone can serve more than one environment: staging and test sharing one database, for example. On the Resources page of the second environment it is offered under Adopt existing resources, marked with the environment that uses it already; adopting it there shares it. Releasing it from one environment keeps it for the others. A container, a secret or a pull zone is one environment's own and cannot be shared.

Under Resources in the organisation's menu, everything in your Scaleway projects and bunny.net account is listed at once, each thing with its project when there are several: what Brewless manages, with the environments each thing serves, and what stands there in no environment.

• Adopting a resource that already exists at your provider records its current settings as what Brewless expects. Nothing at the provider is changed.
• Differences are shown when what Brewless recorded no longer matches what stands at the provider. Brewless reports them; it does not change anything by itself.
• Releasing a resource removes the reference from Brewless. The resource itself keeps running at the provider.

Leaving with an environment#

You can take an environment out of Brewless at any moment without touching what runs. See Leaving Brewless.

Removing an application#

Removing an application removes it and its environments from Brewless. Nothing in your own provider account is touched: containers keep running and databases keep their data until you remove them at the provider yourself. Only the test addresses of its environments stop leading anywhere: their records are in Brewless's own zone.