CSC/ECE 517 Fall 2013/ch1 1w30 ps

From Expertiza_Wiki
Revision as of 15:48, 17 September 2013 by Prbhide (talk | contribs)
Jump to navigation Jump to search

Ruby on Rails Web Hosting Services

Introduction

A web hosting service is a type of Internet hosting service that allows individuals and organizations to make their website accessible via the World Wide Web. Typically, while hosting web applications, it becomes essential to host the core website component, databases and other resources necessary for running the application. There are many web hosting options available like free web hosting, shared hosting, dedicated server, and the list goes on. Today, many companies provide services for hosting web application where they manage the infrastructure along with maintenance and the application developer needs to focus only on the actual application development. The service charges depend upon the factors like disk space, bandwidth, email account or FTP access. Nowadays, many companies provide Platform-as-a-Service(PaaS) to deploy and scale applications in Cloud.

Some popular PaaS providers are:

Not a platform in the traditional sense, Amazon's AWS Elastic Beanstalk changes how developers push their apps into Amazon's cloud. Developers upload the app and Elastic Beanstalk handles the deployment details, capacity provisioning, load balancing, auto-scaling and app health monitoring.

Heroku is a cloud platform as a service (PaaS) supporting building, deployment and scaling of applications using several programming languages like Ruby, Java, Python,Node.js ,Clojure, PHP and Perl.

Engine Yard's platform offers simple, automated Rails deployment and management that makes for easy app migration.

The developer platform that lets users build and host Web apps in the cloud in an effortless fashion.

Open-source cloud application platform helps developers build scalable applications that can work natively on managed infrastructure, from a Google Android device to large grids and clouds. The software supports major OSes and provides native support for Java and Scala.

Heroku<ref>https://devcenter.heroku.com</ref>

Heroku, one of the first cloud platforms, has been in development since June 2007, when it supported only the Ruby programming language, but has since added support for Java, Node.js, Scala, Clojure and Python and (undocumented) PHP and Perl. The base operating system is Debian

History

James Lindenbaum, Adam Wiggins, and Orion Henry founded Heroku supporting Rack-compatible projects<ref>http://techcrunch.com/2008/05/08/ruby-on-rails-startup-heroku-gets-3-million</ref>. In October 2009 Byron Sebastian joined Heroku as CEO<ref>http://venturebeat.com/2009/10/14/sourcelabs-byron-sebastian-joins-heroku-as-ceo</ref>. On December 8, 2010 Salesforce.com acquired Heroku as a wholly owned subsidiary of Salesforce.com. On July 12, 2011 Yukihiro "Matz" Matsumoto, the chief designer of the Ruby programming language, joined the company as Chief Architect, Ruby. That month, Heroku included support for Node.js and Clojure.On September 15, 2011 Heroku and Facebook introduced Heroku for Facebook<ref>https://developers.facebook.com/blog/post/558</ref>. Heroku now supports Cloudant, Couchbase Server, MongoDB and Redis, besides the standard PostgreSQL, both as part of the platform and as a standalone service.

Architecture<ref>https://devcenter.heroku.com/categories/heroku-architecture</ref>

The high-level architectural components of the Heroku platform consist of following components.

Dynos and dyno Manager

  1. A dyno is a lightweight container running a single user-specified command.The commands run within dynos include web processes, worker processes (such as timed jobs and queuing systems), and any process types declared in the app’s Procfile. Dynos are available in 1X or 2X sizes and are allocated 512MB or 1024MB respectively.
  2. Your application’s dynos run in a a distributed, fault-tolerant, and horizontally scalable execution environment. The dyno manager manages many different applications via the the process model and keeps dynos running automatically. The dyno manager restarts all your app’s dynos whenever you create a new release by deploying new code, changing your config vars, changing your add-ons.

Logplex

In a distributed system such as Heroku, manually accessing logs spread across many dynos provides a very disjointed view of an application’s event stream and omits relevant platform-level events.Logplex collates and distributes log entries from your app and other components of the Heroku platform.

The Process Model

The process model gives us a unique way to think about dividing our workloads and scaling up over time. The Heroku Cedar stack uses the process model for web, worker and all other types of dynos. The process model is a generalized approach to managing processes across a distributed environment. It allows you to specify a custom list of process types in a Procfile and provides for very granular management of an application’s components.

