Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

171–180 of 286 posts

Re: Docker's Second Death

#171

Post by fxtentacle »

bayindirh wrote: post #146
pjmlp wrote: post #109

Earlier quoted context omitted.

Because the FOSS generation feels entitled to be paid while refusing to pay for tools, which leaves the typical enterprise customers as the only place one can make money with development tooling.

That's not true. As a FOSS lover, I pay for a lot of tools. Both development related and unrelated. Moreover, some of the tools that I pay extend on FOSS software (Tower, Viscosity, Permute) and some of are FOSS already (Cyberduck). The thing is, as a person I don't want to feel ripped off. I don't subscribe to JetBrains since my work doesn't require these tools (also, I use Eclipse for 15+ years and it works well).…

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.

Re: Docker's Second Death

#172

Post by mikesabbagh »

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…

Podman is not mature yet and it has many bugs. I am currently using it for a project, and lately I am starting to doubt it is prod ready. But it has some security options not available with docker. So Docker is still my first option.

Re: Docker's Second Death

#173

Post by user5994461 »

nikisweeting wrote: post #132
nickjj wrote: post #115

Earlier quoted context omitted.

> 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. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

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/31746182/docker-compose-...

Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that?

IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.

Re: Docker's Second Death

#174

Post by girvo »

nickjj wrote: post #115
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…

> 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. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

Compose plus VS Code’s remote container plugin gives a brilliant development env, and easily deployed to production. I agree with your assessment!

Re: Docker's Second Death

#175

Post by zokier »

cercatrova wrote: post #9
lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure. The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.

> I'm convinced there is no sustainable business model for open source infrastructure

From my personal point of view, the most sustainable way of funding development of free software is through businesses that utilize that software, but whose main business is not that software. The value proposition for the business to open source their software is mainly in getting improvements from outside, and to ensure better integration with other free software. But the main reason to build software should be selfish in the sense that you can directly use it yourself, and not the idea that you could somehow sell the software in some way or form.

Re: Docker's Second Death

#176

Post by mmcnl »

The wording seems so negative. You could also say Docker is evolving to something bigger. And that's a good thing. The simple approach to containers and the workflows that come along with them are nothing short of revolutionary if you ask me, and it will only get better.

Re: Docker's Second Death

#178

Post by bayindirh »

fxtentacle wrote: post #171
bayindirh wrote: post #146

Earlier quoted context omitted.

That's not true. As a FOSS lover, I pay for a lot of tools. Both development related and unrelated. Moreover, some of the tools that I pay extend on FOSS software (Tower, Viscosity, Permute) and some of are FOSS already (Cyberduck). The thing is, as a person I don't want to feel ripped off. I don't subscribe to JetBrains since my work doesn't require these tools (also, I use Eclipse for 15+ years and it works well).…

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 sensible Git UI I've ever used. I also like Tower but, Eclipse both makes sense and helps a lot in the relevant places.

Re: Docker's Second Death

#179

Post by atombender »

yjftsjthsd-h wrote: post #151
joana035 wrote: post #84

Earlier quoted context omitted.

> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.

> It is literally less than 20 lines to define an ingress object. ...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?

Not sure what you think isn't easy about it:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: myingress
    spec:
      rules:
      - http:
          paths:
          - host: example.com
            path: /
            pathType: Prefix
            backend:
              service:
                name: test
                port:
                  number: 80
Since everything except "spec" is common to all Kubernetes resources, this arguably isn't much different than an Nginx configuration file:

    upstream backend {
      server some-backend:80;
    }

    server {
      listen :80;
      server_name example.com;

      location / {
        proxy_pass http://backend;
      }
    }

Re: Docker's Second Death

#180

Post by ucarion »

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…

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.

Post reply on HN