update docs surrounding IAM permissions, add terraform example

[jpetrucciani]

This PR updates some documentation, and adds a docs/ folder with an example of how to create the required minimum permissions policy and IAM user for AWS to run this tool!

[EverettBerry]

One thing I wanted to add here @jpetrucciani, maybe I can just add it in myself, is the build-args. I am building the container like this: docker build --build-arg AWS_ACCESS_KEY_ID=<ACCESS_KEY> --build-arg AWS_SECRET_ACCESS_KEY=<SECRET_KEY> -t ec2instances.info .

Is that what you're doing?

[jpetrucciani]

Sorry, didn't get a notification for this!

Currently I've been just running with locally configured creds with the minimum user like in this example, with the env configured through nix!

If you wanted to use this through docker, I'd probably say we might want to rethink the dockerfile a bit - iirc, build args will leave traces in the container, potentially exposing your creds. This is tricky though since the docker image looks to want to include the data pulled in the final image. We could make use of multi-stage builds for that, if that's the case - although I'd probably want to split out the actual environment used there (into somewhat of a 'cache' image), pull the data + render into one stage, then build the resulting container with the rendered HTML/CSS/JS. Or, if you want to run it locally just to pull the data, you could build the dockerfile to just be the environment, and have it pass in env vars that can be used to pull at runtime.

Although at that point it becomes a question of how you want to host things - if it can all be statically built out (perhaps on a cronjob?), you may just want to drop it into s3 + cloudfront

[EverettBerry]

That's a great point about build-args, hadn't thought of that. Environmental variables are the way to go with docker. I was looking at #610 and I realized that we can set the host via envvars as well.

Anyway this is good to merge I think. Let me just add a little info from this conversation to the README and I'll put it through tonight. Thanks a lot for the additional details.

[Jeffwan]

That's a great point about build-args, hadn't thought of that. Environmental variables are the way to go with docker. I was looking at #610 and I realized that we can set the host via envvars as well.

Anyway this is good to merge I think. Let me just add a little info from this conversation to the README and I'll put it through tonight. Thanks a lot for the additional details.

I am actually doing the same thing.

docker build --build-arg AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID --build-arg AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY  -t ec2instances.info .

[EverettBerry]

Yep! That's what my command looks like. Perhaps then I give folks that option but give a warning saying it is insecure https://pythonspeed.com/articles/docker-history/

[Jeffwan]

BTW, I notice http port doesn't work once I run docker run -d -p 8080:8080 ec2instances.info. Seems the it's the binding issue? Did you guys see the same problem? When I docker exec into the container and curl 8080 and it works.

[EverettBerry]

Yes, by default the python server works over 127.0.0.1, see #610. Happily you can override this with an environmental variable passed during docker run. You can do docker run --env HTTP_HOST=0.0.0.0 to host over the loopback interface which will then expose the app on http://localhost:8080.

[Jeffwan]

@EverettBerry Thanks for the pointer. It works! Should we update the doc or update default HTTP_HOST to 0.0.0.0?

[EverettBerry]

I think update the docs because setting the port to 0.0.0.0 by default may cause the local site to not load for folks not using docker or on mac and windows.