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

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

タグ:docker

タイトルどおりの内容のエラーが発生したので、その原因と解決策を探った記録をブログにまとめました。

環境としては以下の図のようなものです。1台の Windows 10 PC の中に Docker Desktop を導入・起動し、MySQL サーバーのイメージからコンテナを作って 3306 番ポートで公開起動しました。この環境に WSL(2) の MySQL CLI を使って、localhost:3306 の MySQL サーバーにログインする、というだけの内容なのですが、ログイン時にコネクションエラーが発生してしまう、という症状が出ていました:
20210612


具体的に紹介します。今回使った MySQL のコンテナイメージはこちらです。厳密には mariadb を使っています。同様の現象が発生すると思うので、他の MySQL 系イメージでも構いません:
https://hub.docker.com/r/linuxserver/mariadb


Docker Desktop を使ってこのイメージからコンテナを作成します。WSL を起動するなどして docker コマンドが使える状態で以下のコマンドを実行します(目的は Docker Desktop 内のコンテナとして起動することなので、このコマンド自体は WSL から実行しなくても構いません):
$ docker run -d --name=mariadb -e PUID=1000 -e PGID=1000 -e MYSQL_ROOT_PASSWORD=root -e TZ=Asia/Tokyo -e MYSQL_DATABASE=mydb -e MYSQL_USER=user -e MYSQL_PASSWORD=P@ssw0rd -p 3306:3306 --restart unless-stopped linuxserver/mariadb

こんな感じで、Docker Desktop 内のコンテナとして MySQL が起動します:
2021061301


指定したオプションはコンテナイメージのドキュメントを参考に指定しています。上の例では root のパスワードは root 、利用ユーザーは user 、利用ユーザーのパスワードは P@ssw0rd 、利用データベース名を mydb、コンテナ名は mariadb、などを指定しています(適当に変更いただいても構いません)。ポート番号に -p 3306:3306 を指定しているので、ローカルホストの 3306 番ポートからも(公開されているので)アクセスできるはずです。事前準備はここまで。

ではこの方法で Docker Desktop 内に起動した MySQL(mariadb) に、WSL から MySQL CLI で接続してみます。上述のオプションであれば以下のコマンドで接続できるはずです:
$ mysql -u user -pP@ssw0rd -h localhost mydb

しかし実際には以下のようなエラーが表示されてしまいます:
$ mysql -u user -pP@ssw0rd -h localhost mydb
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")

ユーザー名やパスワード、データベース名は間違っておらず、接続先も localhost だから間違えようがないはずです。ポート番号もデフォルトの 3306 のままなので特別なオプションも不要のはず・・・ ではなぜエラーになってしまうのでしょうか?


改めてエラーメッセージをよく見ると "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'" と表示されています。ちなみにこのファイルは存在していません(/var/run/mysqld というディレクトリが存在していません):
$ ls -la /var/run/sqld/mysqld.sock
ls: cannot access '/var/run/sqld/mysqld.sock': No such file or directory

このエラーメッセージでわかる人もいると思うのですが、MySQL コマンドは localhost が対象の場合はデフォルトで「ソケット接続」という方法で接続を試みます。そしてこのソケット接続をする場合の情報を /var/run/sqld/mysqld.sock というファイルで管理しているため、このファイルを読み込もうとしているのでした。

しかし、今回の環境では WSL 内には MySQL サーバーは起動していません。WSL 内からの docker コマンドで起動してはいますが、実体は Windows にインストールされた Docker Desktop のコンテナとして起動しています。要は「WSL と同じマシン上で動いてはいて、ポートも公開されているけど、WSL から直接ソケット接続できる状態で動いていない」のです。これがエラーの原因で、エラーメッセージの理由でもあります。

では、エラーなしに WSL から MySQL に接続するにはどのようなコマンドにすればいいでしょうか? 答はシンプルで「ソケット接続ではなく、TCP 接続するようなオプションを指定」することで解決できます。具体的には以下のように --protocol=TCP オプションを付けて実行します:
$ mysql -u user -pP@ssw0rd --protocol=TCP -h localhost mydb
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 11
Server version: 10.4.18-MariaDB-1:10.4.18+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [mydb]>

今度は無事に接続できました。「localhost の罠」にかかった時の話でした。


docker を使って複数の WordPress 環境を立ち上げる手順をスクリプト化してみました。

