What about Docker on NethServer 7?


(Stéphane de Labrusse) #63

for what I tested

signal-event nethserver-firewall-base-save
signal-event nethserver-firewall-base-update
systemctl restart shorewall

no effects, docker containers run

systemctl restart docker

here the effect is different, if your containers are started with the option ‘–restart unless-stopped’, then when you restart docker, only the containers with this option are restarted with the docker service. I have not tested with other options https://docs.docker.com/engine/admin/start-containers-automatically/.

My concern is that the VM freeze when I restart docker, not all the time, but I saw it. It is not a network problem, the vm was not reachable even with the proxmox console


(Stéphane de Labrusse) #64

not reproducible with another VM, probably tied to a container I installed, or all other developments/tricks I made on it. The service starts normally…nothing to say


(Jonathan Dumont) #65

Hi Steph;

I still using Portainer because it’s light and able to manage multi server
but I found seagull https://github.com/tobegit3hub/seagull
which also answer to those two criteria
and is graphically, a little bit more straight forward to hang on.

Still hoping using docker on nethserver
But the Go or No Go is hard to follow between you and giacomo. :wink:

I still in Thailand and lost access to my swiss server (where all my VM … are)
so for now I just have access to my productions environment
which for sure i’ll keep stable.


(Alessio Fattorini) #66

Looks interesting. Are you using it in production yet or just for test?

ohhh sorry I missed something. What are you doing there?


(Jonathan Dumont) #67

###Portainer vs Seagull
I use portainer in prod

but I think seagull might be more appropriate for nethserver mostly because it’s going direct to the point which is managing docker, container, image, …

I think, If you’re new, in seagull you’re will find faster what you want.
(see the screenshot (https://github.com/tobegit3hub/seagull))

The big advantage of Portainer it is offer authentication

  • Seagull is proposed on Yunohost and DPlateform (in prod or pseudoprod)

###Thailand
My wife have a 3month (extendable) contract;
we hope moving here in long term

Still managing my Swiss and Canadian client remotely :wink:


(Stéphane de Labrusse) #68

seagull doesn’t seem so active in github…last commit in december 16


(Joel Clendineng) #69

Is docker an appropriate use for a firewall/router? Wouldnt it be better to use this as a router server, and leave the nas/webapp stuff for freenas or another server? That way you dont have docker images/files etc on a internet facing server, but I realize everyone is different. I love docker though :slight_smile:


(Emiliano Vavassori) #70

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 -_-


(Stéphane de Labrusse) #71

yep, portainer still merits a module :smiley:


(Jonathan Dumont) #72

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


(Jonathan Dumont) #73

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


(Matthieu Gaillet) #74

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


(Matthieu Gaillet) #75

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 ?


(Rob Bosch) #76

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


(Matthieu Gaillet) #77

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


(Giacomo Sanchietti) #78

We already have such support )https://github.com/NethServer/nethserver-firewall-base/blob/bcb8148c60d5df4685c02c65d4033f34f21e8101/root/etc/e-smith/templates/etc/shorewall/shorewall.conf/60options#L48), 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.


Install pi-hole on NethServer
Help needed - nodejs and docker - Nodebb forum running in Nethserver
(Matthieu Gaillet) #79

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


(Davide Principi) #80

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).


Nethserver-portainer needs testers AND ideas :D
(Forgotten Beast) #81

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.


(Rob Bosch) #82

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!