OpenShift is a rock solid platform engineered for the enterprise. It's built on top of Kubernetes and provides many value add features, tools, and services which help to streamline the complete end-to-end container development and deployment lifecycle.
This introductory level training course is designed to bring you quickly up to speed with the key features that OpenShift provides. You'll then get to observe first hand how to launch a new OpenShift Container Platform 4.2 cluster on AWS and then deploy a real world cloud native application into it.
We’d love to get your feedback on this course, so please give it a rating when you’re finished. If you have any queries or suggestions, please contact us at firstname.lastname@example.org.
By completing this course, you will:
- Learn and understand what OpenShift is and what it brings to the table
- Learn and understand how to provision a brand new OpenShift 4.2 cluster on AWS
- Learn and understand the basic principles of deploying a cloud native application into OpenShift
- Understand how to work with and configure many of the key OpenShift value add cluster resources
- Learn how to work with the OpenShift web administration console to manage and administer OpenShift deployments
- Learn how to work with the oc command line tool to manage and administer OpenShift deployments
- And finally, you’ll learn how to manage deployments and OpenShift resources through their full lifecycle
This course is intended for:
- Anyone interested in learning OpenShift
- Software Developers interested in OpenShift containerisation, orchestration, and scheduling
- DevOps practitioners looking to learn how to provision and manage and maintain applications on OpenShift
To get the most from this course, you should have at least:
- A basic understanding of containers and containerisation
- A basic understanding of Kubernetes - and container orchestration and scheduling
- A basic understanding of software development and the software development life cycle
- A basic understanding of networks and networking
This course references the following CloudAcademy GitHub hosted repos:
- https://github.com/cloudacademy/openshift-voteapp-demo (OpenShift VoteApp Runbook)
- https://github.com/cloudacademy/openshift-s2i-frontendbuilder (OpenShift S2I Frontend Builder)
- https://github.com/cloudacademy/openshift-voteapp-frontend-react (VoteApp Frontend UI)
- [Instructor] Okay, welcome back. In this demo, I'm going to show you how to set up a new IDP, or identity provider, within the cluster, create a new dedicated identity, and assign it cluster admin permissions. This will allow us to remove the temporary kubeadmin credential which was created at installation time. To begin with, I'll jump over into the runsheet, and under step eight, copy the first two commands.
Back within the terminal I'll paste them and kick them off. Now before we progress, let's quickly explain what this command does. The htpasswd command allows us to create a file that contains a username password credential stored in an encrypted form. This is a basic form of a credential database and will be sufficient for the purposes of this demo. In a real-world production setup, you would likely use something more robust with better management capabilities, for example, LDAP. The command that I have just executed created a new credential pair made up of a username of devuser1 with a password of blah. This gets stored in secure form within a file named users.htpasswd. The dash c parameter tells the command to generate the users.htpasswd file. The dash uppercase B parameter tells the command to use bcrypt to encrypt the password. And the dash lowercase b parameter tells the command to perform the operations in batch mode, meaning it avoids prompting you for each user's password when you execute it.
Using the cat command to output the contents of the file, you can see that the devuser1 password is indeed encrypted. Okay, now that we have this file, let's jump back into the admin console and navigate to the Administration, Cluster Settings, Global Configuration, OAuth option, like so. Under the OAuth section I'll click the Add button. Here we can see all of the available IDP options.
We will proceed with the htpasswd option. I now need to browse to and supply the htpasswd file that we just generated, and upload it like so. Back within the terminal, we can actually now query for the new OAauth configuration that we have just applied by executing the oc get oauth, and oc describe oauth cluster commands, like so. Here we can see under the Identity Providers section that indeed our htpasswd setup has been applied successfully. At this stage we can jump back into the web console and log out and attempt to log back in as the new devuser1. You can see here on the login page that we now have two different authentication mechanisms, the original one which allows us to log in with the temporary kubeadmin credential, and the new one via the htpasswd mechanism that we just configured. I'll select this option and then enter in the new devuser1 credentials, in this case, blah is the password. And as you can see, we have authed in successfully. As expected, the devuser1 currently has non-admin rights to the cluster, as indicated by the fact that the cluster administration section is now no longer available within the left-hand menu. Let's now go ahead and update devuser1 and give this user cluster admin permissions.
Jumping over to the runsheet, under step eight, copy the add cluster role to user command. Then I'll execute it within the terminal. This command assigns the cluster admin role to devuser1. Next, I'll use the following oc command to re-authenticate the devuser1. Again, this login has been successful, but this time I now have access to more projects, in fact, 51 of them. This is a direct result of the upgraded cluster admin privileges that devuser1 now has.
The remaining step eight commands are executed to query the user that the oc utility is now operating as, and whether it indeed has cluster admin permissions. If it didn't, the oc get scc command would fail, which it hasn't, as indicated by fact that a list is returned. So our credential and permission management looks good for devuser1. Having confirmed all this, we can jump back into the runsheet and copy the last command within step eight and execute it within the terminal to remove the temporary kubeadmin credential.
Okay, that completes step eight, we're now in good shape and ready to start rolling out the resources required to deploy our working sample Voting App cloud native application.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.