11 ms·
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 fac
by hmottestad 6y ago
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 the simplest way to install Elasticsearch, to make sure everyone on your team is using the same Java version, or run up a production equivalent environment on your laptop. Regardless of if you are on Linux, Mac or Windows.
I still love Docker and hope they end up finding a good business model so they can continue to live on.
- grogenaut 6y agoBack in 2013 before I took a job at amazon but after working with a game dev for playstation I had 2 months off, playing with docker I realized how good it's be for crap like chroot jail dev or multi-project dev env isolation. There were big blockers for it being used this way then. I did some chatting with the docker team and we did push things a little in that direction. But the vision was still about running in prod. To their credit the docker folks I talked with did listen and respond and move the needle (obviously) on it being a local dev tool, so I cheer them for that. I use it all the time in my windows box for dev. Tho I do try and keep my software able to run on any os.
- politelemon 6y agoTheir collaboration work on integration with WSL 1 and 2 has been fantastic.
- alexellisuk 6y agoTake this post with a hint of bias as it's written by a Red Hat'er - if you ask an employee what the "next thing" is, I wouldn't be surprised to hear "podman" (which is an opinionated docker clone) The number of Docker Desktop installations and the popularity of local Kubernetes tools (think KinD, k3d) show that "Docker got boring" which is an aspiration for infrastructure tooling.
- tariqislam_ 6y agoAuthor here. I no longer work for Red Hat these last few years, and my words are strictly my own. I wanted to communicate what's happening now in the context of what I experienced from Docker's early days in the industry.
- musicale 6y ago> Red Hat'er Hat'ers gonna Hat. (disclaimer: author does not actually work for Red Hat.)
- tpetry 6y agoPodman would be next big thing if: 1. they make a package like docker ob mac where you dont have to fiddle with manually starting vms. An environment where using docker feels native 2. When they start the vm to run podman they will use qemu on arm to simulate an x86 machine and run x86 containers The second one will be a huge step forward as docker will not be able to do this for a long time as they use the mac hypervisor which can‘t run x86 vms. Podman would enable again prod/dev comparability which may work for redhat to more people switching to podman even for their production systems.
- freedomben 6y agoAgreed, podman needs better support for mac. It works fine under Windows WSL2 currently, see: https://www.redhat.com/sysadmin/podman-windows-wsl2 https://www.redhat.com/sysadmin/podman-windows-wsl2 The Podman team is working on it but it's not quite there yet. Podman now has an API so at a minimum the whole opaque VM thing should be usable here soon. podman-machine and boot2podman already work for some people, although they didn't work for me. I have a dream of using a lightweight Fedora Core OS VM on Mac/Windows for running the containers with a podman-remote client seamlessly driving it from the Mac user space. Once podman-remote is working, that's my next plan ;-) A self plug here, I'll be keeping an eye open for all of these things and will blog about once I get it reliably working. I'll be submitting it to the Red Hat developer blog but I cross publish everything I write to medium as well in case you want to look for it: https://freedomben.medium.com/ https://freedomben.medium.com/ I'm also starting to tweet when I blog (I'm finally getting serious about it now haha) @Freedom_Ben on twitter.
- Donckele 6y agoPhew, thanks for that. That article got me all agitated, thinking a core piece of tech I use is on its death bed with no alternatives.
- deleted 6y ago[deleted]
- hacknat 6y agoThere’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 been replicated. If they fail as a company it won’t matter to developers who don’t use their enterprise software. I actually think the company isn’t long for this world. It wouldn’t surprise me if they got bought for a paltry sum in the next few years. Their lasting legacy is that most software and people assume that a shortened container image points to docker.io. 1 https://fedoramagazine.org/docker-and-fedora-32/ https://fedoramagazine.org/docker-and-fedora-32/
- viraptor 6y ago> you actually can’t install Docker on Fedora anymore Moby is docker effectively. Your link describes how to install docker on Fedora.
- raesene9 6y agobuildah/podman/skopeo are nice tech. and all, but they don't exactly mimic the setup of Docker for Windows/Mac. If for no other reason that, they don't do Windows containers :) I know of quite a few corps using Windows containers in prod. now, take up may have been slow, but it's happening. Also Docker for Windows/Mac have an easier install/setup process than manually setting up VMs and installing tools on them.
- nobleach 6y agoAre you absolutely certain? I had to hack around a bit but I got it running just fine: https://ibb.co/X7dpt7g https://ibb.co/X7dpt7g
- veeti 6y agoPodman is 1:1 compatible for running hello world. Your mileage in real projects will vary.
- 6y ago
- ampdepolymerase 6y agoA bigger issue is the fact that they were not able to become a unicorn despite having a tremendously popular product. It means there is no money in development tools innovation. This is not a good thing for the software community as it means all tooling innovation will only done and controlled by the FAANGs.
- santoshalper 6y agoI don't think that's a good read on the situation. I think a better analysis is that there is no money being what amounts to a facade on top of an operating system/kernel capability. All the real novelty and challenge to containers is in the OS itself. Everything else is more or less ease of use, which is important but relatively easy to replicate. In the span of 5 years or so, Docker went from being critical glue code to cruft.
- ampdepolymerase 6y agoThat facade enabled millions to have easy access to that particular kernel feature. BSD jail's have been around for decades without mass adoption.
- freedomben 6y agoI think the GP's point is that alternatives can easily spring up when the main feature-set/value is in the kernel rather than the glue code.
- int_19h 6y agoBSD jails weren't widely adopted because the BSDs themselves weren't widely adopted by the time the industry got to the point where something like Docker was increasingly seen as necessary. I remember being involved in one project that had to decide this exact question in the very early days of Docker - jails were much more stable back then, but customers wanted Linux containers, not "sufficiently Linux-like".
- freedomben 6y ago
- brainzap 6y agoI wish we could replace Dockerfiles already with a format that allows for fine grained layer control.
- enos_feedler 6y agoWhat kind of control are you looking for?
- yjftsjthsd-h 6y agoI'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.
- hiram112 6y agoIsn't this the same? RUN apk update && apk upgrade && apk add foo
- kelnos 6y agoIt is, but the syntax is uglier. Also imagine that you might want to do more than just RUN in a single layer. Maybe COPY some file into the container and then RUN something that uses it.
- yjftsjthsd-h 6y agoIn the simple case, yes it is, but it scales poorly; consider ex. https://github.com/docker-library/postgres/blob/b9c080857b880202ebd23c59d33fe86d7a70fea3/13/alpine/Dockerfile#L24 https://github.com/docker-library/postgres/blob/b9c080857b88... which is 112 lines run together like that to keep things in a single layer. This is pretty bad for readability. Also, as sibling comment notes, that only works for RUN commands, not other or mixed groups of commands.
- 6y ago
- pjmlp 6y agoNot necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word. Containers should be about security not cloning local development environment.
- majewsky 6y agoSandboxes are about security. Containers are about deployment tooling. Some containers happen to include/use sandboxing techniques.
- pjmlp 6y agoI have used container based technology for about 20 years now, starting with Virtual Vault on HP-UX, and happen to know a couple of things about what containers are supposed to be.
- FartyMcFarter 6y ago> Containers should be about security not cloning local development environment. Why not? One way to use containers is as a light-weight virtual machine without a kernel, which can be pretty useful.
- pjmlp 6y agoA workaround for broken development practices.
- nickjj 6y ago> 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 Compose with Go to make it more consistent with their main CLI. Looks like full steam ahead to me rather than death. It's really nice having the same Dockerfile + docker-compose.yml get used in dev + ci and prod. There's no surprises and no massive amount of complexity. [0]: https://github.com/docker/roadmap/issues/15 https://github.com/docker/roadmap/issues/15
- nikisweeting 6y agoI 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 limits and define startup order with healthchecks because we don't need the complexity of swarm and v2.4 provides everything we need. Sometimes simple is best. I personally use compose to manage services on my own laptop and homelab as well, it just has the massive advantage of being the greatest common denominator that everyone can pick up in a few days if they're familiar with basic container concepts.
- fredthomsen 6y agoCouldn't agree more. compose is a wonderful tool that lets you avoid the k8s complexity if you don't need it.
- deleted 6y ago[deleted]
- simplecto 6y agoExactly this here as well. I have helped setup a few successful SMEs with Docker, Compose, and some CI/CD best practices. They are running 7-figure businesses on the backend.
- setheron 6y agoTake a look into NixPkgs / NixOS
- pmontra 6y agoIt 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.