Pushing Portal Updates to AWS

When new features or bug fixes need to be pushed to production, there are a number of steps that must be taken. This guide walks you through the actions for you to take with your local code and in the AWS console. Run through these sections in order. If you added any features that required new or updated environmental variables, make sure you also push those new definitions into production.

Local Steps

In the longer term of the SIMS Portal’s lifecycle, it would be beneficial to create a more organized dev ops solution for pushing these updates. I never took the time (nor had the technical expertise) to fully build out that CI/CD pipeline since I’ve been the sole developer and have rarely engaged with other devs. For now, you have to take a few steps prior to pushing updates that involve changing text in three files.

1. Open code editor, activate the virtual environment, and CD into flask_app. Navigate to the directory where you see Dockerfile, docker-compose.yml, SIMS_Portal, etc.
2. In Dockerfile, comment out lines 8, 9, 10 (everything from ENV FLASK_APP=run.py through CMD ["flask", "run", "--host", "0.0.0.0"]) then un-comment out the last line (CMD ["gunicorn", "--bind", "0.0.0.0:5000", "-w", "3", "--preload", "run:app"])
3. In docker-compose.yml, un-comment line 13 (command: gunicorn --bind 0.0.0.0:5000 -w 3 --preload run:app)
4. In config.py, change DEBUG=True to DEBUG=False.
5. Check that AWS is configured with aws s3 ls – this should return your S3 bucket.
   1. If not, run aws configure and enter key and secret key from AWS console

AWS Steps

1. Open AWS and navigate to ECR (Elastic Container Registry)
2. Select the simsportal repo and click “View Push Commands”
3. Run each of the commands in order
4. After the final command is completed where you push the code up to AWS, we need to restart the service
   1. From the ECS (Elastic Container Service) page under clusters, select simsportal
   2. In the cluster info page, under “Services”, select SIMSPortal then click “Update”
   3. On the next page, select “Force new deployment”. Leave the rest of the settings the same and click “Update”.
   4. Hit refresh back on the “Services” table and the “Last deployment” should still be pending.
   5. Click the “Tasks” tab on the table and refresh, you should see the new one spinning up.

Portal Manual Updates

I haven’t yet updated the routes that handle the data visualizations in the system—including the spinning globe, the about page map, and the active emergencies dashboard map—to utilize S3 rather than local storage. When you push an update, the local files are reset, destroying the changes that have been made in production.

Making that change will require a dedicated sprint to fix all of the utility functions that build and reference those files. As a stopgap, I’ve built a number of manual toggles to rebuild those csv files inside the admin portal. After deploying, make sure you go there, click on the Manual Refresh button, and then run the following functions:

1. Update Active Disasters Map
2. Update Response History Map
3. Update Member Locations Map

Post Deployment Code Changes

The changes we made earlier under the Local Steps section need to be reverted back before doing anything else, like running the app in our local development environment. It’s vital that you change these back as running the code with production settings can trigger things we don’t want, like pushing messages to Slack!

1. In Dockerfile, un-comment out lines 8, 9, 10 (everything from ENV FLASK_APP=run.py through CMD ["flask", "run", "--host", "0.0.0.0"]) then comment out the last line (CMD ["gunicorn", "--bind", "0.0.0.0:5000", "-w", "3", "--preload", "run:app"])
2. In docker-compose.yml, comment line 13 (command: gunicorn --bind 0.0.0.0:5000 -w 3 --preload run:app)
3. In config.py, change DEBUG=False to DEBUG=True.