BootC created Bare Metal Containers [TechOps]

We dive deep into the technical details of BootC – a Red Hat-led technology that uses container-like definitions to describe machine boot processes. BootC is an important development, especially as companies embrace containers and seek a unified approach to machine configuration.

RackN CTO, Greg Althaus, provides an in-depth overview of how BootC works, its key capabilities, and the potential benefits and challenges for operations teams. They explore topics like BootC’s relationship to containers, the concept of immutability, different deployment methods, and the operational considerations around managing BootC at scale.

This conversation offers a balanced, non-Red Hat perspective on BootC, highlighting both its technical merits and the significant operational work required to successfully adopt and integrate it. Listeners will come away with a nuanced understanding of this emerging technology and the factors organizations should weigh as they evaluate BootC for their infrastructure.

Why Jenkins in DevOps?

What kind of orchestration systems does the industry use for infrastructure, automation and controlling day to day operations?

In today’s episode, we talk about infrastructure pipelines at the tooling level, and specifically the use of Jenkins and other CI pipelining tools for ops and orchestration. We dig into why and how you would do this, and what pieces are missing from the system. That conversation leads us into larger day to day challenges.

If you are doing infrastructure ops and DevOps automation, you will get a lot out of this session.

Transcript: otter.ai/u/dbTdHdYTIt5bU1G8SFghKSijhU0
Image: www.pexels.com/photo/barista-wit…d-tattoo-6205639/

Rob’s Hot Take:

In the May 19th Cloud 2030 Podcast episode, Rob Hirschfeld delves into the intersection of payment systems, PCI V4, NFTs, blockchain, virtual reality, and the metaverse. The discussion highlights the often overlooked XRP or ripple specification, enabling banks to transfer funds outside the SWIFT system, introducing alternative ways for banks to exchange fiat currency with significant impacts on credit, microtransactions, and blockchain conversions. The episode emphasizes the importance of understanding seemingly esoteric elements that can shape the future landscape and influence how it evolves. Explore the full conversation for insights into this intriguing combination of PCI, V4, Kryptos, and the Metaverse.

Terraform Usage Patterns (Gitops, IaC, Templates)

Cloud provisioning is very difficult when you go beyond simple provisioning and start thinking about how to to stitch together infrastructure in a repeatable way!

Specifically, today’s episode is a deep dive into Terraform usage patterns.

We get very hands on as we talk about how you manage state files and how you connect things together with Terraform.

We will spend a significant amount of time discussing in the fall because building infrastructure in a scalable automatable way, is a critical topic for the group.

This is an ongoing topic for us – stay tuned for more episodes!

Transcript: otter.ai/u/A-NgZOfa1xeIPA1uQOh8_bSStck
Photo by Artem Beliaikin from Pexels [ID 1079033]

Provisioning is not Provisioning

Rob Hirschfeld and Greg Althaus discuss their recent experiences with customers in truly understanding what provisioning is and what it is not. They even compare where the word provision comes from

LinuxKit and Three Concerns with Physical Provisioning of Immutable Images

DR ProvisionAt Dockercon this week, Docker announced an immutable operating system called LinuxKit which is powered by a Packer-like utility called Moby that RackN CTO, Greg Althaus, explains in the video below.

For additional conference notes, check out Rob Hirschfeld’s Dockercon retro blog post.

Three Concerns with Immutable O/S on Physical

With a mix of excitement and apprehension, the RackN team has been watching physical deployment of immutable operating systems like CoreOS Container Linux and RancherOS.  Overall, we like the idea of a small locked (aka immutable) in-memory image for servers; however, the concept does not map perfectly to hardware.

Note: if you want to provision these operating systems in a production way, we can help you!

These operating systems work on a “less is more” approach that strips everything out of the images to make them small and secure.  

This is great for cloud-first approaches where VM size has a material impact in cost.  It’s particularly matched for container platforms where VMs are constantly being created and destroyed.  In these cases, the immutable image is easy to update and saves money.

So, why does that not work as well on physical?

First:  HA DHCP?!  It’s not as great a map for physical systems where operating system overhead is pretty minimal.  The model requires orchestrated rebooting of your hardware.  It also means that you need a highly available (HA) PXE Provisioning infrastructure (like we’re building with Digital Rebar).

Second: Configuration. That means that they must rely on having cloud-init injected configuration.  In a physical environment, there is no way to create cloud-init like injections without integrating with the kickstart systems (a feature of Digital Rebar Provision).  Further, hardware has a lot more configuration options (like hard drives and network interfaces) than VMs.  That means that we need a robust and system-by-system way to manage these configurations.

Third:  No SSH.  Yes another problem with these minimal images is that they are supposed to eliminate SSH.   Ideally, their image and configuration provides everything required to run the image without additional administration.  Unfortunately, many applications assume post-boot configuration.  That means that people often re-enable SSH to use tools like Ansible.  If it did not conflict with the very nature of the “do-not configure-the-server” immutable model, I would suggest that SSH is a perfectly reasonable requirement for operators running physical infrastructure.

In Summary, even with those issues, we are excited about the positive impact this immutable approach can have on data center operations.

With tooling like Digital Rebar, it’s possible to manage the issues above.  If this appeals to you, let us know!

Don’t Balkanize My Installer, Yo!

kubernetesLast week, RackN announced our enterprise support for Kubernetes using nothing but upstream Ansible from the project itself.  This effort represents years of effort by the RackN founders to keep platforms interoperable via open and shareable operations automation.

That’s why our Digital Rebar approach targets underlay challenges and leverages existing automation tools instead of investing yet another install path.

dcosThis week, we added Install Wizard templates to the DC/OS install automation we build in collaboration with Mesosphere last year.  That makes it even easier to run DC/OS on physical infrastructure.  Like our Kubernetes work, the Digital Rebar automation uses the same community dcos_install.sh that’s used in the community documentation.  The difference is that we’re also driving all the underlay prep and configuration automatically.

If this approach appeals to you, contact RackN and join in the open Day 2 revolution.

Interested in seeing the DC/OS install in action?  Here’s a demo video: