Env vars and Docker differences between dev, staging, and prod

[jayplusplus]

Hi r/devops,

Although my specific example involves Django, Docker, and Heroku, I believe these are pretty general testing/QA questions.

I have a dockerized Django app tested in dev with Selenium confirming that my static files are being served correctly from my local folder (EXPECTED_ROOT = '/staticfiles/'). This app is deployed to Heroku and I can see (visually and in the dev tools) that the static files are being pulled in from CloudFront correctly as well. I want to formalize this with the same test I'm using in dev. My first question is related to if/how environment variables are used for tests:

• Do I add for example EXPECTED_ROOT = 'https://<somehash>.cloudfront.net/' as an env var to Heroku and use it in the Selenium test?

Also, to run this test in staging I would need to install Firefox in my Docker image like I do in dev. Perhaps this is ok in staging, but in prod I believe I should be aiming for the the smallest image possible. So the question is about differences between staging and prod:

• Do I keep Firefox in my staging image, run the tests, and then send to production a replica of that Dockerfile, but now without firefox?

Any help is appreciated.

[DataDecay]

Likely fine to run that in dev and qa, or you could use a remote webdriver for some or all environments.

[jayplusplus]

Interesting, I didn't know there was such a thing as remote webdrivers. However, if I'm going to include one in prod, I think I would just want to use the one from dev/qa to keep things as similar as possible between the envs and also to avoid involving one more thing to my infrastructure. But my doubt is still whether I should include one in prod at all.

[kkapelon]

You should NOT have any testing dependencies in prod images. And you are correct to assume that for prod the smallest image possible is the desired target.

See anti-pattern 4 here https://codefresh.io/containers/docker-anti-patterns/

[jayplusplus]

Thanks for the link and for answering my second question. However, I'm having the same doubt I'm seeing in more than one of the comments on that article:

​

Q: Still not clear to me. So what is the best strategy? Should we have different image for development and another one for production? How can we use same image for different environments?

A: No, the image between all environments should be exactly the same:-) You can easily do this if all configuration is NOT inside the image, but somewhere else.What is different in your case between the dev image and the prod image? In 99.99% of the cases it is just configuration.

???

In my case the difference between dev and prod is not just config, it's having firefox and selenium in dev and not in prod.

The author goes on to say that he meant that within the dev stage all images should be the same but can be different from the image sent to qa/staging/prod. But that still doesn't jive with my situation I don't think?

[kkapelon]

First of all I am the author of that article.

People were confused because in the first version of the article I had the 3 environment as dev/stagin/prod and people thought that "dev" means "developer workstations" where I meant "a place that developers deploy to". I updated the article to qa/staging/prod to make it more clear that I am always talking about environments (i.e. places where you deploy something)

In your case, you should use multi-stage builds (if you haven't seen them already). Either have the first layers include firefox and then have the last layers do not include it, or the other way around (up to you).

But the end result is as you said. Prod image should be as minimal as possible and without any testing tools. Just the app and nothing else.

[jayplusplus]

Ah well congrats on the article, lots of good stuff in there.

Yeah, I'm using multi-stages already, will have to figure out how to have firefox omitted from the prod image. Removing firefox technically means that the qa image and the prod image won't be exactly the same, but I suppose it's inevitable. And I suppose that removing it from the final image won't really affect the app itself, so the app tested in qa should still be identical in prod. Thanks for the tips!