Containerizing open-vm-tools – Part 2: Atomic CLI and Converting to a Systems Container

The content of the previous post discussed creating the open-vm-tools container’s Dockerfile and automating its started up via systemd with a unit file.

Continue reading “Containerizing open-vm-tools – Part 2: Atomic CLI and Converting to a Systems Container”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share

Containerizing open-vm-tools – Part 1: The Dockerfile and constructing a systemd unit file

While validating OpenShift Container Platform on a VMware platform the usage of Atomic OS was also a requirement. In the initial reference architecture, the decision was made to use Red Hat Enterprise Linux as the platform. This platform was then customized and the same packages as in Atomic were installed via Ansible and Red Hat Network.

Continue reading “Containerizing open-vm-tools – Part 1: The Dockerfile and constructing a systemd unit file”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share

Container Images Compliance – what we built at ManageIQ to remove a security pain point – part 2

Part 2 of 2

In part one of this blog post, we mentioned a pain point in Container based environments. We introduced SCAP as a means to measure compliance in computer systems and introduced ManageIQ as a means of automating Cloud & Container based workflows.

Continue reading “Container Images Compliance – what we built at ManageIQ to remove a security pain point – part 2”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share

Container Images Compliance – what we built at ManageIQ to remove a security pain point – part 1

Part 1 of 2

“Docker is about running random crap from the Internet as root on your host”  – Dan Walsh

Continue reading “Container Images Compliance – what we built at ManageIQ to remove a security pain point – part 1”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share

Cockpit: Your entrypoint to the Containers Management World

Containers are one of the top trend today. Starting working or playing with them could be really hard also if you’ve well understood the theory at their base.

With this article I’ll try to show you some useful tips and tricks to start into containers world, thanks also to the great web interface provided by the Cockpit project.

cockpit--capture-15-cockpit-project-http___cockpit-project-org_

Cockpit overview

Cockpit is an interactive server admin interface.  You’ll find below some a of its great features:

  • Cockpit comes “out of the box” ready for the admin to interact with the system immediately, without installing stuff, configuring access controls, making choices, etc.
  • Cockpit has (as near as makes no difference) zero memory and process footprint on the server when not in use. The job of a server is not to show a pretty UI to admins, but to serve stuff to others. Cockpit starts on demand via socket activation and exits when not in use.
  • Cockpit does not take over your server in such a way that you can then only perform further configuration in Cockpit.
  • Cockpit itself does not have a predefined template or state for the server that it then imposes on the server. It is imperative configuration rather than declarative configuration.
  • Cockpit dynamically updates itself to reflect the current state of the server, within a time frame of a few seconds.
  • Cockpit is firewall friendly: it opens one port for browser connections: by default that is 9090.
  • Cockpit can look different on different operating systems, because it’s the UI for the OS, and not a external tool.
  • Cockpit is pluggable: it allows others to add additional UI pieces.

Continue reading “Cockpit: Your entrypoint to the Containers Management World”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Share

Container Orchestration Specification for better DevOps

The world is moving to microservices, where applications are composed of a complex topology of components, orchestrated into a coordinated topology.

Microservices have become increasingly popular as they increase business agility and reduce the time for changes to be made. On top of this, containers make it easier for organizations to adopt microservices.

Increasingly, containers are the runtimes used for composition, and many excellent solutions have been developed to handle container orchestration such as: Kubernetes/OpenShift; Mesos and its many frameworks like Marathon; and even Docker Compose, Swarm and SwarmKit are trying to address these issues.

But at what cost?

We’ve all experienced that moment when we’ve been working long hours and think “yes, that feature is ready to ship”. We release it into our staging environment and bang, nothing works, and we don’t really know why. What if you could consistently take the same topology you ran in your development workspace, and run it in other, enterprise grade, environments such as your staging or production, and expect it to always JUST WORK?

Continue reading “Container Orchestration Specification for better DevOps”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share

Docker project: Can you have overlay2 speed and density with devicemapper? Yep.

It’s been a while since our last deep-dive into the Docker project graph driver performance.  Over two years, in fact!  In that time, Red Hat engineers have made major strides in improving container storage:

All of that, in the name of providing enterprise-class stability, security and supportability to our valued customers.

