Wildcard idea: Introduce "apps"

[ivanvanderbyl]

After thinking about the higher level use-cases we have, and reading about some of the other solutions in this space, something I found in Mesosphere's Marathon is the concept of "Apps". I think a couple of ideas here could be useful for composing what we deploy.

I brought up the idea of adding extra details to a deployment in an earlier issue to apply the router config and health checks. The awkward part is having to handle those details on each deploy. So adding Apps would allow us to describe the deployment of a service, initiate a first deploy, and allow future deployments with minimal configuration.

Here's an example of an app payload:

POST /apps

{
  "app": {
    "id": "my-app",
    "namespace": "/mycompany",
    "image": "ivanvanderbyl/tomster",
    "instances": 3,
    "version": "version1",
    "network": "BRIDGE",
    "cpu": 1.5,
    "memory": 256,
    "cmd": "bundle exec rails server",
    "port_mappings": [
      {
        "container_port": 3000,
        "host_port": 0,
        "protocol": "TCP"
      }
    ],
    "health_checks": [
      {
        "protocol": "HTTP",
        "path": "/health",
        "grace_period_seconds": 3,
        "interval_seconds": 10,
        "port_index": 0,
        "timeout_seconds": 10,
        "max_consecutive_failures": 3
      }
    ],
    "dependencies": [
      "/mycompany/postgres",
      "/mycompany/redis"
    ],
    "conflicts": ["/mycompany/*"],
    "upstream": "Host('example.com') && Path('/')"
  }
}

This would use CoreOS to schedule the deployment of 3 instances. It would set up the necessary routes in the router in use. In this example I used the routing language of Vulcan, however this could easily be translated to Nginx or HA, as the route parser is a standalone library.

health_checks

Health checks could be implemented as a plugin, and read this configuration from etcd. It would probably make sense to implement this as a sidekick process.

dependencies

Describes the services which must be running to support this app, which controls restart order, and bring up a whole stack in order. If /my-app depends on /postgres, then the launch order will be /postgres, then /my-app.

The other use case of dependencies would be for creating the networking fabric in flannel to associate all these services.

conflicts

Essentially sets the conflict option in fleet service when launching.

upstream

Describes the routing logic to send public traffic to this app.

Future deployments could the be as simple as:

POST /apps/my-app/deployments

{
  "deploy": {
    "version": "version2",
    "instances": 5
  }
}