0

We have a bunch of micro services running each in its own Docker container in a shared AWS EC2 instance. Giving the excellent results obtained when running locally now we are trying to use Chronicle queues as a way to communicate between our micro services in AWS.

MS1 receives an API request does some internal processing and emits an event to CH2 Chronicle queue. MS2 is listening to CH2 chronicle queue and when an events arrives in there it picks it up does some internal processing and emits an event to CH3 Chronicle queue.

API --> MS1 --> CH2 --> MS2 --> CH3 --> ...

Inside each container we have /tmp/my_app_data an application root folder and a subfolder for each Chronicle queue that micro service interacts with. For example in MS1 container we have /tmp/my_app_data/ch2 and inside MS2 container we have /tmp/my_app_data/ch2 and /tmp/my_app_data/ch3

All these folders are mapped to the EC2 host machine under a similar structure:

/tmp/my_app_data
    |_ch2
    |_ch3
    |_...

Now when trying to run our system we encountered all kind of issues to accessing data which was written by one micro service intended for the next one in the work flow. In the above example the further we could get was to have MS2 read data from ch2 that was sent thee by MS1 but we still could not mark the data as processed which means MS2 writing into files under the ch2 folder.

I cannot list the full set of permutations we have tried even trying to hack file permissions inside the containers and on the EC2 host; it seems I am missing some basic setup specific to Docker/AWS.

This is our Docker configuration from MS1 Dockerfile:

 RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
 RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
 USER nobody
 VOLUME ["/tmp/my_app_data"]

Similar we have the same ur Docker configuration from MS1 Dockerfile:

 RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
 RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
 RUN mkdir -p /tmp/my_app_data/ch3 && chown nobody:nobody /tmp/my_app_data/ch3
 USER nobody
 VOLUME ["/tmp/my_app_data"]

And on the AWS side part of both MS1 and MS2 tasks definitions we have:

    "mountPoints": [
      {
        "readOnly": null,
        "containerPath": "/tmp/my_app_data",
        "sourceVolume": "chronicle"
      }
    ],
    ....
    "volumes": [
      {
        "fsxWindowsFileServerVolumeConfiguration": null,
        "efsVolumeConfiguration": null,
        "name": "chronicle",
        "host": {
          "sourcePath": "/tmp/my_app_data"
         },
        "dockerVolumeConfiguration": null
      }
    ]

So here is my question: What I am doing wrong and how could I fix it? Ideally for us this should work when running as user nobody but because this is a POC I would be thankful to get it running anyway, including root. For us the purpose of this POC is to confirm whether we get the same good results with Chronicle in the cloud as we got when running locally.

Thank you in advance for your inputs.

Julian
  • 3,678
  • 7
  • 40
  • 72
  • Could you use a different queueing solution (RabbitMQ is a popular open-source option) that doesn't depend on shared files? – David Maze Aug 24 '21 at 22:17
  • Yes I could and we already created POCs with solace and IBM MQ and is quite performant too. However Chronicle has an advantage that does nor require any infrastructure setup other than a jar in the class path. This said no decision taken to go away from Kafka as yet. – Julian Aug 24 '21 at 22:57
  • I am trying to wrap my head around this and I am wondering if the problem is with trying to bind mount the same folder in different tasks. It looks like for a [single task you are doing the right thing](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bind-mounts.html). – mreferre Aug 25 '21 at 07:23
  • Having that said, have you considered using EFS in your design to host your queue files? I see a few advantages: it allows to decouple the ephemerality of EC2 from the persistence of a queue, it allows to use more than 1 EC2 (for HA and scale in case it's needed) and it also can bypass completed the POSIX mess by just assigning r/w permissions through IAM to the EC2 via task roles. If you want to dive deeper on this have a look at part 1 and part 2 of [this blog series](https://aws.amazon.com/blogs/containers/developers-guide-to-using-amazon-efs-with-amazon-ecs-and-aws-fargate-part-1/) – mreferre Aug 25 '21 at 07:27
  • EFS was the very first thing I tried. Unfortunately Chronicle-queue open source does not support moving data between different hosts. It works just fine as long as all the data is moved on the same hard disk without involving any networking. Looks like for this you need chronicle-queue-enterprise, all good for us, just for a POC I wanted to make it work on a single EC2 – Julian Aug 25 '21 at 09:30

1 Answers1

0

How to set up Chronicle Queue to work with Docker is documented in Chronicle FAQ. You need to ensure that:

  • containers share IPC namespace (run with --ipc="host")

  • queues are mounted on bind-mounted folders from the host (i.e. -v /host/dir/1/:/container/dir)

Dmitry Pisklov
  • 1,196
  • 1
  • 6
  • 16