This workshop will have you deploying and creating native docker images for a Node.js based website and learning to leverage the power of OpenShift 4 to build, deploy, scale, and automate.
Anyone who has had any exposure to Containers
- Architects
- Developers
- Technical leads
- Operations Engineers
- What you will learn
- S2I
- Rollback Replication and Recovery
- Using Labels
- CI/CD pipeline
Welcome to the workshop! This particular workshop will have you deploying with native docker images as well as using OpenShift to create docker images for a Node.js based website. You will also be leveraging the power of OpenShift to build, deploy, scale, and automate.
If you don’t have a person GitHub account please sign up here to create a free account.
Create GitHub Account
This workshop currently focuses on 4 main customer pain points:
- Compliance (OpenSCAP Scanning) and Vulnerability Management
- Patch/Package Management
- CentOS to RHEL conversion
- Vulnerability Management with Insights
We will be using the following terms throughout the workshop labs; so, here are some basic definitions you should be familiar with. You’ll learn more terms along the way; but, these are the basics to get you started.
Container - Your software wrapped in a complete filesystem containing everything it needs to run
Image - We are talking about docker images; read-only and used to create containers
Image Stream - An image stream comprises one or more OCI images identified by tags.
Pod - One or more docker containers that run together
Service - Provides a common DNS name to access a pod (or replicated set of pods)
Project - A project is a group of services that are related logically
Deployment - an update to your application triggered by a image change or config change
Build - The process of turning your source code into a runnable image
BuildConfig - configuration data that determines how to manage your build
Route - a labeled and DNS mapped network path to a service from outside OpenShift
Operator - A method of packaging, deploying and managing a Kubernetes application
Cluster management nodes - The foreman of the OpenShift architecture, the management node schedules operations, watches for problems, and orchestrates everything
Cluster worker nodes - Where the compute happens, your software is run on worker nodes
This lab provides a quick tour of the OpenShift console to help you get familiar with the user interface. If you are already familiar with the basics of OpenShift, this will be easy in that we are simply ensuring you can login and create a project.
OpenShift provides a web console that allows you to perform various tasks via a web browser.
Use your browser to navigate to the URI provided by your instructor and login with the user/password provided.
$ oc login https://api.openshift4.lab-emergent360.com:6443 --insecure-skip-tls-verify=true
Login Webpage
Once logged in you should see your available projects - or you will be provided with an informational box that “No projects exist”
Developer Default View
First let’s create a new project to do our workshop work in. We will use the student number you were given to ensure you don’t clash with classmates:
Click on the “Project: all projects” button and select “Create Project” from the drop down menu
Populate “Name” with “terminal-0 ” and populate “Description” boxes with whatever you like. And click “Create”
This is going to take you to the next logical step of adding something to the project, but we don’t want to do that just yet.
Click “+Add”, to add a new item to the project
Click “Container Image”, to add an existing image from the container registry
In the dialog box under the default radio button, “Image name from external registry”, enter “quay.io/openshifthomeroom/workshop-terminal”, the image should be “Validated” when found.
Observe default values that are populated in the search results
Click “Create”
You will now see a screen that shows a thumbnail view of your deployed application. Click on it, to expand the screen, and see details of the running pod:
“Topology”
Test out the Butterfly terminal
Notice that in the web console overview, you now have a URL in the service box. You can see the webapp running by clicking the route you just exposed.
Check to see what projects you have access to: Use your existing Butterfly terminal, and login, using the same URI with following command:
$ oc login https://api.openshift4.lab-emergent360.com:6443 --insecure-skip-tls-verify=true
The preceding command should output:
Authentication required for https://api.openshift4.lab-emergent360.com:6443 (openshift)
Username: user1
Password:
Login successful.
$ oc get projects
oc get projects
NAME DISPLAY NAME STATUS
terminal-1 Active
Type the following command to show services, deployment configs, build configurations, and active deployments (this will come in handy later):
$ oc status
Summary You should now be ready to get hands-on with our workshop labs.
We will of course take a look at Inventory management as well:
Efficient inventory management is crucial for scaling your automation. We'll explore how to manage inventories in AAP, including adding machines by IP address, hostname, or cloud provider. Learn how to leverage dynamic inventories to automatically discover and manage your infrastructure.
Finally, we'll take a look at Security and Access Control:
Security is paramount. We'll discuss the robust security features within AAP, including role-based access control (RBAC) and credential management. Learn how to assign different levels of access to users and teams within your organization.
Putting it All Together:
We'll wrap up by showcasing some real-world examples of how AAP can be used to automate various tasks across IT operations, including provisioning servers, configuring software, and deploying applications.
Gain inspiration for how to leverage AAP to streamline your own processes and boost your team's efficiency. Throughout the workshop, there will be ample opportunities for hands-on practice, Q&A sessions, and interaction with your fellow participants and trainers.
Get ready to embark on your automation journey with Ansible Automation Platform!
The objective of this exercise is to setup the lab environemnt following an Infrastructure as Code process. This exercise will require you to launch a series of playbooks. The playbooks accomplish the following:
Populate Ansible Controller with an inventory source, add templates, as well as an additional project. Publish RHEL7 dev content view in Satellite Register servers to the Satellite installation - RHEL7 Register servers to the Satellite installation - CentOS7 Populate dynamic inventories - RHEL7 Populate dynamic inventories - CentOS7
Log into your Ansible Automation Platform (AAP2) Controller
Use the link found here
Select the link noted for "Automation controller"
Once logged in, you should be able to see the Ansible Automation Platform dashboard:
Use the side pane menu on the left to select Projects and review the two projects named Automated Management and Fact Scan. These projects, along with the Workshop Inventory under Resources, and Inventories, have been set up for you during the provisioning of the lab environment.
Next, we will execute our first job template. We'll be working with several templates during today's workshop, and this step uses a couple of them to initialize the lab environment.
You should initially see three Templates, named Demo Job Template, Z / CaC / Controller, and Z / CaC / Satellite
Notice that the Z / CaC / Satellite template has already been run for you.
We will have to run the Z / CaC / Controller job template. To do this, click either into the job template and click Launch, or click the Rocketship icon.
You will be taken under the Views, Jobs output window, where you can view the output from the job run. This will display all the tasks executed as part of the playbook. This should take about two minutes to complete and you should see a green "Successful" tag after the name of the playbook in this view once the last task has completed.
Remember to wait until you see the green "Successful" tag before moving on to the next exercise.
Then, navigate back to Templates on the left side pane.
You will notice many more Job Templates have been provisioned in your Controller. We will use some of these in today's workshop.
Next, let's run SATELLITE / RHEL - Publish Content View job template by clicking the rocketship icon or by pressing the Launch button. When prompted by the survey for the content view to publish, from the drop down menu, select RHEL 7.
Hit Next, then Launch.
You will be taken to the Jobs view, showing the output window for the template SATELLITE / RHEL - Publish Content View. This job will take about a minute to run.
Next, click on Templates and search for CONVERT2RHEL / 01 - Take node snapshot job template. Click on the rocketship icon or the template, and click Launch. This job template will take longer, about seven minutes to complete.
Next up, click on Templates, search for, and run the SERVER / CentOS7 - Register job template by clicking the rocketship icon or by clicking into the template and selecting Launch. When the survey appears, complete it as follows:
The SERVER / CentOS7 - Register output window will appear, showing you the results of each task executed as part of the playbook.
Next, go back to Templates and run the EC2 / Set instance tags based on the Satellite (Foreman) facts job template by clicking the rocketship icon or clicking into the job template and selecting Launch.
Next up, click on Templates, search for EC2 / Set instance tag - Ansible Group template, click the rocketship or click on the template and select Launch
Note that Ansible is being directed to map nodes to a group name. This will be used later via dynamic inventory building to create Ansible inventory groups.
Dynamic inventories can be populated via dynamic sources
Before running additional templates, click on the Inventories menu item and select All Development and the Hosts tab. Do the same for CentOS7 and RHEL7 Development inventories. You will notice the Hosts tab on each is empty. Note the Sources tab as well, looking at the Details tab to see the source variables that will be used.
Let's run a Template to update these inventories. Search and run the CONTROLLER / Update inventories via dynamic sources job template by clicking the rocketship icon or selecting the job template and selecting Launch.
Complete the Survey:
Run the same template again, this time to update the CentOS7 instances. You will still need to select the Templates link from the menu, otherwise you will just rerun the template with the same survey if you select the rocketship icon directly from the CONTROLLER / Update inventories via dynamic sources output page you are currently on.
Complete the survey this time with these variables
During this portion of today's workshop, we will give you a comprehensive overview of Red Hat Satellite, a powerful management tool for Red Hat Enterprise Linux (RHEL) deployments. We'll dive into its features, explore its functionalities, and discover how it can streamline your infrastructure management. By the end of this portion of the workshop, you'll be equipped to leverage Satellite's capabilities to automate tasks, improve security, and achieve greater efficiency in managing your RHEL environment.
Satellite provides many benefits within your IT stack, namely, it serves as...
A centralized management platform for Red Hat Enterprise Linux (RHEL) systems.
Simplifies and automates tasks like provisioning, configuration management, patch management, and subscription management.
Provides a single point of control for managing your entire RHEL infrastructure.
Reduced Costs: Saves time and resources by automating tasks.
Increased Efficiency: Streamlines workflows and simplifies management.
Improved Security: Enhances security posture by automating patch deployment and vulnerability management.
Enhanced Compliance: Simplifies compliance audits with centralized reporting and audit trails.
System Provisioning: Automate the deployment of new RHEL systems with pre-configured settings.
Configuration Management: Apply and enforce consistent configurations across your entire RHEL environment.
Patch Management: Automate the deployment of security patches and software updates to ensure your systems stay up-to-date.
Subscription Management: Manage and track RHEL subscriptions for all your systems from a central location.
Content Delivery: Efficiently distribute content like patches, software updates, and configuration files to your RHEL systems.
Reporting and Auditing: Generate comprehensive reports for compliance audits and track system activity.
Satellite Server: The central management hub that controls and coordinates all Satellite operations.
Capsule Servers (Optional): Optional servers deployed closer to remote systems for faster content delivery and reduced network traffic.
Client Systems: RHEL systems managed by Satellite.
Content Repositories: Repositories containing software packages, patches, and configuration files.
External Systems: External systems like identity management and subscription management services.
We ran several playbooks in Ansible to help configure our Satellite environment. As we are taking our tour today, open your instance of Satellite by clicking the link from your student environment
Once logged into Satellite, click the Hosts button from the side panel menu, then select All Hosts.
You should see your RHEL 7 and CentOS7 instances appearing in your list of hosts. These nodes are now registered to your instance of Satellite.
Next, let's verify that all your content is available for your Dev, QA, and Prod environments. To do this, click on Content, then Content Views, then search for RHEL7.
As we continue our tour, we will learn how to configure and perform an OpenSCAP scan using playbooks in Ansible Automation Platform 2 with Satellite. When running multiple Red Hat Enterprise Linux systems, it's important to keep all of these systems compliant with a meaningful security policy and perform security scans often. OpenSCAP is an open source project that is used by government agencies, corporations, as well as e-commerce (just to name a few examples). OpenSCAP provides tools for automated vulnerability checking. Satellite can be loaded with RPM packages for SCAP workbench v1.2.0-8 which will provide scanning capabilities. Satellite is also loaded with the SCAP security guide v0.1.54-3 for RHEL7 and CentOS device which provides the appropriate XCCDF benchmarks for PCI and STIG compliance for the purpose of this exercise. This exercise will focus on RHEL systems, CentOS will be out of scope.
Now, we will create a new compliance policy. To do this, we will configure a compliance policy that we can use to scan our RHEL nodes.
In Satellite, hover over Hosts in the panel to the left and click on Policies.
Click on New Compliance Policy and complete each of the steps.
Leave Manual selected and click on Next.
Under the Policy Attributes tab, enter PCI_Compliance in both the Name and Description fields. If it gives you an error that the name has already been taken, you can use PCI_Compliance2
Click on Next.
Under the SCAP Content tab, select Red Hat rhel7 default content in the SCAP Content drop-down box, followed by PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 7 in the XCCDF Profile drop-down box.
Click on Next.
Select Weekly and Monday for the Schedule tab.
Click on Next.
Keep the default values for the Locations tab.
Click on Next.
Keep the default values for the Organizations tab.
Click on Next.
Keep the default values for the Hostgroups tab.
Click Submit.
Next up, let's use Convert2RHEL to upgrade a CentOS 7 node to RHEL. To do this, we will first SSH into a node. We can use Node4 for this exercise.
- SSH into Node4
ssh centos@node4
- Login and sudo to root
sudo su
- Update CentOS box and reboot
yum update -y
reboot
- Login again, sudo to root
ssh centos@node4
sudo su
- Download RH GPG key and install convert2rhel repo
curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://www.redhat.com/security/data/fd431d51.txt
curl -o /etc/yum.repos.d/convert2rhel.repo https://ftp.redhat.com/redhat/convert2rhel/7/convert2rhel.repo
- Install convert2rhel utility
yum -y install convert2rhel
- Add activation key. INI file should look like below after opening file using VI. Update the "activation_key" value to convert2rhel_demo.
vi /etc/convert2rhel.ini
# -*- coding: utf-8 -*-
# This file should be in mode 0600
# Example of configuration file convert2rhel.ini for secrets.
# Possible locations of this file:
# 1) user specified and passed by -c, --config-file option; highest priority
# 2) ~/.convert2rhel.ini; lower priority
# 3) /etc/convert2rhel.ini; the lowest priority
[subscription_manager]
# password = <insert_password>
activation_key = convert2rhel_demo
org = 13156267
- Run convert2rhel command
convert2rhel --debug
- IF the conversion fails, the kernel module may cause convert2rhel to fail, so we must ignore that step by setting following environment variable. Run the command below and try again.
export CONVERT2RHEL_ALLOW_UNAVAILABLE_KMODS=1
- Reboot the system
reboot
- Login again, sudo to root, and verify system has been upgraded to RHEL:
uname –r
cat /etc/redhat-release
subscription-manager list
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent