Multi process machines

Machines now supports multiple processes within a VM. To use it, add processes to your machines config. processes has the structure:

"processes": [
  {
    "name": "web",
    "entrypoint": ["/bin/bash", "-c"],
    "cmd": ["some", "command"],
    "env": {
      "HELLO": "world"
    },
    "user": "flyio" // optional
  },
  {
    "name": "logger",
    "entrypoint": ["/bin/bash", "-c"],
    "cmd": ["some", "other", "command"],
    "env": {
      "WORLD": "hello"
    }
  },
  ...
]

An example config

{
  "config": {
    "image": "senyo/watagwan:latest",
    "processes": [
      {
        "name": "web",
        "entrypoint": ["/bin/bash"],
        "cmd": ["loop1.sh"],
        "env": {
          "PROC_ID": "1"
        }
      },
      {
        "name": "logger",
        "entrypoint": ["/bin/bash"],
        "cmd": ["loop2.sh"],
        "env": {
          "PROC_ID": "2"
        }
      }
    ],
    "env": {
      "VERSION": "1.2.3",
    },
    "services": [
      {
        "ports": [
          {
            "port": 443,
            "handlers": [
              "tls",
              "http"
            ]
          },
          {
            "port": 80,
            "handlers": [
              "http"
            ]
          }
        ],
        "protocol": "tcp",
        "internal_port": 8080
      }
    ]
  }
}

This is a first iteration to supporting the sidecar pattern where each process has its own image and can run in its own process namespace.

That’s all there is to it. Now, here’s what you need to know:

  1. As mentioned above, processes run within the same VM. This is different than the [processes] directive in an app config.
  2. When any of your processes exit/dies, the entire VM is shutdown.
  3. You can’t use a different image for each process (we’re working on this). Everything you need for each process to run must be contained within your docker image.
  4. Processes run in the same process namespace (we’re working on this too).
  5. Environment variables can be defined at a global scope and a process scope (see the env config option in the process definition).
    5.1. Each process will be spawned with the globally scoped environment variables and its process scoped environment variables. If the same environment variable is defined in at both scopes, the process scope wins.
    5.2. When you SSH into a running machine, only the globally scoped environment variables are in the environment.

Give it some mileage and let us know if you run into any issues or have questions.

7 Likes

This is great!

2 Questions:

  • I’m assuming I can limit the services section to a certain process similar to the fly.toml section
[[services]]
  processes = ["web"] # this service only applies to the web block
  • This also applies to the fly.toml processes section, but:

    Is there a way to start a process just using the default CMD defined in my Dockerfile? Quite often that is the “main” process and I might want to start auxiliary processes like background workers or logging processes with custom commands. The way it stands right now, I always have to maintain my CMD command in two places.

I tried omitting the cmd section in the JSON but I hit a 60 second timeout on the API with the following body:

{
	"error": "You hit a Fly API error with request ID: 01GGT5M0WGZVBBNYE424X8PBSS-fra"
}

service names

Previously (or…currently with “apps”, instead of “machines”), processes creates more than one VM.

In the setup with Machines, it’s one VM with multiple processes.

So the services section doesn’t make sense to be specific to a specific process as its essentially opening ports into one VM.

ENTRYPOINT + CMD

I’m not totally sure on that point yet - omitting the CMD is definitely what I would have tried also (or setting it to null).

I suspect the FLY API error was a coincidence but let me know if that seems to consistently timeout when you omit that.

Ah okay got it. Seems like I misunderstood the “apps” processes then. I’m currently using Overmind to manage multiple processes on one machine, but this seems like a nice replacement.

I think some kind of config for just running the container image “default” command as a named process would be really nice.

Gotcha! You may even want to keep using Overmind, depending on your needs. Multiple VM’s via processes (in apps) means more compute to pay for.

Machines lets you run multiple processes in one VM, which is why we’re calling it a “sidecar”

1 Like

Great question. cmd and entrypoint override the respective arguments in your Dockerfile. If you omit either of them, it will use the cmd and/or entrypoint set in the Dockerfile. In your case, you can omit both of them.

1 Like

I saw commits to flyctl for multi-proc the other week; and so, any examples for fly deploy / fly run / fly update? Also, does fly clone clone multi-procs just fine?

Btw, the forum could do with a new Machines tag / category?

Thanks.

The commits to flyctl for multi process machines was only to add configuration options. All flyctl commands regarding should work as per usual.

1 Like