Travis CIが出た時から、当社はビルドにおける安定性と信頼性の提供を第一にしてきました。しかし、常に期待に応えてこられたとは言えません。ネットワークの問題や、ビルドのキャパシティが不十分で(オープンソースプロジェクトに対して)ビルド開始までに時間がかかる、ビルド環境におけるCPUやメモリのリソースに制限がある、オープンソースプロジェクトに対応するキャッシュがないなどの問題がありました。また、現在当社で使っている大部分のLinuxのスタックはプライベートクラウド上で動作するため、要求してからキャパシティに空きができるのを待つというプロセスを経なければならなりませんでした。そのため、キャパシティを増やすという課題もありました。

今回ご紹介するのは、このような課題に対応した新たなビルド・インフラストラクチャです。これからは、プライベートやオープンソースのリポジトリにもお使いいただけます。

新しいインフラストラクチャの利点は？

ビルドが数秒で開始する

ビルドの開始まで長時間待つことはなくなり、10秒もせずにビルドが開始します。空き容量があれば（スケーリングもはるかに簡単になりました)、ビルドがスケジュールされてから開始するまで、数秒しかかかりません。

より高速なビルド

私たちは新たなスタックへのプロジェクトの移行をお手伝いする中で、そのほとんどでビルド時間が大幅に改善するのを見てきました。有用性については、ビルドのI/O負荷に大きく左右されるでしょうが、大抵のプロジェクトで改善が見られるはずです。もしビルド時間に改善が見られない、または遅くなったという場合は、ぜひご連絡をいただければと思います。

コンテナ内の利用可能なリソースが増えた

当社の従来のビルド・インフラストラクチャのビルドコンテナは、1.5コア(バーストキャパシティあり)、3GBメモリでした。現在はCPUリソースが保証され、同じホストマシン上の他のノイズの影響を受けにくくなっています。新たなコンテナスタックなら、一日中かかっていたビルド時間がずっと着実に進むようになるはずです。

新しいコンテナは2専用コア、4GBメモリを有しています。

ネットワークのキャパシティ、可用性、スループットの改善

新たなスタックはEC2上で動作します。これにより、EC2でホストされているものを中心に、大抵のサービスへのネットワークアクセスが大幅に高速化します。S3へのアクセスも、私たちの従来のスタックに比べはるかに速くなりました。

キャッシュがオープンソースプロジェクトに利用可能になった

オープンソースプロジェクトに関わる最大のニュースは、当社のビルド・キャッシングがオープンソースプロジェクトにも利用可能になったことです。これにより、キャッシュの依存関係によってビルドのスピードが上がります。試される際は必ずドキュメントをご確認ください。

Rubyのプロジェクトの場合、やり方はとても簡単で、ご自分の .travis.yml に cache: bundler を追加すれば完了です。

スケーリングが容易になった

もしかしたらこれは当社のユーザや顧客の皆さんにとっては直接的なメリットではないかもしれませんが、私たちにとっては有益なことです。これによって要求への対応が迅速にできますし、数分のうちにビルドのキャパシティを増やせるようになりました。そうすることで、オープンソースプロジェクトがキャパシティのピークに達しにくくなり、実行まで何時間も順番待ちをしなくて済むようになるのです。

使い方は？

あなたの.travis.ymlに以下の行を追加するだけで、新しいコンテナベースのスタックをご利用いただけます。

sudo: false

どんな制約がある？

sudoを使用できない(現時点では)

新しいコンテナスタックは内部でDockerを使用しています。こうすることで、起動が速い、利用可能なマシンリソースの稼働率が向上するなど、多くのメリットが得られます。しかし同時にセキュリティによる制約も出てきてしまいます。

現時点では、ビルドで sudo を要求するコマンドを使用できません。

例えばUbuntuのパッケージをインストールしようとして sudo を要求した場合は、ワークアラウンドとしてプリコンパイルされたバイナリを使用します。S3にアップロードしてそれをビルドの一部としてダウンロードし、non-rootに直接インストールするのです。

データベースがメモリディスクを書き出さない

当社の従来のスタックでは、MySQLもPostgreSQLも、メモリディスクへの書き出しによってトランザクションとクエリのスピードを大幅に上げていました。このことでトランザクションの使用やフィクスチャ、汎用データベースの使用法に依存するプロジェクトに影響を与える可能性がありますが、この影響は通常悪いものではないはずです。

新しいスタックについて

この１年、当社は Travis CI Enterprise という、GitHub Enterpriseの顧客のためのオンプレミスのソリューションの開発に取り組んできました。このスタックを開発する中で、OpenStackやVMware、その他の仮想化環境などのカスタム・インフラストラクチャ、さらにはベアメタルのハードウェア上でどうしたらベストな動作ができるかを考える必要が出てきました。

当社の従来のスタックは独自の運用クラウド上で動作し、当社の顧客のデータセンタではAPIが利用できませんでした。スタック全体をインストール用にパッケージ化し、さらに分離環境でビルドを走らせることを可能にする方法を探す中で、私たちは1年ほど前にDockerを選択肢の一つとして考え始めたのです。

私たちの新しいスタックは、顧客の希望に沿ったあらゆる環境で動作可能になりました。EC2へのカスタムTravis CI Enterpriseのインストールや、Digital Ocean、Linode、Rackspace、そして完全にインハウスのインフラストラクチャにも対応します。

他の選択肢もいくつか確認しましたが、EC2の方がパフォーマンスが良く、より信頼性の高いネットワークを持っていることが分かりました。

プライベートにホストされたものにもオープンソースプロジェクトにも対応する当社の新しいスタックは、Dockerコンテナ内のEC2上で動作します。ネットワークでも計算リソースでもすばらしいパフォーマンスを発揮し、S3へのダイレクトアクセスによってビルドのキャッシングが大幅に高速化します。

その他の疑問点

自分のDockerコンテナを使用できる？

当社が現在Dockerベースのセットアップで使用しているビルド環境では、従来のスタックと同じサービスやプログラミング言語、ツールを提供しています。当社はこれらをできる限りのレベルに保ってきました。

sudo が使用できないことで、たしかにカスタムライブラリやサービスのインストールが難しくなり、特権ポート上でそれらを実行するか、単に apt. を使用することになります。ご自分のイメージを使用できないかと思われるのは当然のことです。

まだご自分のDockerを使っていただくことはできませんが、今後の取り組みを考えています。

Dockerコンテナを自分のビルドの一部としてビルドできる？

これも上と同じで、現在はできません。大部分はセキュリティの問題です。しかし将来的にはこれを解決したいと考えています。

Docker内でDockerを走らせられる？

ビルドの一部としてDockerコンテナを走らせることは、根本的なコンテナ技術に由来するセキュリティ関係の問題があるため、現在はできません。これを将来的に解決するために、いくつかの計画を立てています。

あらゆる所にコンテナを

Travis CIでの高速で信頼性の高いより良いビルドの提供を目指す中で、これはまだ始まりに過ぎません。安定性の改善のために計画していることがまだたくさんあります。しかし、今回これを送り出せることを大変嬉しく思っています。

ぜひ使ってみて感想をお聞かせください！

現在および今後の詳しい情報については、ぜひ 新しいコンテナベースのスタックについてのドキュメント をチェックしてください。