|
15 | 15 | [Unreleased](https://github.com/bird-house/birdhouse-deploy/tree/master) (latest) |
16 | 16 | ------------------------------------------------------------------------------------------------------------------ |
17 | 17 |
|
18 | | -[//]: # (list changes here, using '-' for each new entry, remove this when items are added) |
| 18 | +## Changes |
| 19 | + |
| 20 | +- Remove `proxy` component's dependency on `scheduler` and `scheduler-job-logrotate-nginx` |
| 21 | + |
| 22 | + Creates new settings in `optional-components/proxy-log-volume` that create the `proxy-logs` docker volume as well |
| 23 | + as instructing Nginx to write access logs to an additional log file (specified by `PROXY_LOG_PATH`). These settings |
| 24 | + are included as a `COMPONENT_DEPENDENCY` in components that require access to the the `proxy` access logs as a |
| 25 | + regular file. If no components require access to these logs as a regular file then the `proxy` component will only |
| 26 | + write access logs to the stdout stream for that container. |
| 27 | + |
| 28 | + Right now, the only components that require access to logs in this way are `components/canarie-api` and |
| 29 | + `optional-components/prometheus-log-parser`. Both of these now include `optional-components/proxy-log-volume` as a |
| 30 | + `COMPONENT_DEPENDENCY`. |
| 31 | + |
| 32 | + Note: this means that if no optional components require `optional-components/proxy-log-volume` as a dependency |
| 33 | + then logs from the `proxy` container will only be written to stdout/stderr. This means that there is no need |
| 34 | + for any additional custom log rotation handling since the logs are handled directly by docker. This means that |
| 35 | + the `proxy` service itself no longer need to be dependant on the `scheduler` and `scheduler-job-logrotate-nginx` |
| 36 | + components. |
| 37 | + |
| 38 | + Note: a previous discussion suggested that logs could be parsed directly from the stdout stream of the `proxy` |
| 39 | + container. However, there is no way to do so that doesn't require very hacky workarounds. Possible solutions that |
| 40 | + were explored and rejected include: |
| 41 | + |
| 42 | + - Mounting the log file from the `proxy` container from the host to the relevant containers. |
| 43 | + Rejected because this practice is highly discouraged by docker as the actual storage location of log files |
| 44 | + is not standardized and may be changed in future versions. |
| 45 | + - Writing logs to a named pipe or socket within the `proxy` container. |
| 46 | + Rejected because this is very difficult to set up and is untested when then mounted to other containers. |
| 47 | + Also, a different named pipe would be required for each consumer which is currently very difficult to set up |
| 48 | + using birdhouse's deployment tools. |
| 49 | + |
| 50 | + **Breaking Change**: if a custom component (not included in this repository) uses the `proxy-logs` named volume. |
| 51 | + It must now include `optional-components/proxy-log-volume` as a `COMPONENT_DEPENDENCY` for that custom component. |
| 52 | + |
| 53 | + **Breaking Change**: if `SCHEDULER_JOB_BACKUP_ARGS` specifies `-l proxy` explicitly (not `-l '*'`) then this should |
| 54 | + be changed to `-l proxy-log-volume` since the backup script has been moved. Note that it is not necessary to |
| 55 | + specify `-l proxy-log-volume` if `--birdhouse-logs` is also specified because the log data is identical in both. |
| 56 | + |
19 | 57 |
|
20 | 58 | [2.20.2](https://github.com/bird-house/birdhouse-deploy/tree/2.20.2) (2026-01-05) |
21 | 59 | ------------------------------------------------------------------------------------------------------------------ |
|
0 commit comments