From 29ff19148003c31a6b8f67fca1b6a79400c584ce Mon Sep 17 00:00:00 2001 From: Michiel de Jong Date: Mon, 17 Nov 2014 11:10:42 +0000 Subject: [PATCH] first draft of adding an application doc --- doc/adding-an-application.md | 36 ++++++++++++++++++++++++++++++++++++ doc/deploying-a-server.md | 1 + 2 files changed, 37 insertions(+) create mode 100644 doc/adding-an-application.md diff --git a/doc/adding-an-application.md b/doc/adding-an-application.md new file mode 100644 index 0000000..186866e --- /dev/null +++ b/doc/adding-an-application.md @@ -0,0 +1,36 @@ +# Adding an application + +There are two types of application: server-wide, and per-user. Right now, server-wide applications are the postfix-forwarder, +and the haproxy. Available per-user applications right now are wordpress, static, and static-git. + +# Adding a server-wide application + +To add a server-wide application, first make sure it can run on one IPv4 address for multiple domains. If it can, then: + +* Package it into one Dockerfile per process, and add these to the [dockerfiles](https://github.com/indiehosters/dockerfiles) repo. +* Add `docker pull`, `systemctl enable` and `systemctl start` commands to `scripts/setup.sh`. +* Make it take user data from /data/PROCESS/, and data that is needed at runtime but should not be backed up can +go into /data/runtime/PROCESS +* Create a systemd unit file for each process in the `unit-files/` folder +* Either add functionality to `scripts/add-site.sh` to configure domains on this new service, or describe the manual steps for this +in [deploying-a-server.md](deploying-a-server.md). +* Double-check all documentation to see if it is all still correct. + +# Adding a per-user application + +To add a per-user application, first make sure it can run behind an SNI offloader. For instance, for WordPress to work behind an SNI +offloader, we had to activate the "https" plugin. If it can, then: + +* First study how for instance the WordPress application works in this repo, the easiest approach is to copy it as a starting point. +* Package it into one Dockerfile per process, and add these to the [dockerfiles](https://github.com/indiehosters/dockerfiles) repo. +* Add `docker pull` commands to `scripts/setup.sh`. +* Make it take user data from /data/domains/DOMAIN.COM/PROCESS/, and data that is needed at runtime but should not be backed up can +go into /data/runtime/domains/DOMAIN.COM/PROCESS. +* Create a systemd unit file for each process in the `unit-files/` folder, ending in "@.service", so they get symlinked for each domain. +* If there are cronjobs to be added, then this is done with "@.timer" files. +* Link the processes together, using docker linking and systemd dependencies. +* Add import logic, and if there is any pre-backup action necessary to make sure all relevant data is under /data/domain, then add this as +a pre-step to the backup unit. +* Either add functionality to `scripts/add-site.sh` to configure domains on this new service, or describe the manual steps for this +in [deploying-a-server.md](deploying-a-server.md). +* Double-check all documentation to see if it is all still correct. diff --git a/doc/deploying-a-server.md b/doc/deploying-a-server.md index 7c0bf10..7410814 100644 --- a/doc/deploying-a-server.md +++ b/doc/deploying-a-server.md @@ -74,4 +74,5 @@ Make sure you read [getting started](getting-started-as-a-hoster.md) first. * The mysql image (which we used from the mysql Dockerfile published by Tutum) * The wordpress importer (a one-time systemd task) * The mysql importer (a one-time systemd task) + * It might help to remove /data/domains/example.com, /data/runtime/domains/example.com, and /etc/systemd/system/*/*example.com*, and remove the git@bu25:example.com repo from the backup server, make sure /data/import/example.com/TLS/example.com.pem exists, make sure /data/BACKUP_DESTINATION contains git@bu25 (and not core@backup.dev), shutdown -r now, and retry. * If you're setting up a fresh wordpress site, you have to access the admin panel over http first (e.g. run it `-p 80:80`), and activate the [https plugin](https://wordpress.org/plugins/wordpress-https/) before it will work behind the haproxy SSL-offloader. -- GitLab