this post was submitted on 02 Aug 2023
1449 points (98.0% liked)
Programmer Humor
31779 readers
851 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think I'd probably consider myself at/near expert-level with Docker, but CI/CD runners instanced in containers just doesn't work for some of our workloads.
As an example, some of our projects have a bunch of Docker images that get built via their own Dockerfiles in the repo, are ran and discarded during the workflow, and each one is modifying the checked-out source tree in some fashion (NPM stuff, composer, whatever, etc), and then a final prod Docker image is built and tested from that source repo tree that has been modified by the Docker containers built/ran/discarded during the workflow. So in Gitlab, it sounds like we'd be running Docker in Docker for some projects.
You ever ran Docker in Docker? It's temperamental at the very best and there are a thousand gotchas associated with it, not to mention having to worry about how many variable scopes deep you are and keeping track of that, how to properly bind mount volumes into the nested Docker containers because the method and paths will vary depending on how nested you are, etc. It's just an absolute nightmare to deal with all-around in that context.
I'll see if we have some projects I can try out on it, but the majority of ours are like what I described above.