So you’ve been frantic as you try to fix a bug. You get lost in the work and totally forget where you are. All of a sudden… SUCCESS! It works!
But oh no, you just put your secrets into a tracked file. What to do, what to do…
So I’ve been saying “you”, but I really mean “me”. Here’s a short summary of my project, then we’ll get into how I fixed it.
- Web app coded in Python
- Using the Django web framework
- Using Docker with a Dockerfile and docker-compose.yml for containerization
- Deployed to Heroku
- Had a problem serving static files on Heroku and not locally, so I implemented an Amazon S3 bucket for remote file storage, which requires secrets!
Up until this point, I’ve tracked my docker-compose.yml file so that if I want to work on this project on another computer, it will be easy to clone and get going. But I’m hosting this code on GitHub and may share it some day, so I don’t want secrets available.
Fixing Django’s SECRET_KEY
My docker-compose.yml file has my Django SECRET_KEY inside it. When prepping to deploy to Heroku, all I did was generate a new key and place that in my Heroku app as a config var.
This means that the public version of my site has a hidden SECRET_KEY.
But I didn’t want to try to generate a whole new set of credentials for my AWS S3 bucket because this is really my first time using it. I have been debugging this static files problem for over two weeks now and just want it to work. So instead of messing around with more credentials, let’s find another solution.
Serving Django’s Static Files from AWS S3 Bucket
To solve my static files problems, I went looking for a mentor. Matthew Freire of JustDjango (site, YouTube) suggested that Heroku won’t let me serve my files from the same server as my Django site and that I should use an S3 bucket.
I found a tutorial from testdriven.io that was fairly recent and uses Docker, and that was extremely helpful.
I needed to commit and push my changes to Heroku to see if this change would work. When it did, then I realized I needed to remove those keys. Oops!
Fixing AWS Keys
After realizing my keys were in my settings.py file, I set up environment variables and put the keys in my docker-compose.yml file, which is where I’ve stored all my environment variables.
But then I realized I’m tracking docker-compose.yml, too! So I went looking for a new solution.
I found a concise article from David Walsh on using ``docker-compose.override.yml`. <https://davidwalsh.name/docker-compose-override>`__ When building your Docker image with docker-compose.yml, it will take whatever’s in your docker-compose.override.yml file and use it to replace old things and add new things.
Don’t forget to add docker-compose.override.yml to .gitignore.
Then check to make sure it works. Mine does!
What Changed in the Previous Commit?
For my particular scenario, my previous commit was the one that had the secrets in it. So I want to amend that one.
But let’s make sure we’re not missing anything.
Outputs hashes of previous commits.
git diff <HASH1> <HASH2>
This will walk you through the differences between the two commits. I used the command git diff a08db22 04d80e7, which says, “What changed from commit a08db22 to 04d80e7?” Keep hitting enter to scroll.
I first see that my Pipfile and Pipfile.lock have changed. This is good because I wanted to install boto3 and django-storages to get my S3 bucket working.
Next change I see is in settings.py, where we’ve added 'storages', to my INSTALLED_APPS. All good here.
Then, further down, we see the problem. My AWS key variables are pasted in there! Make a note that we need to make sure that we want to amend that change in settings.py.
There are just a few other changes, but nothing that needs to be hidden.
Amend Previous Commit
So I had four files to change:
But since we ignored the new docker-compose.override.yml, then only three files should show up as changed when we ask git to check.
Perfect, our three files show up. Now let’s check what is different since the last commit.
Nice! Environment variables! Repeatedly hit ENTER to make sure everything is good.
git add -A
Stage these modified files.
git commit --amend
Amend the previous commit. A screen will pop up with the message you gave the commit. Adjust as needed, save, and exit.
One last note: maybe push your changes to your remote repository :)
git push origin master