Tech Tip

General Tips for Containers

Print

UrbanCode Deploy GitHub Repository of Templates and Examples

IBM maintains a GitHub repository that contains Application, Component, and Process templates for IBM UrbanCode Deploy. It also includes sample artifacts used in tutorials. The GitHub repository may be found here, while you may find Docker related artifacts here and Kubernetes related artifacts here.

Working with Kubernetes Config (kubeconfig) Files

From the Kubernetes doc:

Use kubeconfig files to organize information about clusters, users, namespaces, and authentication mechanisms. The kubectl command-line tool uses kubeconfig files to find the information it needs to choose a cluster and communicate with the API server of a cluster.

The Kubernetes plug-in for IBM UrbanCode Deploy contains several steps for with kubeconfig files. For example, the Use Context step may be used to set the current-context value of a kubeconfig file. See the plug-in’s documentation page for more information.

By default, Kubernetes uses the file specified by the $KUBECONFIG environment variable (if the environment variable has not been set, the /.kube/config file is used). Once an IBM UrbanCode Deploy agent starts, it does not detect changes to system environment variables. For example, if $KUBECONFIG is set to file1 when the IBM UrbanCode Deploy agent starts, then $KUBECONFIG is changed to file2, the IBM UrbanCode Deploy agent will still reference file1 when running kubectl commands. In order to change which kubeconfig file IBM UrbanCode Deploy is working with, process steps must be altered. For example, most Kubernetes steps contain a Global Flags property (under Show Hidden Properties). A flag may be added in the format:

--kubeconfig=[file]

Helm steps contain a Kube Config File property (under Show Hidden Properties) which may be set to your kubeconfig file so the kubeconfig file will be used when running helm commands (helm commands will use the current-context of this file by default).

Working with Multiple Versions of Helm

There are two pieces to Helm. One is the Helm client, which should be installed on your IBM UrbanCode Deploy agent machine. The second part is the Helm server, called Tiller . Tiller is installed on each Kubernetes cluster which uses Helm.

You may run into conflicts if your Helm client is at a newer version than the Tiller instance you are connecting to. To avoid these conflicts, you may run the Helm Init step from the Kubernetes plug-in for IBM UrbanCode Deploy with the value

--upgrade

added to the Flags field. Alternatively, you may install different versions of the Helm client onto your agent machine and specify which version of Helm to user in your assorted Helm steps. The Helm steps found in the Kubernetes plug-in for IBM UrbanCode Deploy have a helm Path field (under Show Hidden Properties) which may be used to specify which Helm client will execute the step’s commands.

Extending the Sample Kubernetes Application Templates

The Enhance your Kubernetes Experience with UrbanCode Deploy and Kubernetes Blue-Green Deployments Working Example tutorials use an example UrbanCode Deploy application template. The application template includes a resource template (the blue-green application template includes two resource templates). The Kubernetes Resource Template found in both sample applications looks like this:

The Agent Prototype in the resource template has a child component tag. Any agent that is added to the same group as the agent prototype will have the child component tag added to it.

Let’s say you extend the application to include a database which resides on a different machine than your Kubernetes client. An UrbanCode Deploy agent is installed on this machine. You now want to add this new agent your UrbanCode Deploy application. If you added the agent to the same group as the agent prototype, the new agent will have the child component tag added to it:

This is undesirable, as the Deploy from YAML file application process will attempt to deploy Kubernetes components from the database agent.

To avoid this, ensure any additional agents are added to a different group than your agent prototype. For example: