In the last post on this topic I discussed a technique of separating your configuration from your code in CloudForms’ Automation Engine. The technique relied on creating class overrides in a higher priority domain, enabling attributes on those higher priority classes to be passed down.
It works but it’s…clunky, and it requires a duplicate of every class in a higher domain. Not the most scalable technique!
Below I present two other methods – one that uses $evm.instance_get, and another that loads the config directly onto the root object.
Read more “Configuration domains in CloudForms/ManageIQ – part deux”
The CloudForms/ManageIQ automation engine gives us great power to create classes and methods that we can execute in response to various actions (e.g. button presses, events in the environment, REST API calls, etc).
Using Ruby and Ansible we can execute custom code to customise and enhance the CloudForms experience for our customers and users – we can add buttons to interfaces, override provisioning workflows, override approval workflows…etc.
Normally, we’ll have at least two environments – a Quality Assurance environment, and a Production environment. We don’t want those two to mix, and quite often key settings will be different between the two environments. For example, the FQDNs and credentials used to access remote services (e.g. Single Sign On, corporate DNS, etc) may differ between QA and Production. But the underlying logic in the code remains the same – it’s just environment-specific configuration that changes.
To get to a full Continuous Integration/Continuous Deployment model we need to be able to promote Automate code between environments cleanly. Having to execute find/replace across our automate code to replace QA settings with Production settings is not clean.
So how do we keep our common automation logic from intermixing with ou environment-specific settings and configuration?
The answer is a configuration domain. Read more “Configuration Domains with CloudForms/ManageIQ”
State Machines are a powerful feature of CloudForms automation. If you are unfamiliar with the concept, a state machine in the context of CloudForms automation is a series of steps that are executed sequentially by the Automation Engine.
In particular, state machines give us:
- The ability to retry steps if they fail.
- Jump between steps by name, or skip the immediately following step.
- Exceute code on enter or exit of a step, or if the step returns an error.
- Store state variables in earlier steps that can be referenced in later steps.
- Since CloudForms 4.6, we now have the ability to execute Ansible playbooks as steps in a state machine.
State machines are already used heavily for the provisioning workflows that ship with CloudForms out-of-the-box. If you’d like to know more about creating state machines, have a look at Mastering Automation in CloudForms and Manage IQ, available here on the customer portal.
State machines are undoubtedly powerful – when they work start to finish.
What happens if a state machine fails before it’s complete?
Read more “Building resilient state machines with CloudForms/ManageIQ”
Over the last couple of days I’ve been working on a simple, no-frills HTTPS server for Python that supports WSGI applications and – most importantly for my use case – handles mutual TLS support.
I needed to perform mutual TLS to verify client certificates for a work project. I know that I can simply place a reverse proxy such as Apache or Nginx in front of my python application and have it handle the mutual TLS, but why can’t I have a Python server to do that for me? It turns out that’s it’s not as hard as I first anticipated.
Read more “Mutual TLS with Python, Flask and Werkzeug”