We're playing with Docker in the office and there is disagreement on how to set it up.

Trying to dockerize a simple web service - restful, json-over-https api.

One camp wants to package individual applications - Apache in one container, mysql in another, memcached in another, then rely on Docker networking to patch it all together.

Two camp wants to package our whole application into a single container. Since we depend on mysql, memcached, and apache, their argument is all those things should be along for the ride.

Three camp wants to stick to VMs with standard images and autoscale. Seems to be working great right now.

2/21/2018 7:57:30 AM

i've done all 3 and they're all fine approaches.

if you have a legit microservices architecture and want to deploy and scale individual services independently, then you go approach #1. IF you need that. which a lot of times you don't. if you do, orchestrating those containers becomes an additional concern and area of complexity you need to be ready to understand and manage.

why do you want to use docker over VMs in the first place. docker absolutely has some advantages over VMs, but make sure you're adopting docker because you need those advantages, not just because docker is new and shiny

2/21/2018 12:23:44 PM

I personally think it's totally unnecessary and a waste of my time.

But it's a business-wide initiative and the story was they would give us free hardware to run it on (so they can test kubernetes and mesosphere with real load.)

Free stuff makes managers perk up.




Plus my synology runs docker containers but not VM's. Learning on the clock is best learning.

2/21/2018 1:52:11 PM

for a single service it's completely unnecessary. if you have several then it becomes worthwhile. or if you want to do environment versioning better.

2/21/2018 3:15:34 PM

Docker gets really fun when you combine it with things like AWS ECS/CloudFormation.

Your approaches certainly depend on what you're trying to accomplish. I wouldn't take something that I'd have running say in a full VM and just copy/paste it into a Docker image. At a minimum I'd separate major concerns (memcached and mysql in your case). I don't know your full arch. but I imagine Apache would sit out in front of your containers routing traffic (or better yet nginx/something else).. or is this a PHP service?

I'd avoid #2.

Like ^ and ^^ are saying, if you're going "microservice" or just multiple services in general.. splitting into containers can be awesome for versioning and hot-swapping. Splitting further (such as throwing your DB into a separate container from the "app") can make this even better, but like anything else you have to find your cut off point or things become unmanageable.

#1 is worth exploring. While #3 is fine if it's working great (that's a good thing!) you might be missing out on efficiencies in dev/test. There could be arguments for cost, reliability, speed, etc. but so many other variables are at play there.

[Edited on February 21, 2018 at 9:47 PM. Reason : ]

2/21/2018 9:47:23 PM

your app doesn't use custom stuff that's difficult to model/scale in a VM footprint. If you're using aws (you mentioned autoscale) you also have the huge bonus of using RDS, elasticache, and ELB. To me, it sounds like you should be using beanstalk, to me. Put your web service itself in docker and make that the deployable unit for beanstalk

[Edited on February 22, 2018 at 3:37 PM. Reason : also, check out https://fugue.co for that fire orchestration/lifecycle management]

2/22/2018 3:36:31 PM