DemocracyClub / yournextrepresentative / eac7a561-dd52-408e-a5ea-bff988415cdb / 1

68%

master: 71%

push

circleci

[WIP] deploy/cdk: use YNR container image

This currently-broken WIP replaces the example container image in the toy
Fargate service deployed by the CDK with the YNR container image.

The CDK can't currently complete a deployment of this setup, probably due to
the following events never permitting the ECS Service to settle and consider
itself properly deployed to Cloudformation's satisfaction:

    [xx:24:19 +0000] [1] [INFO] Starting gunicorn 23.0.0
    [xx:24:19 +0000] [1] [INFO] Listening at: http://0.0.0.0:80 (1)
    [xx:24:19 +0000] [1] [INFO] Using worker: sync
    [xx:24:19 +0000] [8] [INFO] Booting worker with pid: 8
    /dc/ynr/code/ynr/wsgi.py:26: UserWarning: Not reading /dc/ynr/code/.env - it doesn't exist.
    dotenv.read_dotenv(
    [xx:25:15 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
    [xx:25:16 +0000] [1] [ERROR] Worker (pid:8) was sent SIGKILL! Perhaps out of memory?
    [xx:25:16 +0000] [15] [INFO] Booting worker with pid: 15
    /dc/ynr/code/ynr/wsgi.py:26: UserWarning: Not reading /dc/ynr/code/.env - it doesn't exist.
    dotenv.read_dotenv(
    [xx:25:49 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:15)

... and so on, indefinitely.

Reports of this problem on AWS, either behind a load balancer or using ECS, can
be found online going back to 2016
(https://github.com/benoitc/gunicorn/issues/1194), and remedies include
switching to "gevent" workers, increasing gunicorn's --timeout setting, or
increasing gunicorn's --keepalive setting.

This change is WIP because the manual CDK deployent of the YNR service doesn't
complete successfully.

1556 of 2825 branches covered (55.08%)

Branch coverage included in aggregate %.

7446 of 10460 relevant lines covered (71.19%)

0.71 hits per line