1. 概要
1.1 Build.ioとは
Section titled “1.1 Build.ioとは”現代のアプリケーションを支える安全なPaaS
Section titled “現代のアプリケーションを支える安全なPaaS”Build.ioは、高い生産性を求めるチームに向けた堅牢なPaaSです。セキュリティとCI/CDのベストプラクティスを標準で備え、GitHubとシームレスに連携します。
SaaSアプリケーションの安全なデプロイ
Section titled “SaaSアプリケーションの安全なデプロイ”Build.ioは、すでに利用しているツールとそのまま連携します。GitHubで認証すれば、アプリケーションを直接デプロイできます。
Build.ioがプロジェクトに適したビルドパックを自動検出
Section titled “Build.ioがプロジェクトに適したビルドパックを自動検出”プロジェクトに必要なビルドパックは、Build.ioが自動で検出します。あわせて、ベストプラクティスに基づく安全なビルド環境も構築します。採用しているビルドパックレシピは、Google、Bloombergをはじめ、業界をリードする数千社が利用するものと同じです。デプロイはシームレスに、確実に進みます。
安心してデプロイとスケールを行い、コストを削減
Section titled “安心してデプロイとスケールを行い、コストを削減”アプリケーションのデプロイは、ワンクリックで完了します。デプロイ先は、要件に応じてプライベートクラウドとパブリッククラウドから選択できます。
アプリのデプロイに必要な機能をすべて標準搭載
Section titled “アプリのデプロイに必要な機能をすべて標準搭載”デプロイに必要なものは、最初から揃っています。GitHubで認証すれば、すでに利用しているツールと組み合わせたまま、アプリケーションをBuild.ioへ直接デプロイできます。
データベースやキャッシュをはじめ、幅広いアドオンを用意しています。アプリケーションに組み込むだけで、パフォーマンスやスケーラビリティを高められます。
SSL証明書
Section titled “SSL証明書”SSL証明書はBuild.ioが自動で発行し、アプリケーションに設定します。初回アクセスの時点から通信が暗号化されるため、エンドユーザーからの信頼につながります。
アーキテクチャは、高可用性と耐障害性を前提に設計されています。どのような負荷のもとでも、パフォーマンスと安定性を維持します。
Cloud Native Buildpacksのすべての利点
Section titled “Cloud Native Buildpacksのすべての利点”Cloud Native Buildpacksは、Build.ioの土台です。手作業を挟むことなく、ビルドパックの利点をそのまま活用できます。具体的には次のとおりです。
高度なキャッシュ
Section titled “高度なキャッシュ”堅牢なキャッシュ機構により、パフォーマンスが向上します。
ビルドを再実行しても、生成されるアプリイメージは変わりません。イメージを一意に識別するダイジェスト値も一致します。
モジュール式/プラグイン対応
Section titled “モジュール式/プラグイン対応”複数のビルドパックを組み合わせて、1つのアプリイメージにまとめられます。
マルチ言語対応
Section titled “マルチ言語対応”系統の異なる複数のプログラミング言語に対応します。
Heroku互換
Section titled “Heroku互換”Herokuで広く使われている機能は、標準で利用できます。
コミュニティが公開している本番運用向けのビルドパックを活用できます。
セキュリティとコンプライアンス:世界中の数百人の開発者からの信頼
Section titled “セキュリティとコンプライアンス:世界中の数百人の開発者からの信頼”Build.ioはマネージドサービスです。運用拠点はTier 4データセンターで、米国(東部および西部)、西ヨーロッパ、日本の主要なインターネットハブに置いています。
開発チームには、Cloud Native Computing Foundation(CNCF)傘下の著名なセキュリティツールやプロジェクトのコアコントリビューターが在籍しています。Metasploit、Kubernetes、QVIP、Ciliumがその例です。CISSPおよびCREST CRTの認定を持つペネトレーションテスターも複数名おり、セキュリティをあらゆるレベルで最優先しています。
セキュリティとコンプライアンスの詳細は、support@build.ioまでお問い合わせください。
1.2 仕組み(高レベルアーキテクチャ)
Section titled “1.2 仕組み(高レベルアーキテクチャ)”
Build.ioは、受け取ったコードをクラウド上で実行します。コードをプッシュすれば、サーバーとネットワークの運用も、スケーリングとデプロイも、すべてBuild.ioが担います。この章では、利用にあたって前提となる主要な概念を説明します。
コードがアプリケーションとして稼働するまで
Section titled “コードがアプリケーションとして稼働するまで”Build.ioにデプロイすると、次の順に処理が進みます。
まず、コードがビルドシステムに送られます。ビルドシステムは、言語とフレームワークを自動で判別します。
続いて、Build.ioが依存関係をインストールし、必要に応じてアセットをコンパイルしたうえで、すべてを軽量なコンテナにまとめます。
そのコンテナがBuild.ioのインフラにデプロイされ、トラフィックの受け付けを開始します。
サーバー、オペレーティングシステム、コンテナオーケストレーションを管理する必要はありません。管理するのは、コードと設定だけです。
パイプライン:デプロイワークフロー
Section titled “パイプライン:デプロイワークフロー”パイプラインは、Build.ioの軸になる仕組みです。コードが開発から本番環境に至るまでの流れを表し、現代の開発チームの実務に即して設計されています。
典型的なパイプラインは、3つのステージで構成されます。

