Happy new year as this will be the first post of 2021! 2020 was obviously a challenging year, my hope is I will have more time to devote to blogging in 2021. Please reach out and let me know what topics would be most helpful.
In this Article we will walk through an OpenShift deployment using the IPI (Installer Provisioned Infrastructure) method on AWS. OpenShift offers two possible deployment methods: IPI (as mentioned) and UPI (User Provisioned Infrastructure). The difference is the degree of automation and customization. IPI will not only deploy OpenShift but also all infrastructure components and configurations. IPI is supported in various environments including AWS, Azure, GCE, VMware Vsphere and even Baremetal. IPI is tightly coupled with the infrastructure layer whereas UPI is not and will allow the most customization and work anywhere.
Ultimately IPI vs UPI is usually dictated by the requirements. My view is unless you have special requirements (like a stretch cluster or specific integrations with infrastructure that require UPI) always default to IPI. It is far better to have the vendor, in this case Red Hat own more of the share of responsibility and ensure proper, tested infrastructure configurations are being deployed as well as maintained throughout the cluster lifecycle.
In this article we will dive into machine learning. We will begin by understanding the concept, then look at some of the use cases, requirements and finally explore a real world scenario using a demo application. Machine learning has the potential to dramatically change our lives, jobs and influence decision making on a scale that has never been seen before. It is one of the most exciting and also scary technological advancements to ever come around. It is the future but is also happening right now which is why there couldn’t be a better time to get started than today.
In this article we will look at the OpenShift service broker, understand how to integrate external services into OpenShift and even create a custom broker. First before we begin a big thanks to Marek Jelen and Paul Morie, Red Hatters who both helped me understand the service broker in greater detail.
Obviously if you are reading this article you already understand microservices, containers and why it is all so incredible awesome on OpenShift. Of course everything should be in a container but unfortunately it is going to take a while to get there. As we start dissecting and breaking down the monolithic architectures of the past, likely there will be a mix of lightweight services running in containers on OpenShift and other more heavy services (databases, ESBs, etc) running outside. In addition while the service catalog in OpenShift is vast, even allowing you to add your own custom services for anything that can run in OpenShift as-a-container using a template, there will be the need, especially with public cloud to connect to external services. Both of these use cases, on-premise external services and off-premise cloud services really made it obvious that a service broker and more robust service catalog was needed. Originally OpenShift did not have a service broker so you couldn’t easily consume external services. All that existed was the service catalog and templates, so every service had to be a container running on OpenShift. Thankfully other companies also saw a need for an open service abstraction and the Open Service Broker API was born as an opensource project.
In this article we will look at how to use Ansible Tower to deploy and manage OpenShift environments. OpenShift of course uses Ansible as its deployment and configuration tool already. While that is great, using Tower provides several major advantages:
UI for OpenShift deployment and configuration management
Secure store for credentials
RBAC and ability to delegate different responsibilities for OpenShift deployments
Easy to visualize and manage multiple OpenShift environments and even versions of OpenShift
History, audit trail and detailed logging in central location for all OpenShift environments and deployments
In this article we will discuss why Ceph is Perfect fit for OpenStack. We will see how to integrate three prominent OpenStack use cases with Ceph: Cinder (block storage), Glance (images) and Nova (VM virtual disks).
Ceph provides unified scale-out storage, using commodity x86 hardware, that is self-healing and intelligently anticipates failures. It has become the defacto standard for software-defined storage. Ceph being an OpenSource project has enabled many vendors the ability to provide Ceph based software-defined storage systems. Ceph is not just limited to Companies like Red Hat, Suse, Mirantis, Ubuntu, etc. Integrated solutions from SanDisk, Fujitsu, HP, Dell, Samsung and many more exist today. There are even large-scale community built environments, Cern comes to mind, that provide storage services for 10,000s of VMs.
In this article we will setup a Ceph 1.3 cluster for purpose of learning or a lab environment.
Ceph Lab Environment
For this environment you will need three VMs (ceph1, ceph2 and ceph3). Each should have 20GB root disk and 100GB data disk. Ceph has three main components: Admin console, Monitors and OSDs.
Admin console – UI and CLI used for managing Ceph cluster. In this environment we will install on ceph1.
Monitors – Monitor health of Ceph cluster. One or more monitors forms a paxos part-time parliment, providing extreme reliability and durability of cluster membership. Monitors maintain the various maps: monitor, osd, placement group (pg) and crush. Monitors will be installed on ceph1, ceph2 and ceph3.
OSDs – Object storage daemon handles storing data, recovery, backfilling, rebalancing and replication. OSDs sit on top of a disk / filesystem. Bluestore enables OSDs to bypass filesystem but is not an option in Ceph 1.3. An OSD will be installed on ceph1, ceph2 and ceph3.
Since joining Red Hat in 2015, I have intentionally stayed away from the topic of storage. My background is storage but I wanted to do something else as storage became completely mundane and frankly boring. Why?
Storage hasn’t changed much in 20 years. I started my career as a Linux and Storage engineer in 2000 and everything that existed then, exists today. Only things became bigger, faster, cheaper, due to incremental improvements from technologies such as flash. There comes a point however, where minor incremental improvements are no longer good enough and a completely new way of addressing challenges is the only way forward.
I realized in late 2015 that the storage industry is starting a challenging period for all vendors but, didn’t really have feeling for when that could lead to real change. I did know that the monolithic storage array, built on proprietary Linux/Unix, with proprietary x86 hardware we all know and love, was a thing of the past. If you think about it storage is a scam today, you get opensource software running on x86 hardware packaged as a proprietary solution that doesn’t interoperate with anything else. So you get none of the value of opensource and pay extra for it. I like to think that economics like gravity, eventually always wins.
In this article we will look at how to deploy Red Hat OpenStack Platform 8 (Liberty) using Red Hat OpenStack Director. In a previous article we looked at how to deploy Red Hat OpenStack Platform 7 (Kilo). The first release of OpenStack Director was in OpenStack Platform 7 so this is the second release of OpenStack Director.
One of the main areas where distributions of course distinguish themselves is in regards to the installer. As you will see in this article, Red Hat’s installer, OpenStack Director is far more than just an installer, it is a lifecycle tool to manage the infrastructure for OpenStack. OpenStack Director is based on the upstream OpenStack foundation project TripleO. At this point, Red Hat is only distribution basing it’s installer on TripleO, hopefully that changes soon. All other distributions use either proprietary software or isolated, fragmented communities to build OpenStack installers. Beyond installing OpenStack, lifecycle management is mostly an afterthought. Installing OpenStack is of course the easiest thing you will do, it isn’t a big deal anymore. If your serious about OpenStack you will quickly realize things like updates, in-place upgrades, scaling, infrastructure blueprints and support lifecycles are far more critical. Continue reading →
OpenShift Enterprise is a PaaS platform that enables digital transformation. It lets you build and run traditional (mode 1) as well as cloud-native (mode 2) applications. OpenShift is built on two key technology components: Docker and Kubernetes. Docker provides a standard, consistent application packaging format. It enables OpenShift to easily move applications across the hybrid cloud. Kubernetes provides container orchestration and allows multiple container nodes running Docker to be clustered. Kubernetes provides scheduling for application containers.
OpenShift of course provides a lot on top of Docker and Kubernetes. This includes image registry, routing, SDN, developer experience, data persistence, enterprise-grade container runtime, build / deployment blueprints and much more. Continue reading →