About 4 years ago, I was still working in web development. At that company, we used Django extensively, and so when it came time to create my own website, I chose to create it in Django. There are a lot of things I like about this framework, but my favorite feature is the speed of development. In my experience with Node, the sheer number of external packages can be overwhelming. Django on the other hand includes pretty much everything you need. This made it a perfect choice for me. Because of my busy schedule, I wanted something that would get me up and running as fast as possible, but also wanted something that would be flexible enough to expand on later and customize however I liked.
Of course, it has now been 4 years and I still haven’t deployed this website to its fullest extent. Over my final fall break as an undergraduate, I finally decided to change that. The only problem was that after 4 years, some of the technology I used was starting to show its age. Django itself had seen 2 major version updates since then, and the rich text editor was in the process of being deprecated. Also, the hosting service I used, Heroku, changed their free plan.
When I first designed this website, I wanted to make it as easy as possible for me to upload new articles. As part of this, I chose to integrate AWS as a solution for any uploaded media files. This was really cool, as it integrated directly with the rich text editor plugin I was using. That meant I could edit blog posts just like any other document directly in my website, even when it came to uploading pictures. However, revisting the project several years later I discovered that CKEditor, the WYSIWYG editor plugin I used was no longer considered secure, and so I decided to replace it. Instead, I found a really great Markdown editor. This one is great, but it doesn’t include AWS integration. In the end, I decided this was fine though. I can still embed images in blog posts with a url, so as a workaround I can just manually upload images to my S3 bucket, or even to this websites static files, and simply embed the link there.
Previously, I had used Heroku for server hosting, but as I mentioned, their free plan had changed, and it would now be significantly more expensive to host through them. Plus, the ase of I wanted to shift to a more long-term, budget friendly approach that would ensure I still have access to all my files even several years down the line. There are a lot of benefits to “Platform as a Service (PaaS)” solutions like Heroku, but I was interested in moving away from that kind of service. While they do tend to make deployment very easy, for a long-term project like this I didn’t want to be locked into specific pricing plans. Instead, I decided to invest some additional time up front and manage my own server. Luckily, I’ve had quite a bit of experience working with Ubuntu, so I chose an Ubuntu server hosting provider (DigitalOcean due to their extensive documentation and reputation) and decided to move forward with setting up an Apache server that could serve my website.
Admittedly, this took longer than I anticipated, but it was a great review of basic server administration principles. While I won’t go into detail on how to set up this server, (there are plenty of guides available, like this one!) I wanted to cover some of the questions I ran into.
Ok, first we have to cover what WSGI is. WSGI is a Python standard. Basically, it is a common language that a web servers can use to communicate with Python web frameworks. Django is just a framework, not a web server. It’s designed to help you create the logic and templates which drive your website, but it doesn’t actually SERVE those files on its own. Instead, it presents that information to the webserver using a predefined standard. That way, webservers can support many different Python frameworks, as long as they also comply with the WSGI standard.
Apache doesn’t support WSGI out of the box, but it’s fairly easy to install a plugin to do so. For this, I mostly just followed the documentation , but there were a few steps that were a little unclear. I first used curl to download the latest release of ModWSGI. The documentation only specifed source code locations though, so I’d have to build from source. This wasn’t a huge deal, as there were relatively few additional dependencies. After following the instructions to point ModWSGI to my virtual environment and make the project, I got a .so file in the /lib/apache2/modules directory. If you’re unfamiliar, .so files are binary files that typically contain dynamically linked libraries, or libraries which are run “on the fly” after the main program is already compiled. In order to make the Apache server actually see this module, I still had to create another file in the “mods-available” directory of Apache containing a LoadModule command, and enable it.