I just want to make absolute sure that this is NOT the case. Does this mean that docker images built with `docker build` and pushed up to dockerhub will no longer be useable in kubernetes or not?
[deleted]
Docker's Second Death
191–200 of 286 posts
Re: Docker's Second Death
#192I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the…
I agree with you. Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it. k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and pani…
You summarized the last part of my post. In part, I wrote this article because I wanted to give a little bit of history on why docker is being deprecated at all, where it's being deprecated, and that meant calling out the fact that Docker Inc, at one point, tried to make docker into an enterprise platform.
My other intent was to clarify that this has little impact on the runtime, because Docker was never the runtime, it was always containerd.
Re: Docker's Second Death
#193Earlier 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 have always wanted that too.
the way to create small docker image is:
RUN apt-get install foo && \
do bar && \
do more && \
remove all of the crap you don't want
You can use multi-stage builds, but they are sort of hacky and do not match your thinking.
You can also use --squash but it is a hack too and usually is not available where needed because of experimental.
Also, ADD is stupid.
You can add a tar.gz file and it will expand it (but you can't use -k)
You can add the same file using http/https, except it WON'T expand it so back to the RUN dilemma you get:
RUN apt-get install wget && \
wget foo.tar.gz && \
tar xvkf foo.tar.gz -C dir && \
rm foo.tar.gzRe: Docker's Second Death
#194Earlier quoted context omitted.
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 ba…
> "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control.
But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations).
For that I wrote a simple Bash script at https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.
Re: Docker's Second Death
#195Earlier quoted context omitted.
It depends on what that infrastructure is. Docker owes its existence to the OS not providing an adequate interface to create lighter containers than 00's style virtual machines. They chose to be imported and used as part of the stack by kubernetes instead of offering a better solution, which was clearly where kubernetes was headed. This one is less of a model question, than a market position question. Elastic, on the…
>Elastic on Amazon is a great gateway drug to Elasticco's offerings. Why is that? Is amazon not able to run it properly?
AWS is several versions behind, and only supports a limited number of plug-ins and does not allow custom plug-ins.
Re: Docker's Second Death
#196Does 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. ?
No. Nothing will change in terms of support for Dockerfiles or support for running Docker images. The whole thing is massively overblown.
Re: Docker's Second Death
#197Does 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 heavyweig…
> There's nothing really practical to replace that artifact at this time if you ask me.
I am required by law to spruik Cloud Native Buildpacks. For most uses, I feel Dockerfiles are not necessary or desirable at this point.
Disclosure: I've been around CNBs for a while for Pivotal and now VMware.
Re: Docker's Second Death
#198Earlier quoted context omitted.
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 ba…
Docker compose development was compromised by the agenda of pushing people to use swarm.
This is why v2 features like resource limits were moved under the deploy: key and you have to use the special "--compatibility" flag to get them to work locally.
Re: Docker's Second Death
#199Earlier quoted context omitted.
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 ba…
> "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database. Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control. But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'…
Wait for a TCP port to come up or wait for a HTTP healthcheck to succeed. I think it's exactly the sort of things that should be supported by the tool out of the box. It's a very common need.
The job of the tool is to manage a bunch of containers that depend on one another and restart them on failure. The tool has to know about dependencies and liveness anyway.
Re: Docker's Second Death
#200Earlier quoted context omitted.
A 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.
I work for Red Hat but I'm a long time fan and user of Docker. I don't think that's what this means at all honestly. Docker (the company) made some poor decisions that led to their troubles. I'm not here to crap on docker, but they quit investing in and moving their tool forward because they were focused on the EE offering. This opened the door for "competitors" to do the things docker wasn't doing (daemonless, rootl…
for me it seemed:
- they stopped evolving the Dockerfile. Really this is the complexity killer that developers just "get".
(also they wouldn't have their entire API cloned if they were moving it forward)
- they subtly force everything through docker hub and conveniently forgot to do something like let people have a local repo. (redhat lets you define a local repo with --add-registry)
- telemetry. I went to install it on macos and it started collecting telemetry the moment I launched the installer.