Process Type

Web apps typically have two or more entry points. Each of these entry points can be called a process type which run a specific command. A process type is the prototype from which one or more dynos are instantiated. The process types are declared in Procfile.

Stack

A stack is a complete deployment environment including the base operating system, the language runtime and associated libraries. Heroku uses Celadon Cedar Stack. Celadon Cedar is Heroku’s default runtime stack and is a flexible, polyglot environment with robust introspection and erosion-resistance capabilities.

Procfile

A Procfile is a text file named Procfile placed in the root of your application, that lists the process types in an application. Each process type is a declaration of a command that is executed when a dyno of that process type is started. All the language and frameworks on the Cedar stack declare a web process type, which starts the application server. Rails 3 has the following process type : 

   web: bundle exec rails server -p $PORT
   web:     node web.js
   worker:  node worker.js
   reports: node report.js
   General command 
   <process-type> : <command>

Slug

A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system - ready for execution.

How Heroku Works<ref>https://devcenter.heroku.com/articles/how-heroku-works</ref>

Running an application on Heroku involves following points

  1. Defining an application: The source code for your application, together with the dependency file, should provide enough information for the Heroku platform to build your application, to produce something that can be executed.
  2. Knowing what to execute: If you’re using some established framework, Heroku can figure it out. For example, in Ruby on Rails, it’s typically rails server and in Node.js it’s the main field in package.json. If you want to execute some other process as well declare it in Procfile.
  3. Deploying application: The Heroku platform uses git as the primary means for deploying applications.

When you create an application on Heroku, it associates a new git remote, typically named heroku, with the local git repository for your application.As a result, deploying code is just the familiar git push, but to the heroku remote instead : 

  $ git push heroku master
  1. Building an application: When the Heroku platform receives a git push, it initiates a build of the source application. The build mechanism is typically language specific, but follows the same pattern, typically retrieving the specified dependencies, and creating any necessary assets.
  2. Running application on Dynos:Heroku executes applications by running a command you specified in the Procfile, on a dyno that’s been preloaded with your prepared slug.

Features

  1. Polyglot development environment: Heroku uses Celadon cedar ,a polyglot platform with native support for different language/framework like Clojure, Scala, Java, Ruby and Node.js. Polyglot support at the platform level lets development teams effectively utilize many languages across - and within - projects and ensures the right tool for the job.
  2. Dyno Size selection: Heroku dynos get 512MB of memory and 1x CPU share in their default configuration (“1X”). If your app needs more memory or more CPU share, you can resize dynos to a “2X” configuration for double the memory and double the CPU share on a per process-type basis.
  3. Flexibility in PaaS plan: The cost of hosting application depends upon the number and size of dynos used for running the application. The rates are as follows :
   Dyno Size	Memory CPU Share  Price/dyno-hour
   1X	        512MB	1x	   $0.05
   2X	        1024MB	2x	   $0.10
   Resize with command:
   $ heroku ps:resize web=2X worker=1X
  1. Production check: Production Check tests your app’s configuration against a set of optional—but highly recommended—criteria. It makes it easy to ensure that your app’s configuration lends itself to maximum uptime. To run Production Check, click the “Run Production Check” link in the header for any app in the Heroku Dashboard.
  2. Fault tolerant: Since the application runs on different dynos which are located on physicially distributed environment, the application becomes fault tolerant. If two web dynos are running and due to catastrophic event any of the dyno goes down, the request for that application can be handled by other dyno.
  3. Wide Range of databases supported: Heroku provides support for wide range of database along with the default PostgreSQL like Amazon RDS, MongoDB, Cloudant by purchasing add-ons.
  4. Availability of add-ons:Heroku provides add-ons for catering different requirements for running an application. Some of the available add-ons provides with functionality like monitoring, search utilities, caching, analytics, email and sms, logging etc.
  5. SSL Endpoints: Apps that transmit sensitive data should enable SSL to ensure all information is transmitted securely.To enable SSL on a custom domain, Heroku provides SSL Endpoint add-on.
  6. Ease in scalability: The Procfile exposes an architectural aspect of your application and this architecture lets you, for example, scale each part independently. Generally, if you deploy an application for the first time, Heroku will run 1 web dyno automatically. In other words, it will boot a dyno, load it with your slug, and execute the command you’ve associated with the web process type in your Procfile.You have control over how many dynos are running at any given time. All apps on Heroku use a process model (via Procfile) that lets them scale up or down instantly from the command line or Dashboard. Each app has a set of running dynos, managed by the dyno manager, which are known as its dyno formation.
  7. Error Pages:Heroku’s HTTP router serves unstyled HTML with HTTP status code 503 (Service Unavailable) when your app encounters a system-level error, or while maintenance mode is enabled. Customizing these pages allows you to present a more consistent UI to your users.
  8. Logging ease with Logplex:Logplex collates and distributes log entries from your app and other components of the Heroku platform.It allows collates system error logs and warnings. Even though the application runs in distributed environment the logplex makes log access easier.
  9. Custom domain:All apps on Heroku are accessible via their herokuapp.com app subdomain. E.g., for an app named example it’s available at example.herokuapp.com. To serve traffic on a non-herokuapp.com domain, e.g., www.example.com, you can configure your application with a custom domain.
  10. Maintenance Mode:If you’re deploying a large migration or need to disable access to your application for some length of time, you can use Heroku’s built in maintenance mode. It will serve a static page to all visitors, while still allowing you to run one-off dynos.
  11. One-off dynos:One-off dynos run attached to your terminal and work similar to other dynos, with a character-by-character TCP connection for STDIN and STDOUT. This allows you to use interactive processes like a console.
  12. Configuration and config-var:An open source app may have hundreds or thousands of deployments.Although all running the same code, each of these deploys have environment-specific configurations. Heroku provides solution is to use environment variables, and keep the keys out of the code.Use the Heroku CLI’s config, config:set, config:get and config:unset to manage your config vars.

