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. 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 brokeriib_server
for setting up the IIB server (execution group)iib_deployment
for deploying mediationsiib_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