OFM Raspbian OS - package - any one tried Docker?

Hi there,

As per subject. I´m not sure what to expect the next few days, but I must admit that designating a RPI4 entirely to one microscope seems somewhat inefficient. Few thoughts and questions:

  • SD cards are not made for many write cycles and die silently at the most unwanted point in time. Hence I use a SSD USB drive with plenty of storage and MUCH faster performance.
  • I have not seen a reference to to log2ram ( GitHub - azlux/log2ram: ramlog like for systemd (Put log into a ram folder) ) which may help improving SD card life time, .nor do I know whether its part of the OFM OS image already. Log2Ram log to /tmpfs and reduces write cycles dramatically.
  • The many dependencies being the raison d’ètre for a dedicated OS image make me a bit nervous. How do you manage changes, all sorts of updates, backups, configurations,… Are there any plans to “eliminate” dependencies or to pack everything what is needed in one tar or so?
  • last, but not least back to my subject line: has anyone dockerized OFM? If that´s possible, who would care about dependencies…just deploy a new image / container.

I´m familiar but not an expert in docker. It might be worth to check the possibility to come up with an image. Anyone around who would have the expertise?

With best regards,


Hi Jörg,
The short answer is yes - the OpenFlexure Microscope server can run in Docker, and indeed that is how we run all our tests in CI. However, there is one enormous limitation with doing this: it’s deliberately very hard to access hardware from Docker. So, all our tests use emulated hardware. If you want to spin up a container and run the microscope, we don’t have a ready-made image, but if you look at the CI config it shouldn’t be too hard to turn the relevant bits into a Dockerfile if you are keen.

We manage Python dependencies with Pipenv and so the Python software is about as reproducible as it can be. Dependencies on system libraries are no better or worse than anything else using the scientific Python stack (numpy/scipy/friends) and the remaining issues are mostly connected to hardware, e.g. support for the Raspberry Pi camera.

The majority of people I’ve spoken to that have struggled to reproduce the software already find the creation of virtual environments and the use of git confusing, and would not find Docker helpful I think! The Pi OS image solved a lot of problems for us and cut almost to zero the number of people who couldn’t install the software. This is not currently intended as a general purpose microscope control suite, so installation and support of the server on platforms other than a Pi is not high on the list of priorities for my very limited development hours: there wouldn’t be a lot of advantages for now.

The next major version of the server will be more modular, and easier to customise with different hardware, but I suspect the vast majority of users will still just want to download an SD card image.

I’ll add that, when we took most of these decisions, a Raspberry Pi was something you could easily pick up from RS components for £35 with next day delivery. Clearly the chip shortages have hit everybody pretty hard, but I live in hope of a return to the time when a Pi was an inexpensive and readily available component!

1 Like