|
36 | 36 | Note that all of these configuration options will be ignored if `MAGPIE_NETWORK_ENABLED` is `false`. |
37 | 37 |
|
38 | 38 |
|
| 39 | +[2.21.0](https://github.com/bird-house/birdhouse-deploy/tree/2.21.0) (2026-01-27) |
| 40 | +------------------------------------------------------------------------------------------------------------------ |
| 41 | + |
| 42 | +## Changes |
| 43 | + |
| 44 | +- Remove `proxy` component's dependency on `scheduler` and `scheduler-job-logrotate-nginx` |
| 45 | + |
| 46 | + Creates new settings in `optional-components/proxy-log-volume` that create the `proxy-logs` docker volume as well |
| 47 | + as instructing Nginx to write access logs to an additional log file (specified by `PROXY_LOG_PATH`). These settings |
| 48 | + are included as a `COMPONENT_DEPENDENCY` in components that require access to the the `proxy` access logs as a |
| 49 | + regular file. If no components require access to these logs as a regular file then the `proxy` component will only |
| 50 | + write access logs to the stdout stream for that container. |
| 51 | + |
| 52 | + Right now, the only components that require access to logs in this way are `components/canarie-api` and |
| 53 | + `optional-components/prometheus-log-parser`. Both of these now include `optional-components/proxy-log-volume` as a |
| 54 | + `COMPONENT_DEPENDENCY`. |
| 55 | + |
| 56 | + Note: this means that if no optional components require `optional-components/proxy-log-volume` as a dependency |
| 57 | + then logs from the `proxy` container will only be written to stdout/stderr. This means that there is no need |
| 58 | + for any additional custom log rotation handling since the logs are handled directly by docker. This means that |
| 59 | + the `proxy` service itself no longer need to be dependant on the `scheduler` and `scheduler-job-logrotate-nginx` |
| 60 | + components. |
| 61 | + |
| 62 | + Note: a previous discussion suggested that logs could be parsed directly from the stdout stream of the `proxy` |
| 63 | + container. However, there is no way to do so that doesn't require very hacky workarounds. Possible solutions that |
| 64 | + were explored and rejected include: |
| 65 | + |
| 66 | + - Mounting the log file from the `proxy` container from the host to the relevant containers. |
| 67 | + Rejected because this practice is highly discouraged by docker as the actual storage location of log files |
| 68 | + is not standardized and may be changed in future versions. |
| 69 | + - Writing logs to a named pipe or socket within the `proxy` container. |
| 70 | + Rejected because this is very difficult to set up and is untested when then mounted to other containers. |
| 71 | + Also, a different named pipe would be required for each consumer which is currently very difficult to set up |
| 72 | + using birdhouse's deployment tools. |
| 73 | + |
| 74 | + **Breaking Change**: if a custom component (not included in this repository) uses the `proxy-logs` named volume. |
| 75 | + It must now include `optional-components/proxy-log-volume` as a `COMPONENT_DEPENDENCY` for that custom component. |
| 76 | + |
| 77 | + **Breaking Change**: if `SCHEDULER_JOB_BACKUP_ARGS` specifies `-l proxy` explicitly (not `-l '*'`) then this should |
| 78 | + be changed to `-l proxy-log-volume` since the backup script has been moved. Note that it is not necessary to |
| 79 | + specify `-l proxy-log-volume` if `--birdhouse-logs` is also specified because the log data is identical in both. |
| 80 | + |
| 81 | +- Make docker compose logging options configurable |
| 82 | + |
| 83 | + Introduce a new component `components/logging` that sets default logging options for all docker |
| 84 | + compose services started by `birdhouse-deploy`. This component is enabled by default. |
| 85 | + |
| 86 | + The default value is set by the `BIRDHOUSE_DOCKER_LOGGING_DEFAULT` environment variable. To change the default |
| 87 | + value, set the `BIRDHOUSE_DOCKER_LOGGING_DEFAULT` to a JSON string in the local environment file that contains |
| 88 | + a valid |
| 89 | + [docker compose logging configuration](https://docs.docker.com/reference/compose-file/services/#logging). |
| 90 | + |
| 91 | + For example, to set the default driver to "local" set the following in your local environment file: |
| 92 | + |
| 93 | + ```sh |
| 94 | + export BIRDHOUSE_DOCKER_LOGGING_DEFAULT='{"driver": "local"}' |
| 95 | + ``` |
| 96 | + |
| 97 | + You can also override logging options for a single service using environment variables using a variable |
| 98 | + `BIRDHOUSE_DOCKER_LOGGING_<service_name>` where `<service_name>` is the uppercase name of the docker compose |
| 99 | + service with hyphens replaced with underscores. For example, to set the default driver to "local" only for the |
| 100 | + `weaver-worker` service: |
| 101 | + |
| 102 | + ```sh |
| 103 | + export BIRDHOUSE_DOCKER_LOGGING_WEAVER_WORKER='{"driver": "local"}' |
| 104 | + ``` |
| 105 | + |
| 106 | + Logging options can can also be set directly in a component's ``docker-compose-extra.yml`` file. |
| 107 | + The order of precedence for logging options are as follows: |
| 108 | + |
| 109 | + 1. logging options specified by `BIRDHOUSE_DOCKER_LOGGING_<service_name>` environment variable |
| 110 | + 2. logging options set in a `docker-compose-extra.yml` file |
| 111 | + 3. logging options specified by `BIRDHOUSE_DOCKER_LOGGING_DEFAULT` environment variable |
| 112 | + |
| 113 | +- Add script that automatically updates postgres databases to a later version |
| 114 | + |
| 115 | + In anticipation of upgrading postgres databases in the future, this introduces a script that automatically |
| 116 | + upgrades postgres databases using the backup/restore process. |
| 117 | + |
| 118 | + This includes magpie and all WPS birds that use the postgres component. This does not include test component |
| 119 | + like `optional-components/generic_bird` and will not update custom components (ones not from this repository). |
| 120 | + |
| 121 | + Test components are not assumed to have persistent data that needs to be updated and we cannot guarantee that |
| 122 | + other postgres databases used by components outside this repository do not require additional steps (data |
| 123 | + migrations) in order to comply with a different version of postgres. |
| 124 | + |
| 125 | + It will update postgres databases to the version specified by the `POSTGRES_VERSION_UPDATE` environment variable. |
| 126 | + All of the old database files will be copied to a temporary directory in case you want to inspect them or revert |
| 127 | + this operation later on. To specify which directory to write these backups to set the `BIRDHOUSE_BACKUP_DATA_DIR` variable |
| 128 | + (default: `${TMPDIR:-/tmp}/birdhouse-postgres-migrate-backup/`) |
| 129 | + |
| 130 | + Note that backups in the form of database dumps will also be written to the named volume or directory specified |
| 131 | + by the `BIRDHOUSE_BACKUP_VOLUME` variable. |
| 132 | + |
| 133 | + For example, to update the current postgres databases to version 18.1 and write backups to `/tmp/test/` |
| 134 | + |
| 135 | + ```sh |
| 136 | + $ POSTGRES_VERSION_UPDATE=18.1 BIRDHOUSE_BACKUP_DATA_DIR=/tmp/test/ birdhouse/scripts/update-postgresh.sh |
| 137 | + ``` |
| 138 | + |
| 139 | + In a future update we can update the postgres versions and tell users to run this script first in order to safely |
| 140 | + migrate data from one version to the next. |
| 141 | + |
39 | 142 | [2.20.4](https://github.com/bird-house/birdhouse-deploy/tree/2.20.4) (2026-01-16) |
40 | 143 | ------------------------------------------------------------------------------------------------------------------ |
41 | 144 |
|
|
0 commit comments