Docker Compose - missing "runner" config?

[alvin]

Great project! This week I was very excited to discover ServerlessWorkflow and am planning to utilize the spec for the "Rules / Workers" side of my ambitious developer-friendly low-code framework.

Currently I'm also attempting to evaluate synapse as a near-term runtime for the compute/orchestration. After many hours of trial + error, digging thru the repo and configuring (did not find the other discussion on alpha config until I had figured out most of it myself 🤦‍♂️), I finally have most things running using the docker_compose.build.ymlsetup (The latest thing I had to sort out was copying + customizing the SYNAPSE_RUNTIME_DOCKER_SECRETS_DIRECTORY env var into the .build namespaced file out of the docker_compose.yml)

but now it's saying: No such image: ghcr.io/serverlessworkflow/synapse/runner:1.0.0-alpha2

An error occurred while creating a new Docker process for workflow instance '<workflow-namespace>': Docker.DotNet.DockerImageNotFoundException: Docker API responded with status code=NotFound, response={"message":"No such image: ghcr.io/serverlessworkflow/synapse/runner:1.0.0-alpha2"}

I can't see any runner image config's in deployments/docker-compose tree, although I do note this Dockerfile

Assuming that the runner should be expected to work via docker compose, would someone with more knowledge of the system internals be able to weigh in with some guidance for the docker_compose.build.yml lines for the runner?

[alvin]

Update - adding the following to docker_compose.build.yml gets a build of synapse runner to (apparently?) work:

  runner:
    build:
      context: ../../
      dockerfile: ./src/runner/Synapse.Runner/Dockerfile
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    user: root
    depends_on:
      - garnet
      - api

...and I have SYNAPSE_RUNNER_CONTAINER_PLATFORM: docker in my operator: section.

Now I'm digging for a way to "map" the container from ghcr.io/serverlessworkflow/synapse/runner:1.0.0-alpha2 to docker-compose-runner (via ENV var or ??) because the operator is still throwing the same error looking for the hosted/tagged version.

[cdavernas]

An error occurred while creating a new Docker process for workflow instance '': Docker.DotNet.DockerImageNotFoundException: Docker API responded with status code=NotFound, response={"message":"No such image: ghcr.io/serverlessworkflow/synapse/runner:1.0.0-alpha2"}

