I used containers (namely, FreeBSD jail) in production already in 2001. Still, it was the tool and company called Docker that made the use of containers mainstream. Fast forward another few years and you can hear the names skopeo, buildah and podman more and more often. These tools come from Red Hat, replacing and extending functionality of the docker daemon without the need to run a “big fat daemon” on the hosts. The architectural redesign is closer to the UNIX philosophy and here is no single point of failure. In addition, the redesign makes it safe for regular users to work with containers. No wonder other Linux distributions are picking up the new tools as well.
From this blog you can learn the basics of skopeo, buildah and podman through the examples of a syslog-ng container. These tools are available in the Red Hat family of Linux distributions, openSUSE Kubic, and others (for example, Arch) as well. In my blog I will be using a lesser known Fedora Linux variant called Silverblue. Silverblue is an immutable desktop operating system aiming at good support for container-focused workflows. Nevertheless, the commands I will show should work just the same on any other distributions featuring reasonably recent versions of the tools mentioned above.
I had been planning to test these tools for quite a long time. Then, finally, a talk of Micah Abbott at DevConf.cz gave me the final boost (especially after I read his Fedora Silverblue tutorial at https://miabbott.github.io/2019/01/22/silverblue-day-1.html as well).
Skopeo
The skopeo utility was originally developed to inspect container images residing just about anywhere: on your laptop, on docker.io or your Kubernetes cluster. For example, you can learn more about the balabit/syslog-ng image on the Docker hub. Among other things, you can see tags, layers and supported architecture(s) in the output:
[root@localhost ~]# skopeo inspect docker://docker.io/balabit/syslog-ng
{
"Name": "docker.io/balabit/syslog-ng",
"Digest": "sha256:f30520ed8ddfb09574913cc3375b2fe2eb53feeec796b604e7bdf27b0d0aa880",
"RepoTags": [
"3.14.1",
"3.19.1",
"3.6",
"latest"
],
"Created": "2019-01-08T08:01:49.527947482Z",
"DockerVersion": "18.03.1-ee-3",
"Labels": null,
"Architecture": "amd64",
"Os": "linux",
"Layers": [
"sha256:ff144d3c0ab1033159cf082f681c9f51b09cd701d907e3bad65b1411fa1585a9",
"sha256:9ea1f85f24a102e06d98d8a047c6e8e61d313cb8c732c6825b5603af3dfc39e9",
"sha256:689f4cc944767e5420023914ce263dcaa052142ee9016a027cd0aff9458048fc",
"sha256:47b7ef6f43f2de1dc4cc8b747678e5d222dde26db76931a997ceb5117784a39e",
"sha256:3fe56de2424df2b0b245e33c68584ad17666c6089f5aef2bb24d82e2edf578ce",
"sha256:5f966ecd92c932754730699b014e81e64a81a57039bb77bf1808cacd69c0f833",
"sha256:006a5b635ef03326fcdd1d91fdbb7fd2b75666c831628ca03d9b66b3c8ca672c",
"sha256:b1e59211b538269b94ca77f3337b1d4878df786076a9d1b78745fb896f7270de"
}
Over time, skopeo evolved into a tool that is capable of inspecting images anywhere and copying images from anywhere to anywhere as well.
You can learn more about skopeo from their GitHub page at https://github.com/containers/skopeo.
Buildah
Buildah is a tool that facilitates building Open Container Initiative (OCI) container images. It is also a drop-in replacement when it comes to building images from traditional Dockerfiles andis capable of a lot more.
Here I will show you how to build a container from a Dockerfile. To demonstrate that buildah is not limited to Red Hat Linux (as I overheard quite a few times during discussions), I will rebuild the balabit/syslog-ng image locally using buildah. This image is based on Debian, the Linux of choice for containers by the syslog-ng developers. The Dockerfile and related files are available on GitHub: https://github.com/balabit/syslog-ng-docker/tree/master/syslog-ng.
You can download them by using your browser or by using Git as well:
git clone https://github.com/balabit/syslog-ng-docker/
If you used Git, change to the directory containing the Dockerfile:
cd syslog-ng-docker/syslog-ng
Now you can use buildah to build the image:
buildah bud -t czp/syslogng .
The bud command of buildah is used to build images from a Dockerfile. The -t option is for tagging. I tend to use my initials to tag images built by me. What you use here it is up to you, just remember to use the same name in the next section as well. Once the image is ready, you should see it in the list of images:
[root@localhost syslog-ng]# buildah images IMAGE NAME IMAGE TAG IMAGE ID CREATED AT SIZE docker.io/library/debian jessie ec0727c65ed3 Feb 6, 2019 04:27 133 MB localhost/czp/syslogng latest 867153404003 Feb 15, 2019 15:28 468 MB
You can learn more about buildah from their GitHub page at https://github.com/containers/buildah.
Podman
Podman manages pods, containers, container images and container volumes. It is an almost drop-in replacement for the docker command. Here I will show you how to run the container created using buildah in the previous step.
As I was advised that podman has the same options as the docker command, I started out by recreating the sample environment from my earlier Docker blog at https://www.syslog-ng.com/community/b/blog/posts/central-log-server-docker/. I created a sub-directory called sng and created a very simple configuration in it. This syslog-ng.conf only contains a network source, a file destination and, of course, a log statement connecting the two:
[root@localhost sng]# cat syslog-ng.conf
@version: 3.19
source s_net {
udp(
ip("0.0.0.0")
);
syslog(
ip("0.0.0.0")
);
};
destination d_file {
file("/var/log/syslog");
};
log {source(s_net); destination(d_file); };
When I first tried to run the container by merely replacing docker with podman (and, of course, adopting the path names as well), I received a huge “Permission denied” message. Using a Linux distribution from the Red Hat family, I was immediately suspecting SELinux. And I was right :) With a bit of further research (man podman-run), it turned out that the command line needs a bit of SELinux-related magic. Appending “:Z” to volume mapping resolved the problem for me. It relabels files in a way that only a single container can access them. It was perfectly OK in my situation, but before any kind of production use or running the container in your home directory as a regular user, you should definitely check the documentation.
The following command line starts the previously built syslog-ng container in the foreground with debugging enabled, so you can easily check how it works:
podman run -it -v /root/sng/syslog-ng.conf:/etc/syslog-ng/syslog-ng.conf:Z -v /root/sng:/var/log:Z -p 514:514 -p 601:601 --name="syslog-ng" czp/syslogng -edv
It will print tons of debug information and then start waiting for your log messages. From another terminal you can check it running using podman:
[root@localhost ~]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 13a4873fc7e0 localhost/czp/syslogng:latest /usr/sbin/syslog-... 6 seconds ago Up 5 seconds ago 0.0.0.0:514->514/tcp, 0.0.0.0:601->601/tcp syslog-ng
You can flood it with log messages using the loggen command of syslog-ng. Just replace the IP address with your own:
loggen -S -P 172.16.167.133 601
As syslog-ng is running in debug mode, it will flood your terminal as long as the test is running. If you have been following the directory structure above, you should see a new file: /root/sng/syslog with many similar looking lines:
Feb 15 16:22:27 172.16.167.1 prg00000[1234]: seq: 0000002456, thread: 0000, runid: 1550244146, stamp: 2019-02-15T16:22:27 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
You can learn more about podman from their GitHub page at https://github.com/containers/libpod.
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or you can even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/balabit/syslog-ng. On Twitter, I am available as @PCzanik.