As discussed in our previous blog, there are a particular set of behaviors and attributes to take into account when choosing a graph driver.  Included in those are page cache sharing, POSIX compliance and SELinux support.

Reviewing the technical differences between a union filesystem and devicemapper graph driver as it relates to performance, standards compliance and density, a union filesystem such as overlay2 is fast because

  • It traverses less kernel and devicemapper code on container creation (devicemapper-backed containers get a unique kernel device allocated at startup).
  • Containers sharing the same base image startup faster because of warm page cache
  • For speed/density benefits, you trade POSIX compliance and SELinux (well, not for long!)

There was no single graph driver that could give you all these attributes at the same time — until now.

How we can make devicemapper as fast as overlay2

With the industry move towards microservices, 12-factor guidelines and dense multi-tenant platforms, many folks both inside Red Hat as well as in the community have been discussing read-only containers.  In fact, there’s been a –read-only option to both the Docker project, and kubernetes for a long time.  What this does is create a mount point as usual for the container, but mount it read-only as opposed to read-write.  Read-only containers are an important security improvement as well as they reduce the container’s attack surface.  More details on this can be found in a blog post from Dan Walsh last year.

When a container is launched in this mode, it can no longer write to locations it may expect to (i.e. /var/log) and may throw errors because of this.  As discussed in the Processes section of 12factor.net, re-architected applications should store stateful information (such as logs or web assets) in a stateful backing service.  Attaching a persistent volume that is read-write fulfills this design aspect:  the container can be restarted anywhere in the cluster, and its persistent volume can follow it.

In other words, for applications that are not completely stateless an ideal deployment would be to couple read-only containers with read-write persistent volumes.  This gets us to a place in the container world that the HPC (high performance/scientific computing) world has been at for decades:  thousands of diskless, read-only NFS-root booted nodes that mount their necessary applications and storage over the network at boot time.  No matter if a node dies…boot another.  No matter if a container dies…start another.

Continue reading “Docker project: Can you have overlay2 speed and density with devicemapper? Yep.”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share
Docker Logo

Keep it small: a closer look at Docker image sizing

A recent blog post, 10 things to avoid in docker containers, describes ten scenarios you should avoid when dealing with docker containers. However, recommendation #3 – Don’t create large images and the sentence “Don’t install unnecessary packages or run “updates” (yum update) that download files to a new image layer” has generated quite a few questions.  Some of you are wondering how a simple “yum update” can create a large image. In an attempt to clarify the point, this post explains how docker images work, some solutions to maintain a small docker image, yet still keep it up to date.

Continue reading “Keep it small: a closer look at Docker image sizing”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Share

Red Hat Software Collections 2.0 Docker images, Beta release

I’m very happy to announce that Docker images based on collections from Red Hat Software Collections (RHSCL) 2.0 are in beta testing.  The images are available from the Red Hat Container Registry, and we’ve got the set of collections for language, databases and web servers covered – a complete list is below.

If you’ve not tried out the Docker package from RHEL7 Extras, you need to enable the Extras channel, install the docker page, and start the docker service; an extended guide for RHEL Docker is available here.  Once you are set up, pulling the RHSCL Docker images is very simple… for example, you can fetch the Python 3.4 image as follows:

Continue reading “Red Hat Software Collections 2.0 Docker images, Beta release”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Share

Containers in the enterprise – Are you ready for this?

So here’s are deal: We’ve created what we’re calling “PaaS-Containers” in our IT production environment. It consists of core technologies like RHEL Atomic Host, Kubernetes, and Docker along with supporting CI/CD components like Jenkins together as part of an offering that supports the end-to-end automated deployments of applications from a code-commit event through automated testing and roll-out through multiple environments (dev, QA, stage, prod). Oh, did I mention that it’s also integrated with our enterprise logging and monitoring as well as our change management process and tooling so that we have a complete audit trail?

Everyone wants to jump on the bandwagon – they see the benefits of rapid deployment, atomicity, enabling business capabilities faster through technology. But as we learned in the 90-day initiative to get it stood up and an existing application deployed on it, all applications aren’t ready for containers and some may never be based on their current architecture.

Here’s what we think about the deployment options in an enterprise context that allows us to enable innovation while managing enterprise risk…

Continue reading “Containers in the enterprise – Are you ready for this?”


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Share