Introducing the IBM information Bus Puppet modules.

Introducing the IBM information Bus Puppet modules. In May we announced the general availability of our IBM modules. In our blog post from the 30st of may we already introduced the MQ modules. In this blog post we will introduce the IBM Information Bus modules iib_install and iib_config.

Do your own exploring.

What is an introduction without something to try and something to explore? That is why we created this example for you. You can use these examples in a vagrant environment without the need for licenses.

Get the examples

We have created a git repository that contains the example. In there we show you how to use best our modules. We are going to use this repository.

Go to your preferred working directory and enter:

$ git clone git@github.com:enterprisemodules/simple_iib_demo.git

This will create a local copy for you to work and experiment on.

The tools of trade

This example is designed, so you run on your own Workstation running Vagrant and VirtualBox. So to get started, you’ll need Vagrant and VirtualBox. You can find the information on how to install VirtualBox here at the VirtualBox website. Vagrant To install Vagrant, go to the vagrant downloads page, and download the package for your platform. Then install it using standard procedures for your operating system. Because we only use Puppet inside the virtual machine, you don’t need to install Puppet on our workstation.

Required software

The examples repository doesn’t contain the IBM software needed to get the nodes running. You’ll need to contact your IBM representative to get the software. Remember that this is licensed software and you can only use it if you are licensed. In the README, you can find a list of the software needed when you want to run the box.

Masterless Puppet

Most of our clients use Puppet Enterprise, and of course, our modules work with the newest version of Puppet Enterprise. But to focus on the IBM Information Bus installation and configuration, this example contains a Puppet masterless setup. A setup you can easily run on any PC or laptop.

All set….go!!!

Before we dive in and explain some things, let’s first get our IIB machine up and running.

$ vagrant up ml-iib01

This will start Vagrant, create a virtual machine and start Puppet. This is how it should look.

The roles and profiles

This demo uses the Puppet design pattern “roles and profiles.” Look here if you want more information about this design pattern. In simple terms, it means every node has a single role, and that role defines what the system’s role in the infrastructure is. In our example, we are going to provision the system iib01, and its role will be role::iib. You can see the definition of this role here. Here is part of its content:

  ...
  contain ::profile::base
  contain ::profile::installiib
  contain ::profile::iib::example
  ...

