Type of request
New feature
What problem would this solve?
I know we've discussed this before, but it's occurred to me we currently have three containers, with the sole purpose of initialising things for a new install, that are then never used again, but still have dependent containers
typetype-garage-config:
image: busybox:1.38
container_name: typetype-garage-config
networks:
typetype:
command:
- /bin/sh
- -ec
- |
config=/etc/garage/garage.toml
if [ -s "$$config" ]; then
exit 0
fi
umask 077
if [ -s /migration/garage.toml ]; then
cp /migration/garage.toml "$$config"
exit 0
fi
cat > "$$config" <<'EOF'
metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"
replication_factor = 1
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "127.0.0.1:3901"
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
EOF
volumes:
- ${CONFIG}/typetype/typetype-garage/config:/etc/garage
# - ${CONFIG}/typetype/typetype-garage-migration:/migration:ro # Not needed for fresh install of recent versions.
restart: no
typetype-postgres-init:
image: postgres:17
container_name: typetype-postgres-init
networks:
typetype:
# ports:
# - 5432:5432
depends_on:
typetype-postgres:
condition: service_started
environment:
POSTGRES_CONTAINER: ${POSTGRES_CONTAINER}
POSTGRES_DB: ${POSTGRES_DB}
POSTGRES_USER: ${POSTGRES_USER}
PGPASSWORD: ${POSTGRES_PASSWORD}
command:
- /bin/sh
- -ec
- |
until pg_isready -h ${POSTGRES_CONTAINER} -U ${POSTGRES_USER} -d ${POSTGRES_DB}; do sleep 1; done
EXISTS=$$(psql -h ${POSTGRES_CONTAINER} -U $${POSTGRES_USER} -d $${POSTGRES_DB} -tAc "SELECT 1 FROM pg_database WHERE datname='typetype_downloader'")
if [ "$$EXISTS" != "1" ]; then
psql -h ${POSTGRES_CONTAINER} -U $${POSTGRES_USER} -d $${POSTGRES_DB} -c "CREATE DATABASE typetype_downloader"
fi
restart: no
typetype-secrets:
image: busybox:1.38
container_name: typetype-secrets
networks:
typetype:
command:
- /bin/sh
- -ec
- |
generate_secret() {
dd if=/dev/urandom bs=48 count=1 2>/dev/null | base64 | tr '+/' '-_' | tr -d '=\n'
}
ensure_secret() {
file="$$1"
value="$$2"
placeholder="$$3"
legacy_placeholder="$$4"
if [ -n "$$value" ] && [ "$$value" != "$$placeholder" ] && [ "$$value" != "$$legacy_placeholder" ]; then
printf '%s' "$$value" > "$$file"
elif [ ! -s "$$file" ]; then
generate_secret > "$$file"
fi
chmod 0444 "$$file"
}
mkdir -p /run/typetype-secrets
ensure_secret /run/typetype-secrets/youtube_remote_login_internal_token "$$YOUTUBE_REMOTE_LOGIN_INTERNAL_TOKEN" SET_ME_YOUTUBE_REMOTE_LOGIN_INTERNAL_TOKEN SET_ME_SHARED_SECRET
ensure_secret /run/typetype-secrets/youtube_session_encryption_key "$$YOUTUBE_SESSION_ENCRYPTION_KEY" SET_ME_YOUTUBE_SESSION_ENCRYPTION_KEY SET_ME_SHARED_SECRET
# environment:
# YOUTUBE_REMOTE_LOGIN_INTERNAL_TOKEN: ${YOUTUBE_REMOTE_LOGIN_INTERNAL_TOKEN}
# YOUTUBE_SESSION_ENCRYPTION_KEY: ${YOUTUBE_SESSION_ENCRYPTION_KEY}
volumes:
- ${CONFIG}/typetype/typetype-secrets:/run/typetype-secrets
restart: noWhat would you like to see?
Other than the postgres-init container which needs postgres, the other two are just shell scripts. My thought is a couple of different options.
Amalgamate into a single script run via a customised container for at least typetype-secrets & garage-config, even consider making a single init container with postgres installed to perform all the init steps that can then be removed.
This could be documented with as a preinstall step.
- Download
example.env and mv to .env
- Run init container once (this could be in the projects compose.yml or even conceivably in a dedicated compose.yml for the init stage or a single docker run command.
Whilst the project uses docker volumes by standard, personally I've changed to using bind mounts as that's my preference, but either way the volume mapping host side could be achieved with some environmental variables.
The other option I thought of, is to incorporate the init procedure into existing containers, the downside of this is whichever container we used would require volume mounts to provide access that it wouldn't normally need.
Area
Not sure
Type of request
New feature
What problem would this solve?
I know we've discussed this before, but it's occurred to me we currently have three containers, with the sole purpose of initialising things for a new install, that are then never used again, but still have dependent containers
What would you like to see?
Other than the postgres-init container which needs postgres, the other two are just shell scripts. My thought is a couple of different options.
Amalgamate into a single script run via a customised container for at least typetype-secrets & garage-config, even consider making a single init container with postgres installed to perform all the init steps that can then be removed.
This could be documented with as a preinstall step.
example.envand mv to.envWhilst the project uses docker volumes by standard, personally I've changed to using bind mounts as that's my preference, but either way the volume mapping host side could be achieved with some environmental variables.
The other option I thought of, is to incorporate the init procedure into existing containers, the downside of this is whichever container we used would require volume mounts to provide access that it wouldn't normally need.
Area
Not sure