we are migrating to resin.io from our custom deploy system which was based on multiple microservices deployed with docker-compose.
We are aware of an ongoing project to support multicontainer deployments, and in the meantime we are building a temporary solution based on the compose solution by @justin8:
In summary this solution ships a docker in docker (dind) container into the device and triggers docker compose to build and start internal applications as containers
Our main problem is that our internal applications have a bunch of private dependencies from our repos, and we are not very fond of building images inside the devices… The guys at resin suggested the usage of resin cli’s
resin build/deploy commands to externally build and deploy our images…
At this point we can build but not deploy them, as the only thing that can be pushed to the application is the
Our solution is to maintain our own private build servers and our own private docker registry and give credentials for the latter to our devices in order to directly pull the internal applications from inside the
Will this be closely compatible with the future resin.io multicontainer approach, i.e. by removing our private registry and pushing directly to resin’s?
In order to automatically update the internal application, we are thinking on using the resin API to force an application restart when any image is updated in our private registry, thus updating the container… But this is quite a bruteforce approach as it introduces quite a lot of unpleasant downtime in the device… Any thoughts?