261–270 of 275 posts
Earlier quoted context omitted.
> You can pretty much replace "docker build" with "go build". Interesting. How does go build my python app?
It obviously means you dont use a scripting language, instead use a real langauge with a compiler.
Earlier quoted context omitted.
Dockerfile has the flexibility to do what you want though, no? Use a base image with terraform or puppet or opentofu or whatever pre-installed, then your Dockerfile can just run the right command to apply some declarative config file from the build context. And if you want something weird that's not supported by your particular tool of choice, you have the escape hatch of running arbitrary commands in the Dockerfile.…
The loose integration between the declarative tools and the container build system drags down performance and creates a lot of footguns re: image size and inert declarative-build-system transitive deps left lying around, I’ve found.
I'd get your worry if we were talking about splitting up a terraform config and running it across multiple RUN directives, but we're not, are we?
> If you are a developer, our goal is to make Docker an invisible companion I want it not to just be invisible but to be missing. If you have kubernetes, including locally with k3s or similar, it won't be used to run containers anyway. However it still often is used to build OCI images. Podman can fill that gap. It has a Containerfile format that is the same syntax but simpler than the Docker builds, which now provid…
I've not done serious networking stuff for over two decades, and never in as complex an environment as that in the article, so the networking part of the article went pretty much over my head. What I want to do when running a Docker container on Mac is to be able to have the container have an IP address separate from the Mac's IP address that applications on the Mac see. No port mapping: if the container has a web se…
As another commenter mentioned, Colima is a good alternative to Docker Desktop if you're looking. It doesn't expose container IPs either, but docker-mac-net-connect does support Colima ootb now.
Earlier quoted context omitted.
Is it though? If the way that I’m going to edit those files is by typing the same natural language command into Claude code, and the edit operation to maintain it takes 20 seconds instead of 10, to me that seems pretty materially the same
Yes, it is
Earlier quoted context omitted.
Curious what you build/work on? If you're only shipping software library or tools, then yeah, your perspective makes sense - `asdf` or `mise` seem superior to `devcontainer`s. But I wouldn't want to deploy a web application without Dockerizing it.
Mostly web applications actually. Most web stuff is not that complicated. Usually the deployment itself is from docker (ops insists) but I just do development without it and I've never had a problem. I understand in theory I could get mismatched versions of things from production and thereby introduce a bug; in practice this has never happened a single time.
Earlier quoted context omitted.
Most software doesn't need to resolve users. You also can always shell out to `id` if you need an occasional bit of metadata.
That's a fair point, and shelling out to id is probably a good solution. I guess what bothers me is the software authors who don't think this through, leaving applications non-functional in these situations. At least with Go, if you do CGO_ENABLED=0 , and you use the stdlib functions to resolve user information, you end up with parsed /etc/passwd instead of shelling out to id . The Go stdlib should maybe shell out to…
Earlier quoted context omitted.
The loose integration between the declarative tools and the container build system drags down performance and creates a lot of footguns re: image size and inert declarative-build-system transitive deps left lying around, I’ve found.
Why would terraform leave transitive steps around? To my knowledge, Docker doesn't record a log the IO syscalls performed by a RUN directive, the layer just reflects the actual changes it makes. It uses overlayfs, doesn't it? If you create a temporary file and then delete it within the same layer, there's no trace that the temporary file ever existed in overlayfs, correct? I'd get your worry if we were talking about…
Random examples off the top of my head: Puppet has a ton of transitive Ruby libraries and config files/caches that it leaves around; Terraform leaves some very big provider caches on the system; plan or output files, if generated and not cleaned up, can contain secrets; even the “control group” of the status quo with RUN instructions often results in package manager indexes and caches being left in images.
Those are all technically user error (hence why I called them footguns rather than defects), but they add up and are easy mistakes to make.
Earlier quoted context omitted.
> the Dockerfile has continued because of its flexibility I wish we had standardized on something other than shell commands, though. Puppet or terraform or something more declarative would have been such a better alternative to “everyone cargo cults ‘RUN apt-get upgrade’ onto the top of their dockerfiles”. Like, the layer/stage/caching behavior is fine. I just wish the actual execution parts had been standardized usi…
Oof, not terraform please. If you use foreach and friends, dependency calculations are broken, because dependency happens before dynamic rules are processed. I'd get much better results it I used something else to do the foreach and gave terraform only static rules.
Do you mean that if you use a dynamic output in a foreach, Terrafom can error? Or are you referring to “dynamic” blocks and their interactions with iterators?