まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:cpu

以前からこのテーマに興味があって、色々調べたり試したりしてもなかなかうまく行かず、半ばあきらめかけていた所で成功したので、その手順をまとめておきました。後述しますが、このテーマは今後多くの人が興味を持つ可能性が高いと思っているので、そんなみなさんのお役に立てれば。。


【背景】
おそらく最もメジャーなコンテナ技術の1つである docker は、docker hub に公開された多くのイメージが利用できる便利さとの相乗効果もあって、多くのコンテナ技術者に利用されています。自分も勉強用・動作検証用の簡易アプリイメージを docker hub に格納して使っています。

ただ最近になって docker 利用時に少し困ることも起こるようになりました。困っている内容を端的に表現すると「自分が公開しているアプリイメージは特定のアーキテクチャ向けに作られていて、異なるアーキテクチャの docker からは使えない」という問題でした。

もう少し詳しく説明します。自分はメインの開発環境としては Windows 10 を使っています。docker 環境は Windows 10 に Docker Desktop をインストールしてサーバーとして利用し、この環境に WSL2 の Ubuntu から docker コマンドを使って利用する、という使い方をしています。が、このメインマシン以外にも数台の PC があり、その中にはラズベリーパイも含まれています。ラズベリーパイにも docker を含めた開発環境が導入されていて、ラズベリーパイでも docker 環境が利用できます。

この環境が問題でした。Windows 10 や WSL2 の docker は linux/amd64 という「インテルアーキテクチャ CPU の 64 ビット Linux」向けの docker です。一方ラズベリーパイの docker は linux/arm/v7 という「ARM CPU の 32 ビット Linux」向けの docker です。これら2つのアーキテクチャは CPU が異なることもあり、バイナリ互換はありません。したがってどちらかで動くバイナリは、もう一方では動かないことになります。この問題は docker でも(後述の方法を使わない限りは)解決しておらず、一方の docker 環境で作成したイメージは、もう一方では動かない、という現象が発生していたのでした。このため Windows + WSL2 で docker イメージを作って docker hub に登録しても、ラズベリーパイからは使えないし、逆にラズベリーパイで docker イメージを作って docker hub に登録しても、Windows + WSL2 では使えない問題が発生していました。

この問題を解決するのが今回のテーマであるマルチ CPU アーキテクチャ対応 docker イメージです。名前の通りで複数のアーキテクチャ(今回であれば linux/amd64 と linux/arm/v7)に対応した docker イメージを作って docker hub に登録することで、docker pull を実行した環境のアーキテクチャに対応したイメージがダウンロードされ、Windows + WSL2 からもラズベリーパイからも docker 環境内で利用することができるようになるものです。このマルチ CPU アーキテクチャ対応 docker イメージの作り方を以下に紹介します。


【操作環境】
- Windows 10 Pro に Docker Desktop をインストール(docker エンジンは 19.03.13)。
- WSL2 に docker CLI をインストール(バージョン 19.03.13、19.03 以上であれば後述の buildx コマンドが使えます)

未確認ですが、docker は linux/amd64 の macOS 環境であっても以下の操作は可能です。ただ M1 と呼ばれる新しい環境の macOS から利用できるかどうかはわかりません。またラズベリーパイの docker や、CentOS7 環境に用意した docker 環境では後述の buildx コマンド自体は使えるのですが、他プラットフォーム向けのビルドに対応していないようで、操作環境としては事実上不適格でした。

docker CLI を WSL ではなく Windows から実行するケースも未確認ですが、このような open issue もあって、もしかすると動かない可能性もあるのではないかと思っています:
https://github.com/docker/for-win/issues/4991


【操作前の準備(ウェブアプリと docker hub アカウントの用意)】
最初に docker イメージを作る際のアプリケーションを用意します。もちろん自分でアプリを開発できる方はそれを使っていただいても構いません。そうでない人向けに自分が以下で解説する際に使った hostname アプリのソースコードを公開しているので、こちらをダウンロードするか git clone して使って試していただいても構いません:
https://github.com/dotnsf/hostname

このアプリは Node.js で記述されたシンプルなアプリで、以下のような挙動です(もちろん特定のアーキテクチャに依存するような内容ではありません):
- 8080 番ポートで HTTP リクエストを待ち受け
- "/" にアクセス(例えば同じホストからであれば http://localhost:8080/ にアクセス)すると、/etc/hostname ファイルの内容をそのまま text/plain で返す


普通の Windows(WSL) や macOS 、ラズペリーパイを含む Linux 環境では /etc/hostname にはそのマシンのホスト名称が記載されているのが一般的ですが、特に docker 環境においては /etc/hostname には稼働中のコンテナIDが記載されます。したがって k8s などを併用して複数インスタンスを起動してこのアプリのイメージを実行してアクセスした場合、アクセス結果からどのコンテナに振り分けられて処理されたのかが視覚化されて便利なので、そういった動作確認時などに使っていたアプリでした。
//.  app.js
var express = require( 'express' ),
    fs = require( 'fs' ),
    app = express();

app.get( '/', function( req, res ){
  res.contentType( 'text/plain; charset=utf-8' );
  fs.readFile( '/etc/hostname', "utf-8", function( err, text ){
    if( err ){
      res.write( JSON.stringify( err, 2, null ) );
      res.end();
    }else{
      res.write( text );
      res.end();
    }
  });
});

var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );


ちなみに Dockerfile は以下のような内容です:
# base image
FROM node:12-alpine

# working directory
WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080
CMD ["node", "app.js"]


ベースイメージに node:12-alpine を指定しています。ここで注意点として、ベースイメージにアーキテクチャ依存の指定を含まないようにする必要があります。例えばラズペリーパイ向けのイメージを明示的に作ろうとすると、ここは
FROM arm32v7/node:12-alpine

のようにラズベリーパイで使われている arm32v7 アーキテクチャ向けの node:12-alpine イメージをベースとする、という指定を明示的にすることも可能です。が、このような指定をしてしまうとインテル CPU アーキテクチャ向けのイメージを作る際のエラーの原因となってしまいます。このような特定アーキテクチャ向けのベースイメージ指定はしないようにしてください。


そして、もしもまだ docker hub のアカウントをお持ちでない場合は、実際の操作の最後に必要になるので、今のうちに docker hub をアカウントを取得しておいてください。取得済みの人はログインできるように ID とパスワードを思い出しておいてください。


【操作内容】
では実際にアプリケーションファイルと Dockerfile からマルチCPUアーキテクチャー対応 docker イメージを作って docker hub に push してみます。なお今回は linux/amd64(インテルCPU向け 64 ビット Linux)と linux/arm/v7(ラズベリーパイ)の2種類のアーキテクチャー向けにイメージを作る例を紹介しますが、同様の操作で linux/ppc64le(POWER アーキテクチャー向け 64 ビット Linux)や linux/s390x(zLinux)を対象としたマルチCPUアーキテクチャー対応イメージを作ることも可能です。


(追記 2021/02/15)
その後イメージをアップデートし、現在は linux/arm/64, linux/ppc64le, linux/s390x を含めた5アーキテクチャ対応イメージを公開しています
(追記終わり)


まず最初に、今回行うマルチCPUアーキテクチャー対応イメージのビルドは、docker の試験的機能の1つであり、これを行うには試験機能を有効にしておく必要があります。そのためターミナルや WSL2 のコンソールを開き、~/.bashrc に以下の行を追加するなどして、環境変数 DOCKER_CLI_EXPERIMENTAL の値を enalbed に設定しておいてください:
export DOCKER_CLI_EXPERIMENTAL=enabled

設定後、ターミナルを一度閉じてから再度開きます(これで上記環境変数の設定が有効な状態でターミナルが開きます)。

