Changing deployment patterns for more generalised use cases

[almereyda]

This PR implements the following changes and is based on cowboy coding, plus elaborations in private chat channels:

• change lb_web network name to frontend-web
  ⚠️ note this is a breaking change for all service recipies which depend on this name space ⚠️
• reference the docker binary by absolute paths used in the .deb package
  💡 using other ways of invoking the library, i.e. via its global alias in PATH may generalise deployment scenarios here 💡
• do not assume a www subdomain for every service deployment and require explicit configuration via docker-compose.yml and associated environment or env_files settings.
  This affects the VIRTUAL_HOST variable used in many docker-gen-based frontend implementations of edge servers for SSL offloading, load balancing and reverse proxying.

Here we assume to move forward of turning libre.sh into a sane convention of running web services and alike in containerised environments.

[pierreozoux]

Thanks for the PR!

the VIRTUAL_HOST=%i,www.%i, yes, I'd like to remove it as well..

About the rename, I'm not sure, it is a big change at the end. A lot of people rely on this now:
libresh/compose-matomo#22
So if we change it, we have to warn them somehow, and I don't know how to do this :/ Do you have an idea?

the change about the docker binary is not compatible with coreos. I'd wondering how we could resolve that :/ Can we let systemd use $PATH?

I'd like also @JOduMonT to comment here as he is using it too!

[JOduMonT]

for sure renaming will cause down time for some people
there is a way to make a transition and creating/making both works ?
this means a lot of works too

maybe a new branch and a call like hardware/mailserver did for their new release
https://github.com/hardware/mailserver#1---pull-the-latest-image-from-docker-hub

[almereyda]

Yes, this is a breaking change for most and would require adaptations in all downstream packages, i.e. application templates, which are compatible with libre.sh. Collecting and listing them in the README/docs appears useful then.

Maybe it means switching from rolling releases into a more directed development following semantic versioning? Then we declare the current release 1.0, which only lived in the indiehosters sphere, and prepare a 2.0 release for libre.sh itself, and all dependent templates.

Such an environment change could represented by moving to a new GitHub organisation, i.e. librehost, and forking application templates from @indiehosters, @ecobytes and @allmende together, establishing a well documented and curated repository of compatible setups. This may involve making use of templating, secret generation and storage as well as testability.

Also modularising DNS, Domain and Mail API integration is interesting for us at @ecobytes, not to mention provisioning via Ansible and optimisations (SSD, HDD storage for host mounted volumes, optionally Backup integration with ZFS, Alpine images where possible et al.).

[almereyda]

Thanks for pointing out in another place that libre moved to a separete git host.
I like how https://git.indie.host/meta/infrastructure/issues/44 is formulated and will try to interact in that issue repository.

I can't resist to see how Puffin or Portainer can influence the development of libre.sh, before formulating a more generalised 2.0 milestone, including and activating the wider community for easier maintainability and increased accessibility of the documentation. We are still learning this the hard way in https://lab.allmende.io/ecobytes/community/issues/73#note_6335

[pierreozoux]

Puffin, Portainer and cloudron

[JOduMonT]

so I know this is a closed topic/issue but

1. i can't remember where my comment must make more sense (about which post I reed today on github about libre.sh)
2. this post is the most accurate related of what I want to bring on ;)

basically
the 5 years plan is awesome
but sometimes it's easier to define what we don't want because it's what we know then define what we want because most of the time it will be presented in a near feature.

Such as an example :
THESE WILL NEVER BE A PROVIDER : Amazon (AWS), IBM, Google, Microsoft (Azure), ...

[pierreozoux]

What do you mean?

 THESE WILL NEVER BE A PROVIDER : Amazon (AWS), IBM, Google, Microsoft (Azure), ...

[JOduMonT]

I means it might be easier to being agree on what we don't want than on what we want
like boundaries.

[pierreozoux]

Yes understand, and agree :)
I actually start to have a better idea on what this repo should be about.
I'll start to PR documentation soon, would be glad to have your reviews.

[almereyda]

This conversation has been moved to https://lab.libreho.st/libre.sh/compose.libre.sh/merge_requests/159