start on 11

Author: hjwp

chapter_11_ansible.asciidoc

@@ -41,13 +41,14 @@ NOTE: Why not ping me a note once your site is live on the web,
 *******************************************************************************
 As part of my work on the third edition of the book,
 I'm rewriting the deployment chapters,
-but this chapter is far from ready I'm afraid.
-Sorry!
+but this chapter is very rough I'm afraid, sorry!
 
-Following along with this chapter is going to be pretty
-much impossible while I'm still half-done.
+Following along with this chapter is going to be quite challenging,
+since although most of the code listings and commands are there,
+I haven't yet written all the explanations to go in between them.
 
-It might be best to skip ahead to <<chapter_12_organising_test_files>>
+By all means have a go if you're feeling brave!
+But otherwise it might be best to skip ahead to <<chapter_12_organising_test_files>>
 
 *******************************************************************************
 
@@ -69,7 +70,7 @@ I promise seeing your site on a "real" website will be a thrill.
 
 === Manually Provisioning a Server to Host Our Site
 
-TODO: revise this section
+// TODO: revise this section
 
 ((("staging sites", "manual server provisioning", id="SSserver09")))
 ((("server provisioning", id="seerver09")))
@@ -78,24 +79,18 @@ 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.
+Ultimately, infrastructure-as-code tools can let you automate both of these,
+but for the purposes of this book, we can live with manual provisioning.
 
-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 few universal
-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.
+I should probably stress once more that deployment is something that varies a lot,
+and that as a result there are few universal best practices for how to do it.
+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
 
-
 ((("hosting services")))
 There are loads of different solutions out there these days,
 but they broadly fall into two camps:
@@ -104,7 +99,6 @@ but they broadly fall into two camps:
 - Using a ((("Platform-As-A-Service (PaaS)")))Platform-As-A-Service (PaaS)
   offering like Heroku or my old employers, PythonAnywhere.
 
-
 ((("PythonAnywhere")))
 Particularly for small sites, a PaaS offers a lot of advantages,
 and I would definitely recommend looking into them.
@@ -127,8 +121,8 @@ from all the grizzled dinosaurs out there.
 
 I'm not going to dictate how you do this--whether you choose Amazon AWS,
 Rackspace, Digital Ocean, your own server in your own data centre or a
-Raspberry Pi in a cupboard under the stairs, any solution should be fine, as
-long as:
+Raspberry Pi in a cupboard under the stairs, any solution should be fine,
+as long as:
 
 * Your server is running Ubuntu 22.04 (aka "Jammy/LTS").