The UrbanCode product team recently launched a new program called TechConnect, which is a forum to bring customers, product managers and technical leaders together. The first face-to-face event was hosted in our Cleveland lab with over 20 customers joining us for a full day of sharing best practices, providing product roadmap feedback and generally having some fun.

The event kicked off with a discussion around the current state of DevOps, where the market is heading and where our customers recommend we focus our energy. The remainder of the morning was focused on UrbanCode product roadmaps, highlighting recent deliverables and key futures. The entire Cleveland engineering team joined group for lunch and several customers shared their implementation stories including best practices, significant challenges and business results. In the afternoon, the team split into breakout sessions to deep dive into specific feature design topics.

Customer feedback from event was very positive, in fact Tom Gould from L.L. Bean shared – “This was a great event. I have never had a vendor be so open to feedback. I truly believe the time spent at this event will result in an even better UrbanCode Deploy and Velocity.”

The plan is to continue the momentum from this inaugural event by targeting similar meetups on a quarterly basis around different geographies. If you are interested in participating in the next TechConnect, please reach out to our Customer Advocacy Manager, Randi Anderson at randi.anderson@hcl.com.

The comparison feature of the WAS Configure plug-in is great at detecting differences to your WAS configuration, but what if there are differences in your configuration you wish to ignore? For example, what if there are environment specific properties that differ across environments, and you rather not have those properties flagged as differences when your WAS comparison process runs?

Starting with version 80 of the WAS Configure plug-in, we now offer the ability to ignore specific Property objects during comparison. We also added the ability to ignore specific attributes for any object type during comparison.

Check out the videos below for more information:

<< Back to Getting Started with IBM UrbanCode Deploy and Containers

Introduction

With the Kubernetes plug-in for UrbanCode Deploy, users may change the tag (version) of containers used in a deployment without editing YAML files. UrbanCode Deploy tracks and displays which container image versions are deployed where and when, providing auditing and ease of use.

The Kubernetes plug-in now features similar functionality for deployments using Helm charts. The container images used in Helm charts may be managed as components inside UrbanCode Deploy, eliminating the need for users to update Helm charts or values.yaml files in order to change which container version is deployed in environments.

The Create Image Components From Helm Release Step

Easily create container image components with the The Create Image Components from Helm Release step. Users provide a Helm release name. When run, the step will examine the Helm release, find all container images used by the release, then create UrbanCode Deploy components to mange those container images. The Docker Registry source configuration plug-in may then connect to your Docker registry and discover all available image tags, adding them to the component as versions.

In this example, I’ve created a generic process which contains only the Create Image Components from Helm Release step. I’ve provided my Helm release name mra-derby. Once executed, the process created a component for the container image used in my release and added a kubernetes.image tag to the component. I updated the configuration settings for my component so the Docker Registry plug-in could then connected to my Docker Registry (in this case, Artifactory). I then imported versions for the component. The Docker Registry plug-in connected to Artifactory, discovered the container image tags, and created them as versions in UrbanCode Deploy.

Add a Process to the Container Image Components

A process must be added to the container image component in order for these components to perform a Helm upgrade. The Helm upgrade will be used to change which version (tag) of the container image is used by the release. In my simple example, my process only uses one step (Helm Upgrade), however you may want to add steps to configure Helm for reliability.

In this example. I’m providing my Helm release (as a property), my Helm chart (as a property), and two flags. Let’s take a look at the first flag:

--set image.tag=${p:version.name}

The –set flag is used to override a value found in your charts values.yaml file. I determined that image.tag was the property to override by looking at my chart’s values.yaml file:

I saw that image.tag was the property in values.yaml I wanted to override. This value may be different for you. You may also want to use an UrbanCode Deploy property for this value for ease of use going forward (this would make the process generic and would allow you to use a component template).

Finally, ${p:version.name} means we are going to set this property to the version name of our component, which will be an image tag.

The next flag is:

--reuse-values

This tells Helm to leave all other values as is.

