Before we get started, I'm assuming you've mastered or completed the first part of the tutorial, your site code itself is complete, your virtual environment is functional in local development, and you have your domain name pointed the IP of the EC2 instance we just made. If any of these assumptions are false then you are probably getting ahead of yourself.
In your EC2 box, run these two commands:
sudo mkdir -p /var/www/[my-site] sudo mkdir -p /var/www/static.[my-site]
Remember, production Django is begging and pleading to not be asked to serve your static files for you -- so let Apache handle that part!
PRO TIP: The
-pflag will create any intermediary steps in your mkdir command for you.
Next it's time to get your code onto your webserver. Since you are pro, using Django, EC2, and reading this pro blog, I'll assume you're using Github. (If not, just think--today can be the day you switch!) Either way, get your codebase into the
/var/www/[my-site] directory you just made.
PRO TIP for those using Github: When you created that working directory, it was owned by root:root. That means to execute a
git clone in the directory you would have to use sudo.
THIS WOULD BE BAD SO DO NOT DO THIS ON PENALTY OF LOTS OF WASTED TIME.
Instead, run these commands:
sudo chown ubuntu:ubuntu /var/www/[my-site] sudo chown ubuntu:ubuntu /var/www/static.[my-site]
Now you can safely run:
git clone email@example.com:[my-github-path] /var/www/[my-site]/
This step is like taking a nap since you already have that magic happening in your local environment. I personally like to keep my virtualenvs within my projects in a
venv/ directory, but you do whatever gets your rocks off.
In short, adapt this sequence of commands to your needs:
cd /var/www/[my-site] virtualenv venv # PRO TIP: Avoid `sudo` source venv/bin/activate pip install -r [path-to-your-requirements-file] #PRO TIP: Avoid `sudo`
You will know this worked if, only AFTER the pip command finishes, you have a bunch of recognizable packages in
/venv/lib/site-packages/. If you peek ahead of time you won't see any evidence of progress, so sit tight.
I'm lazy, and ultimately only OK at server administration. Thus, I put all of my various server configurations right in the httpd.conf file. I know, I know. SysAdmins everywhere are clicking the Back buttons on their browsers. But really, if you're more pro than me at Apache config then pat yourself on the back and use sites-available like your mother told you. But either way, you'll need this syntax (and if you have no idea what I'm talking about, put it in
<VirtualHost *:80> ServerName static.[my-site] DocumentRoot /var/www/static.[my-site]/ </VirtualHost> <Virtualhost *:80> ServerName [my-site] DocumentRoot /var/www/[my-site] ServerAdmin YOUR-EMAIL ErrorLog "/var/log/apache2/[my-site]-error_log" WSGIDaemonProcess mysite python-path=/var/www/[my-site]:/var/www/[my-site]/venv/lib/python2.7/site-packages WSGIProcessGroup mysite WSGIScriptAlias / /var/www/[my-site]/[my-site]/wsgi.py </VirtualHost>
80in either directive.
To make these commands real, run
sudo /etc/init.d/apache2 restart
From this moment forward, all work regarding your site should be handled with a prompt that looks a lot like this:
If you open a new terminal to run some other command in the process, make sure you do this first:
You should know what to do here. Make your database. Run:
./manage.py syncdb ./manage.py migrate
It's business as usual here.
Assuming you have something like this in your production
STATIC_ROOT = '/var/www/static.[my-site]/static/' STATIC_URL = 'http://static.[my-site]/static/'
You are ready to run:
(In case you have no ability to notice trends, you'll want to avoid using
sudo here as it will knock you out of your virtualenv).
You should have a site. If you don't, I may have forgotten something, so leave it in the comments.