Changes between Version 1 and Version 2 of ServiceDeployment

Timestamp:

11/16/10 19:04:31 (14 years ago)

Author:

Dave Morris

Comment:

--

ServiceDeployment

@@ -27 +27 @@
 This has already been implemented for the BRICCS infrastructure services :
 
- * Subversion repository {{{svn.briccs.org.uk}}}
- * Maven repository {{{mvn.briccs.org.uk}}} http://mvn.briccs.org.uk/
- * Install repository {{{data.briccs.org.uk}}} http://data.briccs.org.uk/
- * Trac issue tracking and wiki {{{trac.briccs.org.uk}}} http://trac.briccs.org.uk/
-
- * Google Mail for the BRICCS team {{{mail.briccs.org.uk}}} http://mail.briccs.org.uk/
- * Google Docs for the BRICCS team {{{docs.briccs.org.uk}}} http://docs.briccs.org.uk/
+ * Subversion repository ({{{svn.briccs.org.uk}}})
+ * Maven repository ({{{mvn.briccs.org.uk}}}) http://mvn.briccs.org.uk/
+ * Install repository ({{{data.briccs.org.uk}}}) http://data.briccs.org.uk/
+ * Trac issue tracking and wiki ({{{trac.briccs.org.uk}}}) http://trac.briccs.org.uk/
+
+ * Google Mail for the BRICCS team ({{{mail.briccs.org.uk}}}) http://mail.briccs.org.uk/
+ * Google Docs for the BRICCS team ({{{docs.briccs.org.uk}}}) http://docs.briccs.org.uk/
 
 Using human readable DNS aliases for our services not only makes things easier for our end users (catissue.briccs.org.uk is easier to remember and check than briccs-3.rcs.le.ac.uk), it also gives us a degree of flexibility in terms of relocating our services.
@@ -56 +56 @@
 === DNS management ===
 
-The DNS settings for {{{briccs.org.uk}}} are currently handled by LCN (https://www.lcn.com/), the [[http://en.wikipedia.org/wiki/Domain_name_registrar DNS registrar]] we used to register the domain name.
+The DNS settings for {{{briccs.org.uk}}} are currently handled by LCN (https://www.lcn.com/), the [http://en.wikipedia.org/wiki/Domain_name_registrar DNS registrar] we used to register the domain name.
 
 This was the quickest and easiest way to get things up and running.
 Registering a new domain name through a commercial registrar typically takes less than 60 seconds to fill in the form and click 'Ok'.
 
-In the longer term we will probably want to transfer ownership of the DNS name to the university IT services.
+In the longer term we may want to transfer ownership of the DNS name to the university IT services.
 Transferring the ownership of a registered DNS domain is a fairly simple operation.
-
-However, the ability to change the DNS aliases for our services forms part of our disaster recovery plan.
-For example, if one of our web servers fails we may need to update the DNS alias to point to a new service quickly and easily.
-
-If we do decide to transfer the management of the {{{briccs.org.uk}}} domain to the university IT services we should check that we would still be able to make changes to the DNS information quickly and easily,
+However, the ability to change the DNS aliases for our services forms an important part of our disaster recovery plan.
+If for example, one of our web servers fails, we would need to be able to deploy a new service and update the DNS alias quickly and easily.
+
+If we do decide to transfer the management of {{{briccs.org.uk}}} to university IT services we need to check that we would still be able to make changes to the DNS information quickly and easily,
 preferably out of normal office hours (see note on DNS caching).
 
@@ -210 +209 @@
 Changing the delegation settings in the Apache web server would take effect immediately, and all of our users would be connected to the new service.
 
-Note that in this scenario, the old service is left intact.
+==== Fallback option ====
+
+Note that in the above scenario, the old Tomcat/JBoss service is left intact.
 This means that if there are any unexpected problems with the new deployment we can swap back to the old service if we need to.
-
-== Recommendations ==
+We only delete the old service once we are happy that the new service is running correctly.
+
+==== Critical services ====
+
+It is also worth noting that the Apache web server is the only component in system that end users interact with directly.
+
+If we deploy the Apache web server on a separate machine, then this is the only component that cannot be moved or re-deployed.
+All of the other components and services can be re-deployed without affecting our users.
+
+Assuming we have good backups for our databases, if a back-end Tomcat/JBoss service fails need can re-deploy a new service on a new machine and update the the Apache proxy service.
+The new service would replace the failed service without having to update the URLs used by our end users.
+
+With this in mind it may be best to keep the Apache web server deployment as simple as possible, with just the web server and AJP proxy module installed on that machine. 
+
+==== Service vulnerability ====
+
+If the Apache web server is deployed on a separate machine, we can restrict access to the back-end JBoss/Tomcat web services to only allow connections from a limited set of machines.
+This will help to reduce the number of security vulnerabilities we are exposed to e.g. ticket:36.
+
+= Recommendations =
 
 If we are considering migrating our live CaTissue service from briccs-3 to briccs-1, then we will need to notify all our users of a change to the URL they should use.