What about Docker on NethServer 7?

I just replicated the setup by @stephdl in the post from April 4th, 2017. I hope to test it more thoroughly in some days, but at first shot, what I have seen is quite good. Thanks @stephdl and sorry for the huge amount of delay -_-

2 Likes

yep, portainer still merits a module :smiley:

2 Likes

Hi Joel;

I might understand you’re concern;

but usually I run my docker daemon in the user namespace and isolate through docker network than serve them via a proxy like nginx or haproxy

1 Like

Hi everyone;

Just want to know if the netfilter vs docker/runc conflict is on his way ?

Because if Nethserver support docker it could be proposed here to these unhappy users.

Also in the same thread and for @stephdl, they talk about swarm visualizer which it running as a container like portainer.

Anyway Cheer and happy new year !

Jonathan

Breaking :

Beginning with Shorewall 5.0.6, Shorewall has native support for simple Docker configurations. This support is enabled by setting DOCKER=Yes in shorewall.conf. With this setting, the generated script saves the Docker-created ruleset before executing a stop, start, restart or reload operation and restores those rules along with the Shorewall-generated ruleset.

This support assumes that the default Docker bridge (docker0) is being used. It is recommended that this bridge be defined to Shorewall in shorewall-interfaces(8). As shown below, you can control inter-container communication using the bridge and routeback options. If docker0 is not defined to Shorewall, then Shorewall will save and restore the FORWARD chain rules involving that interface.

http://shorewall.org/Docker.html

3 Likes

Actually not so breaking since we’re at 5.0.14.1 :joy::joy::joy: The site stated that the page was written yesterday :slight_smile:

Whatever, isn’t it useful ?

1 Like

Another step towards cockpit (not only as admin interface, but also as a docker management console)

Yep. I’m testing it and it’s really promising. Fast, efficient, good looking, … That’s the way to go for sure.

We already have such support )nethserver-firewall-base/root/etc/e-smith/templates/etc/shorewall/shorewall.conf/60options at bcb8148c60d5df4685c02c65d4033f34f21e8101 · NethServer/nethserver-firewall-base · GitHub), but it’s not even documented because it doesn’t play well.

If you want to try it:

config setprop firewall Docker enabled

But you will surely face many issues.

Still, I think Docker is a must have somewhere in the near future.

Thanks. I prefer to wait until there is a proven solution.

I had some nice discussions about Docker during FOSDEM18 with Stephane and other guys.

To run a dockerized application on NethServer there are some issues to solve:

  • networking/firewall configuration
  • container management UI
  • reverse proxy for containerized web applications
  • nethserver-backup integration

I think an initial nethserver-docker package prototype should try to solve the first three issues, and as I read in this discussion, there are some promising solutions:

  • It seems the firewall (shorewall) configuration can be easily fixed.
  • I like the UI management candidate, https://portainer.io/, because it’s shipped as a container itself

About the reverse proxy, @stephdl has recently raised another proposal that I like very much: https://traefik.io/ It’s shipped in a container itself and has its management UI.

The reverse-proxy is a fundamental component, required to integrate existing NethServer applications (like a groupware) with those provided by Docker containers. We could put Apache behind Traefik to make those apps work together (or configure the individual apps behind Traefik itself).

5 Likes

Ok, have some (anecdotal) data!

Networking/firewall configuration

It can be easily bypassed by telling the docker daemon in it’s json configuration file to not modify iptables rules. I have done so on two deployments where I wanted to try the paranoid way (there was a bunch of rules for dropping packets that didn’t come from cloudflare). I think it’s useful to be able to do it but it isn’t my go to option. Nowadays I much prefer to define specific networks that I flag as internal and configure routing between them on a container basis.

Simple example that I’ve been using for several months:
a proxyed network behind an nginx RP: it’s internal so nothing there can communicate with the outside, the nginx container has a leg in a normal network so it can receive data from the outside.

Reverse proxy

Have a look at jwilder’s nginx proxy, it’s great and supports having separate containers so the one with listening on docker isn’t exposed to the internet. I’ve been using it along dockergen and nginx proxy letsencrypt companion to easily deploy https and tor hidden services (yup, it’s that flexible). Usually it’s the first container I run on servers that I think will run anything using http/https. Using external networks as described before allow me to basically do plug and play with containers.

Personal experience: used it to deploy a wordpress, then a personal redmine, then some test website for a friend, it all went up automagically and everything got a certificate from let’s encrypt without any fuss or headache.

Backup integration

I’ve had bad experiences with storing data on the host with mounts so I don’t use it if I can get away with it. My advice: use docker volumes. They are easy to setup, easy to backup (I wrote two ansible roles that are quite short and whose only goal is to backup docker volumes to tar.bz2 or to a borg repository, both work well and I use them extensively when migrating from one server to another). So my advice here: allow the user to specify a number of docker volumes to be backed up/restored and don’t go any deeper, because you don’t want to have to mess with ownership and rights for many containers that might run as different users.

