![Show Menu](styles/mobile-menu.png)
![Page Background](./../common/page-substrates/page0164.png)
Manually Provisioning a Server to Host Our Site
We can separate out “deployment” into two tasks:
•
Provisioning
a new server to be able to host the code
•
Deploying
a new version of the code to an existing server
Some people like to use a brand new server for every deployment—it’s what we do at
PythonAnywhere. That’s only necessary for larger, more complex sites though, or major
changes to an existing site. For a simple site like ours, it makes sense to separate the two
tasks. And, although we eventually want both to be completely automated, we can
probably live with a manual provisioning system for now.
As you go through this chapter, you should be aware that provisioning is something
that varies a lot, and that as a result there are fewuniversal best practices for deployment.
So, rather than trying to remember the specifics of what I’m doing here, you should be
trying to understand the rationale, so that you can apply the same kind of thinking in
the specific future circumstances you encounter.
Choosing Where to Host Our Site
There are loads of different solutions out there these days, but they broadly fall into two
camps:
• Running your own (possibly virtual) server
• Using a Platform-As-A-Service (PaaS) offering like Heroku, DotCloud, OpenShift,
or PythonAnywhere
Particularly for small sites, a PaaS offers a lot of advantages, and I would definitely
recommend looking into them. We’re not going to use a PaaS in this book however, for
several reasons. Firstly, I have a conflict of interest, in that I think PythonAnywhere is
the best, but then again I would say that because I work there. Secondly, all the PaaS
offerings are quite different, and the procedures to deploy to each vary a lot—learning
about one doesn’t necessarily tell you about the others. Any one of them might change
their process radically, or simply go out of business by the time you get to read this book.
Instead, we’ll learn just a tiny bit of good old-fashioned server admin, including SSH
and web server config. They’re unlikely to ever go away, and knowing a bit about them
will get you some respect from all the grizzled dinosaurs out there.
What I have done is to try and set up a server in such a way that it’s a lot like the
environment you get from a PaaS, so you should be able to apply the lessons we learn
in the deployment section, no matter what provisioning solution you choose.
136
|
Chapter 8: Testing Deployment Using a Staging Site