That is wierd: the image exists on this repo (see https://github.com/serverlessworkflow/synapse/pkgs/container/synapse%2Frunner) and we are able to successfully use it on different machines 👀 Can you try to pull the image manually to see if that solves your problem?

Update - adding the following to docker_compose.build.yml gets a build of synapse runner to (apparently?) work

You are absolutly right, I forgot to mention that one should build the runner image before attempting to use the docker-compose.build.yml. It should however not be added as a service: it will be spawned by the operator.

Now I'm digging for a way to "map" the container

You can do so by navigating to the dashboard (by default localhost:8080), authenticating using one of the tokens configured in the tokens file and going to the operators page, which is found under "services" menu item. Then, proceed to edit your operator, and set the image you want to use in spec.runtime.docker.containerTemplate.image.

You should by then be good to go: create a new workflow and start an instance using the UI or the CLI, and watch your operator startup a new instance.

On a side note, I know the doc is a bit rough for the time being (any help/suggestion welcome) but the wiki might give you some good pointers, especially (and not so obviously) the architecture section, which documents all environment variables that can be used to set you up 😉

I hope this helps!

---

PS: the container platform is not be be mistaken for the runtime. As a matter of fact, the former is the platform used by runners to spawn the containers configured by run.container tasks, whereas the latter defines how/where to spawn Synapse workflow runners.

By default, runners are spawned by the Docker runtime (alternatives are Native, which should only be used for test purposes, and Kubernetes), and by default runners use the Docker container platform (the only alternative is Kubernetes). Note that you while it is easier to configure matching runtime and container platform, you are free to use any combination of those.

[cdavernas]

Also, if you like the project, please don't hesitate to star it: it helps to improve its visibility and document its popularity 😉

[alvin]

Absolutely, I starred both repos!

I was able to pull the image manually, as you suggested... and now the operator does launch it, however being an x86 image it core-dumps rather than properly completing on my ARM machine:

I guess for me building the runner image locally is the way to go (all the other locally built images seem to run pretty well). I will dig thru the rest of the docs/ENV vars you pointed out (thanks for the link) to see if I can figure out how to get it to choose the locally built image.

BTW, the container does appear to do some things before dying:

2024-09-13 16:30:19 [23:30:19] info: Microsoft.Hosting.Lifetime[0]
2024-09-13 16:30:19 Application started. Press Ctrl+C to shut down.
2024-09-13 16:30:19 [23:30:19] info: Microsoft.Hosting.Lifetime[0]
2024-09-13 16:30:19 Hosting environment: Production
2024-09-13 16:30:19 [23:30:19] info: Microsoft.Hosting.Lifetime[0]
2024-09-13 16:30:19 Content root path: /app
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.LogicalHandler[100]
2024-09-13 16:30:20 Start processing HTTP request GET http://api:8080/.well-known/openid-configuration
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.ClientHandler[100]
2024-09-13 16:30:20 Sending HTTP request GET http://api:8080/.well-known/openid-configuration
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.ClientHandler[101]
2024-09-13 16:30:20 Received HTTP response headers after 153.7022ms - 200
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.LogicalHandler[101]
2024-09-13 16:30:20 End processing HTTP request after 230.119ms - 200
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.LogicalHandler[100]
2024-09-13 16:30:20 Start processing HTTP request GET http://api:8080/.well-known/openid-configuration/jwks
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.ClientHandler[100]
2024-09-13 16:30:20 Sending HTTP request GET http://api:8080/.well-known/openid-configuration/jwks
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.ClientHandler[101]
2024-09-13 16:30:20 Received HTTP response headers after 17.5363ms - 200
2024-09-13 16:30:20 [23:30:20] info: System.Net.Http.HttpClient.Default.LogicalHandler[101]
2024-09-13 16:30:20 End processing HTTP request after 18.1841ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.Default.LogicalHandler[100]
2024-09-13 16:30:21 Start processing HTTP request POST http://api:8080/connect/token
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.Default.ClientHandler[100]
2024-09-13 16:30:21 Sending HTTP request POST http://api:8080/connect/token
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.Default.ClientHandler[101]
2024-09-13 16:30:21 Received HTTP response headers after 28.1067ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.Default.LogicalHandler[101]
2024-09-13 16:30:21 End processing HTTP request after 28.7284ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.LogicalHandler[100]
2024-09-13 16:30:21 Start processing HTTP request GET http://api:8080/api/v1/workflow-instances/default/multiply-d43dae29d9bf
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.ClientHandler[100]
2024-09-13 16:30:21 Sending HTTP request GET http://api:8080/api/v1/workflow-instances/default/multiply-d43dae29d9bf
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.ClientHandler[101]
2024-09-13 16:30:21 Received HTTP response headers after 29.7421ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.LogicalHandler[101]
2024-09-13 16:30:21 End processing HTTP request after 30.2621ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.LogicalHandler[100]
2024-09-13 16:30:21 Start processing HTTP request GET http://api:8080/api/v1/workflows/default/multiply
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.ClientHandler[100]
2024-09-13 16:30:21 Sending HTTP request GET http://api:8080/api/v1/workflows/default/multiply
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.ClientHandler[101]
2024-09-13 16:30:21 Received HTTP response headers after 5.3674ms - 200
2024-09-13 16:30:21 [23:30:21] info: System.Net.Http.HttpClient.ISynapseApiClient.LogicalHandler[101]
2024-09-13 16:30:21 End processing HTTP request after 5.8683ms - 200
2024-09-13 16:30:21 qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[alvin]

Thank you for your help Charles - with a bit more wrangling here tonight I was able to get the local image compiled and running locally on MacOS ARM.

New question - has there been any consideration or discussion of runner processes available on standby (without spin-up time) for hot-path kinds of processing?

[cdavernas]

Happy to hear you got it working! I hope the software is to your liking!

New question - has there been any consideration or discussion of runner processes available on standby

Not until now, no, but that's a great idea!!! Would you be so kind to create a new feature request issue?
I'll tackle it as soon as I'm back from PTO!