top | item 27017448

(no title)

gindely | 4 years ago

> > Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine

> I mean, that's basically _why_ Docker exists.

It is, but Docker isn't it. At the least, Docker won't run side-by-side with Virtual Box on Windows, so "regardless of prior configuration" is not met. In general, Docker adds an extra dependency on top of a blank system: Now you need to get Docker set up and running first, and then you can deploy your app. The alternative in question is about controlling the build to such an extent that you can reliably deploy the artefacts onto any system without having some runtime environment prepared.

discuss

order

kemitche|4 years ago

I don't view Docker as an "extra" dependency: I view it as the _only_ dependency.

For example, at my last job, before we switched to Docker, a client dev that wanted to run a local backend had to install postures, apply initial schema, and then download and run the app. Not only was this a bunch of steps the client devs weren't familiar with, it led to backend devs being reticent about using the most appropriate tool for new features (e.g. shoving service discovery awkwardly into SQL instead of into something like etcd - and before anyone says "well that's fine" or "just do xyz instead," realize that's just an example of several). It was annoying to client devs to have to add new tools all the time, and annoying to backend devs to have to constantly troubleshoot misinstallation / misconfiguration.

When we switched to Docker, the client devs could run the backend without having to manage anything. Install docker (once), then run a very basic script that basically just ran "docker-compose pull; docker-compose up".

I don't generally want to be able to deploy to arbitrary environments. I want something that is easy to build, builds consistently, and lets all my fellow devs run whatever host they need to be maximally effective.

On Windows, it's true, if you need Virtual Box specifically then you can't use "Docker for Windows". You could either move the VB stuff into Hyper-V, or run Docker directly on a VB VM (a little less turnkey, but not particularly difficult).