Project News

When compared to dynamic sites based on WordPress or Drupal, staticly generated blog and Web sites (like this one) can go a long way toward simplifying deployment and maintenance. There’s no database or server-side code to maintain, and, when paired with a service like Github or Gitlab, you can accept posts or other contributions from anyone, via pull request.

However, while simplifying certain areas, static sites introduce a bit more complexity in other areas. Among the handful of Middleman-based static sites that our team at Red Hat help maintain, we’ve seen the specter of “it works on my laptop” arise.

With Middleman, authors preview content on their local machine, using Middleman’s built-in development server. There isn’t much setup required to run this development server, but when the same Middleman code runs on different machines, with different operating systems, and different assortments of Ruby gems, things don’t always work as expected.

Enter Docker, which makes it easy to enforce a common application environment for users on different machines. Here’s how I’m using Docker to write and preview this post:

First, I’ll make sure that git and docker are installed on my Fedora 20 notebook, and I’ll add myself to the docker group on my machine.

sudo yum install -y git docker-io

sudo usermod -a -G docker $USER

For the group add to take effect, you must log out and back in, or run su - $USER before continuing.

Then, I’ll cruise over to Github, make a fork of the Project Atomic Web site repo, and clone my new repo:

git clone git@github.com:jasonbrooks/atomic-site.git && cd atomic-site

There’s a script named docker.sh in the repository that builds and runs a Docker container for running local development version of the projectatomic.io site.

I have a couple of modifications for the script and Dockerfile, which make it easier to viewing changes to the site as I write.

First, in the Dockerfile included in the repo, I change the FROM line to FROM fedora:20, which is the official Fedora image. If you’d prefer a CentOS image, you can change this line to FROM centos:centos7. If you do, you’ll also need to add tar and patch to the list of packages to install in line 5.

I also remove line 11, ADD source /tmp/source, because rather than roll the site source into my image, I’m going to point to the source directory in my checkout of the site. This way, I can add and edit posts without rebuilding the image.

Next, I edit the docker.sh script included in the repo such that the docker run command reads:

docker run -p 4567:4567 -v "$(pwd)"/source:/tmp/source:ro middleman

Finally, I modify the SELinux context of my checked-out source directory to allow my Docker container to read it: chcon -Rt svirt_sandbox_file_t source/ To build and run the container, simply run: sh docker.sh After a short time (shorter, naturally, if you have an image already cached on your machine), the Middleman development server will be running on your machine at http://0.0.0.0:4567.

When you add to or edit the posts and other files within the source directory in your checked-out repo, you can refresh the page in your browser to see your changes.

I see people rushing to set up Web sites and PaaS Servers that allow random people to upload Docker container images, and I feel like I am the voice in the wilderness. Remember, containers do not contain!

Containers Do Not Contain

As I stated in my posts on OpenSource.com, not all of the operating system is namespaced. Parts that are not namespaced can potentially allow containers to attack each other, or the host, or at the very least will allow leakage of information into the containers.

Read More »

The Fedora Project holds regular Test Days to help put releases or individual components through their paces. This week, Fedora’s Test Day will focus on Cockpit, which will be part of the Fedora Atomic Host in Fedora 21.

If you’d like to participate, be sure to look over the Test Day on the Fedora wiki and check out the prerequisites, test cases, and how to file results and bugs.

Note that the test day runs all day, and you should be able to find help in the #fedora-test-day channel on Freenode. (New to IRC? See the Fedora guide on IRC.)

Questions? Ask on the cockpit-devel mailing list.

Recently I received a bug report on Docker complaining about using rsyslogd within a container.

The user ran a RHEL7 container, installed rsyslog, started the daemon, and then sent a logger message, and nothing happened.

# docker run -it --rm rhel /bin/bash
# yum -y install rsyslog
# /usr/sbin/rsyslogd
# logger "this is a test"

No message showed up in /var/log/messages within the container, or on the host machine for that matter.

The user then looked and noticed that /dev/log did not exist and this was where logger was writing the message. The user thought this was a bug.

The problem was that in RHEL7 and Fedora we now use journald, which listens on /dev/log for incoming messages. In RHEL7 and Fedora, rsyslog actually reads messages from the journal via its API by default.

But not all docker containers run systemd and journald. (Most don’t). In order to get the rsyslogd to work the way the user wanted, he would have to modify the configuration file, /etc/rsyslogd.conf:

• In /etc/rsyslog.conf remove $ModLoad imjournal.
• Set $OmitLocalLogging to off.
• Make sure $ModLoad imuxsock is present.
• Also comment out: $IMJournalStateFile imjournal.state.

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

If you wanted to logging messages to go to the host logger, you could volume mount /dev/log into the container.

# docker run -v /dev/log:/dev/log -it --rm rhel /bin/bash
# logger "this is a test"

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.

Mark Lamourine is working on an excellent series of posts that demonstrate how you’d use Kubernetes to run services using Docker containers. The latest is Kubernetes: Simple Containers and Services.

The most recent post explores creating the subsidiary services for a Pulp service within a Kubernetes cluster:

Read More »