-
Notifications
You must be signed in to change notification settings - Fork 10
Solution overview
The core service of Genesis is a server side application which responses for creating application environments, executing operations on them, destroying existing environments, tracking record of the user activities, provide information about existing environments and its status etc. The service provides REST API for the any type of external client interfaces. Right now Genesis has a web UI which is separated from the core service and communicates with it using the REST HTTP requests.
Environment templates are described using a domain-specific language which is specially designed for this case. The DSL is a subset of Groovy programming language and any valid Groovy code can also be a part of template. However acquaintance with Groovy is completely optional. Ready environment templates are stored in the source code repository. Genesis takes the templates directly from the SCM so a developer just need to commit templates in order to use them.
Each operation that can be performed with the environment are described as a number of steps. A step is a logically atomic unit of work. A good example of the step is provisioning of the several virtual machines with the same hardware configuration on the cloud. The other example is execution of a deployment script on a group of machines via the SSH. A description on how the particular step should be accomplished exists in the system in a form of plugin. New types of steps can be added to the system by creating additional plugins.
A set of steps is called a workflow in Genesis terminology. The execution of steps in a workflow are parallel by default but can be ordered. It is typical when a step needs a results of execution of another step in order to work. For instance a hardware provisioning step is usually a first step in a environment creation workflow. Then other steps use the provisioned machines as a target for the deployment. The notion of phase is used to set ordering between the steps. A step can be assigned to a phase of execution and it also can have a set of phases that should be finished before its execution.
The system supports several types of steps out of the box. There is a plugin that allows to provision VMs on both public and private clouds. Currently it supports OpenStack Compute private cloud as well as Amazon EC2 and GoGrid. The public clouds are famous for their instability so Genesis provides a reliable way to provision the VMs. A VM created on the cloud are checked if it is operational i.e. the OS is started and it is possible to log in on the machine via the SSH. If the VM is broken it will be destroyed and re-provisioned.
The other yet to be created type of hardware provisioning plugin can prepare a hardware machine using network boot. A plugin that can introduce any ready machine to the system is also in development plans.
The deployment part has its own subset of the plugins. There is a plugin that can register machine in Chef deployment tool and then execute an arbitrary Chef script on a group of a machines. The other Chef integration plugin allows to upload data which is declared directly in template on a Chef server in a form of databag. There is also a plugin to execute an arbitrary script using the SSH.
The additional types of plugins can include plugins to validate the component state using the monitoring interfaces like JMX, check the response of the HTTP request and so on. It is also fairly easy to create the plugins for integration with other deployment tools like Puppet. Or use other remote administration tool instead of SSH. Almost any unit of work can be encapsulated in a plugin and then used as a step.
During the workflow execution each notable event like step completion or step failure are logged into the database. This information is also reflected in a UI and user can easily check the state of the execution. It is also possible to suspend the ongoing execution or continue the failed workflow execution from the last successful step. The step plugins can also include logic to retry several times before the give-up in case of failure. This is especially useful in the unstable circumstances like the unreliable network connection or not perfect cloud provider.