search

EnigmaCurry / d.rymcg.tech

A collection of self-hosted docker-compose projects with Traefik reverse proxy, integrated auth, and administrative Makefiles for easy maintainance
MIT License
53 stars 8 forks source link
docker docker-compose self-hosted traefik

readme

d.rymcg.tech

License: MIT Chat on Matrix

ℹ️ New book available now!: Portable Docker: Build and Deploy Anywhere with WireGuard Tunneling

This is a collection of Docker Compose projects, consisting of Traefik as a TLS HTTP/TCP/UDP reverse proxy, and other open-source self-hosted applications and services behind it. Each project is in its own sub-directory containing its own docker-compose.yaml and .env-dist sample config file. This structure allows you to pick and choose which services you wish to enable. You may also integrate your own external Docker Compose projects into this framework.

All (http) apps are secured with automatic TLS certificates (Let's Encrypt or Step-CA), along with configurable self-hosted authentication middleware (mTLS, OAuth2, or HTTP Basic auth), as well as user group authorization middlewares. Even non-TLS apps may be secured with the optional VPN (Wireguard) support.

Each project has a Makefile to simplify configuration, installation, and maintainance tasks. The setup for any sub-project is as easy as running:

Under the covers, setup is pure docker compose, with all configuration derived from your customized .env file.

Contents

All configuration comes from the environment

All of these projects are configured soley via environment variables written to Docker .env files.

The .env files for each application instance are to be kept secret because they include things like passwords and keys, and these should be kept on a secure workstation and not commited to git (they are ignored via .gitignore) . Each project includes a .env-dist file, which is a sample that must be copied to create your own secret .env file and edited according to the example. (Or run make config to run a setup wizard to create the .env file for you by answering some questions interactively.)

For containers that do not support environment variable configuration, a sidecar container is included (usually called config) that will generate a config file from a template including these environment variables, and is run automatically before the main application starts up (therefore the config file is dynamically generated at each startup).

This project stores all application data in Docker named volumes as opposed to host mounted directories. Host-mounted directories are considered an anti-pattern and will never be used in this project, unless there is a compelling reason to do so. For more information see Rule 3 of the 12 factor app philosophy. By following this rule, you can use Docker from a remote client (like your laptop, accessing a remote Docker server over SSH). More importantly, you can ensure that all of the dependent files are fully contained by Docker itself (/var/lib/docker/volumes/...), and therefore the entire application state is managed as part of the container/volume lifecycle.

Prerequisites

Create a Docker host (server)

Install Docker Server on your own public internet server or cloud host. You may also install to a private server behind a firewall (but in this case be sure to setup the Traefik ACME DNS Challenge, because the default TLS challenge requires an open port 443 public to the internet).

See SECURITY.md for a list of security concerns when choosing a hosting provider.

As one example, see DIGITALOCEAN.md for instructions on creating a secure Docker host on DigitalOcean.

If you need a semi-private development or staging server, and want to be able to share some public URLs for your services, you can protect your services by turning on Traefik's HTTP Basic Authentication, OAuth2 Authentication, mTLS with Step-CA and IPAllowlist middlewares, or you can make an exclusively private Traefik service with a Wireguard VPN.

For local development purposes, you can install Docker on a raspberry pi or you can install Docker in a virtual machine (in all scenarios you will remotely control Docker from your native workstation), this ensures that your development environment is deployed in the same way as you would a production server. Never install Docker on your native workstation/desktop! (Or, if you do, never give your normal user account any docker privileges!) See _docker_vm for details on how and why to install Docker in KVM/Qemu. Please note that Docker Desktop is not currently supported because it does not support host networking, and the Traefik configuration relies upon this (if you know a way around this, please open an issue/PR). (If you don't use Linux on your workstation, you may have better luck installing Docker yourself inside of a traditional virtual machine like VMWare or Virtualbox, and then setting up an SSH service so you can access the VM remotely from your native desktop (the docker client works just fine from WSL2); or even easier would be to install Docker on a raspberry pi and connect it on your LAN.

Setup DNS for your domain and Docker server

You need to bring your own internet domain name and DNS service. You will need to create DNS type A records (or AAAA records if using IPv6) pointing to your docker server. There are many different DNS platforms that you can use, but see DIGITALOCEAN.md for one example.

It is recommended to dedicate a sub-domain for this project, and then create sub-sub-domains for each application. This will create domain names that look like whoami.d.example.com, where whoami is the application name, and d is a unique name for the overall sub-domain representing your docker server (d is for docker, but you can make this whatever you want).

By dedicating a sub-domain for all your projects, this allows you to create a DNS record for the wildcard: *.d.example.com, which will automatically direct all sub-sub-domain requests to your docker server.

Note that you could put a wildcard record on your root domain, ie. *.example.com, however if you did this you would not be able to use the domain for a second instance, but if you're willing to dedicate the entire domain to this single instance, go ahead.

If you don't want to create a wildcard record, you can just create several normal A (or AAAA) records for each of the domains your apps will use, but this might mean that you need to come back and add several more records later as you install more projects, (and also complicates the TLS certificate creation process) but this would let you freely use whatever domain names you want.

Notes on firewall

This system does not include a network firewall of its own. You are expected to provide this in your host networking environment. (Note: ufw is NOT recommended for use with Docker, nor is any other firewall that is directly located on the same host machine as Docker. You should prefer an external dedicated network firewall [ie. your cloud provider, or VM host]. If you have no other option but to run the firewall on the same machine, check out chaifeng/ufw-docker for a partial fix.)

With only a few exceptions, all network traffic flows through one of several Traefik entrypoints, listed in the static configuration template (traefik.yml) in the entryPoints section.

Each entrypoint has an associated environment variable to turn it on or off. See the Traefik configuration for more details.

Depending on which services you actually install, and how they are configured, you may need to open these ports in your firewall:

Type Protocol Port Range Description
SSH TCP 22 Host SSH server (direct-map)
HTTP TCP 80 Traefik HTTP entrypoint (web; redirects to websecure)
HTTP+TLS TCP 443 Traefik HTTPS entrypoint (websecure)
TCP socket TCP 1704 Traefik Snapcast (audio) entrypoint
TCP socket TCP 1705 Traefik Snapcast (control) entrypoint
RTMP(s) TCP 1935 Traefik RTMP (real time message protocol) entrypoint
SSH TCP 2222 Traefik Forgejo SSH (TCP) entrypoint
SSH TCP 2223 SFTP container SSH (TCP) (direct-map)
TLS TCP 5432 PostgreSQL mTLS DBaaS (direct-map)
TCP+TLS TCP 6380 Traefik Redis in-memory database entrypoint
TCP socket TCP 6600 Traefik Mopidy (MPD) entrypoint
HTTP TCP 8000 Traefik HTTP entrypoint (web_plain; explicitly non-https)
TLS TCP 8883 Traefik MQTT (TLS) entrypoint
WebRTC UDP 10000 Jitsi Meet video bridge (direct-map)
VPN UDP 51820 Wireguard (Traefik VPN) (direct-map)

The ports that are listed as (direct-map) are not connected to Traefik, but are directly exposed (public) to the docker host network.

For a minimal installation, you only need to open ports 22 and 443. This would enable all of the web-based applications to work, except for the ones that need an additional port, as listed above.

See DIGITALOCEAN.md for an example of setting the DigitalOcean firewall service.

Later, after you've deployed things, you can audit all of the open published ports: from the root project directory, run make show-ports to list all of the services with open ports (or those that run in the host network and are therefore completely open. You will find traefik and the wireguard server/client in this latter category). Each sub-project directory also has a make status with useful per-project information.

Configure Docker bridge networks (optional)

By default, Docker will only reserve enough IP addresses for a total of 30 user-defined networks. This means that, by default, you can only deploy up to 30 apps per docker server.

If you would like more than 30, you can increase the range of IP addresses that Docker reserves. On your Docker server, edit /etc/docker/daemon.json (create this file if it does not exist), and merge the following configuration:

{
  "default-address-pools": [
    {"base": "172.17.0.0/16", "size": 24}
  ]
}

and restart the docker daemon, or reboot the server.

Setup Workstation

Your local "workstation" is assumed to be a Linux desktop/laptop computer, or another Linux system that you remotely connect to via SSH:

Install Docker CLI tools

You need to install the following tools on your local workstation:

For Arch Linux, run: sudo pacman -S docker docker-compose docker-buildx

For Debian or Ubuntu, you should strictly follow the directions from the links above and install only from the docker.com third party apt repository (because the docker packages from the Ubuntu repositories are always out of date).

You do not need to (and perhaps should not) run the Docker Engine on your local workstation. You will use the docker client exclusively to control a remote docker server (or VM). To turn off/disable the Docker Engine on your worksation, run the following:

## Disable local Docker Engine:
sudo systemctl mask --now docker

Enable Docker buildx (optional)

Following the buildx installation guide, and run the installation:

docker buildx install

Install workstation tools

The Makefiles have extra dependencies in order to help configure and manage your containers. These dependencies are optional, but strongly recommended. (The Makefiles are strictly convenience wrappers for creating/modifying your .env files, and for running docker compose commands, so if you would rather just edit your .env files by hand and/or run docker compose manually, these dependencies may be skipped):

On Arch Linux, run this to install all these dependencies:

pacman -S bash base-devel gettext git openssl apache xdg-utils jq sshfs wireguard-tools curl inotify-tools w3m moreutils

For Debian or Ubuntu, run:

apt-get install bash build-essential gettext git openssl apache2-utils xdg-utils jq sshfs wireguard curl inotify-tools w3m moreutils

For Fedora, run:

dnf install bash gettext openssl git xdg-utils jq sshfs curl inotify-tools httpd-tools make wireguard-tools w3m moreutils

Setup SSH access to the server

Make sure that your local workstation user account is setup for SSH access to the remote docker server (ie. you should be able to ssh to the remote server root account, or another account that has been added into the docker group). You should setup key-based authentication so that you don't need to enter passwords during login, as each docker command will need to authenticate via SSH.

When set for a remote Docker context, the docker command will create a new SSH connection for each time it is run. This can be especially slow for running several commands in a row. You can speed the connection time up, by enabling SSH connection multiplexing, which starts a single background connection and makes new connections re-use this existing connection.

On your workstation, create or edit your existing ${HOME}/.ssh/config file. Add the following configuration (replacing ssh.d.example.com with your own docker server hostname, and root for the user account that controls Docker):

Host ssh.d.example.com
    User root
    ControlMaster auto
    ControlPersist yes
    ControlPath /tmp/ssh-%u-%r@%h:%p

(The hostname ssh.d.example.com relies upon the wildcard *.d.example.com or an explicit A record having been created for this hostname.)

Note: if you use a workstation that goes to sleep, or loses network connectivity, you may find that your shared+multiplexed SSH connections will sometimes become zombies and stop communication. Get used to running killall ssh before trying to restablish the connection.

Set remote Docker context

On your local workstation, create a new Docker context to use with your remote docker server (eg. named d.example.com) over SSH:

docker context create d.example.com --docker "host=ssh://ssh.d.example.com"
docker context use d.example.com

(To benefit from connection multiplexing, make sure to use the exact Host name [ssh.d.exmaple.com] that you specified in your ${HOME}/.ssh/config)

Now whenever you issue docker commands on your local workstation, you will actually be controlling your remote Docker server through SSH, and you can easily switch contexts between multiple server backends.

For example, I have three docker contexts, for three different remote Docker servers:

$ docker context ls
NAME              DESCRIPTION  DOCKER ENDPOINT
d.rymcg.tech *                 ssh://ssh.d.rymcg.tech
docker-vm                      ssh://docker-vm
pi                             ssh://pi

(The * indicates my current context.)

I can select to use which context I want to use:

$ docker context use docker-vm
Current context is now "docker-vm"

(This is a permanent setting that will survive a workstation reboot. Use the same command again to switch to any other context.)

Clone this repository to your workstation

git clone https://github.com/EnigmaCurry/d.rymcg.tech.git \
    ${HOME}/git/vendor/enigmacurry/d.rymcg.tech

cd ${HOME}/git/vendor/enigmacurry/d.rymcg.tech

You may clone to any path you like, but the path suggested above is a vendor neutral way of organizing third party repositories, with the intention of making the same path work on all machines.

Main configuration

Run the configuration wizard, and answer the questions:

## Run this command inside the root source directory of d.rymcg.tech:
make config

Running make config, in the root project directory, writes the main project level variables into a file named .env_${DOCKER_CONTEXT} (eg. .env_d.example.com) in the root source directory, based upon the name of the current Docker context. This file is excluded from the git repository via .gitignore.)

All of the Makefiles depend on a helper utility called script-wizard, which is automatically installed the first time you run make config.

This will also check your system for the dependencies and alert you if you need to install something.

The ROOT_DOMAIN variable is saved in .env_${DOCKER_CONTEXT} and will serve as the default root domain of all of the sub-project domains, so that when you run make config in any of the sub-project directories, the default (yet customizable) domain will be pre-populated with this root domain suffix.

You can have multiple .env_${DOCKER_CONTEXT} files, one for each Docker server, named after the associated Docker context. To switch the current .env file being used, change the Docker context:

docker context use {CONTEXT}

Install applications

Each of the sub-projects have their own README.md. You should install Traefik first, as almost all of the others depend on it. After that, install the whoami service to test that things are working correctly.

Install these first:

Install these recommended backbone applications next:

Install these other services at your leisure/preference:

You can create a new application by using any other application as an example, (whoami is the most basic one).

Bespoke things:

Also check the _attic directory for a collection of old and broken things.

Command line interaction

As alluded to earlier, this project offers multiple ways to control Docker:

  1. Editing .env files by hand, and running docker compose commands yourself (this is a usable, but lower level, base abstraction).
  2. Running make targets that edit the .env files automatically and runs docker compose for you (this is the author's preferred method, and the one that most of the documentation will actually use).
  3. Running the d.rymcg.tech CLI script, which runs the make targets from any working directory. (This method also includes extra features such as creating your own new projects from templates.)

All of these methods are compatible, and they will all get you to the same place. The Makefiles offer a more streamlined approach with a configuration wizard and sensible defaults. Most of the sub-project README files reflect the make command style for config. Editing the .env files by hand still offers you more control, with more freedom for experimentation, and this option always remains available.

Using the Makefiles

Each project has a Makefile that helps to simplify installation and maintainance. You can use the Makefiles to automatically edit the .env files and to start the services for you (and this way you won't have to run any docker commands by hand).

The most important thing to know is that make looks for a Makefile in your current working directory. make is contextual to the directory you are in.

make config does not literally create a file named .env, but rather one based upon the current docker context: .env_${DOCKER_CONTEXT}_default. This allows for different configurations to coexist in the same directory. All of the make commands operate assuming this contextual environment file name, not .env. To switch between configs, you switch your current docker context: docker context use {CONTEXT}.

During make config, you will sometimes be asked to create HTTP Basic Authentication passwords, and these passwords can be optionally saved into a file named passwords.json inside the sub-project directory. This file is a convenience, so that you can remember the passwords that you create. passwords.json is stored in plain text, but excluded from being checked into git via .gitignore. When you run make open the username and password stored in this file is automatically applied to the URL that the browser is asked to open, thus logging you into the website account automatically. To delete all of the passwords.json files, you can run make delete-passwords in the root directory of this project (or make clean which will delete the .env files too).

For a more in depth guide on using the Makefiles, see MAKEFILE_OPS.md

Using the d.rymcg.tech CLI script (optional)

By default, both make and docker compose expect you to change your working directory to use them, and so this is sometimes inconvenient. You can work around this by using make -C or docker compose -f, but another option is to use the eponymous d.rymcg.tech script that is included in this repository.

In addition to letting you run any project's make targets from any working directory, this shell script also offers a convenient way to create external projects from a skeleton template, and to create shorter command aliases for any project.

To install the script, you need to add it to your PATH shell variable, and at your option, evaluate the Bash shell tab completion script:

#### To enable Bash shell completion support for d.rymcg.tech,
#### add the following lines into your ~/.bashrc ::
export PATH=${PATH}:${HOME}/git/vendor/enigmacurry/d.rymcg.tech/_scripts/user
eval "$(d.rymcg.tech completion bash)"

Once installed, run d.rymcg.tech to see the command help text.

## Main d.rymcg.tech sub-commands:
cd             Enter a sub-shell and go to the ROOT_DIR directory
create         Create a new external project
make           Run a make command for the given d.rymcg.tech project name

## Documentation sub-commands:
help                  Show this help screen
list                  List available d.rymcg.tech projects
                      (not including external projects, unless you symlink them into ROOT_DIR)
readme [PROJECT]      Open the README.md for the given project name
readme                Open the main d.rymcg.tech README.md in your browser
readme raspberry_pi   Open the RASPBERRY_PI.md documentation
readme makefile_ops   Open the MAKEFILE_OPS.md documentation
readme security       Open the SECURITY.md documentation
readme digitalocean   Open the DIGITALOCEAN.md documentation
readme license        Open the LICENSE.txt software license

You can use this script to run the make targets for any of the bundled projects, usable from any working directory, and with full tab completion support:

d.rymcg.tech make [PROJECT_NAME] ... is a simple wrapper for make -C ~/git/vendor/enigmacurry/d.rymcg.tech/${PROJECT_NAME} ... (the script will detect the correct path that you cloned to) so that you can run all of the same things as outlined in MAKEFILE_OPS.md, but from any directory. The special project placeholder value - (any number of consecutive dashes) indicates to use the root Makefile rather than any particular project Makefile.

You can get into the root d.rymcg.tech directory quickly, from anywhere:

## This enters a subshell and changes the working directory to the d.rymcg.tech root:
## (You can also specify a second argument to specify the sub-directory.)
d.rymcg.tech cd

Press Ctrl-D to exit the sub-shell and jump back to wherever you came from.

From any working directory, you can create a new, external project, from an external repository URL:

# This creates a new project directory in your current working directory:
# It will ask you to enter the name of the project and choose the template.
# Optional 2nd and 3rd args will skip the asking: PROJECT_NAME TEMPLATE_REPO
d.rymcg.tech create

Check out the example Python Flask template repository.

Open any project's README file directly in your web browser:

## Open the main README
d.rymcg.tech readme

## Open the Traefik README
d.rymcg.tech readme traefik

Project and context specific shell aliases

You can add additional command aliases to your shell (put these in your ~/.bashrc after the eval line that loads the main d.rymcg.tech script):

## Alternative alias to shorten `d.rymcg.tech` to simply `d`:
__d.rymcg.tech_cli_alias d

You can make project specific aliases:

## Example project alias: creates a shorter command used just for the Traefik project:\
## e.g., `traefik config`, `traefik install`
__d.rymcg.tech_project_alias traefik

If you have created an external project (eg. named mikeapp), you can create a command alias for it:

## Example external project alias:
## e.g., `mikeapp config`, `mikeapp install`
__d.rymcg.tech_project_alias mikeapp ~/git/mikeapp

You can also do context specific aliases:

## Example context alias: creates a shorter command used just for the given Docker context:
## e.g., `sentry make traefik config`, `sentry make traefik install`.
__d.rymcg.tech_context_alias sentry

To get a synopsis of all of these completion commands, run:

d.rymcg.tech completion

Using docker compose by hand (optional)

This project was originally designed to be a pure docker compose project, and it still is. The make commands or the d.rymcg.tech wrapper script are the recommended methods to use, however you can still use docker compose by hand if you wish.

For all of the containers that you wish to install, do the following:

When using docker compose by hand, it uses the .env file name by default. To use any other filename, specify the --env-file argument (eg. when deploying multiple instances).

Creating multiple instances of a service

By default, each project supports deploying a single instance per Docker context. The singleton instance environment file is named .env_${DOCKER_CONTEXT}_default, which is contained in each project subdirectory (eg. whoami/.env_d.example.com_default).

If you want to deploy more than one instance of a given project (and to the same docker context, and from the same source directory), you need to create a separate environment file for each one. The convention that the Makefile expects is to name your several environment files like this: .env_${DOCKER_CONTEXT}_${INSTANCE_NAME} (eg. whoami/.env_d.example.com_foo).

Not every project supports instances yet (nor does it make sense to in some cases), it is opt-in for each project, by including the Makefile.instance file at the top of their own Makefile.

By default, all of the make targets will use the default environment, but you can tell it use the instance environment instead, by setting the instance (or INSTANCE) variable:

make instance=foo config  # Configure a new or existing instance named foo
make instance=bar config  # (Re)configures bar instance
make instance=foo install # This (re)installs only the foo instance
make instance=bar install # (Re)installs only bar instance
make instance=foo ps      # This shows the containers status of the foo instance
make instance=foo stop    # This stops the foo instance
make instance=bar destroy # This destroys only the bar instance

# Show the status of all instances of the current project subdirectory:
make status

It may seem tedious to repeat typing instance=foo everytime (and its easy to forget!), so there is a shortcut: make instance, which will ask you to enter an instance name, and then enter a new sub-shell with the environment variables set for that instance, making it now the default within the sub-shell, so you don't have to type it anymore:

# Use this to create a new instance (or to use an existing one):
# Enter a subshell with the instance temporarily set as the default:
make instance

Example:

## Example terminal session for creating a new instance of whoami named foo:

$ cd ~/git/vendor/enigmacurry/d.rymcg.tech/whoami
$ make instance
Enter an instance name to create/edit
: foo
Configuring environment file: .env_d.rymcg.tech_foo
WHOAMI_TRAEFIK_HOST: Enter the whoami domain name (eg. whoami.example.com)
: whoami-foo.d.rymcg.tech
WHOAMI_NAME: Enter a unique name to display in all responses
: foo
Set WHOAMI_INSTANCE=foo
## Entering sub-shell for instance foo.
## Press Ctrl-D to exit or type `exit`.

(context=d.rymcg.tech project=whoami instance=foo)
whoami $

Inside the sub-shell, the PS1 Bash prompt has been set so that it will remind you of your current locked instance: (context=d.rymcg.tech project=whoami instance=foo). You have access to all of the same make targets as before, but now they will apply to the instance by default:

## Inside of the foo instance sub-shell ...
make config                  # (Re)configures foo instance
make install                 # (Re)installs foo instance
make destroy                 # Destroys foo instance
etc...

To exit the sub-shell, press Ctrl-D or type exit and you will return to the original parent shell and working directory.

When you create a new instance, make config will automatically run. You may switch to an existing instance with either: make instance or make switch (the former will re-run make config while the latter will not).

Overriding docker-compose.yaml per-instance

Most of the time, when you create multiple instances, the only thing that needs to change is the environment file (.env_${DOCKER_CONTEXT}_${INSTANCE}). Normally the docker-compose.yaml is static and stays the same between several instances.

However, sometimes you need to configure the docker-compose.yaml of two instances a little bit differently from each other, but mostly stay the same. You may also wish to modify the configuration without wanting to commit those changes back to the base template in the git repository.

You can override each project's docker-compose.yaml with a per-docker-context docker-compose.override_${DOCKER_CONTEXT}_default.yaml (default instance) or a per-instance docker-compose.override_${DOCKER_CONTEXT}_${INSTANCE}.yaml file.

You can find an example of this in the sftp project. Each instance of sftp will need a custom set of volumes, and since this is normally a static list in docker-compose.yaml, you need a way of dynamically generating it. There is a template docker-compose.instance.yaml that when you run make config it will render the template to the file docker-compose.override_${DOCKER_CONTEXT}_default.yaml containing the custom mountpoints (this file is ignored by git.) The override file is merged with the base docker-compose.yaml whenever you run make install, thus each instance receives its own list of volumes to mount.

Reference the Docker compose documentation for Adding and overriding configuration regarding the rules for how the merging of configuration files takes place.

Backup .env files (optional)

Because the .env files contain secrets, they are to be excluded from being committed to the git repository via .gitignore. However, you may still wish to retain your configurations by making a backup. This section will describe how to make a backup of all of your .env and passwords.json files into a GPG encrypted tarball, and how to clean/delete all of the plain text copies.

Setup GPG

First you will need to setup a GPG key. You can do this from the same workstation, or from a different computer entirely:

# Create gpg key (note the long ID it generates, second line after 'pub'):
gpg --gen-key

# Send your key to the public keyserver:
gpg --send-keys [YOUR_KEY_ID]

On the workstation you cloned this repository to, import this key:

# Import your key from the public keyserver:
gpg --receive-keys [YOUR_KEY_ID]

Create encrypted backup

From the root directory of your clone of this repository, run:

make backup-env

The script will ask to add GPG_RECIPIENT to your .env_${DOCKER_CONTEXT}_default file. Enter the GPG pub key ID value for your key.

A new encrypted backup file will be created in the same directory called something like ./${DOCKER_CONTEXT}_environment-backup-2022-02-08--18-51-39.tgz.gpg. The GPG_RECIPIENT key is the only key that will be able to read this encrypted backup file.

Clean environment files

Now that you have an encrypted backup, you may wish to delete all of the unencryped .env files. Note that you will not be able to control your docker-compose projects without the decrypted .env files, but you may restore them from the backup at any time.

To delete all the .env files, you could run:

## Make sure you have a backup of your .env files first:
make clean

Restore .env files from backup

To restore from this backup, you will need your GPG private keys setup on your worstation, and then run:

make restore-env

Enter the name of the backup file, and all of the .env and passwords.json files will be restored to their original locations.

Integrating external projects

You may create your own external projects, and/or integrate your existing docker-compose projects, including from external git repositories, and have them use the same d.rymcg.tech framework.

Create the Makefile in your own separate repository so that it includes the main d.rymcg.tech Makefile.projects file from elsewhere:

## Example Makefile in your own project repository:

# ROOT_DIR can be a relative or absolute path to the d.rymcg.tech directory:
ROOT_DIR = ${HOME}/git/vendor/enigmacurry/d.rymcg.tech
include ${ROOT_DIR}/_scripts/Makefile.projects
include ${ROOT_DIR}/_scripts/Makefile.instance

.PHONY: config-hook # Configure .env file
config-hook:
    @${BIN}/reconfigure_ask ${ENV_FILE} EXAMPLE_TRAEFIK_HOST "Enter the example domain name" example.${ROOT_DOMAIN}
    @${BIN}/reconfigure_ask ${ENV_FILE} EXAMPLE_OTHER_VAR "Enter the example other variable"

By convention, external project Makefiles should always hardcode the enigmacurry git vendor path: ROOT_DIR = ${HOME}/git/vendor/enigmacurry/d.rymcg.tech, (but you may want to use your own directory if you have forked this project and you have introduced unmerged changes):

## As long as everyone uses this same ROOT_DIR, then we can all share the same configs:
## (You might also create this path as a symlink, if you don't like this convention):
ROOT_DIR = ${HOME}/git/vendor/enigmacurry/d.rymcg.tech

A minimal Makefile, like the one above, should include a config-hook target that reconfigures your .env file based upon the example variables given in .env-dist. This is what the user will have to answer qusetions for when running make config for your project.

Now in your own project directory, you can use all the regular make commands that d.rymcg.tech provides:

make config
make install
make open
# etc

Questions and discussion

If you have a question, or have some feedback, you can join us on the Matrix chat room. You can also use the discussions interface on github.

Feature suggestions, bug reports, and pull requests, are all welcome on the github repository, but only open source self-hostable software is acceptable for inclusion in this repository.