4 ms·

Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dock

Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dockerfile is still the easiest way to build images (even though now there are alternatives to docker build such as buildah). docker-compose is still a very simple way of running containers locally if you don't need kubernetes (e.g. on my raspberrypi for running homeassistant, transmission and plex)... but yeah.., Docker Inc. overestimated their importance and got what they deserve = Open Source tools wanting to distance from them.

pm90 6y ago
After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways. If your language runtime supports testcontainers (https://www.testcontainers.org/ https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.
- viraptor 6y ago
  What features do you find missing in compose?
  - pm90 6y ago
    https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
    - nikisweeting 6y ago
      Docker-compose v2.4 is arguably much better than v3.0, and in a lot of ways they are really separate specs, not a "newer version" of an old spec. Compose v3 exists to push you towards swarm, whereas compose v2 exists to make docker-compose a complete mini cluster management tool, and succeeds at it in my experience. We continue to use v2.4 in all our projects today because it allows you do easily do things like define startup order with healthchecks, as well as limit cpu, memory, etc. without having to spin up a whole swarm cluster.
      - ucarion 6y ago
        I push for docker-compose v2 over v3 at work for the same reason. Just to spell out explicitly what nikisweeting is hinting at: For local development use-cases, docker-compose v3 is just v2 minus all the features Docker Swarm doesn't support.
      - nikisweeting 6y ago
        If anyone is curious, this is the native official way to define startup order using healthchecks present in v2.4 (but removed in v3 to push you towards swarm): some_service: depends_on: other_service: condition: service_healthy
        nikisweeting 6y ago
        TIL this has been returned to compose in the latest version! They merged the specs in September so this is now officially supported again going forward. That fixes my last major gripe with compose trying to push people to swarm, which no longer seems to be the case after this merge. https://github.com/docker/compose/releases/tag/1.27.0 https://github.com/docker/compose/releases/tag/1.27.0
raesene9 6y ago
It's worth noting that dockershim isn't actually getting removed at the moment, it's being deprecated (so a warning will pop up in kubelet logs) and there's no fixed date for actual removal. At the same time Docker/Mirantis have committed to creating a CRI plugin for Docker, so it seems pretty likely that Docker is and will continue to be an option for Kubernetes clusters.

pm90 6y ago

After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways. If your language runtime supports testcontainers (https://www.testcontainers.org/ https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.

viraptor 6y ago
What features do you find missing in compose?
- pm90 6y ago
  https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
  - nikisweeting 6y ago
    Docker-compose v2.4 is arguably much better than v3.0, and in a lot of ways they are really separate specs, not a "newer version" of an old spec. Compose v3 exists to push you towards swarm, whereas compose v2 exists to make docker-compose a complete mini cluster management tool, and succeeds at it in my experience. We continue to use v2.4 in all our projects today because it allows you do easily do things like define startup order with healthchecks, as well as limit cpu, memory, etc. without having to spin up a whole swarm cluster.
    - ucarion 6y ago
      I push for docker-compose v2 over v3 at work for the same reason. Just to spell out explicitly what nikisweeting is hinting at: For local development use-cases, docker-compose v3 is just v2 minus all the features Docker Swarm doesn't support.
    - nikisweeting 6y ago
      If anyone is curious, this is the native official way to define startup order using healthchecks present in v2.4 (but removed in v3 to push you towards swarm): some_service: depends_on: other_service: condition: service_healthy
      - nikisweeting 6y ago
        TIL this has been returned to compose in the latest version! They merged the specs in September so this is now officially supported again going forward. That fixes my last major gripe with compose trying to push people to swarm, which no longer seems to be the case after this merge. https://github.com/docker/compose/releases/tag/1.27.0 https://github.com/docker/compose/releases/tag/1.27.0

raesene9 6y ago

It's worth noting that dockershim isn't actually getting removed at the moment, it's being deprecated (so a warning will pop up in kubelet logs) and there's no fixed date for actual removal. At the same time Docker/Mirantis have committed to creating a CRI plugin for Docker, so it seems pretty likely that Docker is and will continue to be an option for Kubernetes clusters.