We’re using a docker-in-docker base image, along with docker-compose to marshal all our containers, and it’s working (reasonably) well. There’s one area that I’d like to improve, specifically related to the initial build process. Right now, the core app is pushed, and build, and then when the app starts up, it kicks off a docker-compose process to actually build all the individual containers as defined within the docker-compose.yml
This has a number of disadvantages, not least of which is that one can quite easily push a “broken” app, given that the resin build process doesn’t really “know” anything about the child containers built by docker-compose. If an error creeps into one of the child containers, then that’s only obvious when the container is actually bit, which of course happens within the app itself, on the device, rather than within the builder environment.
I’ve tried running a docker-instance from within the “parent” Dockerfile itself, but the permissions assigned to the user within the build environment don’t seem to be enough to allow it.
Can anyone think of any neat tricks to allow the docker-compose build process to run within the build environment?
I think the resin.io official stance on this would be that multicontainer applications are coming, and that won’t be based on docker-in-docker, but something more manageable.
In the meantime, some ideas! You can try having either:
a) a staging application - you have some device there and deploy to that, once that works, deploy to your production application;
or
b) develop on local mode - push changes to a dev machine on the LAN, and only commit when you are satisfied with the result, and push that to the rest of the fleet.
What do you think, would either of these work for you?
We’re already doing both of those anyway, and would do even if we could run docker-in-docker in the builder.
Perhaps I overstated the issue with pushing a broken app - there are a bunch of other issues which running docker in the builder would also solve, for example being able to build a deployable image which can be pre-loaded onto each device. At the moment, the loading (i.e. execution of docker-compose) only happens when the app starts. If you have any hints on that one, I’d love to hear it
hey @cmoss, interesting idea, though I can’t see a good way approach the preloading. Presumably you are mapping your var/lib/docker to data for persistence right? /data is only mounted on the device so it’s inaccessible from the build server.
Of course you could docker pull all your containers in the build and then when the container lands on the device move them to /data, this would better experience for the device’s first push but that wouldn’t take advantage of docker cache and you’d just end up with long builds.
I’ll give it some more thought though I can’t see a great solution here, but perhaps someone others have ideas?
You can try having either: