Docker from a freelance perspective. How Docker makes Django and Rails development easier.
Fun game: replace every instance of docker with “the browser Java plugin”. For instance:
The browser Java plugin is already being used in production by big companies, has received a tremendous amount of publicity, and continues to spur excitement in the tech industry. For a project that is only two years old, this success is unprecedented.
The example of youtube-audio-dl is another great example of making problems so we can solve them. I agree that the https://github.com/jcalazan/youtube-audio-dl/blob/master/README.md list of dependencies is more than I’d care to spend a day setting up. Which is why I use youtube-dl (which involves downloading a single Python file) instead. Downloading audio from YouTube doesn’t seem like the kind of task that should require nginx, Postgres, and rabbitmq.
I think that is the stack for running youtubeadl.com which is intended to be a public service, not what an end user is actually supposed to run on their own just to fetch audio from a single YT video.
I think you could have s/Docker/Virtual Machines/ a few years ago and written the exact same article. That isn’t to say the content is wrong, but rather that the benefits in this article are not new to Docker and Docker comes with a whole bunch of cultural problems as well.
Docker comes with a whole bunch of cultural problems as well.
can you elucidate? That’s quite a statement.
Specifically, Docker might save you from dependecy hell but it can just as easily put you into blob-hell.
You have some image, no idea how it was constructed, and if it doesn’t work it’s a massive black box and good luck debugging it. There was a recent post about someone running into this issue trying to get Discourse running. Infrastructure at some places I have worked heavily uses docker and getting the environmen running locally was not all sunshine and lollipops. Docker is often presented as an abstraction that saves you from having to set things up, however the way it’s being deployed it can often be brittle. When it works it works when it doesn’t it’s a nightmare.
Docker might be making it easier to distribute software, however one has to be just as transparent, if not more so, on how they create the images. We are moving the dependency problem around, not solving it, like I think many people believe.
Ah, that. That is a problem. I don’t really cut the cake to have Docker on that slice, but you’re quite right; it’s a problem, and Docker makes it worse.
It’s probably not what he was hinting at, but when I was using it during my internship this summer I found that most of the documentation is in bug reports on github.
That was my experience a couple of years ago (very early days), but the docs and other materials have gotten much, better. I’ve only had to look at github issues for newer things (networking, storage/volumes).
However, I don’t think it’s any worse than other large open-source projects. Right now, I feel like Kubernetes is at the “up-to-date info is only in github issues” stage, but presumably that will get better as well.
And it’s way better than Mesos, where you can’t find any good documentation (up-to-date or otherwise), despite the fact that it’s much older than Kubernetes.
People seem to think it makes things repeatable, and it very much does not.
Not only that, but now people are using docker as their deployment/installation instructions. Aka: macosx install instructions become install docker-machine to run this.
And the app is just a mysql db behind rails/python/go.
We’re trading open source handcuffs for ease of development. I’m not particularly happy about this direction of things. Seems like backwards progress to say: just use linux everywhere. Punting on portability is a bad sign and portends a rather bad future.
Except that in my experience, they weren’t writing such articles (or they weren’t as popular).
I just had a conversation this past week where instead of putting all of the possible dependencies that any version of our application could need (Java 6, 7, 8, various JDBC drivers, app servers, etc.) into a single VM image, we’d create multiple VM images, that only had particular versions (i.e., custom images per version of our app). Net result is smaller images, with fewer/no conflicts, that are easier to build and manage.
That’s not to say that people weren’t doing the above years ago, but it’s become the dominant philosophy with ephemeral/immutable servers, especially those taking advantage of Docker images/containers.
I agree that wasn’t a big initial part of the first VM/cloud hype wave, but I do think it still predates the Docker wave by one wave (if I can use a hand-wavy unit of measurement). The wave before Docker was the one that introduced “devops” as a replacement for “sysadmin”, tools like Ansible/Chef/Salt, and pushed the idea of ephemeral servers, reproducible configurations, one application per server where you start with base Debian/Ubuntu and then install only what your app needs, etc. Docker is definitely pushing those ideas, but I think it’s getting a lot of traction because a lot of those ideas are already pretty widely accepted.