レビューアプリは、プルリクエスト(PR)の作成時に自動で用意される一時的な環境です。PRごとに独立したアプリが起動し、専用のURLが割り当てられます。マージ前に、チームで変更を確認してレビューできます。PRがクローズされると、レビューアプリは自動で削除されます。
ステージングは、本番の一歩手前に置くプレ本番環境です。コードをメインブランチにマージすると、自動でここへデプロイされます。構成は本番をできるだけ忠実に再現しており、最終テスト、QAチェック、デモを済ませたうえで本番環境へ移します。
本番環境は、実際のユーザーにサービスを提供するライブ環境です。ステージングでの動作を確認できたら、ワンクリックで本番環境へプロモートします。このとき再ビルドは行われません。ステージングで稼働していたコンテナがそのまま本番環境にデプロイされるため、開発環境では動いたのに本番環境では動かないといった問題を防げます。
パイプラインの設定と運用については、セクション9で詳しく説明します。
アプリは、デプロイの基本単位です。デプロイ可能な単一のコードベースを指し、通常は1つのWebサービス、API、ワーカープロセスのいずれかに対応します。
Dynoは、コードを実行する軽量なコンテナです。Dynoの数を増やせば水平方向にスケールし、Dynoのサイズを大きくすれば垂直方向にスケールします。
ビルドパックは、アプリケーションのビルドを担うスクリプトです。言語の検出、依存関係のインストール、コンパイルまでを実行します。一般的なプログラミング言語には公式のビルドパックを用意しており、独自のカスタムビルドパックも使用できます。
Config Varは、アプリに環境変数として渡される設定値です。データベースURL、APIキー、フィーチャーフラグは、いずれもここで管理します。コード内には記述しないでください(セクション4.1を参照)。
アドオンは、データベース、キャッシュ、モニタリング、ロギングなどのマネージドサービスです。コマンド1つでアプリにアタッチできます(セクション5を参照)。
お客様が管理する範囲とBuild.ioが管理する範囲
Section titled “お客様が管理する範囲とBuild.ioが管理する範囲”
1.3 クイックスタートガイド(初めてのアプリを5分でデプロイ)
Section titled “1.3 クイックスタートガイド(初めてのアプリを5分でデプロイ)”初めてのアプリは、5分以内にデプロイできます。ここでは、アカウントの準備からデプロイの確認までを順に説明します。
次のものが必要です。
- Build.ioアカウント(こちらからサインアップし、アカウントが有効化されるまでお待ちください)
- デプロイ対象となる既存のアプリケーション
1.3.1 アプリを作成する
Section titled “1.3.1 アプリを作成する”ページ右上、アバターの隣にあるドロップダウンボタン(New +)をクリックし、表示されたメニューからNew Appを選択します。