My 2 cents, keep in mind that those deployment I talk about are only for services where the main goal was to have them running quickly, backed up and restored easily in case something went wrong. If you want to set up nethserver as a node in a cluster (either swarm or kubernetes or anything else) then your end setup would look different and I’d advocate using other facilities for backups, monitoring and such. Also those deployments took place on servers where EVERYTHING was in a docker container. No service running directly on the host.

5 Likes

Maybe you are hitting a key factor here. With new developments all around us, NethServer still has a quite traditional setup: Base OS with several services running on it. But with the possibility to use those new developments, like using Docker (cockpit is being developed as we speak, it could be used as a docker admin interface too) or install on Virtual platforms like KVM or ProxMox.

I am very much in favor for an open development. Anyone can contribute, and if you do contribute, it is your choice how you build the new functionality. But also with introducing new functionality you take up the responsibility to maintain that new functionality. I do realize this last remark is the biggest challenge we face with all that new functionality: make it sustainable and keep it safe. As soon upstream updates are available, work should start to implement those in the features offered by the service or module that has been developed.

Looking forward to these new options. Exiting times ahead!

3 Likes

Amongst the things that made me decide to run everything inside docker containers instead of a more hybrid setup (base os + services + containers) was the potential headache from the admin point of view. Also there is the fact that I wanted to do test deployments of home made monstrosities that could appear stable if I had two of them running and answering to requests so at least one would be up at any point in time (yup, they were ungodly things and quite prompt to crashes too).

For nethserver it seems that integrating with the new kids on the block (docker in this case) is going to require some planning and deep thought by the people who know the system best. One of the things that appeal to me is how easy NS is to setup. Working right out of the box, nice UI, etc… I can see how being too hasty while integrating new things (yay, let’s do docker, docker is cool! gimme the nail gun, some tape and hot glue! wait what about micro services running the internet of things? MOAR NAILS) could result in a net loss in maintanability.

Potential solution

I wonder how feasible a “walled courtyard” would be. One could have a reverse proxy running on nethserver that would be aware of all the web apps it should proxy, one docker network with a standard name that the users could connect to to make their containers reachable from the RP.

That way there are minimal requirements (if you want to be reachable for http trafic, hook to this net) and most of the work is on the user’s end if they want to implement something fancy (you can create a complicated interwoven set of docker networks but that won’t change anything from NS’s point of view).

Dockergen container could be of tremendous help, since it already provides the “listen to docker socket and update nginx” functionality, I reckon there wouldn’t be anything to modify to get it to work with a RP running on the base OS (one would just mount the folder rather than use a volumes-from instruction). Same thing with letsencrypt.

And yet…

With all my words of caution I’m already asking for the nail gun and tape…
Maybe something worth considering is whether having docker on NS is desirable at all.

One of the big selling points of docker is the ability to run anything (almost) anywhere easily without having to bother with such trivialities as a dependency graph.

Is NS meant to do that? To offer a platform where you can just pop any software and have it work(ish)? Or is it about providing some much desired functionality (samba, collaboration software and so on) out of the box to users without any strings attached? Because if the main goal is to provide a tightly packed feature rich yet stable experience, then the costs in maintenance, usability and stability of adding docker on top might not be worth it.

Or maybe make it optional with a big red label saying “use at your own risk, by opening you lose your warranty, any hope for a better tomorrow and perhaps your immortal soul to the Great Devourer behind the Veil”

7 Likes

If Discourse would allow to give 10 likes, you would have gotten them from me. Truly enlightening and IMO you ask the correct questions.
Looking forward to @dev_team comments on this… :slight_smile:

3 Likes

Agree. Problem is that discourse is distributed as a docker instance :slight_smile:

10 likes for this one as @robb said!

And also thank you for your great tips!
IMHO docker is now a must have, but for now I think it will not be the core of Nethserver.

Would be quite funny to exactly state this in the warning… :smiley:

3 Likes

nethserver-portainer is on the grill

7 Likes

I’m quite concerned about Docker release cycle sustainability

Starting with Docker 17.03, Docker uses a time-based release schedule.

  • Docker EE releases generally happen twice per year, with patch releases as needed.
  • Docker CE Stable releases generally happen quarterly, with patch releases as needed.

Updates/Patch releases

  • A given Docker EE release receives patches and updates for at least one year after it is released.
  • A given Docker CE Stable release receives patches and updates for one month after the next Docker CE Stable release.

[source Get Docker | Docker Docs]

This becomes another upstream project to track for us and it evolves rapidly. It does not seem designed to be stable (even the Enterprise version) as I’m used to, because the schedule is really fast, much faster than the 10 years lifecycle of RHEL.

If we run some NethServer applications as Docker containers we must take into account the need of recreating the containers quite often (they’re designed for that) to follow the docker-ce package updates.

1 Like