Project Atomichttp://www.projectatomic.io/blog/2019-11-21T00:00:00+00:00Project Atomic. Sponsored by Red Hat, Inc.Fedora Atomic Host Nearing End Of Lifehttp://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/2019-11-21T00:00:00+00:002021-10-07T14:03:16+00:00Dusty Mabe<p><strong>TL;DR</strong> <em>Fedora 29 will be End Of Life <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/">soon</a>.</em>
<em>With it Fedora Atomic Host will have its last incremental release (based on</em>
<em>the Fedora 29 stream). Please move to the Fedora CoreOS preview if you can.</em></p>
<p></p>
<p>Last year we <a href="https://fedoramagazine.org/announcing-fedora-coreos/">introduced the plans for Fedora CoreOS</a>
including that Fedora CoreOS would be the successor to Fedora Atomic Host
and Container Linux (from CoreOS Inc.). As part of that succession
plan we decided that Fedora 29 Atomic Host would be the last stream of
Fedora Atomic Host to be released.</p>
<p>Fedora 29 Atomic Host has served us well, but with Fedora 29 End of
Life <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/">coming soon</a>
, so will the last release of Fedora 29 Atomic Host.
The next release of Fedora 29 Atomic Host (in the next few weeks) will be
the last two-week release. It will contain all of the latest content
from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic
Host will no longer receive any updates.</p>
<p>Please try out the Fedora CoreOS preview to help us get it towards
stable. Documentation and download links can be found at
<a href="https://getfedora.org/coreos/">https://getfedora.org/coreos/</a>.</p>
Fedora 28->29 Atomic Host Upgrade Guidehttp://www.projectatomic.io/blog/2018/10/fedora-atomic-28-to-29-upgrade/2018-10-31T00:00:00+00:002021-10-07T14:03:16+00:00Dusty Mabe<h3>Introduction</h3>
<p>This week we put out the <a href="https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2018-October/msg00006.html">first</a>
release of Fedora 29 Atomic Host. This will be the last major release
of Fedora Atomic Host as we prepare for <a href="https://coreos.fedoraproject.org/">Fedora CoreOS</a>
which will be released in Fedora 30.</p>
<p>In this post we’ll quickly list some known issues and then talk about updating
an existing Fedora 28 Atomic Host system to Fedora 29. We’ll cover preparing
the system for upgrade and performing the upgrade.</p>
<p></p>
<p><strong>NOTE:</strong> If you really don’t want to upgrade to Fedora 29 see the
later section: <em>Appendix B: Fedora 28 Atomic Host Life Support</em>.</p>
<h3>Known Issues</h3>
<ul>
<li>Device timeout when installing from ISO with swap space. </li>
</ul>
<p>We found <a href="https://pagure.io/atomic-wg/issue/513">an issue</a>
where instances installed via the ISO image via anaconda were
having long boot times because of device timeouts. We traced
this down to <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1641268">a bug in dracut</a>
and this will be fixed in the next release.</p>
<ul>
<li>Incompatibilities with OpenShift Origin >= 3.11 and Kubernetes >= 1.10.4</li>
</ul>
<p>In newer versions of <code>systemd</code> an API was removed that was needed by
older versions of OpenShift/Kubernetes. It is recommended that you
upgrade to Origin 3.11 or Kubernetes > 1.10.4 before moving to Fedora
29 Atomic Host. If you must use an older version of OpenShift/Kubernetes
with Fedora 29 Atomic Host please see the later section:
<em>Appendix A: Using older versions of Kubernetes/OpenShift on Fedora 29 Atomic Host</em>.
Discussion of this issue can be found in the <a href="https://pagure.io/atomic-wg/issue/512">pagure ticket</a>.</p>
<h3>Preparing for Upgrade</h3>
<p>Before we update to Fedora 29 Atomic Host we should check to
see that we have at least a few GiB of free space in our root
filesystem. The update to Fedora 29 can cause your system to
retrieve more than 1 GiB of new content (not shared with Fedora
28) and thus we’ll need to make sure we have plenty of free space.</p>
<p><strong>NOTE:</strong> Luckily if you skip this step OSTree will perform
<a href="https://github.com/ostreedev/ostree/pull/987">filesystem checks</a>
to make sure that upgrade will error gracefully before filling
up the filesystem.</p>
<h3>Upgrading</h3>
<p>Now we should be ready for the upgrade. If you are hosting any services
on your instance you may want to prepare for them to have some downtime.</p>
<p>Currently we are on Fedora 28 Atomic Host using the
<code>fedora/28/x86_64/atomic-host</code> ref.</p>
<pre class="highlight plaintext"><code>[vagrant@host ~]$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-atomic:fedora/28/x86_64/atomic-host
Version: 28.20181007.0 (2018-10-07 20:43:44)
Commit: 8df48fa2e70ad1952153ae00edbba08ed18b53c3d4095a22985d1085f5203ac6
GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1
</code></pre>
<p>In order to do the upgrade we need to add the location of
the Fedora 29 repository as a new remote (similar to a
git remote) for <code>ostree</code> to know about:</p>
<pre class="highlight plaintext"><code>[vagrant@host ~]$ sudo ostree remote add --set=gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-primary fedora-atomic-29 https://dl.fedoraproject.org/atomic/repo/
</code></pre>
<p>You can see from the command that we are adding a new remote known as
<code>fedora-atomic-29</code> with a remote url of <code>https://dl.fedoraproject.org/atomic/repo/</code>
We are also setting the <code>gpgkeypath</code> variable in the configuration for
the remote. This tells OSTree that we want commit signatures to be
verified when we download from a remote.</p>
<p>Now that we have our <code>fedora-atomic-29</code> remote we can do the upgrade!</p>
<pre class="highlight plaintext"><code>[vagrant@host ~]$ sudo rpm-ostree rebase fedora-atomic-29:fedora/29/x86_64/atomic-host
26 delta parts, 9 loose fetched; 264197 KiB transferred in 44 seconds
Upgraded:
NetworkManager 1:1.10.12-1.fc28 -> 1:1.12.4-1.fc29
NetworkManager-libnm 1:1.10.12-1.fc28 -> 1:1.12.4-1.fc29
NetworkManager-team 1:1.10.12-1.fc28 -> 1:1.12.4-1.fc29
acl 2.2.53-1.fc28 -> 2.2.53-2.fc29
atomic 1.22.1-2.fc28 -> 1.22.1-27.gitb507039.fc29
atomic-devmode 0.3.7-4.fc28 -> 0.3.7-6.fc29
atomic-registries 1.22.1-2.fc28 -> 1.22.1-27.gitb507039.fc29
attr 2.4.48-3.fc28 -> 2.4.48-3.fc29
...
python-unversioned-command-2.7.15-10.fc29.noarch
python3-pyyaml-4.2-0.1.b4.fc29.x86_64
Run "systemctl reboot" to start a reboot
[vagrant@host ~]$ sudo systemctl reboot
[vagrant@host ~]$ Connection to 192.168.121.95 closed by remote host.
Connection to 192.168.121.95 closed.
</code></pre>
<p>After reboot we can log in and see the status:</p>
<pre class="highlight plaintext"><code>$ vagrant ssh
Last login: Wed Oct 31 21:14:44 2018 from 192.168.121.1
[vagrant@host ~]$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-atomic-29:fedora/29/x86_64/atomic-host
Version: 29.20181025.1 (2018-10-25 14:46:54)
Commit: 4a999b4b303b47468ff1464051a14fd075d2e7b8bb647584b7cc80fed48cf27b
GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
ostree://fedora-atomic:fedora/28/x86_64/atomic-host
Version: 28.20181007.0 (2018-10-07 20:43:44)
Commit: 8df48fa2e70ad1952153ae00edbba08ed18b53c3d4095a22985d1085f5203ac6
GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1
[vagrant@host ~]$
[vagrant@host ~]$ cat /etc/os-release | head -n 2
NAME=Fedora
VERSION="29.20181025.1 (Atomic Host)"
</code></pre>
<p>We are now on Fedora 29 Atomic Host. Now is a good time to check your
services (most likely running in containers) to see if they are still
working. If not, then you always have the rollback command: <code>sudo
rpm-ostree rollback</code>.</p>
<p><strong>NOTE:</strong> Over time you can see updated commands for upgrading Atomic
Host between releases by visiting <a href="https://fedoraproject.org/wiki/Atomic_Host_upgrade">this</a>
wiki page.</p>
<h3>Appendix A: Using older versions of Kubernetes/OpenShift on Fedora 29 Atomic Host</h3>
<p>Due to <a href="https://pagure.io/atomic-wg/issue/512">an issue</a> that arises from the
combination of the version of systemd that ships with Fedora 29 Atomic Host,
and the version of runc that’s bundled with Kubernetes and with OpenShift
Origin, users of certain Kubernetes and OpenShift Origin releases must take
steps to keep their Kubernetes or Origin clusters running following an upgrade to 29.</p>
<p>Users running Kubernetes releases older than v1.10.4 or OpenShift Origin
releases older than v3.11 would do best to upgrade their Kubernetes or
Origin clusters to a more recent version before undertaking an upgrade
to Fedora 29 Atomic Host.</p>
<p>For users who prefer to upgrade to 29 without changing their cluster
version, it’s possible to work around the issue by changing the
<code>cgroupdriver</code> for both docker and for either the kubelet or the
orgin-node component from its default value of <code>systemd</code> to <code>cgroupfs</code>.</p>
<h4>For docker (applies to both Kubernetes and OpenShift Origin clusters):</h4>
<pre class="highlight plaintext"><code># cp /usr/lib/systemd/system/docker.service /etc/systemd/system/
# sed -i 's/cgroupdriver=systemd/cgroupdriver=cgroupfs/' /etc/systemd/system/docker.service
</code></pre>
<h4>For kubelet (applies to Kubeadm-based Kubernetes clusters):</h4>
<pre class="highlight plaintext"><code># sed -i 's/cgroup-driver=systemd/cgroup-driver=cgroupfs/' /etc/systemd/system/kubelet.service.d/kubeadm.conf
</code></pre>
<h4>For origin-node (applies to OpenShift Origin clusters):</h4>
<pre class="highlight plaintext"><code># vi /etc/origin/node/node-config.yaml
</code></pre>
<p>Add the following element to the <code>kubeletArguments:</code> section:</p>
<pre class="highlight plaintext"><code>cgroup-driver:
- "cgroupfs"
</code></pre>
<p>After making these changes, rebase to 29 as directed above. After reboot
the nodes should return in <code>Ready</code> state as expected.</p>
<h3>Appendix B: Fedora 28 Atomic Host Life Support</h3>
<p>As with Fedora 27 we will keep updating the Fedora 28 Atomic Host tree
but we won’t be performing regular testing on that tree and there will
be no more formal releases for Fedora 28. Please move to Fedora 29 to
take advantage of regular testing and formal releases every two weeks.</p>
<h3>Conclusion</h3>
<p>As in the past, the transition to Fedora 29 Atomic Host should be an
easy process. If you have issues please join us in IRC (#atomic on
<a href="https://freenode.net/">freenode</a>) or on the
<a href="https://lists.projectatomic.io/mailman/listinfo/atomic-devel">atomic-devel</a>
mailing list.</p>
Buildah version 1.2 Release Announcementhttp://www.projectatomic.io/blog/2018/07/Buildah-version-v1.2/2018-07-14T00:00:00+00:002021-10-07T14:03:16+00:00Tom Sweeney<h3>Buildah version 1.2 Release Announcement</h3>
<p><img alt="buildah logo" src="https://cdn.rawgit.com/projectatomic/buildah/master/logos/buildah-logo_large.png" /></p>
<p>We’re pleased to announce the release of Buildah version 1.2 which is now available from GitHub for any Linux distro. We are shipping this release on Fedora, RHEL 7, CentOS and Ubuntu in the near future. </p>
<p>The Buildah project has continued to grow over the past several weeks, welcoming several new contributors to the mix. The highlights of this release are the added ability to control image layers when building an image, CVE’s Fixes, the initial support for user namespace handling and several other enhancements and bug fixes.</p>
<p></p>
<h4>The major highlights for this release are:</h4>
<h5>Allow the user to control the layers of the image when the image is built with the ‘buildah bud’ command.</h5>
<p>A container is comprised of a final readable/writeable layer and when the layers are cached, a number of intermediate read only layers. The read only layers are created with each step in the Dockerfile and the final readable/writeable layer contains the intermediate layers. Prior to these changes Buildah did not cache these intermediate read only layers.</p>
<p>This release has a new environment variable ‘BUILDAH_LAYERS’ and a new ‘buildah bud’ –layers parameter. When either is set to true, the image layers are cached during the ‘buildah bud’ processing and not discarded. The disadvantage to retaining layers is the space that they use. The advantage to retaining them is if you make a change to your Dockerfile, only the layers for that change and the ones following it will need to be regenerated. </p>
<p>The –nocache parameter has also been added to the ‘buildah bud’ command. When this parameter is set to true the ‘buildah bud’ command ignores any existing layers and creates all of the image layers anew.</p>
<h5>Added initial user namespace support.</h5>
<p>To isolate the container’s processes from running as root on the host machine, user namespaces are used by container technologies. This allows the administrator to configure the containers processes that must run as root to remap the user to a less privileged user on the container’s host machine. This remapping is handled in part by settings in the /etc/subuid and /etc/subgid files on the host machine.</p>
<p>The changes for this release does not yet provide full support for user namespaces, but does set up the options to control the mapping with the –userns-uid-map and –userns-gid-map options. Changes have also been made to prevent the container from modifying the /etc/host or /etc/resolv.conf files on the host.</p>
<p>Also with this release if a user with a uid that’s not equal to zero creates a container, a namespace is now created based on the users uid and gid and the container will be reexec’d using that namespace. In addition, the storage driver, storage root directory and storage state directory will all be created under alternate locations. Please reference the buildah (1) man page for more details. Further information will be published in upcoming blogs and additional changes are in progress to provide full support of user namespaces in future versions of Buildah.</p>
<h5>CVE security issues with /proc/acpi and /proc/keys have been addressed.</h5>
<p>The /proc/acpi and /proc/keys were added to the list of blocked kernel files. This prevents the container from manipulating these files on the container’s host.</p>
<h4>Release Changes</h4>
<ul>
<li>Added the ability to remove or retain image layers for ‘buildah bud’:
<ul>
<li>Add –layers and –no-cache options to ‘buildah bud’.</li>
<li>Add –rm and –force-rm options to 'buildah bud’.</li>
<li>Fixed the buildah bud –layers option.</li>
<li>Added environment variable BUILDAH_LAYERS to control image layers creation.</li>
</ul></li>
<li>Added environment variable BUILDAH_RUNTIME to setup alternate runtimes.</li>
<li>build-using-dockerfile: let -t include transports again.</li>
<li>Block the use of /proc/acpi and /proc/keys from inside containers. These address potential CVE Security issues.</li>
<li>Add –cidfile option to 'buildah from`.</li>
<li>Add a –loglevel option to build-with-dockerfile.</li>
<li>Begin supporting specification of user namespace for container separation:
<ul>
<li>Allow –userns-uid-map/–userns-gid-map to be global options.</li>
<li>If unprivileged, reexec in a user namespace.</li>
<li>Force ownership of /etc/hosts and /etc/resolv.conf to 0:0.</li>
</ul></li>
<li>Recognize committing to second storage locations with 'buildah commit’.</li>
<li>Add the –all option to 'buildah unmount’ to unmount all mounted containers.</li>
<li>When doing multiple mounts, output all pertinent errors, not just the last error.</li>
<li>Implement basic recognition of the <q>–isolation</q> option for 'buildah from’ and 'buildah run’.</li>
<li>Fix ARGS parsing for run commands.</li>
<li>When building a container the HTTP User-Agent is set to the Buildah version.</li>
<li>Makefile: add the uninstall command.</li>
<li>Support multiple inputs to 'buildah mount’.</li>
<li>Use the right formatting when adding entries to /etc/hosts.</li>
<li>A number of minor performance improvements for 'buildah run’ and 'buildah bud’.</li>
<li>Change RunOptions.Stdin/Stdout/Stderr to just be Reader/Writers.</li>
<li>Use conversion code from containers/image instead of converting configs manually.</li>
<li>Do not ignore any parsing errors during initialization.</li>
<li>Explicitly handle <q>from scratch</q> images in Builder.initConfig.</li>
<li>Fix parsing of OCI images.</li>
<li>Don’t ignore v2s1 history if docker_version is not set.</li>
<li>Add –all,-a flags to 'buildah images’.</li>
<li>Remove tty check from buildah images –format.</li>
<li>Fix usage information for 'buildah images’.</li>
<li>Documentation changes:
<ul>
<li>Add registries.conf link to a few man pages.</li>
<li>Add information about the configuration files to the install documentation.</li>
<li>Follow man-pages(7) suggestions for SYNOPSIS in all man pages.</li>
<li>Minor update to buildah config documentation for entrypoint.</li>
<li>ONBUILD tutorial created.</li>
<li>Touch up images man page.</li>
</ul></li>
<li>Plus a number of smaller fixes.</li>
</ul>
<h4>Try it Out.</h4>
<p>If you haven’t yet, install Buildah from the Fedora repo or GitHub and give it a spin. We’re betting you’ll find it’s an easy and quick way to build containers in your environment without a daemon being involved!</p>
<p>For those of you who contributed to this release, thank you very much for your contributions! If you haven’t joined our community yet, don’t wait any longer! Come join us in GitHub, where Open Source communities live.</p>
<h4>Buildah == Simplicity</h4>
Announcing the Fedora CoreOS community!http://www.projectatomic.io/blog/2018/06/welcome-to-fedora-coreos/2018-06-20T00:00:00+00:002021-10-07T14:03:16+00:00Dusty Mabe<h3>Welcome to Fedora CoreOS</h3>
<p>Earlier this year Red Hat acquired <a href="https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership">CoreOS, Inc.</a>.
In the past few
months we have been working hard to evaluate the different technologies
in the CoreOS Container Linux and Project Atomic spaces. Since Container
Linux and Atomic Host overlap in functionality quite a bit we have decided
to merge future development of the two projects so that we can combine
our efforts and bring two great communities of people together to solve
future challenges in the transactional update and container operating
system landscape.</p>
<p></p>
<h3>What does this mean for Atomic Host?</h3>
<p>The last major release of Fedora Atomic Host will most likely be Fedora
29 Atomic Host. After Fedora 29 we’ll recommend you use Fedora CoreOS for
any deployments. The use cases for Fedora CoreOS should overlap with the
existing use cases for Atomic Host, but there may be some use cases that
are left behind as we narrow our focus. Hopefully disruptions will be minimal.</p>
<h3>What will happen to the Project Atomic community channels?</h3>
<p>The mailing lists, IRC channels, and GitHub organization will mostly
be retired once the last releases are End Of Life. Please join us on the
new community spaces (more details below)!</p>
<h3>Where can I learn more about Fedora CoreOS and get involved?</h3>
<ul>
<li>There is a new website and FAQ at <a href="https://coreos.fedoraproject.org">https://coreos.fedoraproject.org</a>.</li>
<li>There is a mailing list at <a href="mailto:coreos@lists.fedoraproject.org">coreos@lists.fedoraproject.org</a>.</li>
<li>There is an IRC channel #fedora-coreos on freenode.</li>
<li>There is a new Discourse board at <a href="https://discussion.fedoraproject.org/c/coreos">https://discussion.fedoraproject.org/c/coreos</a>.</li>
</ul>
<p>For future blog posts around containers, please refer to the new website
that is currently under active development.</p>
<p>We’re excited to have the existing Container Linux and Atomic Host
communities working together and we hope you’ll join us in making
Fedora CoreOS a success.</p>
Buildah version 1.1 Release Announcementhttp://www.projectatomic.io/blog/2018/06/Buildah-version-v1.1/2018-06-12T00:00:00+00:002021-10-07T14:03:16+00:00Tom Sweeney<h3>Buildah version 1.1 Release Announcement</h3>
<p><img alt="buildah logo" src="https://cdn.rawgit.com/projectatomic/buildah/master/logos/buildah-logo_large.png" /></p>
<p>We’re pleased to announce the release of Buildah version 1.1 which is now available from GitHub for any Linux distro. We are shipping this release on Fedora, RHEL 7, CentOS and Ubuntu in the near future.</p>
<p>The Buildah project has continued to grow over the past several weeks, welcoming several new contributors to the mix, launching new functionality and creating a number of improvements and bug fixes. </p>
<p></p>
<h4>The major highlights for this release are:</h4>
<ul>
<li>Drop capabilities if running container processes as non root</li>
<li>Print Warning message if cmd will not be used based on entrypoint</li>
<li>Add OnBuild support for Dockerfiles</li>
<li>Add support for buildah bud –label</li>
<li>Report errors on bad transports specification when pushing images</li>
<li>Add registry errors for pull</li>
<li>Give better messages to users when image can not be found</li>
<li>Add environment variable to buildah –format</li>
<li>Accept json array input for config entrypoint</li>
<li>buildah bud now requires a context directory or URL</li>
<li>buildah bud picks up ENV from base image</li>
<li>Run: set supplemental group IDs</li>
<li>Use CNI to configure container networks</li>
<li>add/secrets/commit: Use mappings when setting permissions on added content</li>
<li>Add CLI options for specifying namespace and cgroup setup</li>
<li>Always set mappings when using user namespaces</li>
<li>Read UID/GID mapping information from containers and images</li>
<li>build-using-dockerfile: add –annotation</li>
<li>Implement –squash for build-using-dockerfile and commit</li>
<li>Manage <q>Run</q> containers more closely</li>
<li>Handle /etc/hosts and /etc/resolv.conf properly in container</li>
<li>Make <q>run –terminal</q> and <q>run -t</q> aliases for <q>run –tty</q></li>
<li>buildah push/from can push and pull images with no reference</li>
<li>Attempt to download file from url, if fails assume Dockerfile</li>
<li>builder-inspect: fix format option</li>
<li>buildah-from: add effective value to mount propagation</li>
<li>Documentation Changes</li>
<li>Change freenode chan to buildah</li>
<li>Add example CNI configurations</li>
<li>Touch Up tutorial for run changes</li>
<li>Update 01-intro.md tutorial</li>
<li>Update troubleshooting with new run workaround</li>
<li>Add console syntax highlighting to troubleshooting page</li>
<li>Touchup man page short options across man pages</li>
<li>Demo Changes
<ul>
<li>Added demo dir and a demo.</li>
<li>Added Docker compatibility demo </li>
<li>Added a bud demo and tidied up</li>
<li>Update buildah scratch demo to support el7</li>
<li>Quick fix on demo readme</li>
</ul></li>
<li>Test Changes
<ul>
<li>Add tests for namespace control flags</li>
<li>CI tests and minor fix for cache related noop flags</li>
<li>Add cpu-shares short flag (-c) and cpu-shares CI tests</li>
<li>Add buildah bud CI tests for ENV variables</li>
<li>Additional bud CI tests</li>
<li>Run integration tests under travis_wait in Travis</li>
<li>Re-enable rpm .spec version check and new commit test</li>
<li>Update to F28 and new run format in baseline test</li>
<li>Add context dir to bud command in baseline test</li>
<li>add test to inspect</li>
<li>Test with Go 1.10, too</li>
<li>rmi, rm: add test</li>
<li>add mount test</li>
<li>Fix SELinux test errors when SELinux is enabled</li>
</ul></li>
<li>Vendor changes
<ul>
<li>Vendor in latest container/storage for devicemapper support</li>
<li>Vendor github.com/onsi/ginkgo and github.com/onsi/gomega</li>
<li>Vendor github.com/containernetworking/cni v0.6.0</li>
<li>Update github.com/containers/storage</li>
<li>Update github.com/projectatomic/libpod</li>
<li>Vendor in latest containers/image</li>
</ul></li>
<li>Plus a number of smaller fixes.</li>
</ul>
<h4>Try it Out.</h4>
<p>If you haven’t yet, install Buildah from the Fedora repo or GitHub and give it a spin. We’re betting you’ll find it’s an easy and quick way to build containers in your environment without a daemon being involved!</p>
<p>For those of you who contributed to this release, thank you very much for your contributions! If you haven’t joined our community yet, don’t wait any longer! Come join us in GitHub, where Open Source communities live.</p>
<h4>Buildah == Simplicity</h4>