Deploying IBM UrbanCode Deploy Blueprint Designer Cloud Applications Part 1 – Connecting to the AWS Cloud

This blog series is about deploying your first IBM UrbanCode Deploy Cloud application using UCD, the Blueprint Designer, and Amazon Cloud Services. IBM used to refer to the Blueprint Designer extension with UCD as UrbanCode Deploy With Patterns (UCDP) but seems to have dropped that distinction after bundling the applications post version 6.1.1.  It is now simply referred to as the Blueprint Designer (BPD). To begin, we assume that you already have the BPD product components installed and you have an AWS account.  With those in place, the first part of our journey is to connect UCDP with the AWS Cloud. 

Understanding the OpenStack Components

BDP comes with a set of packaged Openstack services – Orchestration (HEAT) and Identity (Keystone). The HEAT engine is how BPD communicates with Openstack based clouds like AWS, Azure, and SoftLayer. Keystone is a requirement of the Orchestration Service and is needed for BPD and HEAT to authenticate with AWS. The installation preconfigures a couple of Keystone projects (tenants), roles, and users that are necessary for BPD to connect to the AWS cloud.  The same values can be used over and over again to configure additional cloud connections.   The Identity service objects are only used for the cloud connections, whereas the identity, and authentication of BPD users, is typically managed through an enterprise directory.  Authorization for users is then managed in the Blueprint Designer.

 

The Cloud Agents

UCD also comes with Cloud agents. These are UCD agents for the various supported platforms.  If you are familiar with UCD and how to manually extract and deploy agents, the cloud agents provided here are added as components to UCD.  So these are now deployable components and their deployment is automated at provisioning time. The cloud agent package also adds an example component and application to UCD.

 

Integrating UCD and Defining Authentication Realms

The first step is to log in to BPD and create an authentication realm.  This allows the import of users from the authentication source into the Blueprint Designer. In UCD create a token and paste it somewhere for later use. Log into BPD, click on the gear in the upper right corner and select Administration -> Users.  Buried in the documentation the default credentials are ucdpadmin/ucdpdmin for username and password. In the Realms column, click the plus sign to create a new Realm. Give it a name, select the Realm type, identify the UCD server URL, select Token Based Authentication, and place your UCD token in the text box.  Click Save and then Test Connection.

 

It is possible to setup an LDAP realm in BPD, however since there is a relationship between cloud deployments and Team ownership of UCD resources, a typical setup would be to define an LDAP realm in UCD and an UrbanCode Deploy realm in BPD. After clicking Save a new realm will appear in the Realms column.  Under Administration -> Users in the Users subtab, select import users. You will see the UCD users imported into BDP.

Arnone 1

Figure 1 – Defining an UrbanCode Deploy Authentication Realm

 

Assigning Users to Roles

At this point, you can log into BPD as a UCD user but users cannot do anything because those users have not yet been given permissions.  To do so, click the gear in the upper right and select Administration -> Teams.  In the Teams column, click the + to create new Team.  In the Members sub-tab, select a realm and add users.  Click on a user and assign them to the appropriate Roles. Roles can be added or modified in the Administration -> Roles configuration tab.

 

Creating an AWS Cloud Connection

In order to see UCD components in the Blueprint Designer you first need a cloud connection. This is a bug that will be corrected in UCD version 6.2.4. In BPD, under Administration, select Clouds and create a cloud connection.  In the Edit tab give the connection a name and select AWS cloud type. Uncheck “Use default orchestration engine” and enter the Identity and Orchestration end points.  Replace {hostname} with the fully qualified name of the server hosting the Openstack Identity and HEAT services.  Click Save.

Figure 3 - Creating an AWS Cloud ConnectionFigure 2 – Creating an AWS Cloud Connection

 

When the Openstack services are installed, a couple of users, projects, and roles are created by default in the Identity Service.  These defaults can be used as functional ids to authenticate to the cloud. In the home directory of the user who installed the Openstack services is an environment script called keystonerc. Sourcing keystonerc on the command will create the environment needed to access the Identity Service. To authenticate to the cloud you are going to need a project and an associated user in that project.  To find these values requires a couple of Openstack commands in a terminal.

 

First, initialize the environment needed to access the Identity Service.  Replace install_user_home with the home of the user that installed the Openstack Services.

cd install_user_home

source keystonerc

 

List the projects:

openstack project list

 

Output:

+———————————-+———+

| ID                               | Name    |

+———————————-+———+

| 225414a2c49e4cb29975b5533a1c75b1 | service |

| 84c4595f6d284356a80acebf8880bb67 | admin   |

+———————————-+———+

 

List users in an Identity Service project:

openstack user list –project admin

 

Output:

+———————————-+——-+

| ID                               | Name  |

+———————————-+——-+

| 20ba7d67df2b44968ac607e1d13e85d8 | admin |

+———————————-+——-+

 

Easy to miss in the IBM documentation is the default password of the Identity Service admin user.  It is openstack1.  This can also be found in the ~/keystonerc file.

 

Picking up from where we left off, click the Authorization sub-tab, supply the Identity project, user, and password.  You will also need your AWS Access Id and Secret Key.  Click Test Connection and then Save.

DArnone pt 1 fig 2Figure 3 – AWS Cloud Authentication

 

Lastly, the cloud user needs to be authorized. Click the gear and select Administration -> Teams.  Navigate to the Cloud Authorization sub-tab and click Add.  Add admin@Cloud_Name. Doing so accesses the Amazon cloud.  You can select the region you will create instances in and browse network and image resources. Click OK.

Arnone 4Figure 4 – Authorizing the Cloud User

 

It is important to remember that the users in the Identity Service really have nothing to do with the users in UCD or BDP. They are simply meant as functional ids to authenticate to the cloud.  However, it is possible to use the Identity Service as an authentication source and add more projects and users but most installations would use an enterprise directory service for this purpose.

 

Navigate to Blueprints on the left side of the webpage. From the palette on the right, open the various drawers to view UCD components and cloud resources.  If you don’t see components, go back into UCD and make sure you are in a team that is mapped to components and has appropriate rights. To build a blueprint you simply drag resources from the palette onto the canvas.

David J. Arnone

is an ALM and DevOps Architect specializing in IBM CLM and UrbanCode Deploy solutions and services. As a certified Rational CLM Architect, David joined Zilker Technology in January, 2017 and is part of the growing Zilker DevOps practice team.

David Arnone. David Arnone

TAGS

NEWSLETTER

Don't miss out! Get updates on new webcasts, events, and blogs.