Here’s the current related code:
docker_wrapper = '{}bin/docker-wrapper'.format(settings.ROOT_DIR)
distro_id = distro.id() # for Leap 15 <--> Tumbleweed moves.
if distro_id not in KNOWN_DISTRO_IDS:
distro_id = 'generic'
# TODO: Consider sourcing /usr/lib/systemd/system/docker.service
inf = '{}/docker-{}.service'.format(settings.CONFROOT, distro_id)
outf = '/etc/systemd/system/docker.service'
with open(inf) as ino, open(outf, 'w') as outo:
for l in ino.readlines():
if re.match('ExecStart=', l) is not None:
outo.write('{} {}\n'.format(
l.strip().replace(DOCKERD, docker_wrapper, 1),
mnt_pt))
elif re.match('Type=notify', l) is not None:
# Our docker wrapper use need NotifyAccess=all: avoids
# "Got notification message from PID ####1, but
# reception only permitted for main PID ####2"
outo.write(l)
outo.write('NotifyAccess=all\n')
elif re.match('After=', l) is not None:
show original
Note, however, that we have a pending pull request aiming at simplifying this part as mentioned in my previous post. See here for information:
rockstor:master ← FroggyFlox:Issue2044_DockerConf
opened 03:19PM - 21 May 19 UTC
Fixes #2044
In Leap 15.1 rc, the docker package was updated, breaking our us… e of `docker-opensuse-leap.service` due to unmet dependencies.
As proposed in a previous rework from @phillxnet (#1989, see below), we can move to sourcing the docker-ce package's configuration file directly and apply our custom settings onto it. This will help keep our custom settings in sync with any changes in the upstream docker-ce package.
https://github.com/rockstor/rockstor-core/blob/1102e2805a9290704ed6f3fd8963dbab37674c5e/src/rockstor/smart_manager/views/docker_service.py#L79
Note that these changes are proposed to be done only for OpenSUSE-based Rockstor builds in order to keep full compatibility with our existing centOS builds.
### Summary of changes
This PR simply sources the package's `docker.service` file from `/usr/lib/systemd/system/docker.service` if `distro_id` is either `opensuse-lead` or `opensuse-tumbleweed`.
### Turning the Rock-on service ON
#### CentOS
```
May 21 10:50:01 rockdev systemd[1]: Reloading.
May 21 10:50:01 rockdev systemd[1]: Starting Docker Socket for the API.
May 21 10:50:01 rockdev systemd[1]: Listening on Docker Socket for the API.
May 21 10:50:01 rockdev systemd[1]: Started Docker Application Container Engine.
```
#### Leap 15.1 rc
```
May 21 10:16:57 rockdev systemd[1]: Reloading.
May 21 10:16:57 rockdev systemd[1]: Starting Docker Application Container Engine...
May 21 10:16:58 rockdev kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
May 21 10:16:58 rockdev kernel: Bridge firewalling registered
May 21 10:16:58 rockdev kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
May 21 10:16:58 rockdev kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
May 21 10:16:58 rockdev kernel: Initializing XFRM netlink socket
May 21 10:16:58 rockdev kernel: Netfilter messages via NETLINK v0.30.
May 21 10:16:58 rockdev kernel: ctnetlink v0.93: registering with nfnetlink.
May 21 10:16:58 rockdev systemd-udevd[29250]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.5767] manager: (docker0): new Bridge device (/org/freedesktop/NetworkManager/Devices/3)
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6129] device (docker0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6148] keyfile: add connection in-memory (76d248d1-0646-4b2d-af60-d64db1b236c4,"docker0")
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6153] device (docker0): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6161] device (docker0): Activation: starting connection 'docker0' (76d248d1-0646-4b2d-af60-d64db1b236c4)
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6165] device (docker0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6169] device (docker0): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6173] device (docker0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6174] device (docker0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6178] device (docker0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6180] device (docker0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
May 21 10:16:58 rockdev NetworkManager[803]: <info> [1558448218.6189] device (docker0): Activation: successful, device activated.
May 21 10:16:58 rockdev dbus-daemon[709]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.2' (uid=0 pid=803 comm="/usr/sbin/NetworkManager --no-daemon ")
May 21 10:16:58 rockdev kernel: IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
May 21 10:16:58 rockdev systemd[1]: Starting Network Manager Script Dispatcher Service...
May 21 10:16:58 rockdev dbus-daemon[709]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
May 21 10:16:58 rockdev systemd[1]: Started Network Manager Script Dispatcher Service.
May 21 10:16:58 rockdev nm-dispatcher[29277]: req:1 'up' [docker0]: new request (3 scripts)
May 21 10:16:58 rockdev nm-dispatcher[29277]: req:1 'up' [docker0]: start running ordered scripts...
May 21 10:16:58 rockdev systemd[1]: Started Docker Application Container Engine.
```
#### Tumbleweed 20190517
```
May 21 10:30:58 rockdev systemd[1]: Starting Docker Application Container Engine...
May 21 10:30:59 rockdev kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
May 21 10:30:59 rockdev kernel: Bridge firewalling registered
May 21 10:30:59 rockdev kernel: bpfilter: Loaded bpfilter_umh pid 3236
May 21 10:30:59 rockdev kernel: Initializing XFRM netlink socket
May 21 10:30:59 rockdev systemd-udevd[3228]: Using default interface naming scheme 'v240'.
May 21 10:30:59 rockdev NetworkManager[888]: <info> [1558449059.1882] manager: (docker0): new Bridge device (/org/freedesktop/NetworkManager/Devices/3)
May 21 10:30:59 rockdev systemd-udevd[3228]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 21 10:30:59 rockdev systemd-udevd[3228]: Could not generate persistent MAC address for docker0: No such file or directory
May 21 10:30:59 rockdev systemd[1]: Started Docker Application Container Engine.
```
### Final docker.service contents
#### CentOS
```
[root@rockdev ~]# cat /etc/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket rockstor-bootstrap.service
Requires=docker.socket
[Service]
ExecStart=/opt/build/bin/docker-wrapper /mnt2/rockons_root
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
[Install]
WantedBy=multi-user.target
[root@rockdev ~]#
```
#### Leap 15.1 rc
```
linux-1pi9:~ # cat /etc/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target lvm2-monitor.service SuSEfirewall2.service rockstor-bootstrap.service
[Service]
EnvironmentFile=/etc/sysconfig/docker
# While Docker has support for socket activation (-H fd://), this is not
# enabled by default because enabling socket activation means that on boot your
# containers won't start until someone tries to administer the Docker daemon.
Type=notify
NotifyAccess=all
ExecStart=/opt/build/bin/docker-wrapper --add-runtime oci=/usr/sbin/docker-runc $DOCKER_NETWORK_OPTIONS $DOCKER_OPTS /mnt2/rockons_root
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this property.
TasksMax=infinity
# Set delegate yes so that systemd does not reset the cgroups of docker containers
# Only systemd 218 and above support this property.
Delegate=yes
# Kill only the docker process, not all processes in the cgroup.
KillMode=process
# Restart the docker process if it exits prematurely.
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
[Install]
WantedBy=multi-user.target
```
#### Tumbleweed 20190517
```
rockdev:~ # cat /etc/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target lvm2-monitor.service SuSEfirewall2.service rockstor-bootstrap.service
[Service]
EnvironmentFile=/etc/sysconfig/docker
# While Docker has support for socket activation (-H fd://), this is not
# enabled by default because enabling socket activation means that on boot your
# containers won't start until someone tries to administer the Docker daemon.
Type=notify
NotifyAccess=all
ExecStart=/opt/build/bin/docker-wrapper --add-runtime oci=/usr/sbin/docker-runc $DOCKER_NETWORK_OPTIONS $DOCKER_OPTS /mnt2/rockons_root
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this property.
TasksMax=infinity
# Set delegate yes so that systemd does not reset the cgroups of docker containers
# Only systemd 218 and above support this property.
Delegate=yes
# Kill only the docker process, not all processes in the cgroup.
KillMode=process
# Restart the docker process if it exits prematurely.
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
[Install]
WantedBy=multi-user.target
```
### Shortcomings and potential improvements
Should we test for the existence of the source file (`/usr/lib/systemd/system/docker.service`) and raise an exception if not found? It is my understanding that the docker-ce package will be "shipped" with the Rockstor build so it should always be present, but should we still account for this possibility?
The few “Rockstor” options that are added are as follows:
ROCKSTOR_DOCKER_OPTS = [
'--log-driver=journald',
'--storage-driver', 'btrfs',
'--storage-opt', 'btrfs.min_space=1G']
These mostly included one critical fix to docker-ce disabling quotas in BTRFS, which caused some issues in the past (see rock-ons-root host pool quota disabled by docker-ce. Fixes #1872 by phillxnet · Pull Request #1873 · rockstor/rockstor-core · GitHub ). @phillxnet will be able to correct me and bring more details to these if needed.
Mmmm… for the most “formalized” source of information regarding the latest update on the Rocsktor’s changes, I would say we can look at the current release notes for the Stable branch , as well as the Github pull requests . @phillxnet always writes quite the detailed notes so they usually have a lot of information in them.
ArmyHill01:
The gist of what I want to say is, I don’t really see the value in enhancing the whole Rockon system beyond the super simple click and install model simply because any ‘advanced need’ can simply be filled with a docker manager like Portainer/ShipYard/Rancher. I’m a dev so anytime I see someone rewrite something… we’ll you know how that smells…
Thanks a lot for spending the time to write these down :-). I actually agree with pretty much everything you listed. Before I add my 2 cents to it, I’ll point you to a rather old but still information thread in this forum , in which you will find similar conversation and ideas. Also, note that what I’m saying only reflects my personal opinion on things, and explains the recent contributions I’ve had in this part of Rockstor.
I personally see the rock-ons framework as a very nice tool to give quick and easy access to what docker containers can offer without necessarily needing to get familiar with it or even the project(s) they will end up using. As you mentioned, a “more advanced user” can simply run Portainer to run her/his own choice of containers with any setting (s)he wants, use docker run from the cli, or even docker-compose up. None of these should interfere with Rockstor’s functions and I personally run several containers like that. From my own experience, I originally wasn’t familiar enough with docker to do any of that, but I was still able to run Owncloud and Emby thanks to the existing rock-ons and it’s how I see their use. I believe the rock-on framework still has a lot of room for improvement to reasonably expand this simplicity to other areas of the docker ecosystem, but–like you said–while trying not to reinvent the wheel. I’m thinking, for instance, about multi-containers rock-ons such as the older owncloud rock-on, which ran its own postgres database in a separate container but from the same owncloud install wizard.
Again, I agree with you on pretty much everything you said
ArmyHill01:
Allow users to select a path, not a share (why force the root of a share… makes no sense)
I actually have several docker_store_X shares where X corresponds to my various container stacks
This allows containers to share any needed data all while allowing me to set custom setting on those various shares (i.e. compression/quotas/etc)
I apologize in advance if I completely misunderstood this, but would the “Add Storage” feature fit your need here? The related detailed documentation is in the process of being published, but you’ll find a description in the post below. It basically allows to bind the same share to multiple rock-ons in order to make data available to as many rock-ons as desired.
Hi @svberloo ,
If I understand correctly, you have installed the NZBGet Rock-on? If yes, you can simply ‘add a volume’ to the Rock-on:
in the Rockstor web-UI, turn off NZBGet Rock-on
click on the wrench icon to edit the Rock-on configuration
Add the volume you want to use (it needs to be created first) and submit the changes. I assume this specific Rock-on supports this feature but I don’t use it myself so I don’t know.
Turn back the NZBGet Rock-on to restart it
This newly-added volume should…
ArmyHill01:
Also need the ability to set the access mode on a containers volumes. Example: An image gallery container should have 2 at least 2 volumes: 1 its data dir with r/w access and 2: the media it’ll show but i’d only want this readonly.
I like this idea very much. I believe the json file defining the rock-on does support the definition of rw or ro (I will need to verify that, however), but I like the idea of being able to customize this on any share post-install.
Thanks again a lot for all your feedback, and I hope I was able to help a little bit.
. A few points, though: