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
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
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.
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.
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, …
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
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 -_-
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.
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).
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.
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!