Deployment
During your CoreConnect installation, you will be able to choose a pre-configured infrastructure template to deploy and provision your CoreConnect environment. CoreConnect’s infrastructure templates are based on Pulumi, an open-source infrastructure as code tool that allows you to define, deploy, and manage cloud infrastructure using familiar programming languages. Although you are not required to use these templates, they are recommended for a quick and easy deployment of your CoreConnect environment.
fly.io
Fly.io is a global edge platform that makes it easy to deploy, run, and scale your applications. Unfortunately fly.io does not currently support Pulumi as a deployment method, but we have prepared a guide with some example files to help you easily deploy your CoreConnect application on fly.io.
Technical details
Deploying CoreConnect’s back-end services on fly.io
This guide will help you deploy CoreConnect’s back-end services on fly.io and set up continuous deployment using GitHub Actions in the absence of Pulumi providers. Note that fly.io does not currently support Pulumi as a deployment method, there are some terraform providers available but they are not officially supported by fly.io or compatible with Pulumi.
Prerequisites
This guide assumes that you have already set up your fly.io account and have the fly CLI installed on your local machine. If you haven’t done so, you can follow the instructions on the fly.io documentation.
Our example will go through the steps needed to deploy RabbitMQ, Gateway, and Functions applications on fly.io based on a typical CoreConnect repository structure from the CLI template. If your project is not set up in the same way, you may need to adjust the steps accordingly.
Deploying RabbitMQ image
Copy the files (Dockerfile, fly.toml and prod.conf) from infrastructure/fly.io/rabbitMQ
to the respective application directory and make the necessary changes (if any) to those files.
fly cli
- Login in the fly.io
- Create, configure the rabbit app in fly.io and create the toml file
- Set the rabbitMQ user password secret
- Deploy the rabbitMQ app in fly.io
Example of rabbitMQ toml file
Miscelaneous
Connect to RabbitMQ management
Create a proxy (rabbit-getsales is the app name):
Now, the RabbitMQ management can be connected through http://localhost:15672/
Remove the rabbitMQ app
If the app needs to be removed:
Deploying Gateway and Functions applications
The Gateway and Functions applications are deployed using the same steps. The only difference is the Dockerfile and fly.toml files used for each application.
First we will copy the files from the infrastructure/fly.io/gateway
and infrastructure/fly.io/functions
directories to the respective application directories. You might need to replace the existing Dockerfiles but that’s okay as the original ones are set up for Azure.
After the files have been copied, we modify the fly.toml files to match the desired application name and non-sensitive environment variables.
Here’s an example of a fly.toml file for the Gateway application:
Note the RabbitMQ__Host
environment variable, which should be set to the RabbitMQ service (that we deployed on the previous step) internal’s URL.
First deployment
Before deploying the first version of the services’ docker images, we need to create the applications on fly.io. To do this, we open the terminal on the corresponding application directory and run the following command:
Follow the instructions on the terminal to create the application making sure to select the desired region and organization. After the application has been created, it’s a good idea to add the sensitive environment variables as secrets to the application. This can be done by either running the following command for each secret:
Or directly on the fly.io dashboard:
Note that the secrets will only be available to the application after the first deployment.
GitHub Actions for continuous deployment
Once the applications have been created and the secrets have been set, we can set up GitHub Actions to deploy the applications on each push to the main branch.
For standard CoreConnect repositories, we have provided example GitHub Actions workflows that can be copied to the .github/workflows
directory and run without any modification.
Let’s take a look at the dev-deploy-gateway.yml
file:
As you can see, the workflow is triggered on each push to the main branch and only runs when changes are made to the Gateway application (including the fly.toml
file where the env variables are set) or the workflow file itself.
There are 2 mandatory secrets that will be needed for the workflow to run, these are the github Personal Access Token (GH_PAT
) with access to the CoreConnect NuGet packages and the Fly.io API token (FLY_API_TOKEN
) for the deployment.
Deploying to the production environment
Once you are ready to go live, you will want to create new environments on fly.io for the production/staging applications.
To do this you can just create a new toml file for each application (e.g. fly-prod.toml
) and a corresponding GitHub Actions workflow file (e.g. prod-deploy-gateway.yml
) pointing to this new file and a specific branch (e.g. production
).
You can now follow the same steps as before to deploy the applications to the new environments, just make sure to specify the correct toml file on your fly launch
command (e.g. fly launch --no-deploy --config ./fly-prod.toml
).
Notes about the production environment: The provided fly.io configuration files are set up on a basic infrastructure level and should be ok for the dev environment. However, for production, you might want to consider setting up a more robust infrastructure with multiple regions, autoscaling, and other features that fly.io provides. We will provide more information on this in the future.
Azure ContainerApps
By choosing this infrastructure template, you will be able to deploy your CoreConnect environment on Azure using ContainerApps and Azure Service Bus.
Technical details
Core Connect Infrastructure as Code
Infrastructure as Code for Azure Container Apps
The structure of the pulumi project
The index.ts
file is the entry point of the pulumi project. Inside this file, you can find the following:
- First we set up a Azure Resource Group
- Then we set up a Azure Vault
- Then we set up a container registiry
- Then we set up the Azure Service Bus (ASB) using
./setupASB.ts
Prerequisites
Install Pulumi
Install pulumi: https://www.pulumi.com/docs/get-started/install/
- Install Pulumi CLI on macOS using Homebrew:
Install Azure CLI
- Install Azure CLI on macOS using Homebrew:
Authenticate to Azure & Pulumi
- The Azure CLI’s default authentication method for logins uses a web browser and access token to sign in
- Set the default subscription for all Azure operations
- Manage your Pulumi stacks by logging in.
- Set the default destination org for all stack operations
- List stacks
- Choose a stack, or create a new one
e.g. pulumi stack rb2/dev
How to provision the infrastructure
- To create or update the stack, run
pulumi up
and selectyes
to perform the deployment. Make sure you’re using the correct stack and have the right Azure subscription selected.
How to destroy the infrastructure
⚠️ Be very cautious here, this action will destroy all resources
- Run
pulumi stack ls
to list all the stacks inside the pulumi state (cloud) - Run
pulumi stack select <stack-name>
to select the stack you want to destroy - Run
pulumi destroy
to destroy the infrastructure of the selected stack before removing the stack from Pulumi Cloud
How to remove the Pulumi Stack from the Pulumi Cloud
⚠️ Be very cautious here, this will remove the stack from the pulumi state (cloud) and you will not be able to recover it withouth a Pulumi Enterprise license.
- Run
pulumi stack ls
to list all the stacks inside the pulumi state (cloud)
- Run
pulumi stack select <stack-name>
to select the stack you want to remove
- Run
pulumi stack rm
to remove the stack from the pulumi state (cloud)
Storing secrets inside the pulumi config
To store secrets inside the pulumi config, you need to use the --secret
flag. For storing secrets in the nested
object, see below:
How to store secrets inside nested objects of the pulumi config
Normally, you can just follow the basic docs to store secrets. But when storing secrets inside a nested config, you need to do the following:
Use the following command for example to store a encrypted secret inside the config:
This will create the following inside the Pulumi.dev.yaml file:
To access this value inside the code: