Developer Images

[gilesknap]

Is the best approach to have a lean runtime container and full-fat developer container?

Currently for DLS IOCs we create a developer (and build) version and a runtime version for each generic IOC. This means that we have a portable development environment that closely resembles the runtime environment.

However this makes the Dockerfiles more complex and gives us more images to maintain.

So we are considering dropping runtime containers and using the full-fat container at runtime too.

This would mean that it is very easy to debug IOCs in place and it simplifies image build and management. It costs more RAM but IOCs tend to share most of the base layers so this should be minimised.

[thomascobb]

I'm still on the fence about this, but I'd be inclined to try the full-fat approach on a larger range of devices for a beamline before making a permanent decision. If it's not too resource intensive then it certainly maintains simplicity

[gilesknap]

One point worth making is that this is fine for on prem clusters like ours where you have quite a bit of spare hardware. Those that run on public cloud will be increasing their costs.

[remivoirin]

In our case we stick to runtime images that have basic debugging tools and run the same CentOS version as hosts. Given the multiple languages and frameworks that exist in our controls environment, development images are built by development teams based on runtime images... Sometimes they can be up to a few GBs so we keep a strong split dev/runtime for now.