Self Service VM Provisioning with Morpheus, Part 2: Morpheus Level-Setting and Planning Out the Automation

In Part 1, I got dark and existential about VM Self Service, and we talked about how some relevant features of Morpheus might provide a reprieve from this.

If you have been reading my blog, you should be aware by now that I am a process-oriented kind of blogger. So, here in Part 2 I am going to walk you through how to plan for VM Self Service within the context of Morpheus. I know some of you are probably like, “Hey man, just get to the making of all the things!”

If that’s you, I guess I will see you for Part 3 where we actually do just that. But for those of you who want to see the process involved with making real automation, then this should set the stage for the ensuing Part 3.

For the record I meant to do this in 2 parts. I don’t usually do “Part 3’s” but, you’ll thank me later, because even Tolstoy would have said I went on too long.

The Usual Disclaimer Section

1. As usual I do not make any claims that what I do here is the only and/or best way of doing it; nor do I make any “fanboi” claims that Morpheus (or any product for that matter) will solve all of your problems. Morpheus has its shortcomings (as does every product). We certainly have our own set of feature requests pending. . . . OK, one.
2. For this project, I am responsible for Windows VM creation through vSphere (and here you thought I was only a VMware/Linux person hmmmmm?), therefore this will be vSphere and Windows-focused. You can probably fill in the blanks though on the Public Cloud/Linux side.

The Overall Gist

The best way I can describe how Morpheus works, in “Bryan” terms, is that it’s a hierarchical, granular, modular, integrated, and “pipelined” (loaded term!) approach that allows you to manage the full life cycle of a VM from a centralized dashboard and API . . . you know, the way things are done in more . . . “cloudy” . . . environments, if you know what I mean. But we’re doing this straight on top of bread-and-butter on-prem vSphere in this case.

But, what if you already have a lot of this all automated, or in a series of scripts? Well, instead of building the automation or scripts from scratch in Morpheus (which you can do), you can augment/integrate your existing automation into the product workflow with a limited touch (possibly zero!) approach.

What I have found, is that whatever you are doing, as long as it can be run as a Script or REST API call, or integration with existing automation platforms, it’s a simple matter of making those things. You specify when the scripts/calls run and then let Morpheus worry about running them. It’s an automation orchestrator, if you want to call it that.

Morpheus does both Governance and Analytics as well, but those are not our main focus since we do that through other means. Those features are not detailed here; I am focusing on automated VM creation and lifecycle management.

. . . Hey there again Morpheus marketing department. How you doin’?

First Things First: Whiteboard the Workflow

Ask yourself, “how do we do our rollouts now?” and therefore, “how do we manage a VM from the cradle to the grave?” Without a platform like Morpheus, the VM is an island unto itself. With Morpheus we shepherd it along through its lifetime. And we get to know everything about it.

The first thing I would recommend doing is spelling out exactly what needs to happen, step by step. Maybe that starts with how it’s done manually. What’s the workflow and what needs to happen at each step? Will it be an API call to a CMDB? Is it a Powershell or Python Script that sets up user accounts? An Ansible playbook? Spell it out the best you can because you will need to apply this to the various object types in Morpheus. This should all come together later.

We’ll be talking about a very simple workflow here, as a case study:

1. In Morpheus (or ServiceNow), the user will indicate:
   1. User account(s) that will be granted admin access to the Windows machine.
   2. Choose a T-Shirt size for their VM.
2. VM is created from a Morpheus-managed vSphere Template (same process as if it’s done manually, just done by a robot).
3. The Morpheus Agent gets installed on the VM.
4. VM/OS gets a regex-generated hostname with a numeric suffix incremented by 1 with each instance.
5. VM/OS gets an IP address automatically from a Morpheus IP Pool.
6. Once all of the above is in place, the server gets added into the AD domain.
7. The Windows VM is added into SCCM/SCOM (or other for OS-layer management).
8. Provision/Post Provision Scripts that run on the machine (runs using a Morpheus Service account):
   1. Set Timezone (runs as a powershell script during provisioning).
   1. Specified user account is added in as a local Admin of the machine.
   2. Email is sent to user account that their machine is ready and indicates hostname and IP Address.
9. The VMs data is entered into a CMDB Automatically using a REST API call.
10. TearDown Script: Teardown script that will delete the user from the group(s) needed for local access runs just before the VM is deleted.

What is an “Instance” and Why Does it Matter?

The most important Morpheus object I will be talking about is an “Instance”. Simply put, an “Instance” is a Morpheus-manageable entity, that under the hood is just a vSphere VM. This should sound familiar to you if you’ve dealt with more cloudy environs that shall not be named.

In order to build instances, you need to build an “Instance Type” which will kick off the workflow you create (as above).

So, side note, why not just automate the entire process using other tools?

Well, are you making a Private Cloud with “kewl-kid cloudy thingz” or not? With what we are doing here, you get stuff like, oh, I don’t know . . .

1. A more cloud-like experience on-prem for app owners and devs.
2. All-in-one Lifecycle Management of the VM, including graceful decomm.
3. Self Service through ServiceNow.
4. An API for possible CI/CD features and abilities.
5. Multi/Hybrid Cloud future planning.
6. Application-layer management.
7. Possibly treating your VMs as cattle for all of the above.

Some Vocabulary

Let’s get some vocabulary down. Morpheus has a hierarchy of objects. Most of these definitions are taken from Morpheus’ official documentation for their product version 4.1.1:

1. Tenant – An isolated environment with unique users and workloads. The Master Tenant is the default Tenant in Morpheus, created upon installation. All other Tenants outside of the Master Tenants are Subtenants.
2. Cloud – Integrations or connections to public, private, hybrid clouds, or bare metal servers. We are using their vSphere Cloud integration.
3. Virtual Image – In this case, we are talking about the vSphere VM Template Morpheus knows about.
4. Network – The Network object consists of three things:
   1. The Network associated with the Instance (in this case, the portgroup in vCenter).
   2. The IP Pool, which specifies the list of IPs to be automatically assigned to each Instance.
   3. The Domain – This is for adding the Instance into the Domain.
5. Library – The Library contains Most of the components you will need to create in order to build an Instance Type.
6. Scripts – Run at a particular phase of the workflow, such as “Provision”, “Post Provision”, or “Teardown”. Specifying these would be the “big person pants” way of running a series of scripts.
7. Layouts – Specifies additional steps as part of the workflow, including the Node Type.
8. Node Types – Can additionally specify steps along the way, but also will specify the Template to use (Virtual Image).
9. Morpheus Agent – Use of the Morpheus agent is optional, but this provides for coordination of the initial automation, but also unleashes a bevy of other features, such as more life-cycle adjacent approaches.

Now that we have somewhat of a foundation of the building blocks for Morpheus, in Part 3, we’ll go through how to actually create the Self Service automation.

Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.