
Docker Container Anti Patterns - vegasbrianc
http://blog.arungupta.me/docker-container-anti-patterns
======
Terretta
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
> 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
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?

~~~
mikewhy
The dev image is just used to test on a CI server, if everything passes the
production image is sent to our registry.

------
oherrala
> Data or logs in containers

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