普通に1つの WordPress 環境を作るだけであれば(特に docker-compose を使えば、yaml ファイルを1つ用意するだけで)簡単に作れます。詳しくはここでは紹介しませんが、"docker WordPress" などでググると多くの紹介ページが見つかります。

ただ今回自分が作りたかった環境はこれらとは少し異なり、1つのホスト内に複数の独立した WordPress 環境を作る、というものでした。具体的には MySQL サーバーは1つだけ用意した上で、ポート番号で分離して1つ目の環境は localhost:8081 で、2つ目の環境は localhost:8082 で、・・・といった具合に、それも簡単に後から WordPress 環境を追加/削除できるよう考慮してスクリプト化して公開しました:
https://github.com/dotnsf/docker-wordpress

2021030700


※ここで方法で作成した WordPress 環境を実際にインターネットに公開する場合は DNS と連動したポートフォワーディングができる環境があれば、全ての WordPress 環境に 80 番ポート(http)や 443 番ポート(https)でアクセスできるようになると思っています。が、そちらについては環境依存になるので本ブログでは触れません。


利用方法については README.md で紹介していますが、一応ここでも説明します:

まず前提条件として docker が導入された環境が必要です(docker-compose は使わないので導入する必要はありません)。また用意したシェルスクリプトは Linux などの bash などで動かすことを想定しています。ただ docker コマンドが使える環境下であれば、(例えば Windows であれば、シェルスクリプトファイルの拡張子を .sh から .bat などに変更するだけで)使えるはずです。 なお、以下の内容については Windows10 の WSL2(Ubuntu 18.04) 環境で動作を確認しています。


docker 導入済みのシステムで docker を起動後、最初に MySQL イメージと WordPress イメージをダウンロードしておきます。実際には後述のシェルスクリプト実行時にダウンロードされていないと判断されれば docker が自動で最新イメージをダウンロードした上で実行してくれるので、この手順は必須ではありません。ただ最初に1回実行しておくことで後述のスクリプトが軽快に動くようになるので特に理由がなければこのタイミングでダウンロードしておくことを推奨します:
$ docker pull mysql

$ docker pull wordpress

次に今回の作業用に用意したシェルスクリプトをダウンロードして、実行可能な状態に設定します:
$ git clone https://github.com/dotnsf/docker-wordpress

$ cd docker-wordpress

(UNIX 環境の場合)
$ chmod 755 *.sh

(Windows 環境の場合 以下、拡張子を .sh から .bat に変更して実行)
> ren *.sh *.bat

まず docker 環境でデータベースである MySQL サーバーを起動します(以下のコマンドで 3306 番ポートで MySQL サーバーが起動します):
$ ./docker_run_mysql.sh

なお、この MySQL コンテナに接続してコンテナの中身を確認する場合は、以下のコマンドでターミナルにアタッチ可能です(exit で元のホストに戻ります):
$ docker exec -it mysql /bin/bash

そして docker 環境内に WordPress サーバーを起動します。この際に「何番目の WordPress 環境か」を意味するインデックス番号をパラメータとして指定します(以下の例では 1 を指定しています):
$ ./docker_run_wordpress.sh 1

このコマンドが成功すると、8081 番ポートで wordpress1 という名前の docker コンテナが起動します。ウェブブラウザで http://localhost:8081/ にアクセスすると、WordPress の初期設定画面に遷移して、サイト名やログイン設定などを指定して利用を開始できます:

2021030701


2021030702


2021030703


2021030704


2021030705


2021030706


とりあえず1つ目の WordPress 環境はこれだけで作れました。次の環境を作ることもできますが、この1つ目の WordPress 環境に関する操作を一通り説明しておきます。

この WordPress コンテナに接続してコンテナの中身を確認する場合は、以下のコマンドでターミナルにアタッチ可能です(exit で元のホストに戻ります):
$ docker exec -it wordpress1 /bin/bash

コンテナを停止する場合は以下のコマンドを実行します:
$ docker stop wordpress1

停止したコンテナを再起動する場合は以下のコマンドを実行します:
$ docker start wordpress1

停止したコンテナを削除する場合は以下のコマンドを実行します(コンテナを削除し、MySQL データベースも drop してデータごと削除します):
$ ./docker_rm_wordpress.sh 1


では1つ目の WordPress 環境を起動したまま、2つ目の WordPress を追加で起動してみます。以下のコマンドを実行します:
$ ./docker_run_wordpress.sh 2

このコマンドが成功すると、8082 番ポートで wordpress2 という名前の新しい docker コンテナが起動します。ウェブブラウザで http://localhost:8082/ にアクセスすると、新しい WordPress の初期設定画面に遷移し、同様にサイト名やログイン設定などを指定して利用を開始できます(それぞれが独立した環境なので起動済みの WordPress1 側には変化や影響はありません):

2021030707


2021030708


2021030709


wordpress2 のコンテナについても wordpress1 環境同様に docker コマンドで操作可能です。

後は必要なだけこの操作を繰り返すことで、WordPress 環境をコマンド1回ずつ追加していくことができます。ポート番号が利用中でなければ、おそらく好きなだけ起動できるはず(ポート番号が 8081 から始まるルールを変更したい場合は docker_run_wordpress.sh スクリプト内で適当な値に変更してください)。


そこそこのスペックを持った docker 導入済みのサーバーが1台インターネット上にあれば、DNS やポートフォワーディングなどと組み合わせることで複数の WordPress 環境を好きなタイミングで好きなだけ簡単に構築することができるようになると思っています。docker 環境なのでコンテナごと消してしまえば元のホスト環境を汚すこともなく元に戻せます(開発環境だと大事!)。

なお Github 上に公開したシェルスクリプトはそのまま利用することができますが、特にインターネットに公開する WordPress の場合、セキュリティの観点からパスワード類は変更してから利用することを推奨します。その場合は以下の部分を(すべて同じ文字列に)変更してください:
(docker_run_mysql.sh ファイル内)
- docker コマンド実行時の環境変数 MYSQL_ROOT_PASSWORD の値

(docker_run_wordpress.sh ファイル内)
- docker コマンド実行時の環境変数 WORDPRESS_DB_PASSWORD の値

(docker_rm_wordpress.sh ファイル内)
- docker コマンド実行時のパラメータ -p に続いて指定されている文字列

ある意味、先日のこの記事の続きです:
「チームでアプリケーション開発を体験したい」、どうやる?


1つの案として(候補案4の)「オンラインエディタを使う」方法を紹介しました。ここで紹介したオープンソースのオンラインエディタ Eclipse Orion を Linux サーバーに、特に docker 環境下で簡単に導入する方法を紹介します。なお、ここでの「 docker 環境下」は正確には「x86_64 チップの docker 環境下」とさせてください(後述する docker イメージが linux/amd64 アーキテクチャ向けのため)。


まずは docker 環境を用意します。既に手元にあれば飛ばしていただいて構いませんが、こちらを参考いただくなどして環境にあった方法で docker エンジンが起動している状態にしておいてください:
Docker のインストール

今回紹介する方法ではこちらの Eclipse Orion 用 docker イメージを使わせていただきます:
https://hub.docker.com/r/cloudeity/orion


早速 docker pull して、・・・の前に、Eclipse Orion が参照する対象となるフォルダを自分の手元に用意しておきます。フォルダが空の状態から始めるのであれば空のフォルダを用意すればいいのですが、サンプルファイルが含まれた状態で始めるのであれば、対象ファイルがコピーされた状態のフォルダを用意しておく必要があります。

今回は以下のような index.html ファイル1つだけが用意されたフォルダを /tmp/web/ 以下に準備することにします(別のフォルダでも構いませんが、以下の内容を読み替えてください)。まず /tmp/web というフォルダを作ります(後でこのフォルダを Eclipse Orion の作業フォルダとします):
$ mkdir -p /tmp/web


そして以下の内容の index.html を作って、/tmp/web/ フォルダにコピーしておきます(/tmp/web/index.html ファイルを作ります):
<html>
Hello World.
</html>

改めて docker を使って Eclipse Orion をインストールします。まずは docker pull でイメージをダウンロードしておきます(初回のみ):
$ docker pull cloudeity/orion

次にコンテナ化して起動するのですが、その際に -v オプションで作業フォルダをボリューム指定します。今回のように /tmp/web を作業フォルダとする場合は以下のコマンドを実行します:
$ docker run -d --name orion -v /tmp/web:/opt/orion.client/modules/orionode/.workspace -p 8081:8081 cloudeity/orion

コマンドの実行に成功したらウェブブラウザで 8081 番ポートにアクセスします。成功していると /tmp/web フォルダがプロジェクトフォルダとなって、ウェブブラウザ画面から既存の index.html ファイルを編集したり、新規にフォルダやファイルを作成したり、編集したりができるようになります:

