Topic objectives
Upon the completion of this workshop, developers or managers should be able to:
• Discuss and choose the Rails production deployment configuration;
• Identify and evaluate the ways to take move the development site on your computer to the online production site;
• Evaluate and devise how to integrate a new Rails site into an existing or future e-commerce structure;
• Conclude the development of the OTBS as a Ruby on Rails application;
• Think critically and analytically about the policy for site maintenance and further development.
• Share your findings with your peers and examine what the other team is doing.
Focus Question
As either a developer or as an IT manager, what are the options available when deploying and maintaining the Ruby on Rails application online?
There are many options available to deploy and maintain the OTBS. The choise of which options are the most appropriate depend on the knowledge and experience of the deployment team. Ruby on Rails has a number of methods for deployment, as does the vast majority of web developement applications.The company may choose to deploy to an in-house hosting setup. This would mean we would have to take into consideration the cost of hosting equipment and associated maintenance, which could include outsourcing. Aternatively, the company could deploy to an external hosting service which would maintain the hosting equipment.
In terms of the technical methods for deploying the OTBS, there are many options available to the deployment team. Phusion Passenger, which is further dicussed below, is the recommended method of deployment however as IT manager, I would take the advice from developers and the deployment team as these personnel would have greater experience and knowledge of which option would be most appropriate. I see my responsibility as an IT manager is to oversee the deployment of the OTBS from a holistic approach. Having said this, I have conducted some basic research on Phusion for my own edification and some findings are presneted below.
Phusion Passenger is a module for the Apache HTTP Server and nginx for deployment of Ruby applications, including those built using the Ruby on Rails framework.At this time, Phusion Passenger is the preferred way to deploy Ruby on Rails applications, having been recommended by the Ruby on Rails authors. In terms of deployment
Having said this, there is alway more than one way to skin a cat, and other methods of deployment are as follows. Prior to Phusion Rails was mostly deployed using Apache or nginx with either a built-in or standalone proxy against a cluster of mongrels or thins. This setup is still works great, but it's more complicated to setup and administrate than using Passenger. Another consideration is JRuby which brings Rails to the Java Virtual Machine. This means that you can deploy Rails applications on app servers like Glassfish and Jetty. Finally, Capistrano brings deployment automation to Rails whether you're working with a single server or on a cluster of dozens.
It should be noted however that deploying Rails is only the first step. The second, and very crucial, step is monitoring and maintaining the application. There are a number of ways to do this. One way is to install a monitoring tool or third party application such as New Relic RPM. This involves the installation of a very lightweight plugin within the Rails application which provides access to a control panel that is hosted on the New Relic RPM site. This enables the user to be able to spot and prevent all sorts of issues related to the performance of the application. Alternatively users can maintain the Rails application mannually user the rails console.Through the console the user can inspect the Rails internals to undertake various maintenenace tasks such as tracking down a bug, viewing a list of recently updated records, or even updating a user’s information manually.
IT INFRASTRUCTURE MANAGER’S THREAD (BLUE team)
To Do:
What are the hosting solutions?
There are a myriad of hosting solutions available to host the Ruby on Rails application and these are presented below. In addition to these, the deployment team may also consider a Ruby on Rails dedicated host, which has a more intimate knowledge of Ruby on Rails and greater understanding of the supporting software.Deploying the Rails application using Phusion to one of these Rails hosts would be a low risk way to go as potential complications would be minimised. Examples of these dedicated of Ruby on Rails host providers are Rails Machine.com, EngineYard.com and even an Australian host provider Anchor.com.au .
- Free web hosting service: offered by different companies with limited services, sometimes supported by advertisements, and often limited when compared to paid hosting.
- Shared web hosting service: one's website is placed on the same server as many other sites, ranging from a few to hundreds or thousands. Typically, all domains may share a common pool of server resources, such as RAM and the CPU. The features available with this type of service can be quite extensive. A shared website may be hosted with a reseller.
- Reseller web hosting: allows clients to become web hosts themselves. Resellers could function, for individual domains, under any combination of these listed types of hosting, depending on who they are affiliated with as a provider. Resellers' accounts may vary tremendously in size: they may have their own virtual dedicated server to a collocated server. Many resellers provide a nearly identical service to their provider's shared hosting plan and provide the technical support themselves.
- Virtual Dedicated Server: also known as a Virtual Private Server (VPS), divides server resources into virtual servers, where resources can be allocated in a way that does not directly reflect the underlying hardware. VPS will often be allocated resources based on a one server to many VPSs relationship, however virtualisation may be done for a number of reasons, including the ability to move a VPS container between servers. The users may have root access to their own virtual space. Customers are sometimes responsible for patching and maintaining the server.
- Dedicated hosting service: the user gets his or her own Web server and gains full control over it (root access for Linux/administrator access for Windows); however, the user typically does not own the server. Another type of Dedicated hosting is Self-Managed or Unmanaged. This is usually the least expensive for Dedicated plans. The user has full administrative access to the box, which means the client is responsible for the security and maintenance of his own dedicated box.
- Managed hosting service: the user gets his or her own Web server but is not allowed full control over it (root access for Linux/administrator access for Windows); however, they are allowed to manage their data via FTP or other remote management tools. The user is disallowed full control so that the provider can guarantee quality of service by not allowing the user to modify the server or potentially create configuration problems. The user typically does not own the server. The server is leased to the client.
- Colocation web hosting service: similar to the dedicated web hosting service, but the user owns the colo server; the hosting company provides physical space that the server takes up and takes care of the server. This is the most powerful and expensive type of web hosting service. In most cases, the colocation provider may provide little to no support directly for their client's machine, providing only the electrical, Internet access, and storage facilities for the server. In most cases for colo, the client would have his own administrator visit the data center on site to do any hardware upgrades or changes.
- Cloud Hosting: is a new type of hosting platform that allows customers powerful, scalable and reliable hosting based on clustered load-balanced servers and utility billing. Removing single-point of failures and allowing customers to pay for only what they use versus what they could use.
- Clustered hosting: having multiple servers hosting the same content for better resource utilization. Clustered Servers are a perfect solution for high-availability dedicated hosting, or creating a scalable web hosting solution. A cluster may separate web serving from database hosting capability
- Grid hosting: this form of distributed hosting is when a server cluster acts like a grid and is composed of multiple nodes.
- Home server: usually a single machine placed in a private residence can be used to host one or more web sites from a usually consumer-grade broadband connection. These can be purpose-built machines or more commonly old PCs. Some ISPs actively attempt to block home servers by disallowing incoming requests to TCP port 80 of the user's connection and by refusing to provide static IP addresses. A common way to attain a reliable DNS hostname is by creating an account with a dynamic DNS service. A dynamic DNS service will automatically change the IP address that a URL points to when the IP address changes.
Will our Rails applications run on a cloud computing service in future?
As discussed above, cloud hosting is a new type of hosting platform that allows customers powerful, scalable and reliable hosting based on clustered load-balanced servers and utility billing. This type of hosting removes single-point of failures and allows customers to pay for only what they use versus what they could use. There has been a great deal of hype about the Cloud computing and cloud hosting of late. Essentially cloud hosting is a very scalable, pay-as-you-go architecture. After examining the hosting capacity and scalability of http://www.rackspacecloud.com I believe that cloud computing is a viable option for Ruby on Rails in the future. Currently many Ruby on Rails applications are developed or utilised by small businesses. Cloud computing hosting service provides a relative low price option for a company to run their Rails applications on the Internet without the large overheads of technical staff and equipment. Interestingly, the are already cloud hosting companies which specialise in Ruby On Rails applications, such as Engineyard (http://www.engineyard.com/), funnily enough termed "Rails in the Cloud".
Can we make a deployment and maintenance plan by team consensus?Add your ideas for policy planning and documentation about production site deployment and maintenance solutions.
The development of a deployment plan and maintenance plan are important activities which take time and resources.Sufficient rigour should be applied to developing these plans to help ensure that the deployment and ongoing maintanince of your web application is relaitvely trouble free. As with most Project Management philosophies the development of such plans assists in bringing about the successful completion of specific project goals and objectives by ensuring the everyone is reading from the same sheet of music.Thankfully there is no requirement to reinvent the wheel as there are many resources online which contain guidelines on developing plans, sample plans and actual plans utilsed for the deployment and maintenance of various applications. The information below presents an outline of a deployment plan and maintenance plan that could be used to deploy the OTBS for either in-house hosting or to an external host provider.
Deployment Plan
Deployment planning can reduce project risk by reducing uncertainty in implementation of system products. Documentation of detailed deployment activities contributes to the success of IT systems by establishing and communicating expectations for all aspects of the activities necessary to get a product to production, including necessary resources. In addition, risks are minimized by contingency planning, including withdrawal or back-out procedures to be executed if problems occur during deployment activities. The below are the main headings of a deployment plan. Each heading is relatively self explanatory. This would form the basis of a plan, which is heading forming a section of the plan, with the relevant detail completed for each area.
1. Introduction
1.1 Purpose
1.2 Objectives
1.3 Scope of Work
1.4 Sites/Seats/Locations
1.5 Assumptions
1.6 Issues
1.7 Constraints
1.8 Dependencies
2 Site Information
2.1 Site Diagram
2.2 System Overview
2.3 Site Preparation
2.4 Site Readiness
3 Roles & Responsibilities
3.1 Project Manager
3.2 System Integrator
3.3 Installation Manager
3.4 Chief Technology Officer
3.5 Hardware Installation Engineer
3.6 Software Support Engineer
3.7 Consultants / Subcontractors / Third Parties
3.8 Points of Contact
4 Schedule
4.1 Resource Allocation Chart
5 Resources
5.1 Facilities
5.2 Hardware
5.3 Software
5.4 Documentation
6 Technical Support
6.1 Help Desk
6.2 Desktop
6.3 Servers
6.4 Network / Voice / Telecommunications
7 Training
7.1 Training
7.1.1 Training Plan
7.1.2 Training Requirements
7.1.3 Audience
7.1.4 End-user Training
7.1.5 Support Staff Training
8 Installation Considerations
8.1 Safety
8.2 Code & Industry Standards
8.3 Installation Planning
8.4 Weather & Productivity
8.5 Installation Site Maintenance
8.6 Installation Records
9 Installation Process
9.1 Preparing
9.1.1 Validation
9.1.2 Scheduling
9.1.3 Reviews
9.1.4 Communication Plan
9.2 Installing
9.2.1 Common Deployment Tasks
9.2.2 Uploading Deployment Files to the Server
9.2.3 Deploying an Application to Servers on the Same Machine
9.2.4 Deploying an Application to Servers on Multiple Machines
9.2.5 Redeploying or Stopping a Deployment
9.2.6 Un-deploying a Deployment Unit
9.2.7 Changing the Order of Deployment
9.2.8 Migrate to New Environment
9.3 Testing
9.3.1 Use Activation
9.4 Site Monitoring
9.4.1 Monitoring for Defects
9.4.2 Sign-off
9.4.3 Customer Satisfaction
10 Transfer to Operations
10.1 Resources
10.2 Procedures
10.3 Expected Areas of Change
10.4 Transition Activities
10.5 Monitoring
10.6 Help Desk
Test the plan:
After the plan is completed, test it thoroughly. Verify all deployment strategies and identify any potential issues. Then update the plan based on test results.
Review and accept the plan:
The deployment plan should be finalised before OTBS deployment. All project teams should review and accept the contents of the plan before deployment begins.
Maintenance Plan
IT maintenance is a very broad activity often defined as including all work made on a IT system after it becomes operational. This covers the correction of errors, the enhancement, deletion and addition of capabilities, the adaptation to changes in data requirements and operation environments, the improvement of performance, usability, or any other quality attribute.The Maintenance Plan provides Support personnel with the information necessary to maintain an IT system effectively. This document defines the support environment, roles and responsibilities, and scheduled activities essential for support and maintenance, whether OTBS is in-house or outsourced hosting. As per the below, this is the recommended structure and information to be included in a Maintenance Plan. Again, the headings are relatively self explanatory.
1 Executive Summary
6 Technical Approach
1.1 Background
1.2 Objectives
1.3 Scope
1.4 Relationship to Other Plans
2 System Details
2.1 System Organisation
2.2 Details
2.2.1 Security
2.2.2 Points of Contact
2.2.3 Authorized Usage
3 Support Environment
3.1 Equipment Environment
3.1.1 Computer Hardware
3.1.2 Facilities
3.2 Support Software
3.3 Storage Requirements
4 Project Team
4.1 Roles and Responsibilities
4.2 Training
5 Management Approach
5.1 Priorities
5.2 Schedule
5.3 Tasks
5.4 Constraints
5.5 Assumptions
5.6 Dependencies
6.1 Types of Maintenance Activities
6.2 Configuration Management
6.3 Risk Assessment
6.4 Testing
6.5 System Protection
6.6 Special Processes
6.7 Maintenance Reports
6.8 Documentation
6.9 Quality Assurance Activities
7 Maintenance Procedures
7.1 Consolidated Unit List
7.2 Maintenance Procedure for Software Unit [x]
7.2.1 Description
7.2.2 Conventions
7.2.3 Verification Procedures
7.2.4 Error Conditions
7.3 Maintenance Procedure for Software Unit [x]
7.4 Maintenance Procedure for Software Unit [x]
8 Database Maintenance Procedure
8.1 Database [x]
8.1.1 General Characteristics
8.1.1.1 Permanency
8.1.1.2 Storage
8.1.1.3 Restrictions
8.1.2 Organization and Detailed Description
Administration, scaling, reliability and integration with existing and future services are issues.
Consider all the business options of both in-house deployment and outsourcing as shown by hosting sites like http://www.engineyard.com/
As already stated above, the deployment of the OTBS is only the first step. Once the system is deployed and operational, it is then required to be administered and maintained to ensure ongoing relaibility. Further, ensuring integration with existing and future services are an issue.
Administration and Maintenance
As stated above and to reiterate there are a number of ways to undertake administration and maintenance of the web application one it is deployed. One way is to install a monitoring tool or third party application such as New Relic RPM. This enables the user to be able to spot and prevent all sorts of issues related to the performance of the application. Alternatively users can maintain the Rails application mannually using the rails console.Through the console the user can inspect the Rails internals to undertake various maintenenace tasks such as tracking down a bug, viewing a list of recently updated records, or even updating a user’s information manually.
Scaling
Scaling of the OTBS will probably not be a concern initially, but as the business grows and the website recieves more and more traffic, there may be a requirement to look at scaling options. Based on my brief research there appears to be some discussion and concern about scalability of Rails. While Rails is not the world’s speediest framework, the supposed scalability issues are very unlikely to be a legitimate reason not to use Rails.Rails makes it easy to get your application running without worrying about any of the performance issues If you ignore everything about performance tuning during the development phase, you’ll still have a working application, and from there you can tune as required. There’s little point in tuning for performance before you have something that is successful for a small group of people. And if you focus on building an optimally scalable site and end up late to market as a result, you’ll have achieved nothing.
Rails provides a rich set of caching mechanisms that can dramatically increase the speed of most web applications. You can typically achieve dramatic performance gains by applying page, action, and fragment caching. And for big sites, memcached is a popular solution. In many cases, these solutions largely take Rails out of the picture for the highest-traffic pages.
Integration
A final consideration is integration with existing and future services. Given the current popularity of Ruby on Rails, integration does not present a significant issue and indeed a simple google search on "Ruby on Rail intgration" reveals a large number of site involving Ruby on Rails integratipon testing with various applications. Given the growing popularity of Ruby on Rails, this is likey to continue into the future.
Resources
http://en.wikipedia.org/wiki/Web_hosting_service
http://www.klariti.com/templates/Maintenance-Plan-Template.shtml
http://www.techstreet.com/direct/SWM_samples.pdf
http://www.klariti.com/deployment-plan-template/
http://saassdlc.com/support-files/SDLC-RUP-Deployment-Plan.pdf
No comments:
Post a Comment