 Hello, my name is Andrew Sullivan with the Red Hat Cloud Platforms Business Unit. Today we are going to look at deploying OpenShift 4 to VMware's vSphere using the OpenShift User Provisioned Infrastructure model. The install process for User Provisioned Infrastructure, also known as UPI, follows a few basic steps. At a high level, these steps include creating the virtual machine resources, configuring the bootstrap node and control plan, and last, the installer will configure the worker nodes. First, we need to have DNS entries and a load balancer in place. The documentation covers the required DNS entries and which host the load balancer should be configured for. Since this configuration is specific to each environment, for this video it has been addressed prior to beginning. The next step is to generate the ignition configurations needed by the bootstrap, master, and worker nodes. This is an example install-config.yaml file, which contains the basic information needed by the installer to generate the configs. Since this file contains sensitive information, we will not show the contents of the file here. After populating the file with the correct information, invoke the installer with the createignition-config option. The installer will ingest the config file and generate the files needed for the next step. In the directory, we have three ignition files, ending with .ign, a metadata file, and a newly created directory named auth. Note that the install-config.yaml file is deleted after the ignition configs are generated. The auth directory contains the kube-config file and kube-admin password, which will be used for connecting to the deployed cluster later. The terraform directory is not created by the OpenShift installer. This demo will use terraform to automate the deployment of virtual machines. However, the VMs may be configured manually or through other automation if desired. Before invoking terraform, we need to update the TFR's file with the information for our deployment. The example file contains the variables which are used to connect to vCenter, deploy VMs from a template, and the master and worker ignition data needed to configure them for OpenShift. Since this file also contains sensitive information, it has been updated with the correct values separately. We see here the top few lines with the data for our cluster. Deploying virtual machines with terraform is done using the apply command. Moving to our vCenter, we see a resource pool is created and the virtual machine template is cloned seven times. Once the virtual machines have completed cloning and have been reconfigured, terraform boots them for us. We can browse to the virtual machine configuration and see that the ignition configuration data has been added as a Vapp option, which the Red Hat Enterprise Linux CoreOS operating system will access using standard VM tools for basic configuration, such as network. With the VMs deployed and booted, we can now use the OpenShift installer. At this point, the Bootstrap node is waiting for additional commands from the installer to continue its work of configuring the master nodes. This process normally takes a few minutes and has been sped up for this video. With the master nodes now hosting the OpenShift control plane services, the Bootstrap VM can be deleted. We'll use terraform to do this process for us. After deleting the VM, we will use the OpenShift installer to complete the process. As with the Bootstrap and control plane setup, this process will take a few minutes, so it has been sped up for this video. During this time, the OpenShift cluster version operator is deploying and configuring the other operators, which are each responsible for the instantiation and configuration of their respective component of the OpenShift deployment. After a few minutes, when the installer finishes, the OpenShift cluster is fully deployed and ready to begin hosting applications. We can quickly check the status of the OpenShift services using the oc-git cluster operator command. We see that all of the services are available and none have a progressing or failing status. Last, we will log into the console of our new cluster to view the status and explore aspects of the UPI deployment. A cluster which is deployed to user-provisioned infrastructure does not have machines or machine sets, which are used when deploying installer-provisioned infrastructure, also known as IPI, to manage and scale nodes. However, both UPI and IPI use machine configs to manage many aspects of the CoreOS operating system used by the nodes and other aspects of the OpenShift cluster. Browsing to the cluster status page, we see our cluster ready to begin hosting applications with all indications green. Thank you for joining me today. Please watch for more videos about Red Hat OpenShift 4 in the future.