Setting up the Application in UrbanCode Deploy

In UrbanCode Deploy, create an application. Add the component that represents your Helm chart and the container image components to the application.

Build an application process.

Above is an example of an application process. The first step installs the Helm chart component. My component process for the Helm chart component downloads the chart from the component version artifact into a specific directory. The process then checks to see if the Helm release already exists. If the release does not exist, the chart is installed. If the release does exist, an upgrade is performed. See this page for an example process.

Next, my process installs the container image component. In my example, I only have one container image, so I install it directly. If you have multiple container image components, you may use the Install Multiple Components step to install all components with the kubernetes.image tag, for example. This step runs the process we created earlier for the container image component. The end result is a helm upgrade command is run to ensure the Helm release uses the image tag specified in the UrbanCode Deploy user interface.

Conclusion

UrbanCode Deploy is now setup to allow users to change which tag (version) of their container image is used in a Helm deployment without requiring the user to update YAML files or manually run Helm commands.

In the example above, version 2.0.0 of my Helm chart is deployed. The release includes a container named ucds, and the tag for that container image is 7.0.0.0.981343c-x86_64. If I want to change the tag of the container image used in my release, I could simply run another deployment, choosing which image tag to use in the UrbanCode Deploy user interface.

Good luck with your Helm deployments!

The Cloud Foundry plugin provides the ability to automatically discover a Cloud Foundry installation on an agent, and subsequently provision the environment in UrbanCode Deploy. The plugin’s auto-configuration step will create resources for each organization and space found in a using the cf CLI tool. This post will discuss the process for allowing your Cloud Foundry topology to be automatically configured using UrbanCode Deploy.

• Role Permissions in UrbanCode Deploy
• Properties for Auto-Discovery
• Utilizing the Resource Tree

Role Permissions in UrbanCode Deploy

Before you get started, there are a few required permissions that we must make sure are set on the UC Auto Discovery and UC Auto Configure roles in UCD. These two roles are meant to be used for auto-discovery and auto-configuration. However, in certain versions of UrbanCode Deploy you must add the ‘Manage Properties’ permission for resources.

You can ensure that this permission is set on both roles from the Settings -> Role Configuration page in UrbanCode Deploy. After you have navigated to the role configurations, select the UCD Auto Configure role. Next, click to the Resource selection and expand the Edit permissions for standard resources.

Ensure that the Manage Properties field is checked on the Resource.

After you’ve validated the permission settings for the UC Auto Configure role, repeat the process for the UC Auto Discovery role.

Properties for Auto-Discovery

cf.commandPath

The auto-discovery task will search through multiple directories for the ‘cf’ executable. If the file is located, a new ‘CloudFoundryController’ resource will be created under the agent resource. The process can utilize a few different options to discover the Cloud Foundry executable. These options are listed in order of precedence, meaning that if the first option is being utilized, all others will be ignored:

1. You may set the ‘cf.commandPath’ property on the agent. This property is an absolute path to the Cloud Foundry executable file on the agent machine.
2. You may otherwise set the ‘cf.home’ property on the agent. This is the path to the directory where your Cloud Foundry executable exists on the agent machine.
3. If none of the above options are configured, the auto-discovery process will pick up the ‘CFHOME’ environment variable from the agent machine.
4. After exhausting all of the above options, the auto-discovery task will search a few common installation directories listed below.

If the ‘cf.commandPath’ field, the ‘cf.home’ field, and the ‘CF_HOME’ environment variable are all not set the discovery task will search through a few common installation directories.

If the agent is a Windows machine, it will recursively search:

• C:\Program Files\CloudFoundry
• C:\Program Files (x86)\CloudFoundry

If the agent is a Linux/Mac machine, the auto-discovery task will search:

• /opt/CloudFoundry/cf
• /usr/share/CloudFoundry/cf

These are just the most common installation locations, and hence the default search locations. It is very possible that the Cloud Foundry executable may be in a different location on the file system. In this case, you must use one of the other options described earlier.

