sdr-enthusiasts / docker-readsb-protobuf

Multi-architecture readsb-protobuf container with support for RTLSDR, bladeRF and plutoSDR (x86_64, arm32v7, arm64v8)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

making readsbpb_rrd persistent

nick2k3 opened this issue · comments

Hello,
I am encountering some issues while trying to make the rrd volume persist between updates of the readsb-protobuf container.

At the moment I have the following docker composed deployed through portainer as a Stack:

version: '2.1'
volumes:
  readsbpb_rrd:
    driver: local
    driver_opts:
      type: none
      device: /docker_config/config/readsb/run/collectd
      o: bind
#  readsbpb_autogain:

services:
  readsb:
    image: mikenye/readsb-protobuf:latest
    tty: true
    container_name: readsb
    hostname: readsb
    devices:
      - "/dev/bus/usb:/dev/bus/usb"
    ports:
      - 8080:8080
    environment:
      - TZ="Europe/Rome"
      - READSB_DEVICE_TYPE=rtlsdr
      - READSB_RTLSDR_DEVICE=a1090
      - READSB_GAIN=autogain
      - READSB_LAT=y.yyyy
      - READSB_LON=x.xxxx
      - READSB_RX_LOCATION_ACCURACY=2
      - READSB_STATS_RANGE=true
      - READSB_NET_ENABLE=true
      - READSB_RTLSDR_PPM=0
      - FEEDER_ALT_FT=69
      - FEEDER_ALT_M=21
      - READSB_DCFILTER=true
    volumes:
      - /docker_config/config/readsb/run/autogain:/run/autogain
      - readsbpb_rrd:/run/collectd
    tmpfs:
      - /run/readsb
      - /var/log

This results into the following volume to be created.
Schermata 2021-11-19 alle 17 32 30

Today I had to rebuild the stack and change its name (it was formerly something like test1234) and after the deployment, I realized that the whole content of the docker_config/config/readsb/run/collectd folder has been overwritten, thus loosing a couple of months of stats.

Now, my question is: has it been initialized by readsb-protobuf? if so , what are the conditions under which it rebuilds the collectd folder?

no, I think this is caused by docker stack. WHen you're defining your volumes like you did, DOcker will create a new volume with the defined name, this happens when defining the volume like you did in your compose:
readsbpb_rrd:

when deploying in Stack, docker will automatically create a fresh volume with the defined name. I had the same happening when rebuilding my stack. I changed the volume definition in my stack and added the external:true definition to the volume, taken from my environment:

volumes:
  readsbpb_rrd:
    external: True
  readsbpb_autogain:
    external: True

this way it seems that docker will check on the existing volume on the node you deployed. If it's existing, it will mount the volume, if not, you will probably have to create the volume up front your container deployment.

If you're working in Swarm mode with multiple nodes, you need to ensure that the defined volumes are available on every node you wish to deploy the container on and that the volume contents are the same on every node your deploy on. You can do this by building local volumes everwhere you wish to deploy or you build a volume which is for instance using a nfs share, then you will have the same contents everywhere with little efforts. Or you work with placement constraints to ensure that this container is only started on a specific node of your Docker Swarm.