開いたページでアプリに名前を付け、リージョンをus-east-1に設定します。

新しいアプリが作成され、上部にタブが並んだページが表示されます。
1.3.2 スタックを選択する
Section titled “1.3.2 スタックを選択する”Settingsタブをクリックします。推奨されるビルドパック方式でアプリをビルドする場合は、このページでStackを最新のHerokuスタックに設定します。

1.3.3 必要なビルドパックを選択する
Section titled “1.3.3 必要なビルドパックを選択する”同じページを下にスクロールし、Buildpacksセクションへ移動します。このセクションで、アプリケーションに必要な言語またはフレームワーク固有のビルドパックを追加します。今回のサンプルアプリはRubyアプリケーションのため、公式のHeroku Rubyビルドパックを、GitHubリポジトリのフルパスで指定します。

1.3.4 Gitリポジトリを接続する
Section titled “1.3.4 Gitリポジトリを接続する”ページ上部のDeployタブをクリックし、Connectionセクションへ移動します。ここでアプリをGitHubリポジトリに接続します。1つ目のボックスでGitHub Organizationを選択し、2つ目のボックスでリポジトリ名を検索します。表示された検索結果から、目的のリポジトリのConnectをクリックします。

このステップが完了すると、Connectionセクションの表示は次のようになります。接続が有効になっていることを、ここで確認できます。

1.3.5 デプロイする
Section titled “1.3.5 デプロイする”このページの下部までスクロールし、デプロイ対象のブランチを選択してManual Deployを実行します。Deploy Branchをクリックすると、デプロイが始まります。

デプロイを開始すると、ビルドページが自動で開きます。アプリのビルド状況は、このページでリアルタイムに確認できます。

Overviewタブへは、いつでも移動できます。アプリのメインビューでは、44秒前にビルドが成功し、その直後にデプロイが完了したことを確認できます。ページ右上のGoリンクをクリックすると、作成したアプリが開き、そのまま利用できます。

以上で、初めてのアプリをBuild.ioにデプロイできました。
1.4 対応言語とフレームワーク
Section titled “1.4 対応言語とフレームワーク”Build.ioは、すでに利用している言語とフレームワークに対応します。コンテナで実行できるものであれば、Build.io上でも実行できます。コンテナを扱った経験がなくても、たいていはビルドパックがすべて自動で引き受けます。
使用している技術スタックが対応しているか分からない場合でも、ほとんどのWebアプリケーションは追加の設定なしで動作します。問題が発生した場合は、support@build.ioまでご連絡ください。セットアップをお手伝いします。
公式ビルドパック
Section titled “公式ビルドパック”公式ビルドパックには、主要なクラウドプロバイダーが管理する業界標準のCloud Native Buildpacksを採用しています。いずれも実運用で十分に検証されており、ビルドの速さ、イメージサイズの小ささ、本番環境にそのまま使えるデフォルト設定を重視して設計されています。追加の設定は不要です。ビルドパックは定期的に更新され、新しい言語バージョンへの対応やセキュリティパッチ、パフォーマンス改善が加わります。
コミュニティビルドパック
Section titled “コミュニティビルドパック”公式ビルドパックに加えて、Cloud Native Buildpacksコミュニティが公開するビルドパックも利用できます。追加の言語や代替ランタイム、特殊な構成にも対応できます。
カスタムビルドパック
Section titled “カスタムビルドパック”技術スタックに固有の要件がある場合は、独自のビルドパックを作成することも、既存のビルドパックをフォークすることもできます。デプロイパイプラインの利点はそのままに、ビルドプロセスを完全に制御できます。
コンテナデプロイ
Section titled “コンテナデプロイ”すでにDockerワークフローを運用している場合は、ビルドパックを介さず、任意のDockerイメージを直接デプロイできます。コンテナで実行できるものであれば、Build.io上でも実行できます。