(同じマシンから http://localhost:8081 にアクセスした時の画面。他マシンからアクセスする場合は localhost 部分を IP アドレス指定にします)
2021022301

(index.html ファイルを選択するとエディタが開き、直接編集できます)
2021022302


Eclipse Orion 自体を終了するには docker コンテナを止めます:
$ docker stop orion




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


【背景】
おそらく最もメジャーなコンテナ技術の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


このケースというか、この利用パターンでの情報がググっても意外と見つからなかったので、自分でメモを残します。

なお、以下の内容は x86_64 アーキテクチャの docker 環境が導入済みであるという前提で説明します。


【やりたかったこと】
やりたかったことは、
- クラウドなどでデータベース・サーバー(今回は PostgreSQL)を利用して、
- そのデータベース・サーバーを GUI 管理するためのクライアント(今回は pgadmin4)をローカルの docker コンテナとして起動する

というものです。環境自体は docker なしでももちろん可能ですが、自分の開発環境に余計なものを入れたくなかったので、docker コンテナで ON/OFF できる形で用意できれば理想かな、と思い、docker を使って構築しようと考えました。

この場合、前者(PostgreSQL)は既に起動している前提となるので、後者(pgadmin4)をどうやって docker 内に用意すればよいか、が課題となります。

クラウドのデータベース利用時ではそれほど珍しくない利用パターンだと思っているのですが、ググってみると(docker-compose 等を使って)ローカル docker コンテナに PostgreSQL と pgadmin4 の両方を起動して利用するケースでの手順が多く見つかり、pgadmin4 だけを単独でローカル docker に起動して利用する手順が意外と見つかりませんでした。 というわけで、以下は自分で調べた内容の備忘録メモです。


【調べたこと】
pgadmin は dpage/pgadmin4 イメージを使わせていただくことにします。ページ概要だけを見るとコンテナ起動時にどんなパラメータをどのように指定すればよいかわかりにくかったのですが、結論としてはこんな感じでパラメータを指定すればよさそうでした:
パラメータ指定方法パラメータの意味
PGADMIN_DEFAULT_EMAIL 環境変数 pgadmin ログイン時のユーザー名
PGADMIN_DEFAULT_PASSWORD 環境変数 pgadmin ログイン時のパスワード
ポートフォワード docker run 時の -p パラメータ 80 番(http)への内部ポートをどのポート番号からフォーワードするか


【動かしてみる】
ターミナルやコマンドプロンプトを起動し、上述の内容を docker コマンドで指定して dpage/pgadmin イメージをコンテナ化します:
$ docker pull dpage/pgadmin

$ docker run --name pgadmin4 -e "PGADMIN_DEFAULT_EMAIL=dotnsf@xxxx.com" -e "PGADMIN_DEFAULT_PASSWORD=P@ssw0rd" -d -p 8000:80 dpage/pgadmin4

上の例では PGADMIN_DEFAULT_EMAIL に dotnsf@xxxx.com を、PGADMIN_DEFAULT_PASSWORD に P@ssw0rd を指定し、ポートフォワードのポート番号は 8000 番に指定して、pgadmin4 という名前でコンテナを起動しています。必要に応じて上述部分を変更して使ってください。


今回は 8000 番ポートで起動しているので、ウェブブラウザで 8000 番ポートを指定して http://localhost:8000/ にアクセスします:
2021021001


pgadmin(4) が起動していれば上記のような画面になります。ここで docker コンテナ起動時に環境変数で指定したログインユーザー名とパスワードを指定し、必要であれば言語を "Japanese" に指定してログインします:
2021021002


無事に pgAdmin にログインできました。実際にクラウドで起動中のデータベース・サーバーに接続するにはトップページから「新しいサーバを追加」を選択します:
2021021003


起動中の PostgreSQL データベース・サーバーに接続するためのホスト名やポート番号等の情報を入力して保存します:
2021021004


正しい情報が入力できているとデータベース・サーバーに接続でき、統計情報やスキーマ、実際のデータを pgadmin 画面から参照できるようになります:
2021021005


使わない時はコンテナを止めてしまえばポートも開放されるし、コンテナを削除しなければ接続情報なども保存されるので、気軽に ON/OFF できる pgadmin 環境が構築できました。


このページのトップヘ