Navigation Menu
Red Hat Summit 2019 Follow Up

Red Hat Summit 2019 Follow Up

By on May 20, 2019 in Article | 3 comments

If you attended a session of ours at Red Hat Summit, thank you for spending some time with us! As a follow up, I wanted to give a brief write up on the sessions, as well as share the labs and presentations. Thanks to Dan Walsh, Ben Breard, Jamie Duncan, John Osbourn, and Rodrigo Freire (special thanks for amazing Cachaca):

Choosing the Right Container Base Image For Your Applications

Are you having trouble understanding the different options you have when it comes to container base images? Have you have looked at Red Hat Enterprise Linux base images but don’t quite understand when you are allowed to use and distribute them? Or, are you looking for a set of criteria to help you decide?

If you are struggling with any of these questions, Red Hat’s principal product manager for container images can help. In this session, we’ll cover a set of guidelines and best practices that every developer needs to know when selecting a base image. We will also discuss the latest technology from Red Hat, the universal base image, a newly released solution for developers looking for the best of all worlds.

Presentation: Choosing the right container base image for your application

Blog: Introducing the Red Hat Universal Base Image

Building Production Ready Containers

Everyone knows that building containers is easy. Or is it? Have you ever wondered if it’s too easy? Are you following all the “best practices?” Which ones are relevant? What about security considerations?

In this session, we’ll look at several strategies and provide recommendations for creating container images that can be confidently deployed in production environments. Application developers are encouraged to also attend a related session, “Choosing the right container base image for your application.”

Presentation: Summit 2019_ Building Production-Ready Containers

RHEL 8 Container Tools

We’ve introduced the command-line tool podman, which can be used to replace the Docker Daemon in most use cases. When building and managing container-based applications, it’s important to consider every element of the proposed deployment, from selection of a base image on which to build to an understanding of the security, scalabiltity, and ease of use of the deployment platform. With the introduction of the Red Hat container tools suite, comprising podman, buildah and skopeo and the availability of base images and container runtimes based on Red Hat Enterprise Linux, developers and users alike have a comprehensive set of tools at their disposal.

In this session, we’ll demonstrate how to replace Docker with podman and demonstrate podman. We’ll also demonstrate additional new features like management of pods, and better security features available in podman.

Presentation: Red Hat Enterprise Linux 8 – Container Tools

Linux Container Internals 2.0

What’s the difference between a container runtime and a container engine? How about container images and repositories? Are you having trouble making heads or tails of all of the great Kubernetes projects you see? Are you and your team debating architecture, because it seems like everybody has slightly different interpretations of how things work under the covers? If you have answered, “Uhm,” to any one of these questions, then this lab’s for you.

Join Red Hat engineers as we walk you through the deep, dark internals of the container host and what’s packaged in the container image. This hands-on lab will give you the knowledge and confidence you need to take advantage of your current Linux technical knowledge and apply it to containers. We’ll cover:

•  Images
•  Registries
•  Hosts
•  Orchestration
•  Tools (runtimes, engines, build)
•  Standards (Open Containers Initiative)
•  Security
•  Performance

Presentation: Linux Container Internals 2.0

Labs: Katacoda Interactive Labs – Live on Katacoda – run through them anytime you want, day or night.

Code: GitHub Repository – Feel free to submit any PRs to this repo (the fork I work out of) and I will get them merged upstream (learn.openshift.com). Most common is grammar and prose errors 🙂

Conclusion

Again, thank you to everyone who attended, and everyone who co-presented, provided source material, and crunched time before Summit. I am for one am sighing of relief 🙂 Here are a couple of final piece of meterial which were either sparked by Summit or fresh in my mind:

    3 Comments

  1. Scott, in reading your incredible blogs at red hat, there is mention of a comment section, but I am not able to find such a section. I would like to add a few comments or questions, notably of thanks because the articles on containers were amazing.

    One of my questions, is, if a container has all the user space dependencies, but of course those are in different layers….is Docker intercepting calls to “libraries”, and redirecting them to where a file might be found in a layer … rather than something that might normally be on /var/lib on a host Linux machine? For example, the dotnet core runtime, has a ton of dependencies in the layers. How the heck is dotnet as an example, able to get the dependencies it has on the linux kernel — without docker intercepting “system calls” like at the open() level??? I’d be happy to post this somewhere if I could, just not finding a spot to do so.

  2. Scott, I sent a reply earlier today, and I’d be appreciative if my name wasn’t listed there either. In fact maybe if the post is not approved that is best both ways. I was able to find some notes on a presentation you did which answered my questions for the most part! If you don’t mind shooting an email to me on this request it’s appreciated. thank you kindly.

Post a Reply

Your email address will not be published.