Closed almereyda closed 6 years ago
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: https://github.com/indiehosters/piwik/issues/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!
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
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.).
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
Puffin, Portainer and cloudron
so I know this is a closed topic/issue but
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), ...
What do you mean?
THESE WILL NEVER BE A PROVIDER : Amazon (AWS), IBM, Google, Microsoft (Azure), ...
I means it might be easier to being agree on what we don't want than on what we want like boundaries.
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.
This conversation has been moved to https://lab.libreho.st/libre.sh/compose.libre.sh/merge_requests/159
This PR implements the following changes and is based on cowboy coding, plus elaborations in private chat channels:
lb_web
network name tofrontend-web
⚠️ note this is a breaking change for all service recipies which depend on this name space ⚠️docker
binary by absolute paths used in the.deb
package 💡 using other ways of invoking the library, i.e. via its global alias inPATH
may generalise deployment scenarios here 💡www
subdomain for every service deployment and require explicit configuration viadocker-compose.yml
and associatedenvironment
orenv_files
settings. This affects theVIRTUAL_HOST
variable used in manydocker-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.