> With docker I can just get up and running on my local box and every dev I share this with has the exact same environment and config.
Well, that's the dream. The reality is like that sometimes, but also sometimes like "I ran `docker-compose up -d` like you said, and the local-dynamodb container seems fine, but the app container output 'Cannot find /volumeforsomething' and died...?" and then there's a slack thread for a couple hours about which version of Docker and is it native or Docker for Mac, and whether to try upgrading Docker for Mac first or just `docker volume rm -f volumeforsomething` or even `docker volume prune -f`...
Yeah but some of us have paid those dues over time and don't have that level of issue with Docker any longer.
I used to really struggle getting Docker and docker-compose to do what I want, but after a few years working with it, I'm not blocked by the various volume or network or what-have-yous that used to come up.
Alternative proposal: run your containers in docker-compose environments on an ec2 instance. Everyone wins?
We started that way. I'm honestly surprised this isn't suggested more often. It allowed our devs to benefit from containers while not totally uprooting our existing Infrastructure.
We've mostly moved to EKS now but we had plenty of time to do it right thanks to this approach.
Depends on... literally everything about your infrastructure. All kinds of options, pretty much anything is possible here, depending on what you want to do.
Well, that's the dream. The reality is like that sometimes, but also sometimes like "I ran `docker-compose up -d` like you said, and the local-dynamodb container seems fine, but the app container output 'Cannot find /volumeforsomething' and died...?" and then there's a slack thread for a couple hours about which version of Docker and is it native or Docker for Mac, and whether to try upgrading Docker for Mac first or just `docker volume rm -f volumeforsomething` or even `docker volume prune -f`...