The idea of using yaml instead of env file format for app env config #105

New Issue

decentral1se · 2021-07-21T14:25:04Z

decentral1se commented

2021-07-21 14:25:04 +00:00

Follows from coop-cloud/go-abra#6 (comment).

The .env format is super nice but also, maybe it is not the most beginner friendly since there are some strange conventions that are really more to do with "we're moving fast and this is easier to do in Bash". Perhaps we could see a more explicit config and also a less verbose one.

If we take our Gitea config:

TYPE=gitea
STACK_NAME=gitea

DOMAIN=git.autonomic.zone
LETS_ENCRYPT_ENV=production

GITEA_DOMAIN=git.autonomic.zone
GITEA_ALLOW_ONLY_EXTERNAL_REGISTRATION=true
GITEA_APP_NAME="Git with solidaritea"
GITEA_AUTO_WATCH_NEW_REPOS=false
GITEA_DISABLE_REGISTRATION=false
GITEA_ENABLE_NOTIFY_MAIL=true
GITEA_ENABLE_OPENID_SIGNIN=true
GITEA_ENABLE_OPENID_SIGNUP=true

COMPOSE_FILE="compose.yml:compose.smtp.yml"
GITEA_SMTP_MAILER_ENABLED=1
GITEA_MAILER_FROM=noreply@autonomic.zone
GITEA_MAILER_HOST=mail.gandi.net:465
GITEA_MAILER_USER=noreply@autonomic.zone

GITEA_SSH_PORT=2222
GITEA_SSH_ENABLED=1

SECRET_INTERNAL_TOKEN_VERSION=v1 # length=105
SECRET_DB_PASSWORD_VERSION=v1
SECRET_DB_ROOT_PASSWORD_VERSION=v1
SECRET_JWT_SECRET_VERSION=v1 # length=43
SECRET_SECRET_KEY_VERSION=v1 # length=64
SECRET_SMTP_PASSWORD_VERSION=v1

Then maybe we could imagine something like:

app:  # definitely can be less vague
  type: gitea
  domain: git.autonomic.zone    # optional
  lets_encrypt_env: production  # optional

env:
  gitea_domain: git.autonomic.zone
  gitea_allow_only_external_registration: true
  ...
  
secrets:
  internal_token:
    length: 105
    version: v1
  db_password: v1
  ...

Where we:

categorise values under top-level markers e.g. "env", "secrets" (I think this would mostly help to formalise where things go and how to specify if they are mandatory/optional (both for human and machine) and furthermore, to aid in documentation)
everything is lowercase and is uppercase'd by the code (handier to type)
secrets are much less verbose and simpler (complexity goes to go-abra)

I'm for the idea of having a yaml -> envfile migration tool. We'll probably want to write a envfile -> yaml thing anyway.

I wouldn't do this now but here is a ticket for the thoughts 🤔

Follows from https://git.autonomic.zone/coop-cloud/go-abra/issues/6#issuecomment-7674. The `.env` format is super nice but also, maybe it is not the most beginner friendly since there are some strange conventions that are really more to do with "we're moving fast and this is easier to do in Bash". Perhaps we could see a more explicit config and also a less verbose one. If we take our Gitea config: ```env TYPE=gitea STACK_NAME=gitea DOMAIN=git.autonomic.zone LETS_ENCRYPT_ENV=production GITEA_DOMAIN=git.autonomic.zone GITEA_ALLOW_ONLY_EXTERNAL_REGISTRATION=true GITEA_APP_NAME="Git with solidaritea" GITEA_AUTO_WATCH_NEW_REPOS=false GITEA_DISABLE_REGISTRATION=false GITEA_ENABLE_NOTIFY_MAIL=true GITEA_ENABLE_OPENID_SIGNIN=true GITEA_ENABLE_OPENID_SIGNUP=true COMPOSE_FILE="compose.yml:compose.smtp.yml" GITEA_SMTP_MAILER_ENABLED=1 GITEA_MAILER_FROM=noreply@autonomic.zone GITEA_MAILER_HOST=mail.gandi.net:465 GITEA_MAILER_USER=noreply@autonomic.zone GITEA_SSH_PORT=2222 GITEA_SSH_ENABLED=1 SECRET_INTERNAL_TOKEN_VERSION=v1 # length=105 SECRET_DB_PASSWORD_VERSION=v1 SECRET_DB_ROOT_PASSWORD_VERSION=v1 SECRET_JWT_SECRET_VERSION=v1 # length=43 SECRET_SECRET_KEY_VERSION=v1 # length=64 SECRET_SMTP_PASSWORD_VERSION=v1 ``` Then maybe we could imagine something like: ```yaml app: # definitely can be less vague type: gitea domain: git.autonomic.zone # optional lets_encrypt_env: production # optional env: gitea_domain: git.autonomic.zone gitea_allow_only_external_registration: true ... secrets: internal_token: length: 105 version: v1 db_password: v1 ... ``` Where we: - categorise values under top-level markers e.g. "env", "secrets" (I think this would mostly help to formalise where things go and how to specify if they are mandatory/optional (both for human and machine) and furthermore, to aid in documentation) - everything is lowercase and is uppercase'd by the code (handier to type) - secrets are much less verbose and simpler (complexity goes to `go-abra`) I'm for the idea of having a yaml -> envfile migration tool. We'll probably want to write a envfile -> yaml thing anyway. I wouldn't do this now but here is a ticket for the thoughts 🤔

❤️ 1

decentral1se added the

question

design

labels 2021-07-21 14:25:04 +00:00

This repo is archived. You cannot comment on issues.