Changes between Version 2 and Version 3 of ServiceDeployment

Timestamp:

11/16/10 19:16:27 (14 years ago)

Author:

Dave Morris

Comment:

--

ServiceDeployment

@@ -12 +12 @@
 
 The proposed system would also enable us to deploy test services in a range of different configurations to compare different configurations and evaluate what the actual requirements are for each of our web services.
+
+----
+
+= 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.
+
+In which case, we should take the opportunity to put in place the following components in order to avoid similar problems in the future.
+
+ * Use the DNS alias catissue.briccs.org.uk for our live service
+ * Install an Apache web server as the front end request handler
+ * Update all our clients to use http://catissue.briccs.org.uk/catissuecore/
+ 
+Once we have these components in place, we will have a lot more flexibility as to where and how we deploy our services, without causing any side effects for our end users.
+ 
+----
 
 == DNS aliases ==
@@ -56 +72 @@
 === 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 [https://www.lcn.com/ LCN], the [http://en.wikipedia.org/wiki/Domain_name_registrar DNS registrar] 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 may 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 an important part of our disaster recovery plan.
+However, the ability to change the DNS aliases for our services forms an important part of our disaster recovery toolkit.
 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.
 
@@ -114 +130 @@
 === Apache virtual hosts ===
  
-A better option is to use an Apache web server as the front end request handler, and use virtual hosts within the Apache service to delegate requests to the appropriate back-end server.
+A better option may be to use an Apache web server as the front end request handler, and use virtual hosts within the Apache service to delegate requests to the appropriate back-end server.
 
 Using an Apache web server as the front end to Tomcat/JBoss has a number of advantages:
@@ -231 +247 @@
 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.
-
-In which case, we should take the opportunity to put in place the following components in order to avoid similar problems in the future.
-
- * Use the DNS alias catissue.briccs.org.uk for our live service
- * Install an Apache web server as the front end request handler
- * Update all our clients to use http://catissue.briccs.org.uk/catissuecore/
- 
-Once we have the above components in place, we will have a lot more flexibility as to where and how we deploy our services, without causing any side effects for our end users.
-