Broadly there are three main areas that require developer input before being able to run the app locally and in production; global environment variables in the .env file, creation of production resources with Terraform, and automated deployment with GitHub workflows.
To get started locally first, only the .env file is needed.
You will also need to setup mysql locally, there is a guide here. Please note that Strapi relies on a deprecated authentication plugin (mysql_native_password) which has been removed from MySQL versions past 8.0.37, as they now use caching_sha2_password. Please also note that current MySQL installations allow you to set a root password so starting the server with --skip-grant-tables is not required and can sometimes cause connectivity problems.
Strapi requires a number of environment variables to be set in order to do basic things like connect to the database, as well as power some of the installed plugins. To get started make a new .env file and copy the contents from the .env.example file at the root of the project. .env files ares excluded from version control using the .gitignore file.
Strapi itself can be customised to serve in different ways depending on the local or production setup you'd like. Refer to the Strapi documentation for full details.
The hostname or IP that the server is running on. Usually set to 0.0.0.0.
The port that the server is listening on. Usually set to 8080.
The URL that the server is listening on. Usually set to http://localhost.
The full URL if the port is not set to 80 or 443. By default this is a combination of previous variables in the style http://${URL}:${PORT}.
The customizable URL of the admin panel. By default this is a combination of previous variables in the style http://${URL}:${PORT}/dashboard.
This template installation of Strapi is configured to connect to a MySQL server. Where this server is running is up to the developer, but it is recommended to connect to a local instance for development and then change the variables in production. It is HIGHLY recommended not to use the root database user. Instead create a new user with restricted access using a mysql shell or a GUI like MySQL Workbench.
The hostname or IP of the MySQL server.
The port the MySQL server is listening on.
Does the MySQL server require secure connections? Value can be true or false. In production this should ALWAYS be true.
The name of the database schema to be used by Strapi. The schema should be empty the first time you start up the app because Strapi instantiates all the tables and views it needs.
The username of the MySQL server user.
The password of the MySQL server user.
To secure API tokens generated by users creating sessions with the Strapi the follwoing variables are required.
App keys are random strings used to generate unique session IDs. It is recommended to have 4 comma seperated values, for example key1,key2,key3,key4. Use a random string generator to create app keys.
New API tokens are generated using a salt. Changing the salt invalidates all the existing API tokens.
A random string used to encode JWT tokens. Use a random string generator to create one.
The Sentry Strapi plugin is included in this installation for tracking uncaught errors. The plugin GitHub readme has the full documentation if required.
The only required variable is the Data Source Name, which can be found in the project settings in Sentry. In development it is recommended to set this variable as an empty string so that no errors are sent. In production it is HIGHLY recommended to setup Sentry to aid debugging.
Terraform files are included to create all of the resources nessecary to run Strapi in Azure. This includes a Container Registry for storing container images, a Storage Account for persisting uploaded media and an App Service for running an instance of the container image.
This guide assumes the developer is already familiar with Terraform, so the commands to create and destroy resources are not covered here. The main file that needs developer input is /terraform/variables.tf. The /terraform/main.tf file is parameterised in such a way that it shouldn't need editing unless making significant changes to the resources. Instead, the variables file prompts the user to enter all of the values required when running Terraform commands. A large portion of these are the same as required to run the app locally, and are outlined in the Environment Variables section. Variables not covered there are described here.
Manually entry of terraform variables can get annoying if done repeatedly, in that case checkout the excellent tfenv library to read the values from a .env file.
The subscription ID in the billing account, this is the level at which billing happens. Each project should request its own subscription via NU Service and provide a cost center to charge.
The name of the Azure resource group in which to create all the resources.
The Azure geolocation of the data center to run the resources in.
The name of the project.
The Principle Investigator or Project Lead
A list of names of people contributing to the project.
The name of the image from the registry to run in the app service. This must match the value in the GitHub workflow used to create the image.
There are two workflow files that come setup for build and deploy actions. These are stored in the ./github/workflows directory.
The build step produces a Docker image with your Strapi instance packaged up and ready to deploy. A build is triggered on any push to main or a tagged release. For push based triggers the Docker images is tagged with a label of latest. For tagged releases the image is labeled with a matching semantic version, for example 1.2.3. These images are then pushed to a container registry, the intention being the one created by Terraform but it could be to a third party registry like DockerHub.
If the included terraform files are used, you can find the value for all of these properties in the settings page of the Azure registry that gets created.
The URL for the container registery to push images to.
The image name you want to use, for example strapi-api, this then gets labled in the form strpai-api:latest.
The username used for authenticating with the container registry.
The password used for authenticating with the container registry.
The deploy step assumes a build has just run successful that has ended with a semantically tagged version pushed to the registry.
The name of the Azure Web App that runs the container, this is the one created via Terraform.
Azure uses publish profiles to allow CI/CD pipelines to interact with Azure App Services. A publish profile is a small XML string that needs to be stored as a repository secret. Follow these steps for obtaining a publish profile for your app.