Continue reading “Containing System Services in Red Hat Enterprise Linux – Part 1”
Does your team want to move as quickly as possible? Are you and your development team looking for the latest features and not necessarily optimizing on stability? Are you just beginning with the docker runtime and not quite ready for container orchestration? Well, we have the answer, and it’s called the docker-latest package.
About 6 months ago, Red Hat added a package called docker-latest. The idea is to have two packages in Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host. A very fast moving docker-latest package and a slower, but more stable package called, well of course, docker.
The reasoning is, the larger and more sophisticated your container infrastructure becomes, a more stable version is often what people want – but when split into small agile teams, or when just starting out, many teams will optimize on the latest features in a piece of software. Either way, we have you covered with Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host.
Continue reading “Container Tidbits: Understanding the docker-latest Package”
Red Hat Enterprise Linux Atomic Host is a small footprint, purpose-built version of Red Hat Enterprise Linux that is designed to run containerized workloads. Building on the success of our last release, Red Hat’s Atomic-OpenShift team is excited to announce the general availability of Red Hat Enterprise Linux Atomic Host 7.2.6. This release features improvements in rpm-ostree, cockpit, skopeo, docker, and the atomic CLI. The full release notes can be found here. This post is going to explore a major new feature
Continue reading “Announcing Red Hat Enterprise Linux Atomic Host 7.2.6”
Hyperconvergence is a key topic in IT planning across industries today. As customers look to lower costs and simplify day to day management of their IT operations, the hyperconverged model emerges as fit in a number of operational use cases.
Convergence began at the hardware level, with compute, network, and storage appearing in consolidated platforms, but it’s now accelerating as hyperconvergence goes “software defined”. As a leading software infrastructure stack provider, Red Hat recognizes that reducing the overall moving parts in your infrastructure and simplifying the procurement and deployment processes are core requirements of the next generation elastic datacenter.
Applying a solutions-aligned lens, Red Hat is innovating software defined compute-storage solutions across the portfolio, designed to meet the needs of a broad customer base with diverse requirements. As a vendor-partner in this journey, we recognize the value of bringing storage close to your compute and eliminating the need for discreet storage tier. Doing so across both traditional virtualization and cloud, as well as containers and leveraging our industry-proven software defined storage assets – Red Hat Gluster and Red Hat Ceph Storage – we’ve defined a robust set of efficient, solution-aligned hyperconverged offerings.
Continue reading “Red Hat Hyperconverged Solutions”
There have been countless advances in technology in the last few years; both in general and at Red Hat. To list just the ones specific to Red Hat could actually boggle the mind. Arguably, some of the biggest advances have come more in the form of “soft” skills. Namely, Red Hat has become really good at listening – not only to our own customers but to our competitors’ customers as well. This is no more apparent than in our approach to applying a self-service catalog to virtualization. Specifically, pairing Red Hat Enterprise Virtualization (RHEV) with CloudForms for the purpose of streamlining and automation of virtual machine provisioning.
Continue reading “Self-Service Portals and Virtualization”
Red Hat engineers have been working to more securely distribute container images. In this post we look at where we’ve come from, where we need to go, and how we hope to get there.
When the Docker image specification was introduced it did not have a cryptographic verification model. The most significant reason (for not having one) was the lack of a reliable checksum hash of image content. Two otherwise identical images could have different checksum values. Without a consistent tarsum mechanism, cryptographic verification would be very challenging. With Docker version 1.10, checksums are more consistent and could be used as a stable reference for
Continue reading “Container Image Signing”
In our first post defending the pet container, we looked at the challenge of complexity facing modern software stacks and one way that containers address this challenge through aggregation. In essence, the Docker “wrapper” consolidates the next level of the stack, much like RPM did at the component level, but aggregation is just the beginning of what the project provides.
If we take a step back and look at the Docker project in context, there are four aspects that contribute to its exceptional popularity:
- it simplifies the way users interact with the kernel, for features we have come to call Linux containers;
- it’s a tool and format for aggregate packaging of software stacks to be deployed into containers;
- it is a model for layering generations of changes on top of each other in a single inheritance model;
- it adds a transport for these aggregate packages.
Continue reading “In Defense of the Pet Container, Part 2: Wrappers, Aggregates and Models… Oh My!”
In November 2015, I blogged about the announcement to bring .NET to RHEL from the .NET Core upstream project to enterprise customers and developers, both as an RPM and as a Linux container. That was quite a moment for the industry and, quite frankly, for me as well, having participated in the discussions that led to the significant announcement with Microsoft. Since then, we have been in tight collaboration to make sure this day would actually arrive. Despite the usual challenges with a relatively new open source project, the project was
Continue reading “.NET Core on Red Hat Enterprise Linux”
It’s been just over three years since Solomon Hykes presented the world with the (so far) most creative way to use the tar command: the Docker project. Not only does the project combine existing container-technologies and make them easier to use, but its well-timed introduction drove an unprecedented rate of adoption for new technology.
Did people run containers before the Docker project? Yes, but it was harder to do so. The broader community was favoring LXC, and Red Hat was working on a libvirt-based model for Red Hat Enterprise Linux. With OpenShift 2, Red Hat had already been running containers in production for several years – both in an online PaaS as well as on-premise for enterprise customers. The model pre-Docker however was fundamentally different from what we are seeing today: rather than enabling completely independent runtimes inside the containers, the approach in
Continue reading “In Defense of the Pet Container, Part 1: Prelude – The Only Constant is Complexity”
In our previous posts, we’ve explored the Red Hat container ecosystem, the Red Hat Container Development Kit (CDK), OpenShift as a local deployment and OpenShift in production. In this final post of the series, we’re going to take a look at how a team can take advantage of the advanced features of OpenShift in order to automatically move new versions of applications from development to production — a process known as Continuous Delivery (or Continuous Deployment, depending on the level of automation).
Continue reading “Continuous Delivery / Deployment with OpenShift Enterprise”