cf.api

By default the auto-discovery process will execute the ‘cf api’ command using the found cf executable. Using the output from this command, the cf.api property will also be set as your Cloud Foundry API endpoint. However, to retrieve the API endpoint from the ‘cf api’ command output, you need to have already successfully logged into Cloud Foundry on your agent machine. A successful login generates the ‘config.json’ file in your user’s home directory, which holds the name of your API endpoint.

If you have not yet successfully logged into Cloud Foundry on your agent machine, you will need to set the cf.api property.

You have two separate ways to set the cf.api property:

1. You may set the ‘cf.api’ property at the agent level before auto-discovery executes.
• This option will create the cf.api property on the CloudFoundryController when auto-discovery executes successfully.
• You must remember to set the cf.api property on the agent as an agent property before running auto-discovery.


Configure the cf.api property on the agent before running auto-discovery.

2. You may also set the cf.api property on the CloudFoundryController after auto-discovery has completed.
• Using this option, you will allow auto-discovery to execute without a predefined cf.api property on the agent, and then update the property on the generated CloudFoundryController resource.


Setting the cf.api property on the CloudFoundryController resource after auto-discovery.

Running Auto-Discovery

Once properties are configured to actually run auto-discovery, executing the task is fairly simple. In the ‘Resources’ tab on UrbanCode Deploy create a new or use an existing top level resource group, and then add your Cloud Foundry agent to that group. Assuming the Cloud Foundry plugin is installed, this will kick off the auto-discovery process, which you can view under the History tab of your agent resource.

After the auto-discovery process completes successfully you will have a new resource with the role ‘CloudFoundryController’ under your agent resource.

The newly created CloudFoundryController resource listed with your api endpoint.

Running Auto-Configuration

After successfully running auto-discovery, you may now use the CloudFoundryController resource created to run auto-configuration. This process will replicate your Cloud Foundry topology as a resource tree in UrbanCode Deploy. To access all of your Cloud Foundry domains and spaces you will need to provide your username and password.

To configure the CloudFoundryController resource, click the edit resource button and you will be able to fill out the required properties to execute auto-configuration.

Configuring the CloudFoundryController resource for auto-configuration.

You’ll notice that the Cloud Foundry API Endpoint and Cloud Foundry Executable properties have already been configured. These properties were set during the auto-discovery process. If either of these properties have not been configured, please re-read the Properties for Auto-Discovery section.

Auto-configuration generates all of the organizations, spaces, and applications as resources under the CloudFoundryController.

Utilizing The Resource Tree

The auto-discovery and auto-configuration processes generate the resource tree in UCD including your controller and all organizations, spaces, and applications in your Cloud Foundry installation. Each resource that is created is assigned a resource role that specifies which properties are assigned to that resource.

Here are all of the resource roles created and the names of each role property defined on them:

• CloudFoundryController:

Property Name	Description
cf.api	The url of the Cloud Foundry API endpoint.
cf.commandPath	The path to the directory where the cf command line executable resides.
cf.username	The Cloud Foundry username.
cf.api	The Cloud Foundry password.

• CloudFoundryOrganization:

Property Name	Description
cf.org	The name of the Cloud Foundry organization.

• CloudFoundrySpace:

Property Name	Description
cf.space	The name of the Cloud Foundry space.

• CloudFoundryApp:

Property Name	Description
cf.app	The name of the Cloud Foundry application.

The resources are defined in a hierarchical structure, which determines the properties that each resource has access to. For instance, the CloudFoundryApp resource has access to every property in the list. Components that are added to the resource tree may reference the properties of resources above it.



The ‘CF’ component has been added to the ‘JeffPHPApp’ CloudFoundryApp resource.

You can now define a component process and utilize all of the resource properties in the hierarchy. The syntax to reference resource properties in UCD is ‘${p:resource/propName}’. The property will be resolved if it is found during runtime.



A new component process defined on the ‘CF’ component has access to all resource properties in the hierarchy.