Extended Procfile Roadmap

Step 1 - Pull ELB creation into scheduler/ecs.Scheduler Done

Right now, attaching load balancers to ECS services is done as a decorator/middleware around the ecs.ProcessManger interface. A better approach would be to remove the ProcessManager interface and inject an lb.Manager into ecs.Scheduler. If someone wishes to use the ecs scheduler without the creation of load balancers, a null lb.Manager implementation can be injected.

The primary benefit to doing this is that we can remove some uncessary and confusing layers of abstraction (ProcessManager).

Step 2 - Move port allocation into scheduler/ecs Done

Currently, there are 2 problems with port allocation:

1. We allocate a port per app instead of per process.
2. The allocation is done within Empire core, where it's really an implementation detail of the ecs backend. There may come a day when we no longer need to allocate ports.

We should move port allocation into scheduler/ecs so that ports are allocated for ECS services as needed. The Ports, Exposure, LoadBalancer and SSLCert attributes on the scheduler.Process will be replaced by a single Exposure attribute, which will allow consumers to declaritively define the processes exposure settings as "http", "https", "tcp", etc.

Step 3 - Assign addition CNAME's with the process name Done

Right now, we CNAME the elb using the app name. If there are multiple "web" processes per app, we'll need to add additional CNAME's.

One possibility would be to assign the top level ".empire" CNAME to the "web" process, as well as other CNAME's with the process type. For example, if I had the Procfile:

web: ./bin/web
api: ./bin/api

Then I'd get 3 CNAMEs:

<app>.empire
<app>-web.empire
<app>-api.empire

Step 4 - Refactor how we define process exposure Done

Currently, it only supports HTTP/HTTPS. We also want to be able to define TCP.

Step 5 - Refactor how we store process configuration and extracted Procfile Done

Currently, process configuration (desired count, constraints, etc) are stored in a processes table. With an extended Procfile, we'll need to store more information (e.g. health check configurations, exposure settings, etc). It may be better to define an application manifest and store it as a document instead.

Some work has already been done to move towards this in https://github.com/remind101/empire/pull/696

Step 6 - Implement the new extended Procfile format Done

Once the steps above are complete, accepting a new Procfile format should be extremely easy/straightforward.

Example

web:
  command: ./bin/web
  # For processes named "web". Should this just be the default?
  expose:
    type: http
    external: true
    check:
      path: /health
      healthy_threshold: 2
      unhealthy_threshold: 10
grpc:
  command: ./bin/grpc
  expose:
    type: tcp
    check:
      healthy_threshold: 2
      unhealthy_threshold: 10