確認のため、以下のヘルプコマンド("docker --help")を実行します。結果が下図のように buildx* といった * が付いた試験機能を含めたコマンドリストのヘルプが表示されれば試験機能が有効になっています:
$ docker --help

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/home/dotnsf/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and
                           default context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/home/dotnsf/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/home/dotnsf/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/home/dotnsf/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Management Commands:
  app*        Docker Application (Docker Inc., v0.8.0)
  builder     Manage builds
  buildx*     Build with BuildKit (Docker Inc., v0.4.2-tp-docker)
  config      Manage Docker configs
  container   Manage containers
:
:

ではここからは実際にマルチCPUアーキテクチャー対応 docker イメージを作るための操作を行います。まず最初に "docker buildx ls" を実行して現在のビルダーインスタンスの一覧を確認します:
$ docker buildx ls

NAME/NODE    DRIVER/ENDPOINT             STATUS  PLATFORMS
default *    docker
  default    default                     running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

default という名前の標準ビルダーインスタンスが見つかります(横の * は現在選択されているビルダーインスタンスを示します)。このビルダーインスタンスは linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 のビルドに対応している、ということがわかります。

※なお CentOS7 版の docker や、ラズベリーパイ版の docker でこのコマンドを実行すると buildx コマンドそのものは利用できるのですが、ビルドの対応プラットフォームがあまりに少なく、クロスビルド環境としては不十分であることがわかります。なので今回は Windows(WSL) 版の docker コマンドを使って作業します。

ということはこの default ビルダーインスタンスを使うことで linux/amd64 と linux/arm/v7 向けイメージをビルドできそうに見えるのですが、実際にやってみるとこのエラーになってしまいます。理由や原因はよくわからないのですが、新しいビルダーインスタンスを作成して使うことで回避できそうなので、今回はその方法を紹介します。


といった事情もあり、まずはクロスビルド用のビルダーインスタンスを作成します。以下のコマンドを実行してビルダーインスタンスを(下の例では mybuilder という名前で)新たに作成&選択&起動します:
$ docker buildx create --name mybuilder

$ docker buildx use mybuilder $ docker buildx inspect --bootstrap

この時点でのビルダーインスタンス一覧は以下のようになります。mybuilder が作成されて選択(* 印)され、起動(STATUS が running) の状態になっているはずです:
$ docker buildx ls

NAME/NODE    DRIVER/ENDPOINT             STATUS  PLATFORMS
mybuilder *  docker-container
  mybuilder0 unix:///var/run/docker.sock running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
default      docker
  default    default                     running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

ここまでの設定で新たに作成した mybuilder ビルダーインスタンスを使って docker イメージを(クロス)ビルドする準備が整いました。では早速クロスビルドしようと思うのですが、その前に少し注意が必要です。

ただ単に linux/amd64 と linux/arm/v7 向けにクロスビルドを実行しようとすると、アプリケーションソースと Dockerfile の存在するディレクトリで以下のコマンドを実行することになります(エラーになるので実行しなくていいです):
$ docker buildx build --platform linux/amd64,linux/arm/v7 -t dotnsf/hostname --load .

クロスビルドの対象プラットフォームを --platform オプションに続けて指定します(上の例では linux/amd64,linux/arm/v7)。また -t オプションに続けてイメージの名称(上の例では dotnsf/hostname)を指定するのですが、一般的には (docker hub のログイン名)/(アプリケーション名) という形で指定します。僕の場合はそれが dotnsf/hostname となるわけですが、ここは皆さんの環境に合わせて変更してください(僕の hostname アプリを使う場合は dotnsf の部分だけを皆さんの docker hub ログイン名に変えてください)。

コマンドとしてはこれで指定したプラットフォーム用の docker イメージがビルドされる・・・はずなのですが、docker は自分のビルド環境(今回の場合は linux/amd64)と異なるプラットフォーム( linux/arm/v7)のイメージを出力できないという制約があります。そのためこのコマンドをそのまま実行してもエラーとなってしまうのでした。

