No description

Find a file

Slavi Pantaleev b52a07037e Add missing if statement		2023-03-16 18:41:31 +02:00
.github	Add .github/FUNDING.yml	2023-03-15 11:01:19 +02:00
docs	Add Gitea and Woodpecker CI support	2023-03-16 18:26:06 +02:00
examples	docs: Add necessary email var to example	2023-03-15 13:34:39 +01:00
group_vars	Add missing if statement	2023-03-16 18:41:31 +02:00
inventory	Create inventory/host_vars	2023-03-15 11:20:20 +02:00
roles/mash/playbook_base	Make service prefix configurable	2023-03-16 14:41:37 +02:00
.editorconfig	Initial commit	2023-03-15 10:58:12 +02:00
.gitignore	Initial commit	2023-03-15 10:58:12 +02:00
CHANGELOG.md	Initial commit	2023-03-15 10:58:12 +02:00
justfile	Initial commit	2023-03-15 10:58:12 +02:00
LICENSE	Initial commit	2023-03-15 10:58:12 +02:00
README.md	Initial commit	2023-03-15 10:58:12 +02:00
requirements.yml	Add Gitea and Woodpecker CI support	2023-03-16 18:26:06 +02:00
setup.yml	Add Gitea and Woodpecker CI support	2023-03-16 18:26:06 +02:00

README.md

Mother-of-All-Self-Hosting Ansible playbook

MASH (Mother-of-All-Self-Hosting) is an Ansible playbook that helps you self-host services as Docker containers on your own server.

By running services in containers, we can have a predictable and up-to-date setup, across multiple supported distros and CPU architectures.

This project is fairly new and only supports a few services so far, but will grow to support self-hosting a large number of FOSS pieces of software.

Supported services

See the full list of supported services here.

Installation

To configure and install service on your own server, follow the README in the docs/ directory.

Changes

This playbook evolves over time, sometimes with backward-incompatible changes.

When updating the playbook, refer to the changelog to catch up with what's new.

Support

Matrix room: #mash-playbook:devture.com. To join Matrix, use a public server like matrix.org or self-host Matrix yourself using the related matrix-docker-ansible-deploy Ansible playbook
GitHub issues: mother-of-all-self-hosting/mash-playbook/issues

You may also be interested in these other Ansible playbooks:

gitea-docker-ansible-deploy - for deploying a Gitea git version-control server - this playbook will soon be merged into mash-playbook
nextcloud-docker-ansible-deploy - for deploying a Nextcloud server - this playbook will soon be merged into mash-playbook
matrix-docker-ansible-deploy - for deploying a fully-featured Matrix homeserver
peertube-docker-ansible-deploy - for deploying a PeerTube video-platform server - this playbook will soon be merged into mash-playbook
vaultwarden-docker-ansible-deploy - for deploying a Vaultwarden password manager server (unofficial Bitwarden compatible server) - this playbook will soon be merged into mash-playbook

The Matrix playbook (matrix-docker-ansible-deploy) will remain independent, because the Matrix ecosystem is incredibly large - lots of bots, bridges and other pieces of software. It deserves its own dedicated playbook.

All other playbooks are for smaller pieces and will be moved into into this playbook for ease of maintenance and all reasons explained below.

Why create such a mega playbook?

All our Related Ansible playbooks re-use roles (for Postgres, Traefik, etc.), but are still hard to maintain and there's a lot of duplication of effort.

Most of these playbooks host services which require a Postgres database, a Traefik reverse-proxy, a backup solution, etc. All of them need to come with documentation, etc. All these things need to be created and kept up-to-date in each and every playbook.

Having to use a dedicated Ansible playbook for each and every piece of software means that you have to juggle many playbooks and make sure they don't conflict with one another when installing services on the same server. All Related playbooks interoperate nicely, but still require at least a bit of manual configuration to achieve this interoperability.

Using specialized Ansible playbooks also means that trying out new software is difficult. Despite the playbooks being similar (which eases the learning curve), each one is still a new git repository you need to clone and maintain, etc.

Furthermore, not all pieces of software are large enough to justify having their own dedicated Ansible playbook. They have no home, so no one uses them.

We're finding the need for a playbook which combines all of this into one, so that:

you don't need to juggle multiple Ansible playbooks
you can try out various services easily - a few lines of extra configuration and you're ready to go
small pieces of software (like Miniflux, powered by the miniflux Ansible role) which don't have their own playbook can finally find a home
you can use a single playbook with the quality you know and trust
shared services (like Postgres) are maintained in one single place
backups are made easy, because everything lives together (same base data path, same Postgres instance)

Having one large playbook with all services does not necessarily mean you need to host everything on the same server though. Feel free to use as many servers as you see fit. While containers provide some level of isolation, it's still better to not put all your eggs in one basket and create a single point of failure.

What's with the name?

Our goal is to create a large Ansible playbook which can be your all-in-one-toolkit for self-hosting services in a clean and reliable way.

We like the MASH acronym, and mashing is popular in the alcohol brewing industry. The result of all that mash is an enjoyable (at least by some) product.

Then, there's mixing and mashing stuff, which is also what this Ansible playbook is all about - you can mix and mash various pieces of software to create the self-hosted stack of your dreams!