Docker Container Anti Patterns

blog.arungupta.me

18 points·vegasbrianc··5 comments

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.

> 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)

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?

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

> Data or logs in containers

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

Reply on news.ycombinator.com