Language Selection

English French German Italian Portuguese Spanish

Three New Container Capabilities in Red Hat Enterprise Linux 7.7

Filed under
Red Hat
Server

We are proud to announce that users of RHEL 7.7 can now use Podman 1.4.4 to find, run, build and share containers as regular users (also called rootless). This builds on the work we did in RHEL 7.6 (A preview of running containers without root in RHEL 7.6).

The new rootless feature can be tested with a fresh installation of RHEL 7.7 or by upgrading from RHEL 7.6. When doing a fresh install, just add a new user ID and the new version of the shadow-utils package will take care of everything (/etc/subuid and /etc/subgid entries). With an upgrade from RHEL 7.6, you will need to add the UID/GID mappings for existing users. For more detailed information, follow the Managing Containers guide in the RHEL 7 documentation.

The tech preview of rootless containers offers only the the VFS driver (no fuse-overlay support). This has the trade-off of better runtime performance at the expense of using more disk space. The VFS driver does not use copy-on-write, so when the container is started it will copy all of the data from lower layers of the container image.

The runtime performance is improved because there is no copy-on-write cost, though it will result in slower start up and can consume quite a bit more disk space. We are currently working on backporting the fuse-overlay capabilities to the 3.10 kernel with an eye towards full fuse-overlay support during the RHEL 7 life cycle.

Read more

Also: What Service Meshes Are, and Why Istio Leads the Pack

More in Tux Machines

Today in Techrights

today's howtos

Red Hat Leftovers

  • Celebrating KEDA 1.0: Providing an event-driven scale capability for any container workload [Ed: Red Hat works with and for Microsoft, even gives Microsoft all the code]

    Today the community celebrates KEDA 1.0, an open source project aimed at providing event-driven scale capabilities for container workloads. Introduced earlier this year, Red Hat is contributing to KEDA both via the upstream project and by bringing its utility to customers using enterprise Kubernetes and containers with Red Hat OpenShift. We celebrate this milestone with Microsoft and the wider community.

  • We're all on a journey to cloud-native adoption together

    The Cloud Native Computing Foundation (CNCF) is hosting its core conference for the fifth year running. It’s official title is KubeCon + CloudNativeCon, but it’s most importantly the home for Kubernetes. Adopters, contributors, and Kubernetes-curious attendees add up to a record-breaking 12,000 people. I attended to cover the show for our community (full disclosure: my ticket was provided as an industry analyst). Here’s what I heard on day 1.

  • Container reality checks and more industry trends

    As part of my role as a senior product marketing manager at an enterprise software company with an open source development model, I publish a regular update about open source community, market, and industry trends for product marketers, managers, and other influencers. Here are five of my and their favorite articles from that update. [...] The impact: Another container reality check that also drives home why going through the trouble of standards can be worth it in the long run.

Google outlines plans for mainline Linux kernel support in Android

This is an extremely long journey that results in every device shipping millions of lines of out-of-tree kernel code. Every shipping device kernel is different and device specific—basically no device kernel from one phone will work on another phone. The mainline kernel version for a device is locked in at the beginning of an SoC's initial development, so it's typical for a brand-new device to ship with a Linux kernel that is two years old. Even Google's latest and, uh, greatest device, the Pixel 4, shipped in October 2019 with Linux kernel 4.14, an LTS release from November 2017. It will be stuck on kernel 4.14 forever, too. Android devices do not get kernel updates, probably thanks to the incredible amount of work needed to produce just a single device kernel, and the chain of companies that would need to cooperate to do it. Thanks to kernel updates never happening, this means every new release of Android usually has to support the last three years of LTS kernel releases (the minimum for Android 10 is 4.9, a 2016 release). Google's commitments to support older versions of Android with security patches means the company is still supporting kernel 3.18, which is five years old now. Google's band-aid solution for this so far has been to team up with the Linux community and support mainline Linux LTS releases for longer, and they're now up to six years of support. Last year, at Linux Plumbers Conference 2018, Google announced its initial investigation into bringing the Android kernel closer to mainline Linux. This year it shared a bit more detail on its progress so far, but it's definitely still a work in progress. "Today, we don't know what it takes to be added to the kernel to run on a [specific] Android device," Android Kernel Team lead Sandeep Patil told the group at LPC 2019. "We know what it takes to run Android but not necessarily on any given hardware. So our goal is to basically find all of that out, then upstream it and try to be as close to mainline as possible." Read more