231–240 of 286 posts
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.
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 use Docker Swarm (basically multi-node Compose) in production, and am also really happy with it. It's an order of magnitude simpler than k8s, and perfect for small-medium scale deployments. In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!
Earlier quoted context omitted.
Their collaboration work on integration with WSL 1 and 2 has been fantastic.
What's your workflow with WSL2 and docker for Windows?
They have some k8s stuff I've never looked at, too.
Earlier quoted context omitted.
Isn't this the same? RUN apk update && apk upgrade && apk add foo
Spend some time on docker hub and you'll find thousands of Dockerfiles with RUN . It's dysfunctional.
Earlier quoted context omitted.
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.
The appropriate solution for this is to put your shell code in a shell script and RUN that.
If the Dockerfile is canonical, I should have as much as I can reasonably put into it.
Earlier quoted context omitted.
This is an application-level design flaw, not a flaw inherent to docker-compose. Regardless of whether you use docker or even if you use containers at all, your webapp should be able to restart if the connection to the database fails or is interrupted for any reason. You would have the same problem if you used supervisord for example. The general solution is to auto-retry the connection until it comes back up, or har…
Hm, yes, but to play devil's advocate - if you want compose for orchestration (I don't) then you want that dependence not so much for initial start up, but for triggering restarts on failure. As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.
restart: on-failure
depends_on:
other_service:
condition: service_healthy
https://docs.docker.com/compose/compose-file/compose-file-v2...
Docker still very simple to use, wish i could do the same with some systemd/containerd integration.
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.
https://docs.docker.com/develop/develop-images/multistage-bu...
Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.
Docker Inc put themselves in an impossible situation because they wanted Docker to be a standard and also be a massively profitable monopoly but they didn't have enough moat to pull it off. Red Hat and Google saw the monopolization coming and aggressively commoditized Docker for the good of the community but also for their own benefit. Now the last battle is over Docker Hub.
similar to npm though they'll keep getting second chances since it's the default namespace in the cli