These three statements tell Puppet how to configure the system. Step 1: make sure the system gets its base profile (profile::base) E.g., all the settings you have defined for all of the systems in this environment. Then make sure the IIB software is installed (profile::installiib). When this is done we apply an example IIB configuration (`profile::iib::example’)

The installation of IIB

In the profile::installiib class, the actual installation is defined. Here we call the iib_install module to do its magic.

...
iib_install::installiib {$version:
    source_location => $source_location,
    version         => $version,
  }
...

We provide the source location and the version. Because the iib_install modules supports multiple concurrent versions of IIB, we also use the version number in the title of the resource.

Besides installing the software, we also have to create an instance. An instance is a combination of a specific IIB install path and a specidic OS user. Here is the code:

...
iib_instance { $version:
    ensure         => 'present',
    os_user        => 'iibadmin',
    home_directory => "/opt/IBM/iib-${version}",
  }
...

With this mechanism, you can define multiple combinations of versions and os users to start your IIB brokers

Configuring your IIB setup

When it comes to Enterprise Middleware, Installation is where most Puppet modules stop. But we think the configuration of your middleware setup is just as important if not more important. So our iib_config module allows you to customize your entire IIB setup. It has support for:

  • iib_broker for setting up the IIB broker
  • iib_server for setting up the IIB server (execution group)
  • iib_deployment for deploying mediations
  • iib_property for setting any property you wish on any resource

In the example repo, all the IIB configuration is done in the file profile/manifest/example/iib/setup.pp. Let’s look at some content.

The broker

Here is the Puppet code that defines the broker:

...
  iib_broker { "${version}/IIB10NODE":
    ensure                       => 'present',
    status                       => 'running',
    function_level               => 'all',
    http_listener_start_listener => false,
  }
...

In the title, you see the ${version} back. This is the definition of the iib_instance we saw before when we were installing the software. With this construction, you can not only configure multiple brokers on a single IIB version but also configure multiple brokers on multiple IIB versions.

The server

After the definition of the broker, we define the IIB server or execution group. Here is the Puppet code for this:

...
  iib_server { "${version}/IIB10NODE/default":
    ensure => 'present',
    status => 'running',
  }
...

Just like in the definition of the broker, we see the ${version} again. All titles for IIB resources are defined like that. With this notation, it is easy to uniquely address every resource.

IIB is a very comprehensive software package. You can define an awfull lot for an IIB server. Here are some of the properties you can define on a server:

Attribute Name Short Description
callable_flow_manager_redeploy_message_timeout This property allows you to manage CallableFlowManager redeployMessageTimeout of iib_server in an IBM IIB realm.
callable_flow_manager_remote_retry_timeout This property allows you to manage remoteRetryTimeout of CallableFlowManager iib_server in an IBM IIB realm.
callable_flow_manager_retry_local_during_deploy This property allows you to manage CallableFlowManager retryLocalDuringDeploy of iib_server in an IBM IIB realm.
execution_group_trace_filter This property allows you to manage ExecutionGroup traceFilter of iib_server in an IBM IIB realm.
execution_group_trace_level This property allows you to manage ExecutionGroup traceLevel of iib_server in an IBM IIB trace.
execution_group_user_trace_filter This property allows you to manage ExecutionGroup userTraceFilter of iib_server in an IBM IIB trace.
http_connector_connection_timeout This property allows you to manage HTTPConnector connectionTimeout of iib_server in an IBM IIB realm.
http_connector_cors_allow_credentials This property allows you to manage HTTPConnector corsAllowCredentials of iib_server in an IBM IIB realm.
http_connector_enable_lookups This property allows you to manage HTTPConnector enableLookups of iib_server in an IBM IIB realm.
http_connector_max_http_header_size This property allows you to manage HTTPConnector maxHttpHeaderSize of iib_server in an IBM IIB realm.
http_connector_no_compression_user_agents This property allows you to manage HTTPConnector noCompressionUserAgents of iib_server in an IBM IIB realm.
http_connector_port This property allows you to manage HTTPConnector port of iib_server in an IBM IIB realm.
http_connector_timeout This property allows you to manage HTTPConnector connectionTimeout of iib_server in an IBM IIB realm.
https_connector_compressable_mime_types This property allows you to manage HTTPSConnector compressableMimeTypes of iib_server in an IBM IIB realm.
https_connector_cors_allow_methods This property allows you to manage HTTPSConnector corsAllowMethods of iib_server in an IBM IIB realm.
https_connector_keypass This property allows you to manage HTTPSConnector keypass of iib_server in an IBM IIB realm.
https_connector_max_posts_size This property allows you to manage HTTPSConnector maxPostSize of iib_server in an IBM IIB realm.
https_connector_restricted_user_area This property allows you to manage HTTPSConnector restrictedUserAgents of iib_server in an IBM IIB realm.
https_connector_server_name This property allows you to manage HTTPSConnector serverName of iib_server in an IBM IIB realm.
https_connector_timeout This property allows you to manage HTTPSConnector connectionTimeout of iib_server in an IBM IIB realm.

The deployment

After the server has been defined, we can add deployments to it. In the example repo, we use the standard HelloProject.Testmode.bar to do this. Here is the Puppet code.

...
  iib_deployment {"${version}/IIB10NODE/default/Hello":
    ensure => 'present',
    source => '/tmp/Helloproject.TestMode.bar',
  }
...

This code will make sure the bar file is deployed and running.

Introspection

Not a lot of people know (or use) this, but puppet allows introspection of the current configuration. All of our config modules support the puppet introspection. You can ask puppet what brokers are defined on a system and what their properties are. Let’s log into the Vagrant box and ask puppet what queues are available:

$ vagrant ssh ml-iib01                                      # ssh into the Vagrant box as vagrant
[vagrant@iib01 ~]$ sudo -i                                # Log in as root user
[root@iib01 ~]# puppet resource mq_queue # Ask for all mq_queues

Using this feature, you can inspect your current IIB configuration and save it in the form of a puppet manifest.

Conclusion

We hope this article helps you to get a glimpse of what you can do with Puppet and IIB. There is a lot more though. If you are interested, contact us so we can discuss how you can use these puppet modules to speed up your IBM messaging software provisioning and deployment. If you want to start in your own infrastructure, take a look at our FREE IIB starter pack