5 ms·

If you are developing within a docker container, how do you get as far as CI before you have tested it working locally?? The whole point of using docker contai

by Daviey 10y ago

If you are developing within a docker container, how do you get as far as CI before you have tested it working locally?? The whole point of using docker containers is to have the same development experience locally, in CI and in prod.. not have some unknown system libraries on your box which don't match other environments. Want a database? docker run mysql/mysql-server Your argument for switching away from containers, seems to actually be arguing for using containers.

crdoconnor 10y ago
You'll never get the same environment locally as you do in prod. That's why you have staging (you do have staging, right?). It's better to make the environment as close as possible to prod without adding massive inconvenience but docker both adds inconvenience and forces you to use it in production (which entails a whole other set of headaches) if you want close environmental parity, and even then, since it's lightweight virtualization there are hundreds of things which can behave differently between dev and prod. IMHO you either want very close environmental parity (in which case full virtualization is the way to go) or you don't, in which case running locally is fine.
- amouat 10y ago
  > That's why you have staging (you do have staging, right?). Plenty of people don't. The main reason being that staging is never quite the same as production...
- sz4kerto 10y ago
  We are working in a remote team, so replicating shared envs locally is important. Our system contains multiple databases, application servers, SMTP, etc etc. -- you can use all of them in your local dev env. It's not the same as prod because of different latencies, etc., but all containers are present locally. It is _very_ useful.
  - crdoconnor 10y ago
    >We are working in a remote team, so replicating shared envs locally is important. It is, but I'm not particularly keen on docker as a solution to this problem. It provides a low level of isolation/realism for these services and the tooling surrounding it is relatively poor.
- bradmwalker 10y ago
  What about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
- bradmwalker 10y ago
  What about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
- deleted 10y ago
  [deleted]

by Daviey 10y ago

crdoconnor 10y ago

You'll never get the same environment locally as you do in prod. That's why you have staging (you do have staging, right?). It's better to make the environment as close as possible to prod without adding massive inconvenience but docker both adds inconvenience and forces you to use it in production (which entails a whole other set of headaches) if you want close environmental parity, and even then, since it's lightweight virtualization there are hundreds of things which can behave differently between dev and prod. IMHO you either want very close environmental parity (in which case full virtualization is the way to go) or you don't, in which case running locally is fine.

amouat 10y ago
> That's why you have staging (you do have staging, right?). Plenty of people don't. The main reason being that staging is never quite the same as production...
sz4kerto 10y ago
We are working in a remote team, so replicating shared envs locally is important. Our system contains multiple databases, application servers, SMTP, etc etc. -- you can use all of them in your local dev env. It's not the same as prod because of different latencies, etc., but all containers are present locally. It is _very_ useful.
- crdoconnor 10y ago
  >We are working in a remote team, so replicating shared envs locally is important. It is, but I'm not particularly keen on docker as a solution to this problem. It provides a low level of isolation/realism for these services and the tooling surrounding it is relatively poor.
bradmwalker 10y ago
What about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
bradmwalker 10y ago
What about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
deleted 10y ago
[deleted]