この制約を回避するため、docker のクロスビルド結果をローカル docker ではなく、直接 docker hub に向けて出力することにします。普段はこういう使い方はあまりしないと思うのですが、マルチ CPU アーキテクチャー対応 docker イメージを作る場合の例外方法だと認識する必要がありそうです。

そのためビルドを実行する前に docker hub へログインします。"docker login" コマンドを実行し、自分の docker hub アカウントのユーザー名とパスワードを指定してログインします:
$ docker login

Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: dotnsf
Password: ********
Login Succeeded

ログイン成功後に改めてクロスビルドを行います。今度は上述のコマンドの最後のオプションとして指定した --load の代わりに --push オプションを指定します(これでビルド結果を直接 docker hub に送信します):
$ docker buildx build --platform linux/amd64,linux/arm/v7 -t dotnsf/hostname --push .

このコマンドの実行にはかなりの時間がかかります。通信環境やビルド内容にもよりますが、自分の場合は hostname アプリを2つのプラットフォーム向けにビルドして docker hub へ送信し終わるまで約10分かかりました。

このコマンドが成功すると docker hub にビルドしたイメージが保存されているはずです。自分が上のコマンドを実行した結果はこちらから確認できます:
https://hub.docker.com/r/dotnsf/hostname

20210213

↑Tags タブを参照すると、このイメージが linux/amd64 及び linux/arm/v7 の両プラットフォームに対応していることが確認できます。

これで目的のマルチ CPU アーキテクチャー対応 docker イメージをビルドして docker hub に push することができました。今後、この mybuilder ビルダーインスタンスをそのまま使い続ける場合はそのままでもいいのですが、元の default ビルダーインスタンスに戻して使い続ける場合は以下のコマンドを実行しておいてください:
$ docker buildx stop mybuilder  (mybuilder 停止)

$ docker buildx use default  (default を選択)

$ docker buildx rm mybuilder  (mybuilder を削除する場合はこれも)


【動作確認】
では実際に上で作成したイメージで動作確認してみます。linux/amd64 か linux/arm/v7 の docker 環境(可能であれば両方)がある方も以下のコマンドで動かすことができるので是非お試しください。上述のビルダーインスタンス作成などは不要です。

まずは linux/amd64 の docker 環境で以下のコマンドを実行します:
$ docker run -d --name hostname -p 8080:8080 dotnsf/hostname

初めて実行した場合は dotnsf/hostname イメージのダウンロードから始まるので起動まで少し時間がかかるかもしれませんが、ダウンロード完了後(2度目以降の実行であればすぐに)コンテナが作成されて実行され、8080 番ポートで HTTP リクエストを待ち受ける状態になります。

起動後、以下のコマンドでコンテナ ID を確認しておきます(以下の例では c4335ca15762):
$ docker ps

CONTAINER ID   IMAGE             COMMAND                  CREATED          STATUS          PORTS                    NAMES
c4335ca15762   dotnsf/hostname   "docker-entrypoint.s…"   32 seconds ago   Up 29 seconds   0.0.0.0:8080->8080/tcp   hostname

curl コマンドでこのアプリケーションにアクセスしてみます。このコンテナの /etc/hostname の値が出力されます:
$ curl http://localhost:8080/

c4335ca15762

先程確認したコンテナ ID と同じ値が表示されるはずです。というわけで、この linux/amd64 プラットフォームでは dotnsf/hostname イメージが期待通りに動きました。


続けて、全く同じコマンドを linux/arm/v7(ラズベリーパイ)環境の docker でも実行してみます。まずは dotnsf/hostname イメージを指定してコンテナを作成&起動します:
$ docker run -d --name hostname -p 8080:8080 dotnsf/hostname

起動後、以下のコマンドでコンテナ ID を確認しておきます(以下の例では 6a0b27c4ad76):
$ docker ps

CONTAINER ID   IMAGE             COMMAND                  CREATED          STATUS          PORTS                    NAMES
6a0b27c4ad76   dotnsf/hostname   "docker-entrypoint.s…"   29 seconds ago   Up 27 seconds   0.0.0.0:8080->8080/tcp   hostname

curl コマンドでこのアプリケーションにアクセスしてみます。このコンテナの /etc/hostname の値が出力されます:
$ curl http://localhost:8080/

6a0b27c4ad76

先程確認したコンテナ ID と同じ値が表示されるはずです。というわけで、この linux/arm/v7 プラットフォームでも dotnsf/hostname イメージが期待通りに動きました。

したがって、全く同じ docker イメージ(dotnsf/hostname)を指定して、linux/amd64 でも linux/arm/v7 でも同様に動くコンテナを起動することができました。マルチ CPU アーキテクチャー対応 docker イメージが正しく作れていることが確認できました。

なお作成したコンテナの起動を止める場合は以下のコマンドを実行してください(両環境共通):
$ docker stop (コンテナID)

起動を止めたコンテナを削除する場合は続けて以下のコマンドも実行してください(両環境共通):
$ docker rm (コンテナID)


【感想】
このマルチ CPU アーキテクチャー対応 docker イメージはまだ試験機能ということもあり、準備にも色々面倒な手順が必要です。ただ異なるアーキテクチャでも同じコマンドでアプリケーションを起動できることができるのが docker の強みでもあると思っています。今回は未確認ですが、今後 M1 mac 環境でも docker が正式対応したりすると、マルチ CPU アーキテクチャー対応 docker イメージの需要も増えてゆくものと想像しています。そうなった場合に備えて今のうちに勉強できました。


【参考】
https://docs.docker.jp/docker-for-mac/multi-arch.html


とある目的で「CPU 負荷とメモリ利用状態を Node.js から取得する」プログラムを作ったので、github で公開してみました:
https://github.com/dotnsf/cpumem

2019020101



Git clone かダウンロードでソースコードをコピー&展開し、
$ node cpumem

で実行します。デフォルト設定だと5秒ごとに以下のようなフォーマットで結果をコンソールに出力します(赤字はコメント):
{
  "cpus": [
    {
      "user": 5.438012814200345, 1つ目のCPUコアのユーザープロセスによる利用率
      "nice": 0.6939879964053115,  1つ目のCPUコアの実行優先度を変更したユーザープロセスによる利用率
      "sys": 0.6002479372975158,  1つ目のCPUコアのシステムプロセスによる利用率
      "idle": 93.26775125209683,  1つ目のCPUコアのアイドル状態になっている割合
      "irq": 0
    },
      :
 (CPU コア数ぶん繰り返し)
      :
  ],
  "totalmem": 8284266496, 総メモリ量
  "freemem": 345624576, 空きメモリ量
  "uptime": 24193171, システム稼働時間(秒)
  "loadavg": [
    0.36669921875, 直近1分間の平均CPUおよびIO利用率
    0.4462890625, 直近5分間の平均CPUおよびIO利用率
    0.50439453125 直近15分間の平均CPUおよびIO利用率
  ],
  "timestamp": 1548947954556 記録したタイミングのタイムスタンプ値
}


2019020100


公開しているこのプログラムでは取得結果を単純にコンソール出力しているだけですが、実際にはこの結果を MQTT などでどこかに飛ばして記録したり、データベースに格納したりすることを想定しています。

中身はすごくシンプルで、単純に os パッケージを require し、os パッケージで提供されている機能をほぼそのまま使って CPU 利用率やメモリ使用量を求め、それを出力しているだけです。CPU 利用率のみ、いわゆる「パーセント」値で出力されるよう計算していますが、その程度です。


なお、デフォルトの取得間隔である5秒を変更する場合は、settings.js 内の exports.intervalms の値を変更してから実行してください(値はミリ秒で指定)。






このページのトップヘ