If you use a cloud provider that support `user_data`, like [Scaleway](http://scaleway.com/), just use [this user_data](https://raw.githubusercontent.com/indiehosters/libre.sh/master/user_data).
### Hetzner
You can also buy a baremetal at [Hetzner](https://serverboerse.de/index.php?country=EN) as they are the cheapest options around. Follow these [instructions](INSTALL_HETZNER.md) in this case.
* Libre.sh V2 (Alpha) is using [kubernetes](https://kubernetes.io/).
This ecosystem can be deployed on [Raspberries](https://kubecloud.io/setting-up-a-kubernetes-1-11-raspberry-pi-cluster-using-kubeadm-952bbda329c8) or on popular cloud providers and scale globally or anything in between.
We can affirm that V2 scales globally because it is based on kubernetes, a tool developped from the experience of Google hosting containers at scale.
## Installation
To install it, follow the instructions in `INSTALL_LINUX.md` : https://lab.libreho.st/libre.sh/compose.libre.sh/blob/master/INSTALL_LINUX.md
libre.sh is a little framework to host Docker. It is simple and modular and respect the convention over configuration paradigm.
This is aimed at Hosters to manage a huge amount of different web application, and a quantity of domain names related with emails and so on.
It is currently installed at 3 different hosters in production and hosting ~20 different web applications, with ~500 containers.
Once well installed, in one bash command, you'll be able to:
- buy a domain name
- configure DNS for it
- configure email for it
- configure dkim for that domain
- configure dmarc for that domain
- configure autoconfig for that domain
- install and start a web application on that domain (WordPress, Nextcloud, piwik...)
- provision a TLS cert on that domain
Amazing, right?
### Modular
The PaaS is really modular, that's why it contains the strict necessary, then you'll probably want to add `system` modules or `applications`.
It contains 2 [unit-files](https://lab.libreho.st/libre.sh/compose.libre.sh/tree/master/unit-files) to manage system modules and applications, start them at boot, and load the appropriate environment.
### Support
You can use the following channels to request community support:
| wordpress | 5.9 | Includes the support of SMTP email though libresh variables |
| dolibarr | 15.0.3 | need manual deletion of the install.lock to upgrade |
### Installation
To install application `wordpress` on `example.org`, first make point example.org to your server IP, and then, just run:
```
libre provision -a wordpress -u example.org -s
```
- -u [arg] URL to process. Required.
- -a [arg] Application to install. (wordpress in REPO_MODE)
- -t [arg] Checkout a specific tag or branch from the application repo. default to master
- -e [arg] Specify the email of the application admin
- -s Start the application right away.
- -b Buys the associated domain name.
- -i Configure OpenDKIM.
- -c Configures DNS if possible.
## To debug a module or an application:
```
libre ps
libre logs -f --tail=100
libre stop
libre restart
```
## Contributing
If you have any issue (something not working, missing doc), please do report an issue here! Thanks
This system is used in production at [IndieHosters](https://indiehosters.net/) so it is maintained. If you use it, please tell us, and we'll be really happy to update this README!
You can help us by:
- starring this project
- sending us a thanks email
- reporting bugs
- writing documentation/blog on how you got up and running in 5mins
- writing more documentation
- sending us cake :) We loove cake!
## Contributors
This project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)].
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/libresh#sponsor)]
The aim of this document is to write the big lines of the future of libre.sh.
# Version 1
The current version, let's call it 1, is a nice opiniated framework on how to run a single host with docker-compose.
It provides a list of packages and module compatible with this framework.
The best features of this framework are:
- https only
- some integration between the tools (auto provisioning of emails for new applications)
- domain name buying (Namecheap api)
- dns configuration (Namecheap api)
# Version 2 - k8s
This roadmap will discuss about the migration to kubernetes (k8s).
## Distributions
There are various k8s distributions (Tectonic, deis, openshift..) and the aim of libre.sh is not to become yet another distribution.
It would be nice if we could list them, evaluate them, and decide to use one of them or not.
## Installation/Operation
libre.sh should be opiniated on the way to install and operate the cluster.
It should provide easy steps to install on baremetal first. We aim for libre software, and as such, we can't rely
on cloud providers like gcloud, aws, or digital ocean.
As a second priority, we should give easy instructions to deploy on any cloud providers, as people are free to choose their chains :)
## Storage
One big challenge in k8s cluster context is to provide an implementation of major cloud providers about [PersistantVolume](https://kubernetes.io/docs/user-guide/persistent-volumes/).
In a libre cluster, this function would be achieved by a distributed file system technology.
After some investigation, the choice would be to use ceph.
There are already some work done on it like the [ceph-docker](https://github.com/ceph/ceph-docker/tree/master/examples) repo.
## Network
Another big challenge is network. k8s is strongly opiniated on what should be the network configuration.
Ideally, we would use some IPsec to secure the links between machine in a context we can't trust the network (like at hetzner).
There are 3 options:
- zerotier
- tinc vpn
- flannel that might implement IPsec in a near future
The cheapest in term of work would be to bet on flannel.
## Packages
There is now a way to create and distribute packages in a standard way.
We can then remove the idea of modules and applications.
They will all be packages.
The k8s standard for that is [helm](http://helm.sh/). There is already a big list of packages.
As for libre.sh, the idea would be to contribute the missing packages there.
### opportunistic packages
libre.sh would then be, just a repo of documentation on how to install, operate and manage a k8s cluster on baremetal.
There is still a place where we can have a difference.
This idea is called opportunistic package.
This would be a package based on an official one.
Let's take the example of WordPress.
The libre.sh version of WordPress would be based on the official one.
But it will have some mechanisms to discovers services available inside the cluster it is running on.
These services could be:
- ldap
- piwik
- email
So, when you install a new WordPress, it will try to discover opportunistically if there is a ldap service in the cluster,
and if yes, configure WordPress to use this ldap service.
It was designed to work with HAproxy, but you can use it for anything! There is no configuration, you'll have to mount the config folder. There is a nice example in [indiehosters/confd git repo](https://github.com/indiehosters/dockerfiles/tree/master/server-wide/confd).
```bash
docker run\
-v /haproxy-config:/etc/haproxy/\
-v ./confd/:/etc/confd/\
-v /var/run/docker.sock:/var/run/docker.sock\
indiehosters/confd
```
It works really well with [indiehosters/haproxy](https://registry.hub.docker.com/u/indiehosters/haproxy/) to have automatic configuration of HAproxy backed by `etcd` or `consul`.
This image will log everything to stdout/stderr. Somehow, it respects 12-Factor App. But it uses the debug flag of HAProxy. If you have a better idea, please read this [blog post](http://pierre-o.fr/blog/2014/08/27/haproxy-coreos/) first.
```bash
docker run\
-v /haproxy-config:/etc/haproxy\
-p 80:80\
-p 443:443\
indiehosters/haproxy
```
Have a look to [indiehosters/confd](https://registry.hub.docker.com/u/indiehosters/confd/) to have automatic configuration of HAproxy backed by `etcd` or `consul`.