Engine Yard

Engine Yard is a private company providing cloud Platform as a Service and focuses on deployment and management of a Ruby and Rails application. It provides a pay-as-you-go pricing policy so you pay only for what you use. It helps developers with learning resources like videos, tutorials for Ruby development. It provides user with a GUI for the configuration, deployment and maintenance of an application.

Architecture<ref>https://www.engineyard.com/products/technology</ref>

Engine Yard Could platform comprises of following layers.

Infrastructure as a Service

Engine Yard is built on top of Amazon Web Services. The IaaS layer takes care of creating managing and running instances created by user on AWS. When a user requests for an environment the Engine Yard Cloud boots a new AWS instance and this instance is configured with the application code and required platform components.

Components available

It provides components like application framework, application server, web server, load balancer, caching mechanisms, databases and virtual machines. It also provides some run-time components like libraries, frameworks and services.

Automation Engine

Engine Yard automates and manages various operations and tasks like Component Automation, System Automation and Lifecycle Automation. This layer provides the automated load balancing, resource monitoring and fault tolerance.

Add-ons

Engine Yard provides add-ons for extending applications and environments. It has a Gateway layer that enables the third party integration with ease. It has partnered with a variety of companies - leading vendors and SaaS providers, providing users with a wide range of options for Add-ons.

Features<ref>https://www.engineyard.com/products/cloud/features</ref>

  1. Open platform: Engine yard components are based on open source technologies providing user a highly configurable and flexible platform for deployment. It offers a wide range of configuration choices for Ruby and Rails application:
App Servers supported: Passenger, Puma, Trinidad, Unicorn.
Web Servers: HAProxy, Nginx, Rack.
Databases: MySQL, PostgreSQL, Riak.
Ruby Versions: 1.9.3-p448 1.9.2-p320, 1.8.7-p374
  1. Flexible:Engine Yard Cloud can be used in a variety of fields like gaming and entertainment, e-commerce, online portals and social networking.
  2. Accessibility made easy with both CLI and a user friendly interface:Engine Yard provides with a GUI Dashboard for managing deployments and creating instances. Deployment can be done from master branch or another branch and code can be deployed with migrations too. The Dashboard shows the deployment status. All this functionality can be done using a Command Line Interface also, which needs to be installed.
  3. Controlling Instances and Scaling:Engine Yard gives user the complete control of instances to the user. Instances can be created easily using the dashboard. When a user requests for an environment, a fresh AWS instance (virtual machine) is created and configured with the user's application code and the platform components the user configured. This helps user to add instances easily to your application tier that will join the load-balanced group.
  4. Database replication:User can configure multiple database setups. For e.g. master databases can be created on both PostgreSQL and MySQL. Additionally, slave databases can also be created.
  5. Monitoring resources:With Engine Yard Cloud user can track all the essential resource utilization for an application like storage, CPU and memory utilization levels.
  6. Cloning:Cloning enables a user to have an on-demand staging environment. The complete production environment can be cloned even when the application is running across many different instances.
  7. Handling Fail-overs: Engine Yard maintains a master instance and slave instance of the database. If some failure is detected in the master database i.e its unable to respond to the requests, then it terminates this instance and the slave is converted into master and a new slave instance is created for later use.

