Day 17 Deploy This Baby II
Day 17 Deploy This Baby II (go to project overview)
My first plan for deploying was fraught with rerouting. But, I have my reroute plan in place. It is:
- Build the docker container using help from this article.
- Deploy the container to digital ocean using help from this article or, maybe this.
Really, just looking for a way–not all the ways
I did quite a bit of searching and reading to try to understand what I need to do to build a container and there is a ton of info and multiple ways.
Github actions is something I just learned about today. My plan was to tackle continuous deployment later. I have a few things I’ve prioritized above CI/CD. Also, even if Github actions is the best and fastest way to deploy, don’t I still have to learn how to set up Jenkins?
I need to stop with the numbered lists for these reasons:
- Joking!!
How much should you know before you go?
Yesterday, I managed to get a working docker container for my production site. It’s using nginx and Gunicorn. I trusted the article listed in #1 above. There are so many things I only know lightly. This whole process has taken me down a bunch of paths that illustrate this fact. As a programmer, you have to deliver stuff. My practice has always been to know what I need to know to deliver quality code. And, we all know quality is on a scale and different projects are rightly on different places on that scale. I’m trying to approach this using best practices and higher understanding than I usually strive for. However, I’m still using some things about which I have a very low level of understanding.
Thanks, testdriven.io!
Today, I’m going to use this article to set up my container to use https and a Lets Encrypt certificate. The testdriven.io articles I’ve been using have been very useful. I’m not doing things exactly as outlined and I’m not having any trouble using their instructions for my project. Thank you to the people who wrote these (Michael Herman, Jan Giacomelli).
The additional code they’ve added includes a flake8. I have a ton of PEP8 violations in my code. I’m going to go ahead and correct them. That’ll be fun. … many changes later… It took a bit. Most of my files had troubles. I have read the pep8 stuff way back when. I love tabs (or did before I just had to correct all of them). Not proud of how my code did NOT conform to PEP8.
Nothing is easy
I know from past experience that when things don’t work as expected, you learn something. But, I’m always disappointed. My inclination is to not want to learn any more today. My container built, but it’s not acting as it’s supposed to act. In order to troubleshoot, I’m going to need a great deal more about all of the Docker, Gunicorn and Nginx, probably. I like troubleshooting, but it always interferes with my timeline.
Hours later with a broken ego…
I’ve rebuilt this from scratch using the exact instructions and end up with the same result. I looked at another tutorial and the suggestions from deploying to AWS. Pretty sure I failed to understand that this was supposed to have been deployed to a public-facing server. I truly don’t understand why I can’t get to the site from my vagrant machine. I think that really means that I truly don’t understand networking. No surprise there. I think I need to deploy it to a DigitalOcean (or Amazon) server. I feel stupid and sad about not understanding this. Learning the hard way is no fun. I do think it helped me to go through all of the courses before-hand, but there are some concepts I didn’t get. PFFFT!
When you have no idea, you have to read to get an idea!
It may serve me well to follow this tutorial also.
It suggests you use more servers, so more expensive, but it may be useful to help me understand what’s going on.
This DigitalOcean question helped me with docker.
Another helpful discussion.
But, the reading didn’t help
So, I Finally, I went back to the original tutorial and realized I’d stopped too soon. I didn’t do the work to serve up static files so niether custom css nor js worked. Once I got that fixed, I had trouble getting the admin static files. I knew I needed to run the CollectStatic command, but it wasn’t working mostly because I had a few issues with the way I set up the setting configuration.
While researching all of this, I found this good article, which makes me think I really need to restructure my project. Always something!
Major side-track coming up
The problem was probably permissions to static files. This is something anyone who has deployed a Django site from scratch knows. I only worked in and around the production deployment in the past. I didn’t have to set it up from scratch or debug problems. Now, I know. I really have no idea what got this working. When I do a diff on the nginx/vhost.d/default, I can see that, I took the trailing slash out of the alias. It started working when I put it back. I’m guessing that’s what ultimately fixed it. I don’t remember where I was knowledge-wise when I did this, but my guess is that I read something that said to take out the trailing slash, so I did. It didn’t work, so I kept searching, but never put back the trailing slash.
You have to know about collect static to deploy to production
All-in-all, I think it was my (manage.py) “collectstatic” ignorance that got me. There was a bunch of info that made it sound like I needed to change the permissions on the static folder and all of its parents, but I did that with no success. Also, I commented it out and static files are still being delivered.
Next problem: 502 Gateway blah, blah, blah
I did a bit of googling. There are a bunch of possibilities but I found this stack overflow post and Frank’s suggestion made me think that I needed to allow incoming traffic from my droplet to my db. Many moons ago, I knew I’d need to do this, eventually, but I forgot. After I did that, all worked well.
When it still hurts after everything is working
Well, that was painful. I guess I have been shown, yet again, you can’t just follow some instructions—great though they may be—and have a working anything. You always end up having to understand more than you wanted to understand. It’s a blessing, really, because you don’t want to have to support production problems on something that didn’t cause any trouble while you were developing it. Still, very painful.
Also, while I went back to their instructions many, many times and looked at their github repository many, many times, I didn’t start from scratch. I was retrofitting their instructions to a working Django project (working in dev). So, that added to the complexity.
Next, I have to make sure it passes the twelve factor rule regarding public repositories and secrets and make the GitHub repository public. After that, I’m calling it done!
