If you want to deploy your code in a docker mapping service such as the Google Container Engine, Amazon Container Service, etc., then option 1 is usually the only possible solution since you do not have access to the host. Option 1 is also more scalable in docker orchestration systems, as you can create multiple instances of your service on different docker hosts.
However, I myself use option 2 for the reasons you mentioned, and because I control the scaling through auto-scaling groups using cloud formations that can provide instances of my war in the local store. Now I donβt think that docker orchestration is mature enough for me to replace my external orchestration systems, and if I have these systems, then it makes no sense to lose the advantages of approach 2. However, when amazon allows us to directly connect ELB to docker containers and will bring some more improvements, Iβm seriously changing my mind.
Due to the large size of the images, supporting one image for each assembly and sharing the image for later deployment can be a problem
FYI Docker uses a diff-based file system, so as long as you change only the war file, your image storage should not be a problem.
Usman ismail
source share