name : obsolete container docker : image : someuser/oldandbusted state : stopped # Stop and remove a container with the specified name. name : application service docker : name : myservice image : someuser/serviceimage state : restarted # Stop all containers running the specified image. This may be useful within a # handler, for example. name : load-balanced containers docker : state : reloaded count : 5 image : someuser/anotherappimage command : sleep 1d # Unconditionally restart a service container.
If fewer than five are running, more will be launched # if more are running, the excess will be stopped. name : application container docker : name : myapplication image : someuser/appimage state : reloaded pull : always links : - "myredis:aliasedredis" devices : - "/dev/sda:/dev/xvda:rwm" ports : - "8080:9000" - "127.0.0.1:8081:9001/udp" extra_hosts : host1 : "192.168.0.1" host2 : "192.168.0.2" env : SECRET_KEY : ssssh # Ensure that exactly five containers of another server are running with this # exact image and command.
# - set the environment variable SECRET_KEY to "ssssh". # - bind UDP port 9001 within the container to port 8081 on the host, only # listening on localhost. # - grant the container read write permissions for the host's /dev/sda device # through a node named /dev/xvda # - bind TCP port 9000 within the container to port 8080 on all interfaces # on the host. # - link this container to the existing redis container launched above with # an alias. # If any configuration options have changed, the existing container will be # stopped and removed, and a new one will be launched in its place. # - ensure that a container is running with the specified name and exact image. This will: # - pull the latest version of your application image from DockerHub. name : redis container docker : name : myredis image : redis command : redis-server -appendonly yes state : started expose : - 6379 volumes_from : - mydata # Ensure that a container of your application server is running. name : data container docker : name : mydata image : busybox state : present volumes : - /data # Ensure that a Redis server is running, using the volume from the data # container. If no container # by this name exists, it will be created, but not started. # Ensure that a data container with the name "mydata" exists. The module # can accept either a name to target a container uniquely, or a count to operate # on multiple containers at once when it makes sense to do so. The message should show up in the host’s journalct log, and if you are running rsyslog on the host, the message should end up in /var/log/messages.# Containers are matched either by name (if provided) or by an exact match of # the image they were launched with and the command they're running. # docker run -v /dev/log:/dev/log -it -rm rhel /bin/bash If you wanted to logging messages to go to the host logger, you could volume mount /dev/log into the container.
Also comment out: $IMJournalStateFile imjournal.state.Īfter making these changes rsyslogd will start listening on /dev/log within the container and the logger messages will get accepted by rsyslogd and written to /var/log/messages within the container.Make sure $ModLoad imuxsock is present.In order to get the rsyslogd to work the way the user wanted, he would have to modify the configuration file, /etc/nf: In RHEL7 and Fedora, rsyslog actually reads messages from the journal via its API by default.īut not all docker containers run systemd and journald. The problem was that in RHEL7 and Fedora we now use journald, which listens on /dev/log for incoming messages. The user then looked and noticed that /dev/log did not exist and this was where logger was writing the message. No message showed up in /var/log/messages within the container, or on the host machine for that matter. The user ran a RHEL7 container, installed rsyslog, started the daemon, and then sent a logger message, and nothing happened. Recently I received a bug report on Docker complaining about using rsyslogd within a container.