-
Notifications
You must be signed in to change notification settings - Fork 9
cedar
Celedon Cedar is Heroku's most recent runtime stack and is a flexible, polyglot environment with robust introspection and erosion-resistance capabilities. It embodies the Twelve-factor app methodology of building, deploying and managing modern web applications.
Celedon Cedar は Herokuの最新の (ランタイム スタック)[wiki/stack]です。堅牢なイントロスペクションとエロージョン抵抗機能を備えた、柔軟で多言語環境です。それは展開とモダンなWebアプリケーションにおけるビルド、デプロイ、管理の方法論である12factorを体現しています。
To create an app on the Cedar stack, use the --stack (or -s) flag from the Heroku command line:
Cedar スタックでアプリケーションを作成するためには--stackまたは-sオプションを付けてHeroku コマンドラインから以下の様に実行します。
:::term
$ heroku create --stack cedar
Make sure you're running version 2.1.0 or higher of the command-line tool which can be installed via the Heroku toolbelt.
なおHeroku コマンドラインツールのバージョンが2.1.0以降であることを確認して下さい。Heroku toolbeltを利用している場合には以下のようにheroku updateコマンドでバージョンを上げることが可能です。
:::term
$ heroku --version
2.0.1
$ heroku update
-----> Updating to latest client... done
$ heroku --version
2.21.2
Cedar is a polyglot platform with native support for many of today's most popular and productive languages and frameworks including:
Cedar スタックでは人気の生産性が高いプログラミング言語やフレームワークを含む多様性のあるプラットフォーム です。
| ここから始めましょう... | |
|---|---|
| Clojure | |
| Java, Spring or Play | Node.js |
| Python or Django | Ruby or Rails |
| Scala | |
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. On Cedar, language choice and deployment infrastructure are orthogonal.
The foundation of Cedar's unified multi-language support is the new process model which provides a consistent interface for running and managing apps.
プラットフォームレベルでの多言語のサポートにより、プロジェクトや仕事のための適切なツールを確実に選択することを含め、開発チームが効果的に多くの言語を利用出来るようになります。Cederでは言語とインフラが直交しています。
Cedarの統一された多言語サポートの基盤は、アプリケーションを実行および管理するための一貫したインタフェースを提供し、新しいプロセスモデルです。
Cedar introduces a new way to think about scaling your app: the process model. 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.
Cedar スタックは、プロセス モデルという、アプリケーションをスケーリングする新たな方法を導入します。プロセスモデルは、分散化された環境を横断したプロセスを管理するための総合的なアプローチです。Procfileにカスタムプロセスタイプを記述して、各プロセスを特定することが出来ます。そして、細かい粒度でアプリケーションのコンポーネントを管理することが出来ます。
:::ruby
web: node web.js
worker: node worker.js
reports: node report.js
The process model enables the thousands of unique process formations across the dyno manifold while giving application developers the flexibility to use the frameworks and libraries of their choice.
プロセスモデルは、何千ものをユニークなプロセスの形成可能にし、アプリケーション開発者に、彼らのフレームワークやライブラリの選択を柔軟なものにしてくれます。
The process model also allows applications with logical components to manage and [scale at a very granular level]scaling). For instance, to dial-down HTTP processing while increasing background job concurrency, apply the heroku ps:scale command against your application's unique process model.
:::term
$ heroku ps:scale web-1 worker+2 reports=1
Scaling web processes... done, now running 3
Scaling worker processes... done, now running 5
Scaling reports processes... done, now running 1
Cedar's flexibility is most evident with the heroku run command which lets you execute any command against your application. Many languages support a REPL which gives you a console with which to interact with your application. Use heroku run to establish an interactive session with a remote REPL for a Clojure app.
Cedar の柔軟さは、あなたのアプリケーションに対してどんなコマンドでも実行できる heroku run コマンドでも明らかです。多くの言語は、コンソールでアプリケーションと対話するための REPL をサポートしています。heroku run を使うと、 Clojure アプリケーション用のリモート REPL 対話セッションを確立できます。
:::term
$ heroku run "lein repl"
Running lein repl attached to terminal... up, run.1
Clojure 1.3.0
user=>
One-off processes, such as rake tasks for Ruby applications, can also be executed against their remote environment on Heroku.
Ruby アプリケーションの rake タスクのような ワンオフプロセス も、同様に Heroku のリモート環境に対して実行できます。
:::term
$ heroku run rake db:migrate
Running `rake db:migrate` attached to terminal... up, ps.1
(in /app)
Migrating to CreateWidgets (20110204210157)
== CreateWidgets: migrating ==================================================
-- create_table(:widgets)
-> 0.0120s
== CreateWidgets: migrated (0.0121s) =========================================
Deployment platforms can appear to be black-boxes in their management and automation of application runtimes. Heroku Cedar provides several tools to give application developers complete insight into their applications.
The heroku ps command lists all processes running for an application and clearly identifies the state of each individual process.
:::term
$ heroku ps
Process State Command
------------ ------------------ ------------------------------------
web.1 up for 8h bundle exec thin start -p $PORT -e production
web.2 up for 3m bundle exec thin start -p $PORT -e production
worker.1 up for 1m bundle exec stalk worker.rb
Aggregated logs for all components in the application stack, including components managed by Heroku such as the HTTP router, are available in a single stream with heroku logs.
:::term
$ heroku logs -t
2012-03-16T14:02:57+00:00 heroku[router]: GET devcenter.heroku.com/articles/git dyno=web.3 queue=0 wait=0ms service=44ms status=200 bytes=32839
2012-03-16T14:02:57+00:00 app[worker.1]: [Worker(host:278fa1bc-d6aa-4409-bffd-0032dd0093b5 pid:1)] Article#reindex_without_delay completed after 0.1200
2012-03-16T14:02:57+00:00 app[worker.1]: [Worker(host:278fa1bc-d6aa-4409-bffd-0032dd0093b5 pid:1)] 1 job processed at 11.3892 j/s, 0 failed ...
2012-03-16T14:03:00+00:00 heroku[router]: GET devcenter.heroku.com/images/dev-center/aside_accordion_indicator_open.png dyno=web.1 queue=0 wait=0ms service=2ms status=200 bytes=369
2012-03-16T14:03:05+00:00 app[web.3]: Started GET "/articles/git" for 213.144.5.2 at 2012-03-16 14:03:05 +0000
2012-03-16T14:03:05+00:00 app[web.3]: Processing by ArticlesController#show as HTML
2012-03-16T14:03:05+00:00 app[web.3]: Parameters: {"id"=>"git"}
2012-03-16T14:03:05+00:00 app[web.3]: Read fragment views/devcenter.heroku.com/articles/git (3.6ms)
Here we see the router receiving a request and passing it to the backend web.3 process while the worker.1 process indexes an article for search. Router logs, database queries and application output is all coalesced into a singled event stream for full visibility into your application's execution.
Component and process-level introspection is also available to quickly zero-in on problematic processes and filter out irrelevant activity.
:::term
$ heroku logs --ps worker.1 -t
2012-03-16T14:16:58+00:00 app[worker.1]: [Worker(host:278fa1bc-d6aa-4409-bffd-0032dd0093b5 pid:1)] Article#reindex_without_delay completed after 0.0645
2012-03-16T14:16:58+00:00 app[worker.1]: [Worker(host:278fa1bc-d6aa-4409-bffd-0032dd0093b5 pid:1)] Article#record_view_without_delay completed after 0.0388
2012-03-16T14:16:58+00:00 app[worker.1]: [Worker(host:278fa1bc-d6aa-4409-bffd-0032dd0093b5 pid:1)] 10 jobs processed at 11.6378 j/s, 0 failed ...
All application deployments and configuration changes are captured and logged by Heroku and are made available with heroku releases.
:::term
$ heroku releases
Rel Change By When
---- ---------------------- ---------- ----------
v52 Config add AWS_S3_KEY [email protected] 5 minutes ago
v51 Deploy de63889 [email protected] 7 minutes ago
v50 Deploy 7c35f77 [email protected] 3 hours ago
Releases ensures that an application's lifecycle is captured in an accountable and actionable format with the ability to undo errant modifications with heroku releases:rollback.
On Cedar, an app named foo will have the default hostname of foo.herokuapp.com.
The herokuapp.com domain routes to a modern HTTP stack which offers a direct routing path to your web processes. This allows for advanced HTTP uses such as chunked responses, long polling, and using an async webserver to handle multiple responses from a single web process.
Cedar does not include a reverse proxy cache such as Varnish, preferring to empower developers to choose the CDN solution that best serves their needs.
Migrating from Bamboo to Cedar allows an application to take advantage of a much more flexible and powerful stack. Because the significant architectural differences, migrating to Cedar is a largely manual process.
Instructions for migrating to Cedar can be found here.