GuidesUpdated July 3, 2026

ODB Server Automation with AWX

guidesodbdatabaseautomationansibleawxplaybooksjob-templatesinventoryschedulingepic

ODB Server Automation

Overview

The ODB automation in Ansible was created to automate as many of the initial manual configuration needs as possible for the ODB servers. This relieves the ODBAs for more meaningful work and makes best use of their expertise. AWX provides an excellent platform to manage and view the output of these jobs.

Resources

The ODB to AWX automation consists of multiple repos and resources.

Ansible
1. Ansible ODB playbook located at odb_playbook
2. Ansible utilities repo
3. Ansible base-os repo
4. Ansible odb_role repo
AWX (managed in the Issue-Tracker repo)
1. Job-Template
2. Inventory
3. Groups
4. Hosts
5. Schedule

Instructions for maintaining the AWX resources can be found here

Structure

The end to end automation can be split into 4 logically separated segments, each with their own Ansible primary tags available:

Tag	Description	Role Repo
linux	This portion establishes linux baseline os requirements	base-os role
preinstall	Downloads dependencies and prepares files and folders for install	odb role
install	Installs all primary software for ODB operations	odb role
postinstall	Confirms success of all previous steps	odb role

Segment Details

linux

The linux tag/stage performs all tasks within the base-os repo here

This step is run on every daily run as well as during a full new build. Steps including but not limited to:

Configure DNS
Manage dependencies
Configure timing sync
Join the domain
SSH hardening
Maintain list of sudoers
Add cron users
Establish the filesystem and mount data drives
Setup swap drive
Configure firewall
Configure Auditd
Configure Journald

All variables currently used are in the default location within the repo here. For any variable needing to be changed, they can be passed in at the appropriate level within the AWX configuration in the Issue-Tracker repo. Details in the Variables section.

preinstall

The preinstall tag/stage lays the groundwork for the ultimate installation of the ODB software. It is the first of three task sections in the odb role repo here.

This step is run on every daily run as well as during a full new build. Steps including but not limited to:

Set and maintain main ODB users
Create the build directory to stage packages for install
Download software from Artifactory
Download specific certs from Artifactory
Run a checkperm function to correct any ODB specific permission changes

See the variables section below for detailed information about variable maintenance.

install

Next, the install tag/stage handles the full installation of the Epic ODB and Iris DB software located in the odb role repo here.

This step is only run during a full installation on a newly built server. Steps included:

Install Iris instances
Instantiate database
Start the Iris DB
Run instaserver script
Various steps installing components, running specific Epic scripts and setting permissions for install and use
Server install

See the variables section below for detailed information about variable maintenance.

postinstall

The last tag/stage is the postinstall stage. This runs a few checks and validations to ensure key elements completed successfully and is located in the odb role repo here.

This step is only run during a full installation on a newly built server. Steps included:

Check for directories and their state
ESMP status
Validate ODB logging
Check Iris memory info
Gather and display metrics
Ensure Redalert service running
Check basic OS info like users, timezone, etc
Ensure services are up
Run Iris qlist

See the variables section below for detailed information about variable maintenance.

Variables

Variables needed for these deployments are stored within AWX. They are managed by the Issue-Tracker repo. All variables are organized at the inventory, group, and host levels. See the chart below for details. Variables trickle down to the host as needed. Variables in the ODB inventory apply to every host under that inventory. Similarly, variables in each group are inherited by the groups and hosts under them. For example, variables for zwplodbew801.ms.ds.uhc.com come from the ODB inventory, the odb_prod_westus3 group, the prod_ecp group, and the host-specific variables under its own variable block.