Steps for deployment<ref>http://guides.railsgirls.com/engineyard/</ref>

Deployment can be done from the master branch, with migrations or from another branch in GIT repository using the Dashboard<ref>https://support.cloud.engineyard.com/entries/21016418-Deploy-from-Your-Dashboard</ref> or CLI<ref>https://support.cloud.engineyard.com/entries/21009927-Deploy-from-the-CLI-Engine-Yard-CLI-User-Guide-</ref>

  1. To deploy a user must create an account on Engine Yard.
  2. User must have an application on his/her account.
  3. User must create an environment by entering details like environment name, ruby version being used in the application, database type, no of backups and snapshots t be maintained.
  4. The GIT branch from which code is to be deployed (master or other) can be mentioned on the Dashborad.
  5. Click on the deploy button to deploy the application.
  6. The deployment status (successful/failed) will be shown once the deployment is completed.

For deployment using the CLI:

  1. The engineyard gem must be installed in the local environment on user's development machine using the command
gem install engineyard
  1. The application can then be deployed by traversing to the application directory and typing the command
ey deploy (The environment can be given using the -e option if user has multiple environments i.e ey deploy -e production)
  1. The check the status of an application and environment following command can be used
ey status
  1. The get help for a specific command use
ey help COMMAND_NAME

Differences between Heroku and Engine Yard

  1. Web application instance creation: In case of Heroku, every procces that needs to be run i.e web process or worker process its runs on different Dynos. In case of Engine Yard, user is provided with a separate AWS instance that acts your environment where you can deploy your web aplication and run different components.
  2. Languages supported: Heroku is a polygot platform which supports different frameworks/languages like Clojure, Scala, Java, Ruby and Node.js. Engine Yard supports interpreters like Ruby, PHP, Node.js, REE, JRuby and Rubinius.
  3. Operating System: Heroku uses Debian version of Linux while Engine Yard uses Gentoo version of Linux.
  4. Fault Tolerance: Since the application runs on different Dynos which are physically distributed hence if any of the Dyno goes down/fails the other is present to take over the control. Engine Yard allows cloning of environments and automatically creates snapshots and backups of application and databases. It maintains a master instance and slave instance of the database. If some failure is detected in the master database then it terminates this instance and the slave is converted into master and a new slave instance is created for later use.
  5. Scalability: Heroku has a Dyno Manager which manages the different running instances of Dynos. Initially only one Dyno is allocated to a process but it can be scaled by adding more Dynos in the Procfile or by increasing the Dyno size. The available Dyno sizes are 1X and 2X. Engine Yard allows a user to add additional instances that join the load balancing group.
  6. Logging: Heroku provides the feature of Logplex which collates and distributes log entries from your app and other components of the Heroku platform. Logging in case of Engine Yard is application specific.
  7. Monitoring and alerting: Engine Yard allows a user to track and monitor the utilization of each resource including storage, CPU and alerts when additional capacity is needed, or when the application may be behaving poorly. Heroku has a web inetrface called as Heroku Dashboard through which you can view the applications deployed to Heroku and the resources/Dynos allocated to it, but it doesn't provide functionality for performance monitoring and tracking CPU utilization.
  8. User Interface: Engine Yard provides a user interface 'Dahsboard' for application deployment and management along with a CLI. Heroku however allows for an application deployment and management only through CLI.

References

<references />

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w30_ps&oldid=76786"