Need help with the best practices for sharing libraries (jars) with multiple containers.
We have dozens of java web applications running in tomcats that we have containerized. All of the applications use and share a handful of custom libraries. Currently we are just bind mounting each container to a directory on the host file system in order to keep to only one copy of the libraries. But we really have one copy per node. This works, but it presents deployment issues with keeping these directories in sync between all the nodes in the cluster.
We are resistant to putting these libraries inside each container because we want to avoid having to rebuild every app when a new library version is introduced.
Thanks… we’ve considered that but are trying to use swarm (with compose) and volumes_from was removed from compose version 3. It seems like they want us to use named volumes, but I haven’t figured out exactly how I am supposed to populate the volumes on each of the nodes in the cluster.
Its weird to me that there isn’t a clear solution to this. Do most people just put all their dependencies in the container???
Might try to bind to a NFS mount directory. That way we can update just one location and just have the swarm restart.
Yes, this drastically simplifies container-based deployment. It also means that if components A and B both depend on shared library X, and X has a “minor” version bump that A needs but it happens to break B, you’re not in shared-library trouble, because the two components have their own copies of the library stack.
As a corollary, your Docker images should contain your application code (including shared library dependencies) and you should store data that needs to be persisted in volumes or otherwise outside of containers; but trying to use volumes to share code is against the spirit of immutable infrastructure.
If space is at a premium, or the shared library dependencies are very large, one thing you can do is to create a base Docker image that contains only the shared libraries, and then create application images that are based on that. Different application images that share the same base library image will share one copy of its contents. (If you update some images but not others, you can end up with multiple copies, of course.)
Thanks for the help. I’ve been trying to avoid that. I just don’t like the idea of rebuilding/testing/redeploying 50 containers when we change a single library version. Doesn’t feel very modular.