tryolabs / aws-workshop Goto Github PK

I got an error in my first deployment:

[stderr]botocore.exceptions.ClientError: An error occurred (AccessDeniedException) when calling the GetParameter operation: The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access. (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 5f642215-959a-11e8-bfd1-81a81941d54a)

when the script tried to read the DB_PASSWORD parameter. I went back to the Encryption keys manager and granted the CodeDeploy role access to use it. I was wondering whether I messed up at an earlier step or it's necessary to configure access for the role.

While deploying the code using Auto Scaling groups I found that there's no access granted for inbound TCP connections for Postgres. Adding api-security-group to the DB security groups list allows access from the load balancer to the DB but not the instances themselves (see here).

I ended up adding a new rule to the group to allow inbound access (TCP 5432) to itself. Though, a more secure approach would be to create a new security group that granted inbound access to the E2 instances security group (i.e db-access-sec-group). api-security-group should only allow the load balancer to access the auto scaling target group instances.

https://paper.dropbox.com/doc/AWS-Workshop-Notes-XLUxW7xdWOafhou8MZUJv

I will be working on fixes to clarify some aspects of the first part (arbitrarily defined by me as points 1 and 2 from the contents in the README.md).

Versions in the Pipfile should be bumped, as the old versions of django in use seem to be incompatible with some of the dependencies marked with *. At least in my case, bumping dependencies solved some weird problems with the API.

Ideally, one would then use pipenv sync instead of pipenv install to deploy the exact locked version, so that these issues don't arise again if in the future some library gets updated.

The gunicorn configuration file now needs to be a .py file. See here:

The third source of configuration information is an optional configuration file gunicorn.conf.py searched in the current working directory or specified using a command line argument. Anything specified in this configuration file will override any framework specific settings.