Open Grieves

Open Grieves

Assimilate quickly!

You must comply!

Red Hat OpenShift (OCP) 3.3 in Microsoft Azure

You must readPosted by Magnus Glantz 2016-11-23 10:26:16
Hi all,

Here's a quick guide on how to get Red Hat OpenShift Container Platform, version 3.3 (latest) running in Microsoft Azure, step-by-step.

Prereqs:
* OpenShift subscriptions
* Azure account
* Azure CLI: Download here.

Run the following Azure CLI commands:

0. Activate keystore provider, this will allow you to create keystores.
a. azure provider register Microsoft.KeyVault
Ex: [azure provider register Microsoft.KeyVault]

1. Create a keystore, in which you'll store your SSH key, to provide access to you.

Create Key Vault using Azure CLI - must be run from a Linux machine (can use Azure CLI container from Docker for Windows) or Mac
a. Create new Resource Group: azure group create <name> <location>
Ex: [azure group create ResourceGroupName 'East US']

b. Create Key Vault: azure keyvault create -u <vault-name> -g <resource-group> -l <location>
Ex: [azure keyvault create -u KeyVaultName -g ResourceGroupName -l 'East US']

c. Create Secret: azure keyvault secret set -u <vault-name> -s <secret-name> --file <private-key-file-name>
Ex: [azure keyvault secret set -u KeyVaultName -s SecretName --file ~/.ssh/id_rsa

d. Enable the Keyvvault for Template Deployment: azure keyvault set-policy -u <vault-name> --enabled-for-template-deployment true
Ex: [azure keyvault set-policy -u KeyVaultName --enabled-for-template-deployment true]

Fill in the deployment template, deploy and configure the OpenShift cluster:

2. Deploy the OpenShift cluster in Azure

a. Goto https://github.com/mglantz/ocp-enterprise


b. Initiate template in Azure. Click on 'Deploy to Azure'



c. Fill in the information in the template. Hoover your mouse over the little 'i' at the end of each row.

Read the additional notes below, as well:

Resource group: Select the same resource group as you used to created the KeyStore!
OpenShift Cluster Prefix: Doesn't matter much what you set here. Just put in something that makes sense.
OpenShift Master Public Ip Dns Label: Whatever you put here will complete the masters public DNS name, as such: <what-you-put-here>.<availability-zone>.cloudapp.azure.com
Node Lb Public Ip Dns Label: Whatever you put here will complete the loadbalancers public DNS name, as such: <what-you-put-here>.<availability-zone>.cloudapp.azure.com. Doesn't matter much as it won't be exposed to end users.
Node Instance Count: Will define the number of servers that will host actual containers. For me I got into issues when defining values higher than 1, I think that was some limitation set on my Azure account.
Data Disk Size: Depending on what you'll use this for, set something that makes sense. I used 75 GB for my demo environment.
Admin Username: I used the same user name as the one I have for azure. This will be the username you use to log in to OpenShift with.
OpenShift password: The password for the user above.
Cloud Access Username: This is your Red Hat Network username, which has access to the OpenShift subscriptions.
Cloud Access Password: Password to your Red Hat Network user.
Cloud Access Pool Id: This is the subscription pool id, which holds your OpenShift subscriptions. To get it, logon to a Red Hat server, registered with that username and type: subscription-manager list --available. You will then see the line 'Pool ID: 8a85f98157b24ea1011234567890'. Copy and paste the pool ID.
Subscription Id: This is your Azure subscription ID. Run: 'azure account show' and look at the line that states 'ID' and copy and paste.
Vault Key Resource Group: What you defined earlier in step 1, should be the same as 'Resource Group', if you listened to my instructions.
Vault Key Name: What you defined earlier in step 1.
Vault Key Secret: What you defined earlier in step 1.
Default Sub Domain Type: Here, I selected 'custom', because I want to set my own domain that applications deployed in OpenShift use. If you do not have your own domain, that doesn't really matter, you can always just put whatever here and then put the hostname + IP to the load balancer, in your hostfile of your laptop, for testing purposes. When I selected xipio, the deployment failed.
Default Sub Domain: Your own domain or something abitrary such as 'domainthatdoesntexist12345.com'

3. Click purchase and wait until everything is deployed. For me it took an hour or so.

4. Log in to the master node, like so:
https://<master-label>.<availabilityzone>.cloudapp.azure.com:8443/console/ with the user and password defined above.


5 (Optional) Setup of custom DNS
If you want your applications to be reachable via something else than the xip.io domain and use your own domain, follow the instructions below:

a. Create a wildcard DNS A record that looks like something like *.openshift.mydomain.com and which points at the Load Balancers IP address. To find it, select 'All resources' in Azure, and then click on 'loadb' (Public IP address) and copy and paste. This means you'll be able to access your applications via DNS and do not have to edit host files and such. I found no way to do this in Azure, I used my own private DNS provider to create the wildcard A record.

b. Ensure that '/etc/origin/master/master-config.yaml' states:
routingConfig:
subdomain: "openshift.mydomain.com"

c. If not, edit the file and restart the OpenShift master, with 'systemctl restart atomic-openshift-master'

Done.
























  • Comments(0)//blog.hacka.net/#post123