CSC/ECE 517 Fall 2013/ch1 1w30 ps

From Expertiza_Wiki
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.

References

<references />

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