Actually Docker doesn't do any virtualization, it's just a tool that handles images and uses LXC container virtualization to run them. I guess you're actually looking for LXC and its capabilities, here. LXC can do virtual networking and MySQL can be accessed over the network. The only thing you need is to connect the building blocks together ;).
In a typical setup, each host has its own IP address and set of open ports and each host can access other host's TCP/IP services over the virtual network. Security is handled by the Linux kernel. One way to handle security is the good old iptables based firewall. But there may be other ways based on selinux labeling.
Not a direct solution but I would enable some debugging to see what's happening behind the scenes.
Idea #1 - Debugging logger
For starters when you run your logger
commands you can do them like so, echoing out messages to STDERR.
$ logger -s "hi"
saml: hi
Idea #2 - validate your configuration file
You can also try validating your rsyslog configuration file:
$ sudo rsyslogd -N6 | head -10
rsyslogd: version 7.2.6, config validation run (level 6), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
6921.173842409:7f8b11df2780: rsyslogd 7.2.6 startup, module path '', cwd:/root
6921.175241008:7f8b11df2780: caller requested object 'net', not found (iRet -3003)
6921.175261977:7f8b11df2780: Requested to load module 'lmnet'
6921.175272711:7f8b11df2780: loading module '/lib64/rsyslog/lmnet.so'
6921.175505384:7f8b11df2780: module lmnet of type 2 being loaded (keepType=0).
6921.175520208:7f8b11df2780: entry point 'isCompatibleWithFeature' not present in module
6921.175528413:7f8b11df2780: entry point 'setModCnf' not present in module
6921.175535294:7f8b11df2780: entry point 'getModCnfName' not present in module
6921.175541502:7f8b11df2780: entry point 'beginCnfLoad' not present in module
Idea #3 - Turn up rsyslogd debugging
Also I'd try enabling debugging of the rsyslogd
daemon for further insight.
$ sudo -i
$ export RSYSLOG_DEBUGLOG="/tmp/debuglog"
$ export RSYSLOG_DEBUG="Debug"
$ service rsyslog stop
$ rsyslogd -d | head -10
7160.005597645:7fae096a3780: rsyslogd 7.2.6 startup, module path '', cwd:/root
7160.005872662:7fae096a3780: caller requested object 'net', not found (iRet -3003)
7160.005895004:7fae096a3780: Requested to load module 'lmnet'
7160.005906331:7fae096a3780: loading module '/lib64/rsyslog/lmnet.so'
7160.006023505:7fae096a3780: module lmnet of type 2 being loaded (keepType=0).
7160.006030872:7fae096a3780: entry point 'isCompatibleWithFeature' not present in module
7160.006033780:7fae096a3780: entry point 'setModCnf' not present in module
7160.006036209:7fae096a3780: entry point 'getModCnfName' not present in module
7160.006038359:7fae096a3780: entry point 'beginCnfLoad' not present in module
...
...
7160.006063913:7fae096a3780: rsyslog runtime initialized, version 7.2.6, current users 1
7160.006102179:7fae096a3780: source file syslogd.c requested reference for module 'lmnet', reference count now 2
7160.006113657:7fae096a3780: GenerateLocalHostName uses 'greeneggs'
Confirming version info
$ rsyslogd -version
rsyslogd 7.2.6, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: No
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
Runtime Instrumentation (slow code): No
uuid support: Yes
See http://www.rsyslog.com for more information.
Confirmed bug and a workaround
The OP submitted this as a bug to Red Hat.
The bug was characterized as follows:
Sure enough when I set the host's own time the VM had the same wrong time as the host. That's when I noticed /var/log/messages was no longer being updated.
It turns out nothing other than restarting the rsyslog service itself logs to files at that point. If I do so this gets logged:
---
Apr 15 16:39:39 rhel7time-dev rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'
Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="574" x-info="http://www.rsyslog.com"] exiting on signal 15.
Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2117" x-info="http://www.rsyslog.com"] start
---
Otherwise nothing is logged to file, including logger.
If I comment out $OmitLocalLogging on in rsyslog.conf then file logging resumes (notice that until that point I hadn't changed rsyslog.conf).
Logging through journal is unaffected by all this. journalctl -b shows logging, including anything sent by logger.
To which the one of the developers responded:
When this issue occurs, you can delete /var/lib/rsyslog/imjournal.state
and restart the daemon as a workaround.
rsyslog doesn't handle the date directly but only through the systemd API.
I've checked the code in imjournal a while ago and this looks like an issue in systemd.
For reference, see: https://github.com/rsyslog/rsyslog/issues/43
Best Answer
OpenVPN wouldn't start with that Dockerfile because there's nothing to start it :-). Your entrypoint is
sh
; that's all it will run.If you want to start two daemons inside Docker, your entrypoint needs to be a program that starts both of them. A lot of people use
supervisord
for this. Note that Docker is relatively opinionated software, and running multiple daemons in one container is not considered idiomatic.If this is just about debugging, there's no problem. Just don't run
openvpn
with--daemon
or--log
. It will write to stdout (allegedly, though I wouldn't be surprised to see stderr). This is great for debugging if you start it manually. You'll see all the log messages immediately in the terminal.If you set up the entrypoint and manually start the container in interactive mode - same deal. If you start it as a background container (pardon my vagueness), the output will be captured for
docker logs
. It's the same technique favored by modern init systems like systemd (and the systemd "journal" logging system).Once you have the daemon set up how you want, you may be interested in more customized systems for capturing logs, like the other answers.
Docker has pluggable logging drivers, according to the manpage for
docker logs
. There's a "syslog" driver which says it writes to the host syslog. It saysdocker logs
won't work, but I don't expect that's a problem for you.WARNING:
docker logs
does work if you use the journald logging driver. However, on Debian defaults, my assumption is this would cause logs to be lost on reboot. Because Debian doesn't set up a persistent journal. It's not hard to change though, if that's what you want.The other logging driver which supports the
docker logs
command is called "json-file". I expect that's persistent, but you might prefer one of the other solutions.The "why" question
The point is that Docker containers don't necessarily work the same as the OS they're based on. Docker isn't OS virtualization like
LXC
,systemd-nspawn
, or a virtual machine. Although Docker was derived fromLXC
, it was specifically designed for "application containers" that run a single program.(Current) server distributions are designed as a combination of several running programs. So you can't take a package from them and expect it to behave exactly the same way inside one of these application containers.
Communication with a logging daemon is a great example. There's nothing there that's going to change, except that people will become more familiar with the concept of application containers. And whether that's what they actually want to use :). I suspect a lot of sysadmins would be more interested in a mashup of LXC (OS containers), with something like NixOS to share packages between containers; it just hasn't been written yet AFAIK. Or just a better LXC.