Shared memory between container - docker-compose

Product support
,
1

I am trying to share memory between two containers by making container A’s memory shareable and allowing container B to access it.

This works outside of balena if I start the containers individually and use the following commands.

docker run --privileged --network host --ipc:shareable containerA
docker run --privileged --network host --ipc:container:<id_of_containerA> containerB

However, when I now try to start this with the following docker-compose.yml in a Balena application, container B does not start and only gives the status “downloaded”.

version: '2'
volumes:
    resin-data:
services:
  containerA:
    restart: always
    build: ./containerA_dir
    network_mode: host
    ipc: "shareable"
    privileged: true

  containerB:
    restart: always
    build: ./containerB_dir
    network_mode: host
    ipc: "service:containerA"
    privileged: true

The documentation of balena directs me to the one of docker for the “ipc” flag, which says that the docker-compose should be working the same way as the regular docker commands.

The only difference between the two commands and the docker-compose would be the “service:containername” part which I think needs to be done, since I don’t know the container ID in advance.

Do you have any ideas what this could be or where I should look?

4

Hi there - looking at the docs (Docker run reference | Docker Documentation), it seems you should be able to use ipc: "container:containerA" in your docker compose for containerB. Where does it say that you must use the container id only, or have to substitute container to service?

Alternatively, does ipc: "host" satisfy your use case?

6

Hi @eike, did you have a chance to read my colleague’s message? Have you tried ipc: "host" or the other method?

Let us know how it went. If you are still having troubles, it’d be good to check the device logs to look for the root cause.

8

Yes the ipc: "host" satisfy the needs for now. It would only be nice with the specified container to gain some control over the container. We will test it and report back.

But thank you for your help

10

While ipc: host is a work-around, it would still be good for security purposes, to support the shareable IPC model. Currently, setting ipc: service:<<name>> fails to start a container with (HTTP code 500) server error - Invalid IPC mode: service:gpsd error:

[error]   Scheduling another update attempt in 1000ms due to failure:  Error: Failed to apply state transition steps. (HTTP code 500) server error - Invalid IPC mode: service:gpsd  Steps:["start"]
[error]         at /usr/src/app/dist/app.js:16:12744
[error]       at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
[error]   Device state apply error Error: Failed to apply state transition steps. (HTTP code 500) server error - Invalid IPC mode: service:gpsd  Steps:["start"]
[error]         at /usr/src/app/dist/app.js:16:12744
[error]       at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
[info]    Applying target state
[event]   Event: Service start {"service":{"appId":..

Using ipc: container:<<name>> is not an option, since this name is dynamic.

Also, balena service ls is not a valid command for the engine, which makes me think this is by design/not supported and the docs should be updated to reflect that.

Fr reference, the redacted compose file for reproduction(s):

services:
  gpsd:
    image: alpine:3
    entrypoint:
    - /bin/sh
    - -c
    command:
    - |
      sleep infinity
    ipc: "shareable"

  ntpd:
    image: alpine:3
    entrypoint:
    - /bin/sh
    - -c
    command:
    - |
      sleep infinity
    ipc: "service:gpsd"