Herokuにvaporをデプロイする

これをみながら。

わからないところメモ

 

remoteとは

heroku create {name}でheroku上にアプリを作る。
—remote {envname}で
 
herokuはheroku上のgitがあってそこにpushするとデプロイ処理が走るってこと?
 

buildpacksとは

buildpacksとは何なのか? - Qiita
任意の言語やソースコードからライブラリやフレームワークを読み取りベストプラクティスに則ってDockerfileすら書かずにイメージを生成してくれる。 Googleがオープンソースとして作成し、GCPではデフォルト使えるようになっている模様 https://github.com/GoogleCloudPlatform/buildpacks 公式のチュートリアルに則って使ってみたのですが本当にコマンド一髪で生成されました。 正直凄いと言うより、不思議です。 と言うわけでbuildpackの中身をみていきましょう。 buildpackはbuilderと言う実際にイメージを生成するツールが存在しています。 自分のソースコードに合わせた適切なbuilderを使うことでimageを作ることができるのです。 builderはビルドするための情報や方法が格納されたイメージ,以下の部品によって構成されています。 ソースコードを検査し、ビルド計画をするための作業単位 最低以下のファイルが必要になる buildpack.toml - buildpackのメタデータ? bin/detect - buildpackが実行できるかどうかを検証 bin/build - buildpackを実行するロジック フェーズとしては以下の二つ buildpackの内容と実際のソースコードが合致しているかどうかを逐次的にみていく 例えばnpm buildpackならpackage.jsonを見る build buildpackが実際にimageを作っていく。この時に、環境変数を設定し、バイナリを埋め込み(ruby,python,php),依存関係を解決する(bunble installなど) 複数のbuildpackを連携させて最終的なimageを作り出す フェーズは以下の4つ Detection - buildするためにbuildpackのグループを探索する Analysis - build か export フェーズに最適化に使うかもしれないファイルを復活させる ---?
なんかいい感じに環境揃えてくれるやつっぽい
つまるところ、vapor/vaporがいい感じの環境をビルドしてくれる
 

.swift-versionいるの?

buildpackがいい感じに決めてくれそうだし要らんのでは?
 

Procfile is何

急にstagingなのにproductionって文字列見えるけどこれ何?
Procfile
Heroku アプリには、起動時にアプリで実行するコマンドを指定する Procfile​ があります。 Procfile を使用して、次のようなさまざまな プロセスタイプ ​を定義できます。 アプリの各 dyno ​ は、宣言されているプロセスタイプのいずれかに属し、そのプロセスタイプに関連付けられている起動コマンドを実行します。 Procfile は、常に、 Procfile​ という名前のシンプルなテキストファイルで、 ファイル拡張子はありません​。たとえば、 Procfile.txt​ は有効では ありません ​。 Procfile は、アプリのルートディレクトリに常駐している必要があります。ほかの場所に配置すると、機能しません。 Procfile では、個々の行で、次の形式を使用してプロセスタイプを宣言します。 ​ は、コマンドの英数字の名前です (web​、worker​、urgentworker​、clock​ など)。 ​ には、起動時にそのプロセスタイプのすべての dyno で実行する必要があるコマンドを指定します (rake jobs:work​ など)。 Heroku アプリの web​ プロセスは特殊です。Heroku のルーターから外部 HTTP トラフィックを受信できるのは、このプロセスタイプのみです。アプリに Web サーバーが含まれている場合は、その Web サーバーをアプリの web ​ プロセスとして宣言する必要があります。
server起動コマンドを書くところっぽい
stagingだったとしてもvaport run serverはproductionで動かしたいからってことね
ここでrunコマンドが定義されてた

dyno

Heroku Dynos | Heroku
アプリ開発者が生産性を高めるための秘訣は、ソフトウェアの抽象化により開発を簡素化することです。アプリの実行に関してはコンテナ化による抽象化が有効であり、Heroku ではアプリをデプロイするだけでそのコードと依存関係ファイルがパッケージとしてコンテナに格納されるので、ハードウェアや仮想マシンの管理が不要になるというメリットがあります。コンテナとは、コンピューティングリソース、メモリ、OS、一時的なファイルシステムを備えた軽量の独立した環境です。通常は複数個が同じホストで実行されますが、それぞれのコンテナは相互に完全に隔離された状態になっています。 Heroku プラットフォーム はコンテナを使用してあらゆる Heroku アプリの実行やスケールを行います。Heroku で使用されるコンテナは「dyno」と呼ばれます。Dyno はユーザーが指定したコマンドにもとづいてコードを実行するように設計された Linux コンテナであり、それぞれが相互に隔離された状態で仮想化されています。アプリで利用できる dyno の数には制限がないため、リソースの必要量に応じてスケールすることができます。Heroku のコンテナ管理機能を使用すると、アプリに必要な dyno の数、サイズ、dyno のタイプをいつでも簡単に変更できます。 Dyno はごくシンプルなものからきわめて高度なものに至るまで、あらゆる Heroku アプリの実行に必要となる要素です。Dyno にアプリをデプロイして Heroku の dyno 管理機能を利用すれば、柔軟性とスケーラビリティに優れたアプリを簡単に開発、実行できるほか、インフラの管理が不要になるため、高品質なアプリの開発と運用に専念することが可能になります。 Dyno の機能の詳細 LitCharts 様事例→ Lean Poker 様事例→