Heroku. Rimantas Kybartas

Transcription

1 Heroku Rimantas Kybartas

2 Salesforce platform (PaaS)

3 Facts about Heroku Has been in development since June 2007, 2010 acquired by Salesforce Open platform Languages and frameworks: Ruby and Rails Node.js Java and Spring or Play Python and Django Clojure Scala PHP

4 Heroku Differs from traditional server-based hosting due to its: focus on application, not infrastructure dynamic and distributed runtime environment utilized process-based execution model enforcing strict separation of apps and their dependencies

5 HOW IT WORKS?

6 Source code and dependency file Applications consist of source code, and a description of any dependencies, and a Procfile. Dependency mechanism vary across languages (e.g. requirements.txt for Node.js, pom.xlm for JAVA) Source code and dependency file should provide enough information to build application

7 Definition of execution Some established frameworks defines what to run (e.g. rails server in Ruby on Rales, main field of package.json in Node.js) Procfiles list process types named commands that may be executed Each Procfiles line declares a process type and command to be executed in order run it The process types named web will receive HTTP traffic Procfile exposes architectural aspect of application Each process type can be scaled independently

8 Process types Each process type is a declaration of a command that is executed when Dyno of this process type is started web process type which starts application web special type that will receive HTTP trafic from Heroku s routers Other name for additional process performing additional tasks of more sophisticated applications (e.g. worker, timerwork etc.)

9 Deploying and building applications Git Heroku s primary mean to deploy applications Deploying sending the application to Heroku using Git A new Git remote is associated with local repository when application is created When Heroku platform receives a Git push, it initiates a build of the source application Build mechanism specific to language A slug is a bundle of source, fetched dependencies, the language runtime, and compiled/generated output of the build system - ready for execution

10 Running applications Dynos are isolated, virtualized Unix containers, that provide the environment required to run an application Applications are executed by running a command specified in the Procfile Number of Dynos should be controlled According to needs, many Dynos for each process can be started While deploying new version of application, all existing Dynos are killed, and new ones are started Dynos are important means of scaling application

11 Configuration Configuration is everything that varies between environments (production, developer, etc.) Configuration is independent from application and stored in Config vars collection of keys and values (limited to 16kb for each application The configuration is exposed to a running application via environment variables All Dynos of application will access the same Config vars

12 Releases Releases are an append-only ledger of slugs, Config vars and add-ons. All releases are automatically persisted in an append-only ledger Every time a new version of an application is deployed, a new slug is created and release is generated Heroku contains a store of the previous releases Change of Config vars values or addition/removal of Add-ons generates new releases

13 Celadon Cedar Stack Default runtime stack Polyglot environment enables utilize many languages across and within projects Right tool for particular job is provided Provides variety of means to handle processes

14 Dyno manager Responsible for keeping Dynos running Dynos are cycled at least once per day, or whenever the Dyno manager detects any fault, exception or failure of software or hardware Applications with only a single web dyno sleep after one hour of inactivity One-off Dynos are temporary dynos, loaded by latest release, that can run with their input/output attached to local terminal Each Dyno gets its own ephemeral file system - with a fresh copy of the most recent release Changes to the file system on one Dyno are not propagated to other Dynos and are not persisted across deploys and Dyno restarts

15 Add-ons Add-ons are third party, specialized, value-added cloud services that can be easily attached to an application, extending its functionality Add-ons are provided as services by Heroku and third parties and acquired via marketplace Add-ons are treated as attached resources Add-ons that provide some kind of storage are typically used as a means of communication between Dynos in an application

16 Erosion-resistance Traditional server-based environments require ongoing maintenance due to: OS updates Disk space filling Service crash and need to restart Failure of underlying hardware Dyno manager keeps Dynos running without manual intervention All infrastructure or PostgreSQL service crashes are managed automatically

17 HOW TO BUILD APPLICATIONS?

18 The Twelve-Factor App Methodology independent from any language to build SaaS applications which: Use declarative formats for setup information Have a clean contract with underlying OS Offers maximum portability Are suitable for deployment on modern cloud platforms Minimize divergence between environments for maximum agility Can scale up without significant changes to architecture or development practices 12factor.net

19 12factor.net I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing Services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes

20 12factor.net VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes

21 Heroku core development principles Heroku developers should be aware of principles grouped in: Development and configuration Runtime Management and visibility

22 Development and configuration principles Codebase is stored in version control system On deployment application is transmitted via VCS (Git) Codebase revisions deployed to different environments using namespacing Each codebase should be deployed as independent application thus making distributed system Configuration should not be stored in the code base, use heroku config Backing services (data stores, messages queues, etc.) are attached via URL or other locator/credentials stored in configuration file. Continuous deployment - gap between development and deployment minimal Use same services in development and production environments

23 Runtime principles No monolithic entities run many lightweight processes Assign each type of work to a process type Single Dyno runs single instance of a process type

24 Runtime - Heroku process model

25 Runtime principles Processes are stateless and share nothing No caching in distributed scalable environment Processes should be concidered to be disposable stop or start an any time Start time has to be minimised Process management should be left to dyno manager - so management activities in processes No runtime injection to web applications their only job listen for requests coming in on assigned port Web server library is added to web application (e.g. Jetty for JVM based languages)

26 Management and visibility principles Administrative and maintenance tasks are performed on One-off Dyno No logging needs to be implemented it is done by Heroku Logplex Logplex automatically collates log entries from all the running Dynos, as well as other components such as the routers, providing a single source of activity

27 Security Nothing is more important to our company than the privacy of our customer s data Bug bounty program Physical infrastructure hosted on Amazon, which have many accreditations Thrid party penetration testing and vulnerability assesments are performed Environmental safeguards Firewals, DDoS mitigation Applications run in secure, isolated environments Vulnerability management procedure Other.

28 Example Install Heroku toolbelt Java sample heroku.com/java Dashboard Marketplace

29 Project sample Create and deploy application in Heroku platform Any other proposed task using Heroku

30 Thank you! Rimantas Kybartas