1. 2
  1. 9

    A post about all the positives without any of the frustration and negatives. What about security updates within the container? A new dev isn’t going to just be able to get up and running day 1 with Docker compose. It will help, but getting on-boarded still takes time. I know the author specifically says this is about development and so it’s fine there is no reference or the trouble with orchestration systems or larger configurations.

    I dunno. It doesn’t feel like there is a lot of really in-depth stuff here. I wrote a post about Docker a while back, and it might be the opposite; too long by comparison.

    1. 2

      Incidentally, we use Docker a lot just in development. Deployment is done through a pipeline like most deployments (you commit code in master and the microservice is automatically built and deployed to QA). There are some discussions about deploying containers but not everybody is sold on the idea and we have it easy because our hosting provider has support for containers.

      Basically, right now we’re simply using Docker as some sort of common ground for everybody, regardless of the OS used. So I think we’re in the same use-case as the author, so let me answer some of your questions/comments.

      What about security updates within the container?

      If you’re just developing with Docker, so you don’t push the actual container, you don’t really care about security updates (except for those within your code, of course).

      A new dev isn’t going to just be able to get up and running day 1 with Docker compose. It will help, but getting on-boarded still takes time.

      Personally, I don’t find a lot of value with Docker (and this is why it took me so long to consider Docker more than a fad) but I am comfortable with managing Linux and FreeBSD systems, I have configured servers with Puppet and Chef. I also run on my laptop the same Ubuntu version as we have on the servers just to make sure I have a very close match to production.

      However, not every developer is like me. We have a .NET developer in our team that recently migrated to Ruby (all our microservices are written in a flavour of Ruby, either MRI or JRuby) and it’s been very simple for him to have install Docker for Windows, copy a docker-compose.override.yml, run docker-compose build and then start working. Previously we had a wiki page that listed some steps, whoever reinstalled their machine had to tinker with it because it was slightly out of date and, in some cases, people would get stuck and ask for help.

      it’s fine there is no reference or the trouble with orchestration systems or larger configurations

      Actually, this is one of the issues with Docker, especially if you’re working with microservices because you’ll sometimes want to have multiple microservices running at the same time (one of them being authentication). Normally. you’d open multiple tabs and start the service in each tab or maybe have something like Foreman to start them all (but you need to make sure the services pick up the right environment variables) but with Docker you kind of need to have a docker-compose.yml file because container A can’t contact container B unless it’s defined in the same docker-compose.yml, so it’s not as straightforward.

      Personally, I found two major issues with Docker from a developing point of view:

      • On OSes like Windows, Docker is definitely not lightweight: you basically have to run a Linux VM which will host the containers. This will likely change in the future as Docker is working on Linux Containers on Windows but it’s still not there yet.
      • I’ve seen cases where people with the same Dockerfile, docker-compose.yml, docker-compose.override.yml and .env files run the same command and get different results (tests would fail). Only after completely removing Docker and reinstalling it the problems were fixed. Having a tool that works most of the time is sometimes worse than having a tool that fails reliably because it’s harder to find a long-term solution :-)
    2. 6

      To the author: please include a more critical analysis of tech. This reads like PR as it stands now.

      1. 5

        “Runs on Linux, Windows, and macOS” is not the same as “runs anywhere”.

        My company’s development environment started using Docker, and it has been a massive productivity leech for me to the point where I spent about two hours rewriting stuff a few months ago just to get rid of it. Most of the problems stem from Docker’s vast complexity and reinvention principles. I’ve had a lot of bugs with their storage abstractions and strange JSON logging stuff; blowing away /var/lib/docker was the only “solution” as the state just got too corrupted.

        Docker is one of those things that work great when it work, but are really really hard to figure out once something goes wrong; either because you did something wrong yourself, or because there is a bug/problem in the program. For example, what do you do with this:

        ERROR: for 929fd864e914_haproxy  open /var/lib/docker/containers/[..]/.tmp-config.v2.json411024355: no such file or directory
        ERROR: for elasticsearch  Cannot start service elasticsearch: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"failed to write 898 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/docker/[..]/cgroup.procs: invalid argument\""

        I traced some of it back to Docker bugs (here, here), but no real solutions, or answers as to why this happens so often on my system (I don’t really do anything weird?), and even less how I go about debugging/fixing this. It’s just a black box and the fastest way is to blow away all of Docker and start over.

        If I look at Docker, at a lot of the concepts and implementations seem … very complicated. Perhaps I am missing something, but I don’t see why all this storage abstractions are needed when we can just use the filesystem, e.g. run-container /usr/containers/cool-container. Stuff like docker pull could conceptually just me curl ... | tar xf - -C /usr/containers/cool-container. Running multiple containers based of a single image? cp -r.

        Maybe I’m just an old Unix guy, but I think that composition from generic tools is a much better approach for a lot of this stuff. It’s easier, less platform-dependent, has less code (meaning less bugs), etc.

        I don’t want to be too harsh about your article, but from my perspective there are many downsides to Docker, and having to deal with Docker (because for some projects that’s the only way to run them, or the only way to run tests) continues to be a timesink I’d rather not have to deal with.

        1. 4

          fwiw, I’ve started flagging all these as spam; there are too many of them with too little content, spurring too little interesting discussion.

          1. 4

            I agree with what everybody else says but also want to offer a bit more explanation. Lobsters is different from other online programming communities. In particular we

            • Have a lot fewer beginners
            • Prefer technical pieces to marketing pieces
            • Prefer content-effort over presentation-effort

            Your “You can do it in SQL” article went over pretty well! I also think “There are only two types of tests” would probably be taken in good faith, even if it would be pretty controversial. But things like “why use docker” aren’t really what we’re about.

            If you want to get a better sense of what would and wouldn’t do well, you should take some time to engage with the community. Post things you didn’t write. Comment on other people’s articles. I think that would help a lot.