Feature Proposal: Simplify installation by creating a collection of docker containers for common configurations.
This doesn't change foswiki itself, but adds a cross-platform installation packaging that should simplify installation and configuration.
The question was asked on IRC recently - "Why is Foswiki so difficult to install", and following up with comments that at least we could create a docker container to automate installation.
Description and Documentation
I'm uncertain how to organize the container structure, but I think foswiki would be derived from the library Perl container, and link to supporting containers for web, database, etc.
- Web (Apache, Nginx ...)
- Database (MySQL, Posgres, ...)
- SolrSearch engine
I'm not sure if it would be better to create specific containers for Foswiki-apache, Foswiki-nginx, etc, or to have just the foswiki container with -options to choose the web server, etc. We could also consider bundling extensions in alternate packages, for example Foswiki-NatSkin, which installs and configures Foswiki and the NatSkin
ecosystem of extensions. With the CLI
, it would be relatively easy to fully configure extensions.
For the site that desires the latest perl, we might also make available
which uses the perl base, and installs all the deps using cpanm.
has some initial docker containers as examples, but they install the web server directly as well. (https://github.com/SvenDowideit/dockerfiles/tree/master/foswiki
We would also create a "foswiki" account on docker for distribution of the containers, and a "dockerfiles" repo under the foswiki account on github.
No direct impact on Foswiki internally, but could provide a much simpler installation process
This solves the Perl and CPAN version and availability issues. Basing Foswiki on Perl:latest would provide the latest version of perl, currently 5.24.0, And CPAN modules can be installed by apt, or cpanm as part of the container.
-- Contributors: GeorgeClark
- 29 Oct 2016
I don't like Docker. It feels totally alien. For most deployments it adds yet another virtualization layer on an already existing one. Most deployments are on a virtual environment already: vmware, virtualbox, .... Not Docker. So adding Docker inside a virtual image adds yet another layer of complication I don't want to handle. Therefore I'd prefer to build virtual images directly.
- 30 Oct 2016
I've really just started looking at it, but it sure seems much more lightweight than a full on virtual environment like vmware, virtualbox, qemu. From what I can see it much more closely resembles a "jail" like we used to run on the f.o FreeBSD
server. It does not virtualize the hardware, like on a classic VM, but uses the running OS kernel and layers on read-only and "copy-on-write" "union" file systems, such as aufs. With this layering of containers it's possible to delegate maintenance of various layers.
For example, with the current VMWare image, when I release a new foswiki, I usually have to also update the OS and other related packages, update any CPAN, clear the log and sanitize the install, reclaim freespace and re-compress the image. And users have to then re-install a completely new vm image, or do the updates themselves.
The Docker containers layer separate file systems. I'm still trying to understand it all, but it appears that base and intermediate containers can be readily updated "underneath" the top layer (which would be Foswiki).
- 31 Oct 2016
Neither a containerized or virtualized Foswiki solves all our 'one-click' installation needs - not everyone could even use Docker or a VM. Mainly because of local customization (e.g. Nginx or Apache to name but one choice) and upgrade-install issues.
I'm going to discuss this further on the related DependenciesFreedom
- 01 Nov 2016
I'm certainly not suggesting it's a one-size-fits-all, but it's probably a fairly low effort way to handle a subset of foswiki installations. Also it's a lot easier to automate this than the VM, which takes a considerable effort to refresh.
More than anything else, I think our biggest challenge is that we intermix code, configuration and data all along the same paths. And I've yet to hear of any realistic solution to our layout. Having the web server serve "pub" makes it even more difficult. And Extensions installation complicates things even further. It would be nice if our distribution files could be a shadow behind the local site's installed files, and let store merge them ... like a "union filesystem". Then System could truly be "read only".
- 01 Nov 2016
Also need consider: the Docker solves only the "Linux" problem. Using the Docker on the FreeBSD
is "strange", because the natural solution is using jails. For the macOS (OS X) for using the Docker need install the
(the mac port of bhyve virtualisation support from the *BSD project) - so unnatural also.
The ideal solution (from my point of view) is (as Michael wrote in the DependenciesFreedom
$ cpanm Foswiki
$ genwiki new /some/path/to/the/wiki/tree # this step is needed for easy generation of multiple wikis
$ plackup /some/path/to/the/wiki/tree/bin/app.psgi
is simple - for example as in the QuoVadisPsgiFoswiki
use Foswiki::Config qw($config);
my $runner = Plack::Runner->new;
$runner->parse_options( $config->get_server_args() );
$runner->run; # <-- this starts the plackup with the wanted "server args" from the config
# for example as: plackup -s Starman -p 8080 .... etc.
The approach also solves the "chicken-egg" problem - we currently using a logic:
- The user MUST specify exact paths for the ApacheConfigGenerator (of course)
- and later, the boostrap guessing(!!!) this already exactly defined paths... (isn't strange?)
By me would be better:
- specify the paths in some config file, which location is relative fixed to the
use Foswiki::Config qw($conv) simply reads the config (our LSC)
- and using the standardized Plack::Runner runs the server & the Foswiki
- the chicken-egg problem solved
- 01 Nov 2016
I want to drag this back to on-point. This is NOT a proposal to boil the ocean. It is a very simple narrow proposal to create some Docker containers that we can make available along side the existing zip, tar and VM packages. We would get an account in the docker repository and release them as officially supported containers.
So that's the proposal.
- Explore creating some docker containers. Based upon experiences there:
- Add the docker container build/release process to the build scripts / documentation.
- Make the containers available for sites that want to use docker. As another alternative. Not as a replacement to any current packages.
- And a commitment that we won't end up with orphaned containers as the project owns them, not an individual developer.
- This does not change foswiki core. The only additional work is on the Release Manager (or future release managers).
I added this as a proposal rather than just "doing it", so that we would not end up with the mess that is ArchivedOtherFoswikiInstallers
And I guess Michael has blocked this. Fine. On to a community vote. But I'll hold off on that until I actually have a bit more experience in how it all works.
- 03 Nov 2016
Removed my concerns. Go ahead and create Docker images if you like. The CPAN discussion goes on at DependenciesFreedom
- 03 Nov 2016
Adjusting the install hierarchy. Choice of base image 'perl' is probably not the best choice for a casual installer. As pointed out elsewhere, it does a full compile of a local perl. See https://www.brianchristner.io/docker-image-base-os-size-comparison/
for a review of the common bases. As ubuntu has the highest usage, that's probably a reasonable one to use. It does have native perl, so there is no requirement to compile perl. While debian is the recommended base image (see https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
), it uses Perl 5.20. Ubuntu is not much bigger and has perl 5.22. For the remaining base images: centos, busybox, and alpine: perl not included. opensuse: perl 5.18
- 04 Nov 2016 - 17:21
Changing this to a Parked proposal.
- 17 Jan 2018