util/os-runner: Use docker-compose to manage containers

[darius-m]

The current Makefile [removes] the container when make clean is used. This is a source of a lot of wasted time whenever someone starts the container, since apt update and apt install run every time.

The issue of changed packages could probably be avoided by using docker-compose that can monitor changes to the source Dockerfile and update the image accordingly.

[Alex-deVis]

apt update and apt install run every time.

This is not the case because these commands only run when you are building the image. Deleting and recreating the container should not trigger the image rebuild unless there are changes in the Dockerfile / files used by the Dockerfile.

I think docker-compose is a better alternative to our comprehensive Makefile and it should be addressed. Please consider renaming the issue or adding a new one for this part only.

[darius-m]

To be fair, the "run every time" was a bad description. It's more that users are inclined to run make clean to stop the container, but aside from stopping it, the the makefile also removes the container. So when they wish to start a different lab / restart their work, the container would also need to be pulled and built once more. This is partially fixed by #205, but there is still no real need to nuke the container whenever make clean runs.

I meant to link to this line - hence the square brackets around the removes in the description, but I failed to properly link it.

[darius-m]

Re-reading your comment, I think you may be right in that the image itself should not be removed, so it should start immediately if the Docker file has not been changed. There may have been some issues with old versions of the Makefile, or the transition to the new Makefile / Dockerfile while still having an old docker image defined.

However, removing the container is not the usual approach when working with containers that you may need again, as far as I can tell, and in our case the stopped container should not really impact the system since it should basically not run anything that takes additional resources.

Regardless, this issue is optional at this point. You may close it if no action is planned.