Onboarding duplicated template VMs to Otter

[jimbobmcgee]

I am trying to determine a way whereby new VMs are automatically made available as deployment targets in Otter. They do not have to be assigned to envrionments yet -- this can be done later -- it's just the onboarding that I want to start with.

For the purposes of this question, assume that there are a significant number of VMs to create. There is a template VM, which has the Inedo agent installed. VMs will be created by copying the template in (for example) the ESXi shell and registered using vim-cmd. I won't know the IPs of the created VMs until after they have first booted and DHCP has assigned them.

The InedoAgent.config is only going to have a single encryption key (the one in the template), and outbound Connection defined to a central Otter server.

If I am reading the documentation correctly, in order for an outbound connection to be made by Inedo Agent, the outbound connection must know both the hostname (of the Otter server) and a key. The key however, must be generated on the Otter server and manually pasted into the InedoAgent.config file, and it must be unique for each individual agent instance.

It cannot be correct that I need to generate objects in Otter, just so Otter can generate a key for each of them, just so I can then manually provision the agent on each VM, so each VM can connect to Otter.

At any significant scale, I'd need an orchestration system to provision Otter, so I can use Otter as an orchestration system.

Although I can run rudimentary python scripts from the ESXi shell, even if I conconcted a script to call out to the Otter API and have it create the server object, provision the agent and retrieve the key (I've not tried this yet), I can't then get that key into the InedoAgent.config file.

Is there a better way?

[atripp]

Hi @jimbobmcgee ,

The "Secret key" field is just an arbitrary string that needs to match on both the Agent and the Otter Server; it needs to be unique across your servers, as its used to uniquely identify an incoming agent connection. The UI generates a random string, but you can enter whatever you'd like.

There needs to be a Server record on the Otter server (i.e. on the "Servers" page) before an agent can connect to Otter. This is true for either Incoming or Outgoing communication modes. This is often called "server registration".

One option is to servers self-register in Incoming mode; you can have the the following script on first boot:

1. Generate a random string ("secret key"); you could use a GUID
2. use the Infrastructure API from the server to "register" the server using that key
3. edit the agent configuration file to have that key
4. start the Inedo agent service

Hope that helps,
Alana