Otter Documentation

Plans in Otter

Plans are a key component of Otter's automation, and are used to direct the Execution Engine. They provide an easy-to-understand, visual representation of configuration and orchestration while also being the "code" behind your Infrastructure as Code.

From simple, single server configurations to complex orchestrations spanning 1000's of system critical servers, plans help bring visibility to the entire development and operations teams, not just those fluent in scripting.

There are two types of plans:

The main difference between these types of plans is the context in which they are used. Both type of plans are created and edited in the same manner. Either in the drag-and-drop Visual Mode, or in Text Mode using OtterScript -- and they both essentially describe a series of steps (i.e. Operations) that could be executed on servers.

Plans are made up of a series of Statements and Blocks. Blocks group statements and other blocks together and are run by the execution engine in the order you specify. There is full parity between the Visual and Text modes, and you can switch back-and-forth anytime for maximum flexibility when creating elaborate configurations.

For example, here's a General Block with several statements that declare the desired state of configuration for an "Accounts" application server.

  • Visual Mode
  • Text Mode (OtterScript)
An IIS Plan Block (Visual Mode)
An IIS Plan Block (Text Mode)

Configuration Plans

Configuration plans collect the actual configuration of a server as it relates to your plan. For example, if the above block were placed in a configuration plan for a server (or on one of the server's server roles), then that server's configuration would look like this:

An IIS Plan Collected Configuration

Configuration plans are run routinely, and Otter would run the above plan in the following manner:

  1. Read the HOSTS file and collect the value of the accounts.local entry
  2. Resolve the $WebsitesRoot variable, which could be a Runtime or Configuration variable whether set on the role, server, Environment, etc
  3. Read the web.config file, and collect the value of the ConnectionString entry
  4. Read the Runtime and Pipeline values of the AccountsAppPool
  5. Read the AppPool, Path, Protocol, and Biding values of the Accounts site
  6. Store the collected configuration in the database
  7. Compare the collected configuration against the declared configuration
  8. If there is configuration drift, and the server is configured to automatically remediate drift:
    • Create or update the actual configuration based on the plan
    • Store the new configuration in the database

Real-world Configuration

Of course, the idea of automatic change is not exactly palatable to many organizations, which is why servers do not automatically remediate configuration drift unless you have explicitly configured them to do so. By default, you will instead remediate drift through a scheduled or on-demand Job. You can even Simulate the execution, just to see exactly what would happen.

Also, the real world rarely works declaratively, and configuration plans often need a mix of declarative statements (like ensure a file is in a specific location) and imperative or procedural operations (like starting or stopping a service).

Otter bridges the gap between the “real” and “ideal” worlds. Otter allows for the modeling of grand infrastructure plans across multiple platforms and 1000s of servers, while maintaining the granular control to define a single change on one server. Common configurations can be stored using a Template and used over and over for easily scalable infrastructure.

Orchestration Plans

Orchestration plans are quite a bit simpler: they just use the same, advanced execution engine to execute operations and scripts on servers. Unlike configuration plans, orchestration plans don't run continuously. Instead, you scheduled them to run (either in the future, or on a recurring basis) using an Orchestration Job.

This simplicity also makes them hard to describe in detail, because they can be used to do just about anything:

  • Installing patches or other changes to 1000’s of servers
  • Spinning up and configuring multiple virtual servers
  • Execute existing scripts in a controlled and visible manner
  • Provisioning bare-metal hardware
  • Deploying ProGet packages