Skip to main content

Provider configuration

Booster applications are deployed to the cloud using the provider's API. Each provider has its own configuration parameters. This section describes how to configure each provider.

Local Provider

All Booster projects come with a local development environment configured by default, so you can test your app before deploying it to the cloud.

You can see the configured local environment in your src/config/config.ts file:

Booster.configure('local', (config: BoosterConfig): void => {
config.appName = 'my-store'
config.providerPackage = '@boostercloud/framework-provider-local'
})

In order to start your application using the local provider, use the following command:

boost start -e local

Where local is one of your defined environments with the Booster.configure call.

AWS Provider Setup

Booster is a cloud-native framework, meaning that your application can be deployed to the cloud with a single command. By default, Booster uses the AWS Provider.

You only need to provide Booster with the credentials of an AWS account and the framework will take care of the rest.

caution

Booster is free to use, but remember that the resources deployed to your cloud provider might generate some expenses.

In AWS, all the resources generated by Booster are part of the AWS free tier. When you're not eligible for the free tier, resources are charged on-demand. Deploying a Booster project and sending a few commands and queries should cost just a few cents.

In any case, make sure to un-deploy your application with the command boost nuke -e production if you're not planning to keep using it.

Creating an AWS account

If you don't have an AWS account, you can create one by following the instructions in the AWS documentation.

Getting the AWS credentials

Once you have an AWS account, you need to get the credentials that Booster needs to deploy your application. You can follow the instructions in the AWS documentation to get them.

Booster needs you to get the following credentials:

  • Access Key ID
  • Secret Access Key

Make sure you get them, as they will be needed in the next step.

Setting the AWS credentials on Booster

Booster needs to know how to authenticate against your AWS account. For that reason, create a folder called .aws under your home folder, and a file inside called credentials with this syntax:

~/.aws/credentials
[default]
aws_access_key_id=<YOUR ACCESS KEY ID>
aws_secret_access_key=<YOUR SECRET ACCESS KEY>

Multiple AWS environments

It's a good practice to have different environments for your application. For example, you might want to have a production environment to serve your customers and a staging environment to test new features before releasing them to production. Booster allows you to configure multiple environments, so you can deploy the same application to different AWS environments.

You may also want to serve your application in different AWS regions. For example, you might want to deploy your application to the eu-west-1 region to serve your European customers and to the us-east-1 region to serve your American customers.

Different accounts

If you want to deploy your Booster application to different AWS accounts, you can do so by creating a profile for each one and then setting the AWS_PROFILE environment variable to the profile you'd like to use.

~/.aws/credentials
[default]
aws_access_key_id = <DEFAULT ACCESS KEY ID>
aws_secret_access_key = <DEFAULT SECRET ACCESS KEY>
region=<DEFAULT REGION>

[other_profile] # You can rename the profile in any way that works for you
aws_access_key_id = <YOUR ACCESS KEY ID>
aws_secret_access_key = <YOUR SECRET ACCESS KEY>
region=<REGION FOR YOUR BOOSTER APP ON THIS ACCOUNT>

Different regions

If you want to deploy your Booster application to different AWS regions with the same account, you

~/.aws/config
[default]
region=<DEFAULT REGION>

[profile other_profile] # You can rename the profile in any way that works for you
region=<REGION FOR YOUR BOOSTER APP>
tip

You can find more information in the official AWS documentation.

Switching Profiles

To change the AWS profile you use to deploy or nuke you need to export the profile in your current AWS_PROFILE environment variable. This is done within your current terminal session with the following command:

$ export AWS_PROFILE=other_profile
caution

When you are switching profiles by setting the AWS_PROFILE environment variable, you will need to ensure you do not have values curently set for either the AWS_SECRET_ACCESS_KEY or AWS_ACCESS_KEY_ID variables. If these have values assigned, they will take precedence over any keys set within the current AWS_PROFILE profile.

You can check if AWS_SECRET_ACCESS_KEY or AWS_ACCESS_KEY_ID have variables assigned by checking all current AWS variables -

$ env | grep AWS

Or by checking these variables explicitly –

$ echo $AWS_ACCESS_KEY_ID
$ echo $AWS_SECRET_ACCESS_KEY

If values are present for AWS_SECRET_ACCESS_KEY or AWS_ACCESS_KEY_ID you can clear them by unsetting them –

$ unset AWS_SECRET_ACCESS_KEY
$ unset AWS_ACCESS_KEY_ID

Selecting different profiles can be done manually, for each deploy or nuke, as shown above, or you can create scripts within your package.json to set these values whenever you deploy or nuke an environment. For example, below we are creating scripts that set a different AWS profile to be used for development and production environments

/package.json
"scripts": {
"deploy:dev": "AWS_PROFILE=profileOne boost deploy -e development",
"deploy:prod": "AWS_PROFILE=profileTwo boost deploy -e production",
"nuke:dev": "AWS_PROFILE=profileOne boost nuke -e development",
"nuke:prod": "AWS_PROFILE=profileTwo boost nuke -e production",
}

These custom scripts are used in the same fashion as other scripts, for example –

npm run deploy:dev 

Azure Provider Setup

Booster applications can be deployed to Microsoft Azure. To do so, you need to have an Azure account and to have the Azure CLI installed on your computer.

caution

Booster is free to use, but remember that the resources deployed to your cloud provider might generate some expenses.

In Azure, when you're not eligible for the free tier, resources are charged on-demand. Deploying a Booster project and sending a few commands and queries should cost just a few cents.

In any case, make sure to un-deploy your application with the command boost nuke -e production if you're not planning to keep using it.

Creating an Azure account

As mentioned, you need to have an Azure account. If you don't have one, you can create one from the Microsoft SignUp page. You can also use your existing Microsoft account to create an Azure account. If you don't have a Microsoft account, you can create one from the Microsoft SignUp page.

Installing the Azure CLI

Once you have created the Azure account, you need to install the Azure CLI on your computer. You can do it by following the instructions on the official documentation. You may also need to install jq on your system.

Logging in to Azure

Once you have installed the Azure CLI, you need to log in to your Azure account. You can do it by running the following command:

az login

This command will open a browser window where you can select the Azure account you want to use. After selecting the account, you will be asked to enter the password for the account. After that, you will be able to use the Azure CLI. You can check that you are logged in by running the following command:

az account show

This command will show the account you are currently logged in. Once you are logged in from the CLI, you can deploy applications in Azure with Booster! 🚀

You can see more details in the Providers configuration section.

Kubernetes Provider Setup

This step is only necessary in the case that you want to use the Kubernetes provider.

note

Kubernetes has experimental support and the team is currently improving them.

The main requirement is having a Kubernetes Cluster already configured. This provider has been succesfully tested in EKS (Amazon Elastic Kubernetes Service), AKS (Azure Kubernetes Service) and GKE (Google Kubernetes Engine). Since Kubernetes is a standard, this provider can also work in other Kubernetes clusters, including on-premises configurations.

caution

Booster is free to use, but remember that the Kubernetes cluster resources used for the deployment might generate some expenses.

Additionally, it is also required to install kubectl and Helm. The required Helm version is 3 or greater.

Please note that the desired cluster should be accessible from the kubectl command and you can successfully run:

kubectl get pods -A