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.
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:
Configuration plans are run routinely, and Otter would run the above plan in the following manner:
HOSTSfile and collect the value of the
$WebsitesRootvariable, which could be a Runtime or Configuration variable whether set on the role, server, Environment, etc
web.configfile, and collect the value of the
Pipelinevalues of the
Bidingvalues of the
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 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: