Android/Linux/Docker 環境

ハードウェア ⚓

現在のハードウェアの仕様は以下のとおりです

最低 7.5GB RAM
最低 2 CPU コア
64bit CPU
最低10GBの空きディスクスペース

環境 ⚓

BitriseはQuay上で発行された標準のDockerイメージとGitHubにある関連したDockerfileを使用します。

Dockerfileとは何ですか?

Dockerfileとはdockerにおいてのイメージ・環境が記載されており、イメージをビルドするのに直接使用される記述ファイルです。

Right now we have four docker images, built on top of each other:

Bitriseには現時点で4つのdockerイメージがあります。

Bitrise ベース・イメージ（GitHub/Quay） ⚓

イメージネームID：quay.io/bitriseio/bitrise-base
全てのAndroid以外のツールと環境構成が含まれています。
これは最も小さいイメージであるため、ローカルで使用される場合は、ベース・イメージとしてAndroid以外のプロジェクトに使用されるのが望ましいです。
Ruby、 Go、 Python、 git と Bitriseコマンドラインツールが全てプリインストールされており、いつでも使用可能です。
OS：Ubuntu 16.04,、64 ビット
関連したDockerfileをチェックして、このイメージ内にプリインストールされているツールをご確認ください。

ベースAndroidイメージ(GitHub / Quay) ⚓

イメージネームID：quay.io/bitriseio/android
Androidに特化したツール・環境を使ってBitriseベースイメージを拡張します。
gradle や maven と同様に、ビルドツールやシステムイメージバージョンといった複数のAndroid SDKがプリインストールされています。
$ANDROID_HOME の環境変数を使用して、プリインストールされたAndroid SDKの場所を示すことができます。
関連したDockerfileをチェックすれば、このイメージ内に何がプリインストールされているか確認できます。

Android NDKイメージ (GitHub / Quay) ⚓

イメージネームID：quay.io/bitriseio/android-ndk
ベースAndroidイメージ上にてビルドされ、最新のAndroid NDKに拡張します。
$ANDROID_NDK_HOME の環境変数を使用して、プリインストールされたAndroid NDKの場所を示すことができ、$PATH へ追加もされます。
関連したDockerfileをチェックして、このイメージ内に何がプリインストールされているか確認できます。
こちらでこのスタックのプリインストール済みツールとシステムレポートが確認できます。

Android NDK LTS イメージ (GitHub / Quay) ⚓

イメージネームID：quay.io/bitriseio/android-ndk-lts
このイメージは、常に古いAndroid NDKイメージのタグ付されたバージョンになります。
$ANDROID_NDK_HOME の環境変数を使用して、プリインストールされたAndroid NDKの場所を示すことができ、$PATH へ追加もされます。
OS：Ubuntu16.04、64ビット
こちらでこのスタックのプリインストール済みツールとシステムレポートが確認できます。

Docker と仮想マシン ⚓

新しいコンテナ上だけでなく、新しい仮想マシン上でも全てのビルドが走行されます。その仮想マシンはビルド終了後すぐに破壊されます。これはDockerと環境全体のフル管理を提供します。

スタックに基づいたDocker上でビルドを開始する際、あなたのコンテナへ/var/run/docker.sock ソケットをボリュームマウントします。 (docker run -v /var/run/docker.sock:/var/run/docker.sock ...の呼び出し方に類似しています。このアクセスの付与についての方法はこちらにて確認できます。）

Dockerバイナリのインストール

dockerバイナリはベースDockerイメージ内にてインストールされている必要があります。Dockerはシングルバイナリソリューションから装填された構成への移動が開始され、dockerバイナリを単にシェアするだけでは不十分だからです。

BitriseがDockerイメージ一つ一つにDockerをインストールするので、Bitriseのイメージを使用する、またはBitriseのDockerイメージ上にご自身のイメージを基礎づける場合は何もする必要がありません。

これであなたはコンテナ内でdockerにアクセスができ、docker-composeのようなdockerを使用する他のツールを使うことができます。例えば、docker-composeを使用するウェブサイトプロジェクトの設計やテスト走行、他の自動化された作業が可能となります。

docker info, docker build, docker run, docker login, docker push をご自身のマシンに呼び出すことができ、正確に行うことができます。

共有ボリューム ⚓

ビルド内でのdockerの走らせ方とボリュームの共有

あなたのビルド内でdockerを走らせたりボリュームを共有する場合、ベースDockerコンテナ（ビルドが動作しているコンテナ）を使って共有されたボリュームのみが共有されます。これはdockerによるボリューム共有の処理方法からなります。/bitrise 以下の全てのものがボリュームとしてマウントされますが、--volume マッピングを使用した他のパスでは保証されません。

これはボリュームマウントするうえで、標準のパスや関連したパスを使用する場合、デフォルトのソースコードディレクトリが/bitrise内に位置していると動作します（BitriseのDockerイメージ内はデフォルトで/bitrise/srcになっています）。

ソースコードディレクトリを/bitrise の外部に変更したり、/bitriseの外部に絶対パスを使用したフォルダのマウントを行いたい場合、動作しません。