In previous tutorials we have covered:
This one covers changing the database engine used by Django and the default 'demoapp' application. The ActivePython AMI Toolkit is required for parts of this tutorial. The toolkit allows you to do your development work on a local machine, deploy the application to an EC2 instance, and scale the applciation as necessary once it's deployed.
Since your development environment (e.g. your laptop or workstation) may not have a running web server or a real database engine, we've set up demoapp so that you can run it on your local machine using the Django development server and SQLite.
python manage.py syncdb
You'll see some output as the tables are created, and you'll be asked to set up a superuser account for Django's auth system:
You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): yes Username (Leave blank to use 'youruser'): admin E-mail address: email@example.com Password: Password (again): Superuser created successfully. Installing custom SQL ... Installing indexes ... Installed 8 object(s) from 1 fixture(s)
This step is done automatically from a config file during deployment to an EC2 instance, but we'll look at that a little later. To run the Django server locally:
python manage.py runserver Validating models... 0 errors found Django version 1.2.5, using settings 'demosite.settings' Development server is running at http://127.0.0.1:8000/ ...
Open a web browser and paste in 'http://127.0.0.1:8000/'. You should have a working Django website similar to cloud.activestate.com. The website is being served by Django itself and it's backed by a file-based SQLite database. This is great for development and initial testing, but that's about it.
The AMI Toolkit scripts have a notion of what a production environment is, and the database choice is set accordingly in the demoapp/settings.py file.
In that file, you'll see the '
if PRODUCTION' block
which sets up a MySQL database if the
environment variable is 'true' (which is set in
'remote/app-setup-a.sh' during deployment) and SQLite if it
The toolkit will install and configure MySQL on the new EC2 instance (see remote/setup.sh) before setting up a new database for demosite as per demosite/settings.py.
To change the database engine of the application to PostgreSQL, we need to change a few lines in demosite's settings.py file, and install PostgreSQL itself and the psycopg2 Python module.
If you haven't previously deployed an instance with the toolkit
(again, see Building a
Python-centric WebServer in the Cloud) add your AWS key and ID,
fab make_master and
fab deploy. If
you've done that already, just run:
fab updateAt this point, demoapp won't work because the EC2 image it's running on hasn't got PostgreSQL installed and configured. To do that, log in to the instance via ssh:
ssh -i nimbus.pem firstname.lastname@example.org
You can get the instance address from the output of the previous
fab commands or run '
fab status'. Your instances will
also be listed in the EC2 tab of the AWS control panel.
Install PostgreSQL with:
sudo apt-get install postgresql
With the software installed, we need to set up the 'demosite' user and database with the following commands:
sudo service postgresql-8.4 start sudo -u postgres createuser -D -R -S -w demosite sudo -u postgres psql postgres=# alter user demosite with password 'demosite'; ALTER ROLE postgres=# \q sudo -u postgres createdb demosite -O demosite -E utf8 psql -U demosite -W -h localhost demosite Password for user demosite: psql (8.4.5) ... demosite=> \q
Next, we need to install the psycopg2 Python module. If you have ActivePython Business Edition you can use PyPM to install it into demosite's virtual environment:
/opt/ActivePython-2.7/bin/pypm -E /var/www/demosite/env install psycopg2If you don't have a Business Edition license, you can compile and install the module using
sudo apt-get install libpq-dev pip install -E /var/www/demosite/env/ psycopg2
Now, get Django to create the application database for us with the new engine. We could have the AMI Toolkit scripts do this for us, but since we're already logged in, let's run it manually to make sure PostgreSQL and Django are working properly together:
cd releases/current/ ./manage.py syncdb
As happened when we did a
syncdb on the local machine,
you'll be asked to set up a superuser account for Django's auth
system. The AMI Toolkit sets this in line 19 of
remote/app-setup-b.sh, pulling in the password and email
address from settings.py.
Once we've finished building the postgres database, let's check that it's working.
(env)ubuntu@ip-10-112-91-241:/var/www/demosite/releases/current$ ./manage.py dbshell Password for user demosite:
It asks for the password for the 'demosite' user as configured in demosite/settings.py ('demosite' by default - use whatever you've set if you've changed it).
Once you're in the shell, use the '\d' command to view the tables, views, and sequences. It should look something like this:
List of relations Schema | Name | Type | Owner --------+-----------------------------------+----------+---------- public | auth_group | table | demosite public | auth_group_id_seq | sequence | demosite public | auth_group_permissions | table | demosite public | auth_group_permissions_id_seq | sequence | demosite public | auth_message | table | demosite public | auth_message_id_seq | sequence | demosite public | auth_permission | table | demosite public | auth_permission_id_seq | sequence | demosite ...
\q' to quit the databases shell.
The real test of this database swap is to see if demoapp will actually run using the new database back-end. To check this, restart apache and stop mysql:
sudo service apache2 restart ... sudo service mysql stop
Back at the command line of your local machine, use '
browse' to open the application in a browser, or just paste the
instance hostname into your browser.