You can deploy the project using Docker Compose to a remote server.
This project expects you to have a Traefik proxy handling communication to the outside world and HTTPS certificates.
You can use CI/CD (continuous integration and continuous deployment) systems to deploy automatically, there are already configurations to do it with GitHub Actions.
But you have to configure a couple things first. 🤓
- Have a remote server ready and available.
- Configure the DNS records of your domain to point to the IP of the server you just created.
- Configure a wildcard subdomain for your domain, so that you can have multiple subdomains for different services, e.g.
*.tribe.example.com
. This will be useful for accessing different components, liketraefik.tribe.example.com
,adminer.tribe.example.com
, etc. And also forstaging
, likestaging.tribe.example.com
,staging.adminer.tribe.example.com
, etc. - Install and configure Docker on the remote server (Docker Engine, not Docker Desktop).
We need a Traefik proxy to handle incoming connections and HTTPS certificates.
You need to do these next steps only once.
- Create a remote directory to store your Traefik Docker Compose file:
mkdir -p /root/code/traefik-public/
Copy the Traefik Docker Compose file to your server. You could do it by running the command rsync
in your local terminal:
rsync -a docker-compose.traefik.yml [email protected]:/root/code/traefik-public/
This Traefik will expect a Docker "public network" named traefik-public
to communicate with your stack(s).
This way, there will be a single public Traefik proxy that handles the communication (HTTP and HTTPS) with the outside world, and then behind that, you could have one or more stacks with different domains, even if they are on the same single server.
To create a Docker "public network" named traefik-public
run the following command in your remote server:
docker network create traefik-public
The Traefik Docker Compose file expects some environment variables to be set in your terminal before starting it. You can do it by running the following commands in your remote server.
- Create the username for HTTP Basic Auth, e.g.:
export USERNAME=admin
- Create an environment variable with the password for HTTP Basic Auth, e.g.:
export PASSWORD=changethis
- Use openssl to generate the "hashed" version of the password for HTTP Basic Auth and store it in an environment variable:
export HASHED_PASSWORD=$(openssl passwd -apr1 $PASSWORD)
To verify that the hashed password is correct, you can print it:
echo $HASHED_PASSWORD
- Create an environment variable with the domain name for your server, e.g.:
export DOMAIN=tribe.example.com
- Create an environment variable with the email for Let's Encrypt, e.g.:
export [email protected]
Note: you need to set a different email, an email @example.com
won't work.
Go to the directory where you copied the Traefik Docker Compose file in your remote server:
cd /root/code/traefik-public/
Now with the environment variables set and the docker-compose.traefik.yml
in place, you can start the Traefik Docker Compose running the following command:
docker compose -f docker-compose.traefik.yml up -d
Now that you have Traefik in place you can deploy Tribe with Docker Compose.
Note: You might want to jump ahead to the section about Continuous Deployment with GitHub Actions.
You need to set some environment variables first.
Set the ENVIRONMENT
, by default local
(for development), but when deploying to a server you would put something like staging
or production
:
export ENVIRONMENT=production
Set the DOMAIN
, by default localhost
(for development), but when deploying you would use your own domain, for example:
export DOMAIN=tribe.example.com
You can set several variables, like:
PROJECT_NAME
: The name of the project, used in the API for the docs and emails.STACK_NAME
: The name of the stack used for Docker Compose labels and project name, this should be different forstaging
,production
, etc. You could use the same domain replacing dots with dashes, e.g.tribe-example-com
andstaging-tribe-example-com
.BACKEND_CORS_ORIGINS
: A list of allowed CORS origins separated by commas.SECRET_KEY
: The secret key for the Tribe project, used to sign tokens.FIRST_SUPERUSER
: The email of the first superuser, this superuser will be the one that can create new users.FIRST_SUPERUSER_PASSWORD
: The password of the first superuser.USERS_OPEN_REGISTRATION
: Whether to allow open registration of new users.SMTP_HOST
: The SMTP server host to send emails, this would come from your email provider (E.g. Mailgun, Sparkpost, Sendgrid, etc).SMTP_USER
: The SMTP server user to send emails.SMTP_PASSWORD
: The SMTP server password to send emails.EMAILS_FROM_EMAIL
: The email account to send emails from.POSTGRES_SERVER
: The hostname of the PostgreSQL server. You can leave the default ofdb
, provided by the same Docker Compose. You normally wouldn't need to change this unless you are using a third-party provider.POSTGRES_PORT
: The port of the PostgreSQL server. You can leave the default. You normally wouldn't need to change this unless you are using a third-party provider.POSTGRES_PASSWORD
: The Postgres password.POSTGRES_USER
: The Postgres user, you can leave the default.POSTGRES_DB
: The database name to use for this application. You can leave the default ofapp
.SENTRY_DSN
: The DSN for Sentry, if you are using it.FLOWER_BASIC_AUTH
: The HTTP Basic Auth for Flower, likeadmin:changethis
.
There are some environment variables only used by GitHub Actions that you can configure:
LATEST_CHANGES
: Used by the GitHub Action latest-changes to automatically add release notes based on the PRs merged. It's a personal access token, read the docs for details.SMOKESHOW_AUTH_KEY
: Used to handle and publish the code coverage using Smokeshow, follow their instructions to create a (free) Smokeshow key.
Some environment variables in the .env
file have a default value of changethis
.
You have to change them with a secret key, to generate secret keys you can run the following command:
python -c "import secrets; print(secrets.token_urlsafe(32))"
Copy the content and use that as password / secret key. And run that again to generate another secure key.
With the environment variables in place, you can deploy with Docker Compose:
docker compose -f docker-compose.yml up -d
For production you wouldn't want to have the overrides in docker-compose.override.yml
, that's why we explicitly specify docker-compose.yml
as the file to use.
You can use GitHub Actions to deploy your project automatically. 😎
You can have multiple environment deployments.
There are already two environments configured, staging
and production
. 🚀
- On your remote server, if you are running as the
root
user, create a user for your GitHub Actions:
adduser github
- Add Docker permissions to the
github
user:
usermod -aG docker github
- Temporarily switch to the
github
user:
su - github
- Go to the
github
user's home directory:
cd
-
Install a GitHub Action self-hosted runner following the official guide.
-
When asked about labels, add a label for the environment, e.g.
production
. You can also add labels later.
After installing, the guide would tell you to run a command to start the runner. Nevertheless, it would stop once you terminate that process or if your local connection to your server is lost.
To make sure it runs on startup and continues running, you can install it as a service. To do that, exit the github
user and go back to the root
user:
exit
After you do it, you would be on the root
user again. And you will be on the previous directory, belonging to the root
user.
- Go to the
actions-runner
directory inside of thegithub
user's home directory:
cd /home/github/actions-runner
- Install the self-hosted runner as a service with the user
github
:
./svc.sh install github
- Start the service:
./svc.sh start
- Check the status of the service:
./svc.sh status
You can read more about it in the official guide: Configuring the self-hosted runner application as a service.
On your repository, configure secrets for the environment variables you need, the same ones described above, including SECRET_KEY
, etc. Follow the official GitHub guide for setting repository secrets.
The current Github Actions workflows expect these secrets:
DOMAIN_PRODUCTION
DOMAIN_STAGING
STACK_NAME_PRODUCTION
STACK_NAME_STAGING
EMAILS_FROM_EMAIL
FIRST_SUPERUSER
FIRST_SUPERUSER_PASSWORD
POSTGRES_PASSWORD
SECRET_KEY
LATEST_CHANGES
SMOKESHOW_AUTH_KEY
There are GitHub Action workflows in the .github/workflows
directory already configured for deploying to the environments (GitHub Actions runners with the labels):
staging
: after pushing (or merging) to the branchmaster
.production
: after publishing a release.
If you need to add extra environments you could use those as a starting point.
Replace tribe.example.com
with your domain.
Traefik UI: https://traefik.tribe.example.com
Frontend: https://tribe.example.com
Backend API docs: https://tribe.example.com/docs
Backend API base URL: https://tribe.example.com/api/
Adminer: https://adminer.tribe.example.com
Flower: https://flower.tribe.example.com
Frontend: https://staging.tribe.example.com
Backend API docs: https://staging.tribe.example.com/docs
Backend API base URL: https://staging.tribe.example.com/api/
Adminer: https://staging.adminer.tribe.example.com
Flower: https://staging.flower.tribe.example.com