🚚 Rename Docker Compose files to new names, compose.yml (#2106)

This commit is contained in:
Sebastián Ramírez
2026-01-22 08:22:25 -08:00
committed by GitHub
parent 03bca13d17
commit 6ab7a40cdd
13 changed files with 21 additions and 21 deletions

View File

@@ -28,5 +28,5 @@ jobs:
steps: steps:
- name: Checkout - name: Checkout
uses: actions/checkout@v6 uses: actions/checkout@v6
- run: docker compose -f docker-compose.yml --project-name ${{ secrets.STACK_NAME_PRODUCTION }} build - run: docker compose -f compose.yml --project-name ${{ secrets.STACK_NAME_PRODUCTION }} build
- run: docker compose -f docker-compose.yml --project-name ${{ secrets.STACK_NAME_PRODUCTION }} up -d - run: docker compose -f compose.yml --project-name ${{ secrets.STACK_NAME_PRODUCTION }} up -d

View File

@@ -28,5 +28,5 @@ jobs:
steps: steps:
- name: Checkout - name: Checkout
uses: actions/checkout@v6 uses: actions/checkout@v6
- run: docker compose -f docker-compose.yml --project-name ${{ secrets.STACK_NAME_STAGING }} build - run: docker compose -f compose.yml --project-name ${{ secrets.STACK_NAME_STAGING }} build
- run: docker compose -f docker-compose.yml --project-name ${{ secrets.STACK_NAME_STAGING }} up -d - run: docker compose -f compose.yml --project-name ${{ secrets.STACK_NAME_STAGING }} up -d

View File

@@ -32,7 +32,7 @@ jobs:
- backend/** - backend/**
- frontend/** - frontend/**
- .env - .env
- docker-compose*.yml - compose*.yml
- .github/workflows/playwright.yml - .github/workflows/playwright.yml
test-playwright: test-playwright:

View File

@@ -37,7 +37,7 @@ The setup is also already configured so you can run the tests through the VS Cod
## Docker Compose Override ## Docker Compose Override
During development, you can change Docker Compose settings that will only affect the local development environment in the file `docker-compose.override.yml`. During development, you can change Docker Compose settings that will only affect the local development environment in the file `compose.override.yml`.
The changes to that file only affect the local development environment, not the production environment. So, you can add "temporary" changes that help the development workflow. The changes to that file only affect the local development environment, not the production environment. So, you can add "temporary" changes that help the development workflow.

View File

@@ -12,7 +12,7 @@ services:
ports: ports:
- "80:80" - "80:80"
- "8090:8080" - "8090:8080"
# Duplicate the command from docker-compose.yml to add --api.insecure=true # Duplicate the command from compose.yml to add --api.insecure=true
command: command:
# Enable Docker in Traefik, so that it reads labels from Docker services # Enable Docker in Traefik, so that it reads labels from Docker services
- --providers.docker - --providers.docker

View File

@@ -32,7 +32,7 @@ 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: Copy the Traefik Docker Compose file to your server. You could do it by running the command `rsync` in your local terminal:
```bash ```bash
rsync -a docker-compose.traefik.yml root@your-server.example.com:/root/code/traefik-public/ rsync -a compose.traefik.yml root@your-server.example.com:/root/code/traefik-public/
``` ```
### Traefik Public Network ### Traefik Public Network
@@ -97,10 +97,10 @@ Go to the directory where you copied the Traefik Docker Compose file in your rem
cd /root/code/traefik-public/ 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: Now with the environment variables set and the `compose.traefik.yml` in place, you can start the Traefik Docker Compose running the following command:
```bash ```bash
docker compose -f docker-compose.traefik.yml up -d docker compose -f compose.traefik.yml up -d
``` ```
## Deploy the FastAPI Project ## Deploy the FastAPI Project
@@ -168,10 +168,10 @@ Copy the content and use that as password / secret key. And run that again to ge
With the environment variables in place, you can deploy with Docker Compose: With the environment variables in place, you can deploy with Docker Compose:
```bash ```bash
docker compose -f docker-compose.yml up -d docker compose -f 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. For production you wouldn't want to have the overrides in `compose.override.yml`, that's why we explicitly specify `compose.yml` as the file to use.
## Continuous Deployment (CD) ## Continuous Deployment (CD)

View File

@@ -105,13 +105,13 @@ After you update it, run again:
docker compose watch docker compose watch
``` ```
When deploying, for example in production, the main Traefik is configured outside of the Docker Compose files. For local development, there's an included Traefik in `docker-compose.override.yml`, just to let you test that the domains work as expected, for example with `api.localhost.tiangolo.com` and `dashboard.localhost.tiangolo.com`. When deploying, for example in production, the main Traefik is configured outside of the Docker Compose files. For local development, there's an included Traefik in `compose.override.yml`, just to let you test that the domains work as expected, for example with `api.localhost.tiangolo.com` and `dashboard.localhost.tiangolo.com`.
## Docker Compose files and env vars ## Docker Compose files and env vars
There is a main `docker-compose.yml` file with all the configurations that apply to the whole stack, it is used automatically by `docker compose`. There is a main `compose.yml` file with all the configurations that apply to the whole stack, it is used automatically by `docker compose`.
And there's also a `docker-compose.override.yml` with overrides for development, for example to mount the source code as a volume. It is used automatically by `docker compose` to apply overrides on top of `docker-compose.yml`. And there's also a `compose.override.yml` with overrides for development, for example to mount the source code as a volume. It is used automatically by `docker compose` to apply overrides on top of `compose.yml`.
These Docker Compose files use the `.env` file containing configurations to be injected as environment variables in the containers. These Docker Compose files use the `.env` file containing configurations to be injected as environment variables in the containers.
@@ -129,7 +129,7 @@ The `.env` file is the one that contains all your configurations, generated keys
Depending on your workflow, you could want to exclude it from Git, for example if your project is public. In that case, you would have to make sure to set up a way for your CI tools to obtain it while building or deploying your project. Depending on your workflow, you could want to exclude it from Git, for example if your project is public. In that case, you would have to make sure to set up a way for your CI tools to obtain it while building or deploying your project.
One way to do it could be to add each environment variable to your CI/CD system, and updating the `docker-compose.yml` file to read that specific env var instead of reading the `.env` file. One way to do it could be to add each environment variable to your CI/CD system, and updating the `compose.yml` file to read that specific env var instead of reading the `.env` file.
## Pre-commits and code linting ## Pre-commits and code linting

View File

@@ -25,9 +25,9 @@ If you are developing an API-only app and want to remove the frontend, you can d
* Remove the `./frontend` directory. * Remove the `./frontend` directory.
* In the `docker-compose.yml` file, remove the whole service / section `frontend`. * In the `compose.yml` file, remove the whole service / section `frontend`.
* In the `docker-compose.override.yml` file, remove the whole service / section `frontend` and `playwright`. * In the `compose.override.yml` file, remove the whole service / section `frontend` and `playwright`.
Done, you have a frontend-less (api-only) app. 🤓 Done, you have a frontend-less (api-only) app. 🤓

View File

@@ -7,4 +7,4 @@ TAG=${TAG?Variable not set} \
FRONTEND_ENV=${FRONTEND_ENV-production} \ FRONTEND_ENV=${FRONTEND_ENV-production} \
sh ./scripts/build.sh sh ./scripts/build.sh
docker-compose -f docker-compose.yml push docker compose -f compose.yml push

View File

@@ -6,5 +6,5 @@ set -e
TAG=${TAG?Variable not set} \ TAG=${TAG?Variable not set} \
FRONTEND_ENV=${FRONTEND_ENV-production} \ FRONTEND_ENV=${FRONTEND_ENV-production} \
docker-compose \ docker-compose \
-f docker-compose.yml \ -f compose.yml \
build build

View File

@@ -7,7 +7,7 @@ DOMAIN=${DOMAIN?Variable not set} \
STACK_NAME=${STACK_NAME?Variable not set} \ STACK_NAME=${STACK_NAME?Variable not set} \
TAG=${TAG?Variable not set} \ TAG=${TAG?Variable not set} \
docker-compose \ docker-compose \
-f docker-compose.yml \ -f compose.yml \
config > docker-stack.yml config > docker-stack.yml
docker-auto-labels docker-stack.yml docker-auto-labels docker-stack.yml