XtremeCloud 3M Pak for OpenMRS
Xtremecloud Migration, Modernization, and Maintenance (3M) Pak.
The XtremeCloud 3M Pak for OpenMRS is a set of Ansible Playbooks hosted in Ansible AWX, the upstream open source fork of Red Hat Ansible Tower, that facilitates a smooth migration of an on-premise OpenMRS to a Cloud Service Provider such as Amazon Web Services (AWS) and Oracle Cloud.
In addition to the generally-available Ansible collections for AWS and Oracle Cloud, this 3M Pak includes Ansible Playbooks specific to an OpenMRS migration to the cloud. With our secret sauce added to the Ansible Playbooks, our customers experience migration automation that has captured decades of Oracle EBS experience, and underlying Oracle technologies experience, that will simplify and accelerate the cloud migration effort.
You cannot bring up modernization in today’s IT landscape without talking about Kubernetes. Eupraxia Labs does not bring up Kubernetes or dive head first into the technology without a broader automation strategy. Kubernetes can’t manage your entire application lifecycle, nor can it bootstrap itself. You cannot settle for automating the inside of a Kubernetes cluster while using manual processes to build and manage your cluster. This becomes increasingly difficult as you manage more than one cluster. Multiple clusters are certainly a best practice for many environments. For instance DevOps, Staging, and Production clusters, or possibly a private internal cluster and a public facing cluster.
We consider Kubernetes clusters to be essential for any effort to modernize as a cloud migration occurs. Of course, Kubernetes clusters do not just appear out of thin air. They must be provisioned, configured, and maintained. With the XtremeCloud 3M Pak for Oracle E-Business Suite, we take care of that heavy lifting. You can provision Kubernetes clusters through a Cloud Service Provider’s (CSP) managed offering (e.g. Marketplace) or you can use our Kubespray Ansible Playbook for your own self-managed Kubernetes cluster.
One important facet of modernizing an IT landscape is to move the on-premise Identity and Access Management (IAM) solution to a cloud-native solution that is easier to deploy and maintain.
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
Oracle E-Business Suite (EBS) is in use by thousands of customers worldwide today. Many of those customers have implemented single sign-on (SSO) to ensure a smooth user experience. The most common use case is to deliver a transparent sign-on experience from the user’s desktop through to EBS. The traditional, certified approach for achieving this is through the deployment and integration with Oracle Access Manager (OAM) and either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as depicted below.
While this approach is well understood and documented, it introduces a number of additional components and additional complexity to an EBS deployment. For SSO you need to deploy Access Manager, a Directory, a WebGate, an AccessGate, and configure each to integrate with EBS. All of these additional components need to be cared for, nurtured, patched, and updated. It’s a lot of work and prone to misconfigurations. For some customers, this additional complexity has led to delayed SSO implementations, resulting in a poor delivery experience.
However, we provide a simpler option available which will still enable that streamlined user experience you require, without the need to deploy and manage all of the above components, and without the need to make significant configuration changes within EBS, such as configuring the integration with OID or OUD.
Our cloud-native XtremeCloud Single Sign-On (SSO) is Eupraxia Labs’ multi-cloud Credentialing, Identity, and Access Management (CIAM) platform, which now enables SSO to a standard installation of EBS through its EBS Connector. The figure below shows this simplified integration.
Source Code Management (SCM) Best Practices
Playbook Repository Structure
It is recommended that the playbook repository structure follow a certain layout. You must create a structure that works with both Ansible Core and Ansible AWX/Tower. Here is an example of a repository structure:
Davids-MacBook-Pro:eds-ansible davidjbrewer$ ansible-galaxy init role_name --offline - Role role_name was created successfully Davids-MacBook-Pro:eds-ansible davidjbrewer$ tree role_name/ role_name/ ├── README.md ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml ├── templates ├── tests │ ├── inventory │ └── test.yml └── vars └── main.yml 8 directories, 8 files
Some notes regarding this layout:
ansible.cfg is at the root of the repository. It allows you to keep version control on the basic Ansible settings. groupvars defines the group variables for the playbooks The inventory is best managed within Ansible AWX/Tower.
A best practice is to have a playbook repository structure by team. For example, Infrastructure, App_1, App_2, Patching. In this example, there are no roles in the repository /roles directory. A best practice is to separate “roles” into its own repository so they can version controlled, shared and life cycle independently of other playbooks.
Use and Create Roles
Roles are a way of automatically loading specific vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows for easy sharing with other users. Here are a couple best practices around roles:
A repository should be created by each role. This allows you to share an individual role with Ansible Galaxy or with other Playbook repositories inside your organization. You should be able to perform unit testing in each role in a Continuous Integration (CI) model. A convenient way to test roles is by using containers. This will allow you to test the role across multiple distributions. Virtual machines (VM) are recommended to test roles when the role is performing low level actions like bootloader setting, kernel parameters, firewall settings, etc..
Use the ansible-galaxy command to create the role structure:
ansible-galaxy init role_name --offline
A .gitignore file should be used to ignore every role inside a playbook repository and allow them to be managed individually with a SCM.