top | item 12908636

Docker Container Anti Patterns

18 points| vegasbrianc | 9 years ago |blog.arungupta.me | reply

5 comments

order
[+] Terretta|9 years ago|reply
I read "anti-patterns" but then it lists a lot of good things to do, with a few anti-patterns mixed in.

Fix the bold to be patterns or anti-patterns, not both, or change the title to be something like lessons learned.

[+] mikewhy|9 years ago|reply
> Don’t use different images, or even different tags in dev, test, staging and production environment.

Can anyone comment on this? For example, many node projects have a list of devDependencies that have no use in production, so we build 3 images:

1. A base image with basically `NODE_ENV=production npm install`

2. A test image from the base with `NODE_ENV=development npm install`

3. A production image from step 1 with the CMD set.

Is this part of an "anti-pattern"? I thought it was how you'd get efficiently sized images in this situation.

(And yes, now that I write this I realize there only needs to be 2 images, the production one, and the test image is built from that)

[+] mattbroekhuis|9 years ago|reply
Are you moving that dev image through the lower environments, or the prod one?

If it's the prod one, I think your pattern is fine. If it's the dev one I would feel like you're opening yourself up to potential issues by confirming things on a different binary than you are publishing to the real world

What do you actually do with that dev image?

[+] oherrala|9 years ago|reply
> Data or logs in containers

Instead of volume mapping like the article suggested, why not just log to stdout?