ODB - Inventory
- odb_prod_westus3 - group region level
  - Groups
  - Hosts
  - prod_communitylead (group)
    - zwplodbcl501.ms.ds.uhc.com
  - prod_ecp (group)
    - zwplodbew801.ms.ds.uhc.com
    - zwplodbew802.ms.ds.uhc.com
    - zwplodbew803.ms.ds.uhc.com
    - zwplodbew804.ms.ds.uhc.com
    - zwplodbew805.ms.ds.uhc.com
  - prod_primary_west (group)
    - zwplodbew501.ms.ds.uhc.com
  - prodsupport_communitylead (group)
    - zwplodbcl301.ms.ds.uhc.com
    - zwplodbcl302.ms.ds.uhc.com
    - zwplodbcl303.ms.ds.uhc.com
    - zwplodbcl304.ms.ds.uhc.com
    - zwplodbcl305.ms.ds.uhc.com
  - prodsupport_primary_west (group)
    - zwplodbew301.ms.ds.uhc.com
    - zwplodbew302.ms.ds.uhc.com
    - zwplodbew303.ms.ds.uhc.com
    - zwplodbew304.ms.ds.uhc.com
    - zwplodbew305.ms.ds.uhc.com
  - rpt_west (group)
    - zwplodbew401.ms.ds.uhc.com
- odb_prod_centralus - group region level
  - Groups
  - Hosts
  - dr_communitylead (group)
    - zcrlodbcl601.ms.ds.uhc.com
  - dr_prod_ecp (group)
    - zcrlodbew851.ms.ds.uhc.com
    - zcrlodbew852.ms.ds.uhc.com
    - zcrlodbew853.ms.ds.uhc.com
    - zcrlodbew854.ms.ds.uhc.com
    - zcrlodbew855.ms.ds.uhc.com
  - dr_west (group)
    - zcrlodbew601.ms.ds.uhc.com

Usage

Apply Against a Brand New ODB Server

Follow these steps when a full, end to end install is needed on a brand new ODB server.

If your new server is entirely new and not a rebuild of an existing ODB server, you will need to add the new host in AWX following the instructions here. If your machine is a rebuild, continue with step 2.
Login to AWX.
Click Templates in the column on the left under Resources and then click on the ODB daily run Job Template.
Click Launch.
You will need the ODB Inventory which is pre-selected for you. Click Next.
For the rare occasion when you want to specify an Instance Group, this option is available. Leaving it blank will let the default apply for the VM you are targeting. Click Next.

On the Other Prompts page you have several options to choose from:

Name	Function	Options
Job Type	Ansible can run a deploy or run in check mode which will give an idea of what changes will be made	Run, Check
Limit	BE CAREFUL HERE This field will specifically target instances to run on. Leaving it blank will run the automation against every VM in your selected Inventory.	Any host, list of hosts, group, or list of groups within your chosen inventory, separated by colons (:). For example: `host1:host2:group1`
Verbosity	Set level of verbosity for potential troubleshooting	0-5
Job Tags	Tags entered here says "Only do the tasks captured by these tags, nothing else"	Many to choose from including the primary tags listed above and ways to subdivide such as linux:fs only running the fs file within the os role
Skip Tags	Opposite logic of Job Tags above "Do all tasks except these"	same as Job Tags

Click Next on the Other prompts page after you have very carefully reviewed your selections.
Review all selections on the Preview page very carefully again to be certain that only the tasks you want to run are selected and only the VMs you wish to apply against are targeted. Click Launch when you've confirmed all settings and your job will begin.

Nightly Scheduled ODB Config Enforcement

This scheduled job ensures that baseline configuration is maintained.

All details for the scope of the nightly run is managed in the Schedule.

The schedule is managed via code in the Issue-Tracker repo. Here is where the details are maintained such as the:

Frequency
Limit
Job Tags
Skip Tags

The schedule is limited to the hosts selected to have this automation regularly applied, set to an agreed upon time of day, and has install and postinstall as skipped tags. The remaining tasks enable the base configuration that is intended to be maintained.

In the code snippet below is an example of the yaml code for this ODB schedule.

---
awx_schedule_list:
  - name: odb_daily_prod_config
    inventory: ODB
    limit: zwplodbew301.ms.ds.uhc.com:zwplodbcl301.ms.ds.uhc.com
    enabled: true
    description: This scheduled job runs the "ODB daily run" template daily against prod ODB servers.
    credentials:
      - epicans1
      - "Hashicorp Vault Token - eoavault"
    instance_groups:
      - central
      - west
    unified_job_template: ODB daily run
    rrule: "{{ query('awx.awx.schedule_rrule', 'day', every=1, start_date='2025-07-22 04:00:00', timezone='UTC') }}"
    skip_tags: "install,postinstall"