This is the documentation of the release 2.1 of automaIT. The documentation of the latest stable release can be found at AUTOMAIT.

Skip to end of metadata
Go to start of metadata


In a nutshell, automaIT is NovaTec's solution to the area of provisioning and data center automation.

Provisioning means deploying software and configurations throughout different servers and keeping them in a working state. Since today's server landscapes have typically grown over a longer period of time and have reached great diversity in operating systems and versions, provisioning is getting more and more difficult. As can be imagined easily, performing the same operation on different operating systems can be complicated and is typically done manually by a single administrator. automaIT offers an alternative to this by performing independent actions on different servers and protocoling the actions performed. It does not try to be an out of the box solution to all problems but can be adjusted to suit each individual system landscape perfectly, since it has a high degree of genericness.

The obvious advantages of this method include:

  • transparency of actions
  • saving of time
  • movement of knowledge from a single point of failure (the system administrator) to a centralized system
  • possibility to re-obtain knowledge (e.g. by succeeding administrators)
  • reproducibility of all actions performed


The following figure shows the basic architecture of automaIT. It consists of a server that is the system's controlling instance and is able to communicate with many agents (one instance of the agent software is run on each machine in the data center) and several clients the server can be controlled with, which currently include a command line interface (CLI) and a web interface.

automait basic architecture


automaIT consists of different kinds of elements, which can be called from within the web interface or the command line interface. Elements are, for example:

A host is one of the system's execution targets, which is reachable from the automaIT server and can be operated using CLI or web interface.
To ensure the host can be accessed by the server, it is necessary that the automaIT agent is running on it. A host can be one of two different kinds, as can be seen in the table below.

host kinddescription

A physical host represents one physical machine in the managed system which can function as a remote agent and/or gateway.

virtualA virtual host is used for logical grouping. Multiple virtual hosts can reference a single physical host.

Using these different kinds and functions, hosts can be structured hierarchically. In such a hierarchy, virtual hosts are only capable of having other virtual hosts as child nodes, while physical hosts can have both virtual and physical nodes. Each physical host can be acting as remote agent, gateway, or both. The fact that virtual hosts are used for logical grouping means that multiple virtual hosts can be attached to a single physical host.
Each host can have one of several host types that can each contain different variable sets. After choosing a host type, each variable is assigned a specific default value but can be adjusted individually.

A sample hierarchy is shown in the figure below. It features most of the host relationships and functions explained above.

host hierarchy example

A component is comparable to a class in object-orientated programming. It contains, for example:

Components can be software artifacts of great variety, for example, a Database, a Database Instance, Database Contents or a Database Management System.

To install a component on specific hosts, one of the component's constructors needs to be chosen as well as the set of hosts on which it shall be installed. The server then executes this constructor, which runs an install routine on the chosen hosts.
These constructors can be influenced by the variables stored in the component. For example, there could be a variable "installPath", telling the component which directory it should be installed to.
After the execution of the constructor, an instance of the chosen component is installed on the host and the control methods of this instance can now be executed on it. Uninstalls can be used to destroy the instance.

Inside all of the aforementioned methods, control structures can be used comparable to those used in programming languages.

At the moment, the control structures, that can be used, include "if" and "try" statements.


component example

This is a sample component for a Database Management System, represented in typical UML syntax. As usual, variables and methods are visually separated from each other. While the install and uninstall methods are constructors and destructors, the rest of the methods are control methods.

A plan contains a sequence of statements, which are executed one after another. Such statements include, amongst others, installing a component, executing a component's control method or uninstalling a component. To ensure the execution works as intended, the same control structures that are used in component control methods can be used to manage the plan's execution flow.
If necessary, plans can be used to execute commands ("ExecNatives") on the target system, though doing so is more common in component methods. Plans provide the ability to simplify provisioning of a chain of dependant applications in the right order.


A plug-in can be seen as a container. It can contain, for example:

  • components
  • plans
  • host types

A plug-in provides the possibility to import all its content into a running system at once. That way it combines all data that belongs together into one bundle.

plugin example

This plug-in contains several components, e.g. the DBMS component introduced earlier, as well as a plan that can be used for component installation.

Each action performed in the system is logged as a job. This form of protocoling grants the ability to trace performed actions and grants easy access to the information, which plan or method was executed on which systems.
The fact that you have access to the different versions of your plans and components at all times makes sure those actions are repeatable.



One of automaIT's advantages is the fact that all different versions of plans, components and plug-ins are stored in the system. No old version is ever deleted, so previous versions can be accessed at any time.

Overview of element relationships

automaIT overview

  • No labels