123 lines
5.5 KiB
Markdown
Raw Permalink Normal View History

2025-02-07 01:09:03 +01:00
# signal-cli-rest-api Docker Compose files
2024-10-10 01:08:53 +00:00
2025-02-07 01:09:03 +01:00
Docker Compose files to spin up an instance of signal-cli-rest-api.
# How to run
We depend on the project's upstream GitHub repo at [github.com/bbernhard/signal-cli-rest-api](https://github.com/bbernhard/signal-cli-rest-api) which comes with a [docker-compose.yml](https://github.com/bbernhard/signal-cli-rest-api/blob/master/docker-compose.yml) file that we're using as our base file in `docker compose` commands.
Add a `COMPOSE_ENV` file and save its location as a shell variable along with the location where this repo lives, here for example `/opt/containers/signal_cli_rest_api` plus all other variables. At [env/fqdn_context.env.example](env/fqdn_context.env.example) you'll find an example environment file.
When everything's ready start signal-cli-rest-api with Docker Compose, otherwise head down to [Initial setup](#initial-setup) first.
## Environment
We're assuming that the `master` branch of [github.com/bbernhard/signal-cli-rest-api](https://github.com/bbernhard/signal-cli-rest-api) is checked out at `/opt/git/github.com/bbernhard/signal-cli-rest-api/tags/latest`. We'll get to the `tags/latest` nomenclature in sec.
```
export UPSTREAM_REPO_DIR='/opt/git/github.com/bbernhard/signal-cli-rest-api/tags/latest'
export UPSTREAM_COMPOSE_FILE="${UPSTREAM_REPO_DIR%/}"'/docker-compose.yml'
export COMPOSE_CTX='ux_vilnius'
export COMPOSE_PROJECT='signal_cli_rest_api-'"${COMPOSE_CTX}"
export COMPOSE_PROJECT_DIR='/opt/containers/signal_cli_rest_api'
export COMPOSE_OVERRIDE="${COMPOSE_PROJECT_DIR%/}"'/docker-compose.override.yaml'
export COMPOSE_COMMON_SETTINGS="${COMPOSE_PROJECT_DIR%/}"'/common-settings.yaml'
export COMPOSE_ENV=<add accordingly>
```
## Prepare upstream Git repo
Check out the newest branch of [github.com/bbernhard/signal-cli-rest-api](https://github.com/bbernhard/signal-cli-rest-api). Notice that we're referencing `"${UPSTREAM_REPO_DIR}"` from above and that we're storing the current Git `refname` of our branch in `"${VERSION}"`. This is typically a string such as `0.91` and happens to coincide with Docker image tags used at [Docker Hub at bbernhard/signal-cli-rest-api](https://hub.docker.com/r/bbernhard/signal-cli-rest-api).
```
git -C "${UPSTREAM_REPO_DIR}" reset --hard origin
git -C "${UPSTREAM_REPO_DIR}" checkout master
git -C "${UPSTREAM_REPO_DIR}" pull
export VERSION="$(git -C "${UPSTREAM_REPO_DIR}" tag -l --sort -version:refname | head -n 1)"
git -C "${UPSTREAM_REPO_DIR}" checkout "${VERSION}"
```
## Context
On your deployment machine create the necessary Docker context to connect to and control the Docker daemon on whatever target host you'll be using, for example:
```
docker context create fully.qualified.domain.name --docker 'host=ssh://root@fully.qualified.domain.name'
```
## Pull
Pull images from Docker Hub verbatim.
```
docker compose --project-name "${COMPOSE_PROJECT}" --file "${UPSTREAM_COMPOSE_FILE}" --file "${COMPOSE_OVERRIDE}" --env-file "${COMPOSE_ENV}" pull
```
## Copy to target
Copy images to target Docker host, that is assuming you deploy to a machine that itself has no network route to reach Docker Hub or your private registry of choice. Copying in its simplest form involves a local `docker save` and a remote `docker load`. Consider the helper mini-project [quico.space/Quico/copy-docker](https://quico.space/Quico/copy-docker) where [copy-docker.sh](https://quico.space/Quico/copy-docker/src/branch/main/copy-docker.sh) allows the following workflow. Note that `"${VERSION}"` comes from the Git `refname` we used a second ago.
```
copy-docker 'bbernhard/signal-cli-rest-api:'"${VERSION}" fully.qualified.domain.name
```
## Start
```
docker --context 'fully.qualified.domain.name' compose --project-name "${COMPOSE_PROJECT}" --file "${UPSTREAM_COMPOSE_FILE}" --file "${COMPOSE_OVERRIDE}" --env-file "${COMPOSE_ENV}" up --detach
```
# Initial setup
We're assuming you run Docker Compose workloads with ZFS-based bind mounts. ZFS management, creating a zpool and setting adequate properties for its datasets is out of scope of this document.
## Datasets
Create ZFS datasets and set permissions as needed.
* Parent dateset
```
export "$(grep -Pi -- '^CONTEXT=' "${COMPOSE_ENV}")"
zfs create -o canmount=off zpool/data/opt
zfs create -o mountpoint=/opt/docker-data zpool/data/opt/docker-data
```
* Container-specific datasets
```
zfs create -p 'zpool/data/opt/docker-data/signal_cli_rest_api-'"${COMPOSE_CTX}"'/config'
```
* Change ownership
```
export "$(grep -Pi -- '^[UG]ID=' "${COMPOSE_ENV}")"
chown -R "${UID}"':'"${GID}" 'zpool/data/opt/docker-data/signal_cli_rest_api-'"${COMPOSE_CTX}"'/config'
```
## Additional files
No additional files are needed to get started.
Head back up to [How to run](#how-to-run).
# Development
## Conventional commits
This project uses [Conventional Commits](https://www.conventionalcommits.org/) for its commit messages.
### Commit types
Commit _types_ besides `fix` and `feat` are:
- `refactor`: Keeping functionality while streamlining or otherwise improving function flow
- `docs`: Documentation for project or components
### Commit scopes
The following _scopes_ are known for this project. A Conventional Commits commit message may optionally use one of the following scopes or none:
- `signal_cli_rest_api`: A change to how the `signal_cli_rest_api` service component works
- `build`: Build-related changes such as `Dockerfile` fixes and features.
- `mount`: Volume or bind mount-related changes.
- `net`: Networking, IP addressing, routing changes
- `meta`: Affects the project's repo layout, file names etc.