Deployment workgroup

Introduction

Let's list ideas to make deployment more solid and simple.

Built-in SSH server in wotaskd

One of the most common mistakes in deployment is problems related to permissions. The default permissions on the startup script of the app make it so that only the owner of the file can run it, so either you need to change the owner of the file when you install the app, or you need to change the permissions. By running a SSH server inside wotaskd and people use that server to upload the application, the application's files will be owned by the user who runs wotaskd, so the file permissions goes away.

The other advantage is since it's running under the same user as wotaskd, if someone get access, it will only be able to view or modify files that the user have access too.

Jenkins plugin

This is somewhat related to the built-in SSH server. We need an easier way to deploy applications from Jenkins. I wrote a Perl script to do so, but you need to install four Perl modules to use it, and those four modules have dependencies, and it goes on and on. We need a real Jenkins plugin for deployment that will do the following:

• Define a list of wotaskd destinations, including the path to where the application will be stored, the port (defaults to 1085) and the hostname.
• Three options: « deploy after a succesful build » (useful for staging servers), « deploy at this specific time » or « manual deployment ».
• Send the application by SSH, by connecting to the built-in SSH server. You could define to which wotaskd destinations you want to send the application to.
• Use the REST APIs in wotaskd to add the application if it's not already in wotaskd's configuration.
• Use the REST APIs to restart the instance. You will have two options: « bounce » or « normal ».

When you deploy the application, it would follow the common convention that many people uses: the new version will be stored with a unique name, and the symbolic link that points to the current version of the app will be modified so that it points to new version.

Monitoring and adjustements

To show that WO can scale, we need something that can monitor the systems and applications and act if something goes bad. For example, by using JMX if the monitoring tool see that the app is using 95% of its heap space for more than 10 minutes, it could decide to start another instance by contacting the REST APIs in wotaskd to add the new instance. If the host's CPU usage is more than 95% (per core/CPU) for 15 minutes and you are on Amazon EC2 or Linode, it could start another VM so that it can handle the load.

Simple deployment service

I think we need a "no hassle" deployment service, à la Heroku or Google App Engine. That service would be useful for people who only wants to deploy one or two apps and don't want to bother with managing a OS X or Linux box. We could use OpenVZ on Linux or FreeBSD Jails to do isolation between users.