3 ms·

The target platform is the same, but the dev environments are different. People will prefer their own MacOS, Windows, or Linux based setups, and all the differe

The target platform is the same, but the dev environments are different. People will prefer their own MacOS, Windows, or Linux based setups, and all the different headaches of various conflicting libraries and architectures (ARM v. x86). Docker seems much simpler than having them setup a matching VM or cloud desktop. The different platforms for deploying is about cloud-agnosticism, avoiding vendor lock-in by using an easily reproducible standard. Even for just one cloud deployment, Ansible and similar tools aren't as simple and reproducible as a docker-compose.yml and Dockerfile. I'm not saying I've started from 0 and tried all the comparable solutions here, comparing and contrasting them. It's that when I looked at the lay of the land, asked "How do I get a Django app easily reproducibly built and deployed, across dev and prod, the Docker solution that I went with appeared to be such a shortcut to the rest.

trabant00 5y ago
> People will prefer their own MacOS, Windows, or Linux based setups As a devops I strongly oppose developing on the desktop OS. Only your repos and code editor should be on your workstation, and you should have dedicated dev environment in a server farm - be that vms or containers. > "How do I get a Django app easily reproducibly built and deployed, across dev and prod, the Docker solution that I went with appeared to be such a shortcut to the rest. Only you don't deploy Docker in prod, do you? The fact that the container starts means nothing if it doesn't interface with the other contanerized apps. So you start needing a Kubernetes cluster locally and all goes to hell from there.
stephenr 5y ago
A VM in and of itself isn't a problem for developers, expecting them to configure it themselves is. Vagrant is a really good solution for this: it is generally VM based, but the same "box" (basically an image) can be build for multiple providers, so you can use Docker or LXC as your provider, I can use Parallels on a Mac, Jenny can use VMWare Desktop, Billy can use HyperV, and the casual tester can use VirtualBox. This also doesn't preclude the use of covering different architectures for the boxes: years ago I setup the tooling for a project where one developer had a laptop without a 64bit-capable CPU, so most of us ran an amd64 box, but his was i386.

trabant00 5y ago

> People will prefer their own MacOS, Windows, or Linux based setups As a devops I strongly oppose developing on the desktop OS. Only your repos and code editor should be on your workstation, and you should have dedicated dev environment in a server farm - be that vms or containers. > "How do I get a Django app easily reproducibly built and deployed, across dev and prod, the Docker solution that I went with appeared to be such a shortcut to the rest. Only you don't deploy Docker in prod, do you? The fact that the container starts means nothing if it doesn't interface with the other contanerized apps. So you start needing a Kubernetes cluster locally and all goes to hell from there.

stephenr 5y ago

A VM in and of itself isn't a problem for developers, expecting them to configure it themselves is. Vagrant is a really good solution for this: it is generally VM based, but the same "box" (basically an image) can be build for multiple providers, so you can use Docker or LXC as your provider, I can use Parallels on a Mac, Jenny can use VMWare Desktop, Billy can use HyperV, and the casual tester can use VirtualBox. This also doesn't preclude the use of covering different architectures for the boxes: years ago I setup the tooling for a project where one developer had a laptop without a 64bit-capable CPU, so most of us ran an amd64 box, but his was i386.