3 ms·

> It’s enabled us to have more confidence that our dev environments match production How does Docker help you know your production code is like your developme

> It’s enabled us to have more confidence that our dev environments match production How does Docker help you know your production code is like your development code? _Maybe_ for the code itself, but I highly doubt it, because you probably have different build targets for dev and production, different ports, networking, environment variables, asset serving, debugging, etc. And certainly the docker-compose, maybe Swarm, setup you run locally looks nothing like production? And of course your databases and other services are set up completely different locally.

Spivak 7y ago
Because the sandboxing various container stacks provide create a much clearer line of demarcation between what is the responsibility of your ops team and your developers. It makes it much harder to accidentally depend on the state of the world. * There are two networking stacks. Developers only see and care about the "inner" stack while the ops team is free to do anything to the "outer" or real network. Devs never see that the ports are actually different in prod. * All the "environment" has to be passed explicitly. You can't accidentally depend on variables, files, programs, libraries, that just happen to be on the host system. Simultaneously, the ops team is now free to configure and manage or change the host system in any way they see fit. * Devs only care that they're deploying to a swarm not any of the details of how that swarm exists in prod. * Devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. * Devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. * Logs and metrics are sent to magic addresses and names on the inner network that map to the real vms outside. * Same with the DB, Redis, Memcache, Queues, etc..
- muxator 7y ago
  > * devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. > devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. > [...] > * Same with the DB, Redis, Memcache, Queues, etc... I am a bit scared by these devs only caring about themselves
yjftsjthsd-h 7y ago
So if by "dev environment" you mean locally on a developer's laptop, then sure. But shared dev/staging environments absolutely look like prod. CI builds an image, deploys it to staging (which is running the same docker-compose.yml or whatever as prod, just with URIs replaced to point at stage database, etc). If we like it, we hit the button to deploy that same image to prod. It's not perfectly identical, but stage and prod are pretty nearly the same.
- stevebmark 6y ago
  I don't see why Docker does anything special here, with Terraform + EC2/AMIs/AWS for example we get the exact same environment parody.

Spivak 7y ago

Because the sandboxing various container stacks provide create a much clearer line of demarcation between what is the responsibility of your ops team and your developers. It makes it much harder to accidentally depend on the state of the world. * There are two networking stacks. Developers only see and care about the "inner" stack while the ops team is free to do anything to the "outer" or real network. Devs never see that the ports are actually different in prod. * All the "environment" has to be passed explicitly. You can't accidentally depend on variables, files, programs, libraries, that just happen to be on the host system. Simultaneously, the ops team is now free to configure and manage or change the host system in any way they see fit. * Devs only care that they're deploying to a swarm not any of the details of how that swarm exists in prod. * Devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. * Devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. * Logs and metrics are sent to magic addresses and names on the inner network that map to the real vms outside. * Same with the DB, Redis, Memcache, Queues, etc..

muxator 7y ago
> * devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. > devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. > [...] > * Same with the DB, Redis, Memcache, Queues, etc... I am a bit scared by these devs only caring about themselves

yjftsjthsd-h 7y ago

So if by "dev environment" you mean locally on a developer's laptop, then sure. But shared dev/staging environments absolutely look like prod. CI builds an image, deploys it to staging (which is running the same docker-compose.yml or whatever as prod, just with URIs replaced to point at stage database, etc). If we like it, we hit the button to deploy that same image to prod. It's not perfectly identical, but stage and prod are pretty nearly the same.

stevebmark 6y ago
I don't see why Docker does anything special here, with Terraform + EC2/AMIs/AWS for example we get the exact same environment parody.