The scenario

Your environment starts very uniform and consistent. Your environment starts very uniform and consistent.

You have a large environment of servers that you need to manage through some form of a transformation initiative. This isn’t going to be simple you’re told; it’s laborious and complex they say. Each server has been setup individually and manually, like an artisan dairy farmer churning his butter at dawn.

These servers were setup based on a design specifications borne from soliciting requirements during countless meetings and conference calls.

Is Brent on the call? Brent? Ah, he is probably on mute.

The servers were documented in artefacts that we now know as “Run Books”, with their respective software versions and configurations painstakingly foretold. Embedded in these documents was an art form known as screenshots, to capture the system builders handy work for posterity.

Initially the documents matched the configured ComputePowerHouse perfectly. However, through the passing of time and a few hundred ITIL approved change requests and incident responses, these servers have been updated and reconfigured, undoubtedly at the hands of the butter churner. The server configuration has drifted from its idyllic initial state.

A few people on your team are familiar with the environment and have an imperfect but reasonable understanding of the current state of the servers. The servers are part of a cloud migration initiative and the applications they support are planned to be migrated to the Cloud.

The problem

Your environment changes, naturally. Your environment changes, naturally.

You need to refresh your configuration information for your servers in order to complete the project, as a first step. This will build a detailed and dynamic server inventory, which together with an application inventory will give you a solid starting position for transformation.

Depending on your transformation approach and the technology you discover in step one, you may also need to change the configuration of these servers prior to application migrations. This is difficult because of how heterogenous your snowflakes servers have become. Each one is potentially different in someway or another.

This second step, pre-migration remediation, is critical to identify and execute early on in your project. Pain awaits those who skip it, and the type of pain includes longer timelines, increased stress on the team, outages and gasp back-out decisions.

An example of a pre-migration remediation task is removing Windows NLB services.

Because of the nature of the environment, one possible solution is to have a team of people who are close to the environment, work through each server and perform the required remediation steps manually. This brute-force approach can work and get the job done, but depending on your environment and team size, the timeframe can quickly become unaffordable.

The solution

Tidal Migrations integrates directly with Ansible Tower. Tidal Migrations integrates directly with Ansible Tower.

Use purpose built software, specifically for cloud migrations, to automate the server and application inventory creation, then leverage this inventory in an automation workflow engine.

Tidal Migrations gives you a platform for your inventory data, while Ansible Tower makes automation a breeze. Users are able to easily collect information, manage servers and execute transformation initiatives with the kind of authority and power that butter-churners long for.

As your systems change, you can use this solution to automatically track these changes and keep your team up to date via the built in Slack integration. These dynamic inventories become our source of truth and point of convergence for our team. Ansible Tower allows us to manage our Ansible playbooks, manage workflows and even control team member’s permissions around execution.

Let’s get started

Start your engines and get your team moving forward. Start your engines and get your team moving forward.

  1. Sign up for a free 30 day trial of Tidal Migrations and begin collecting and organizing your systems. You can do this with Tidal tools by scanning your network and collecting IPs. You can also import them directly with spreadsheets.
  2. Setup your Ansible Tower server. To get started right away you can also try AWX, the upstream open source version that Ansible Tower is based on.
  3. Configure the Tidal Inventory Script for Ansible Tower and automatically import your server inventory from Tidal Migrations to Ansible Tower.
  4. Write an Ansible playbook to execute the necessary steps to update your configuration. Remember it is always recommended to write your playbooks so they are idempotent. Doing this from the beginning will improve your workflow and avoid potential future issues.
  5. Create a project in Ansible Tower and add your playbook.
  6. Create a job template and execute it!
  7. Download the standard output from the playbook execution for any reporting needed.