Docker's Second Death • Hacker News Board

Re: Docker's Second Death

#181

Post by nobleach » Sun, Dec 06, 2020, 10:16 PM UTC

yjftsjthsd-h wrote: post #145

enos_feedler wrote: post #114

Earlier quoted context omitted.

What kind of control are you looking for?

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write FROM alpine STARTLAYER RUN apk update RUN apk upgrade RUN apk add foo ENDLAYER and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

I too have wanted a solution for the massive amount of layers that are generated just by doing normal things. When you reach a point where you're trying to be so clever just to avoid the creation of a useless layer, it's the tooling's fault, not yours.

Re: Docker's Second Death

#182

Post by polskibus » Sun, Dec 06, 2020, 10:29 PM UTC

Does it mean that developers working locally with containers should ditch Docker and Dockerfiles altogether?

If so, what should they replace it with, esp, if all you want to deploy to prod is contained in a single docker-compose? Is switching local development to kubernetes a good idea in terms of performance, fast feedback loop, development experience (smooth flow), etc. ?

Re: Docker's Second Death

#183

Post by nikisweeting » Sun, Dec 06, 2020, 10:40 PM UTC

user5994461 wrote: post #173

nikisweeting wrote: post #132

Earlier quoted context omitted.

I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company that only serves 100,000-1,000,000 monthly hits it's the perfect middle ground. We've tried k8s several times and have always ended up going back because we didn't need the complexity. We even run compose v2.4 to retain the ability to set container memory/cpu li…

>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case. See various workarounds over the years: https://stackoverflow.com/questions/317461…

You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested).

Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it)

I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.

Re: Docker's Second Death

#184

Post by nikisweeting » Sun, Dec 06, 2020, 10:52 PM UTC

nikisweeting wrote: post #117

pm90 wrote: post #95

Earlier quoted context omitted.

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.

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 defin…

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

Re: Docker's Second Death

#185

Post by papito » Sun, Dec 06, 2020, 10:56 PM UTC

loriverkutya wrote: post #36

papito wrote: post #30

Kubernetes is and will be a solution to a problem most organizations don't have.

Like scaling and fault tolerance? :)

Care and feeding of a production Kubernetes cluster requires constant care, feeding, and maintenance of expertise that would cost any company hundreds of thousands of dollars a year.

Have we really arrived at a point where a good old autoscaling group with a few servers and a replicated database is just not good for anything?

Re: Docker's Second Death

#186

Post by user5994461 » Sun, Dec 06, 2020, 10:58 PM UTC

bayindirh wrote: post #178

fxtentacle wrote: post #171

Earlier quoted context omitted.

In my opinion, the Jetbrains tools are very affordable when compared with the huge productivity boost that they grant me. I agree that intellij and eclipse are similar, but as soon as you work with C, C# or Python, there's very few good open source alternatives.

I have no doubt about their quality and affordability. Also, the price goes down when you subscribe for a longer time. I write C/C++ and Python mainly. Eclipse CDT and PyDev are very good. Since I'm using the platform for 15+ years, I've seen its bad days too. Except some edge cases, CDT is bulletproof and works very well. PyDev is also very smart and helps me the way I need. Actually, Eclipse has the best and most s…

Eclipse CDT is very good? I think we have a very different definition of very good. Could write a long rant on everything that was broken in Eclipse for C and C++ development.

One question on eclipse. Did eclipse finally sort out git/svn support?

Here's an interesting tidbit of history for those who don't know. One of the main drivers for the decline of eclipse was the complete lack of support for source control, which is a pretty basic feature for an IDE.

You could try to get some plugins. There were 2 major plugins for SVN and neither worked half the time for no particular reasons. It was a complete shitshow. Don't even think of doing that in a company where HTTP access must go through a proxy.

Developers eventually gave up and moved to JetBrains IDE. Source control worked out of the box.

Re: Docker's Second Death

#187

Post by pmontra » Sun, Dec 06, 2020, 11:04 PM UTC

hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

It keeps living on Linux too. My customers are too small to need Kubernetes and we won't switch off our docker containers in development and production. And a customer created a container on his Mac on Thursday to run something I run natively on my Ubuntu laptop.

To be fair to the author of the post, he wrote about the continuing life of docker in the inner loop of development. It will keep going also in production on medium and small projects until we start using something else for multiplatform pull and run software distribution.

Re: Docker's Second Death

#188

Post by 2ion » Sun, Dec 06, 2020, 11:07 PM UTC

hacknat wrote: post #51

hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

There’s no need for them to live on. There are open source alternatives that mimic Docker exactly. In fact on Fedora[1] the “docker” cli command is actually buildah and podman (you actually can’t install Docker on Fedora anymore - I genuinely haven’t noticed a difference). The commands are exactly the same right down to the command starting with the word “docker”. I don’t wish them ill, but literally everything has b…

Docker Desktop is the only non-hacky way to get a decent Docker (and k8s) setup for development purposes on macOS and Windows. Linux on the desktop never needed that, but those other two do.

Re: Docker's Second Death

#189

Post by user5994461 » Sun, Dec 06, 2020, 11:25 PM UTC

nikisweeting wrote: post #183

user5994461 wrote: post #173

Earlier quoted context omitted.

>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case. See various workarounds over the years: https://stackoverflow.com/questions/317461…

You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not…

Problem being, "depends_on" was removed in version 3, with no replacement in sight.

I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall).

P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.

Re: Docker's Second Death

#190

Post by tariqislam_ » Sun, Dec 06, 2020, 11:31 PM UTC

polskibus wrote: post #182

Does it mean that developers working locally with containers should ditch Docker and Dockerfiles altogether? If so, what should they replace it with, esp, if all you want to deploy to prod is contained in a single docker-compose? Is switching local development to kubernetes a good idea in terms of performance, fast feedback loop, development experience (smooth flow), etc. ?

Author here. In the last part of my post, I do mention that Dockerfiles are probably the one thing that will outlast everything else from Docker. There's nothing really practical to replace that artifact at this time if you ask me.

There are some tools to convert your docker-compose into the k8s resource model. I'd advise against switching local development to Kubernetes. Docker found a sweet spot there, as heavyweight as it is today. I think where we'll land is Dockerfile + one of the other alternatives like kaniko, buildah, etc.