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

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

2021/02

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


【背景】
おそらく最もメジャーなコンテナ技術の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 環境が構築できました。


MySQL 派な自分にとって、初体験中の PostgreSQL の話です。CLI から利用する場合の(MySQL との)コマンドの違いに戸惑いましたが、まあ慣れてしまえばさほどは気になりません。

ただ1つ困ったことがありました。前提として自分はプログラミングで Node.js を使っていて、Node.js から PostgreSQL にアクセスするには node-postgres(pg) というライブラリパッケージを使っています。

今、ある配列(数値または文字列)があったとして、「その配列内のいずれかの値と一致する ID を持つレコードをすべて取り出す」という処理を実行したいとします。PostgreSQL 含めて一般的なリレーショナル・データベースであれば、"in" 句を使って以下のように処理できます:
> select * from mytable where id in ( '000', '001', '002' );

node-postgres を使った場合、この処理は以下のように記述することで同様に実行することができます:
var PG = require( 'pg' );
var pg = new PG.Client({ 
    "postgres://user:pass@host:5432/db"
});
pg.connect( function( err, client ){
  if( err ){
    console.log( 'err00', err );
  }else{
    client.query( { text: "select * from mytable where id in ( '000', '001', '002' )", values: [] }, function( err, result ){
      if( err ){
        console.log( 'error', err );
      }else{
        console.log( 'success', result );
      }
    });
  }
});


困ったことというのは、上述の配列部分を変数にした場合です。例えば以下のようにすると文法エラーにはなりませんが、(期待通りに展開されないのか)該当データが存在していても結果は空でした:
var PG = require( 'pg' );
var pg = new PG.Client({ 
    "postgres://user:pass@host:5432/db"
});
pg.connect( function( err, client ){
  if( err ){
    console.log( 'err00', err );
  }else{
    var ids = [ '000', '001', '002' ];
    client.query( { text: "select * from mytable where id in ( $1 )", values: [ ids ] }, function( err, result ){
      if( err ){
        console.log( 'error', err );
      }else{
        console.log( 'success', result );
      }
    });
  }
});

文法的にはこっちの書き方のほうが正しいかな、と思って以下の SQL に変えてみると、今度は文法エラーになってしまいました:
var PG = require( 'pg' );
var pg = new PG.Client({ 
    "postgres://user:pass@host:5432/db"
});
pg.connect( function( err, client ){
  if( err ){
    console.log( 'err00', err );
  }else{
    var ids = [ '000', '001', '002' ];
    client.query( { text: "select * from mytable where id in $1", values: [ ids ] }, function( err, result ){
      if( err ){
        console.log( 'error', err );
      }else{
        console.log( 'success', result );
      }
    });
  }
});

-> syntax error at or near "$1"

いずれにせよ、配列部分を SQL 内で直接記述して具体的に指定すれば動くのですが、配列を変数化して実行する正しい方法がわかりませんでした。配列をループさせて SQL 文を直に作ればできないこともなさそうですが、そうすると SQL インジェクションにも気を付ける必要がでてくるので、配列変数のままでうまいこと実行する術はないだろうか、、、と悩んでいました。

で、やっとその解決策を見つけることができました。具体的には以下の方法です:
var PG = require( 'pg' );
var pg = new PG.Client({ 
    "postgres://user:pass@host:5432/db"
});
pg.connect( function( err, client ){
  if( err ){
    console.log( 'err00', err );
  }else{
    var ids = [ '000', '001', '002' ];
    client.query( { text: "select * from mytable where id = any($1::varchar[])", values: [ ids ] }, function( err, result ){
      if( err ){
        console.log( 'error', err );
      }else{
        console.log( 'success', result );
      }
    });
  }
});


SQL 文中の "varchar" 部分はテーブル定義した際の配列要素の型です。上の例では id は文字列(varchar)だったのでこのように varchar[] となりますが、int 型で定義していた場合は int[] などとなります。

このように記述すると PostgreSQL 側が実行時に any($1::varchar[]) 部を指定された型(varchar)のパラメータに自動変換してくれるらしく、SQL インジェクションの心配もなく実現できるようでした。


(参考)
https://stackoverflow.com/questions/10720420/node-postgres-how-to-execute-where-col-in-dynamic-value-list-query



IBM Cloud から提供されているマネージドデータベースサービスの1つである PostgreSQL を使う機会がありました(MySQL は過去に使ったことありましたが、PostgreSQL でサービスを作ったのは初めてでした)。PostgreSQL をデータベースとする Node.js のウェブアプリケーションを開発するのが目的でしたが、最初の準備がちと独特だと感じたので次回戸惑わないようにその手順をまとめておきました:
2021020300



【サービス作成までの手順】
まずは IBM Cloud 内のダッシュボードで Database for PostgreSQL という名前のサービスを探して選択します。"PostgreSQL" という名前でいくつかのサービスが見つかりますが、他を選択しないように注意してください(なおこのサービスは有償サービスのみです。無料でのサービスプランは存在していません):
2021020301


"Standard" プランを選択し、必要に応じて容量などのパラメータを調整し、最後に "Create" ボタンでサービスを作成します:
2021020302


サービス作成が完了するとダッシュボードからも参照・選択できるようになります:
2021020303


【サービス作成後の作業、および手順】
Database for PostgreSQL サービスを実際に利用する(テーブルを作ったり、データを読み書きしたりする)ためには、その前にいくつかの準備段階が必要です:
1. 証明書のダウンロード
2. admin ユーザーのパスワード変更
3. 接続情報の確認


まずは証明書をダウンロードします(プログラムコードからデータベースに接続する際に必要です)。作成したサービスインスタンスの画面を開き、画面左の "Overview" メニューを選択します:
2021020304


"Overview" 画面を下にスクロールすると、エンドポイントに関する情報を参照できる画面が現れます。ここの "Quick start" タブ内に TLS 証明書の内容が表示されている箇所があります。その下の "Download Certificate" ボタンをクリックすると、同証明書の内容をテキストファイルでダウンロードできます:
2021020305

(後述の作業のため、ダウンロードしたファイルの名前を cert.crt と変更しておきます)

次に実際にデータベースを読み書きする際のログインユーザー(admin)のパスワードを設定します。画面左の "Setup" メニューを選び、"Change Password" 欄から新しいパスワードを設定できます。ここで設定したパスワードを使って PostgreSQL にログインできるようになります:
2021020306


最後に PostgreSQL へ接続するための接続情報を確認します。"Service credentials" メニューから "New credential" ボタンをクリックして新しい接続情報を作成します:
2021020307


作成した接続情報を展開して、以下3箇所の内容を確認しておきます:
2021020308

接続情報の場所値が意味するもの
connection.postgres.hosts.hostnameホスト名
connection.postgres.hosts.portポート番号
connection.postgres.databaseデータベース名


以上、この3点の作業を行うことで外部プログラムからデータベースに接続するための準備は完了しました。


【外部アプリケーションからデータベースに接続】
以下、Node.js を例として、プログラムから同データベースに接続してクエリーを発行するサンプルを紹介します。上述の準備段階で確認した内容を使って、以下のようなコードを記述して実行します:
var fs = require( 'fs' );
var PG = require( 'pg' );  //. node-postgres https://www.npmjs.com/package/pg

//. PostgreSQL
var pg_hostname = 'hostname';    //. connection.postgres.host.hostname の値
var pg_port = 35432;             //. connection.postgres.host.port の値
var pg_database = 'ibmclouddb';  //. connection.postgres.database の値
var pg_username = 'admin';       //. ユーザー名(固定値)
var pg_password = 'password';    //. 設定したパスワード

var connectionString = "postgres://" + pg_username + ":" + pg_password + "@" + pg_hostname + ":" + pg_port + "/" + pg_database;//+ "?sslmode=verify-full";
var caCert = fs.readFileSync( './cert.crt', 'utf-8' );  //. ダウンロードした証明書ファイル
var pg = new PG.Client({ 
    connectionString: connectionString,
    ssl: { ca: caCert, rejectUnauthorized: true }
});
pg.connect( function( err, client ){
  if( err ){
    console.log( 'err00', err );
  }else{
    var sql = 'select * from mytable where id = $1';
    var query = { text: sql, values: [ "123" ] };
    client.query( query, function( err, result ){
      if( err ){
        console.log( err );
      }else{
        console.log( result );
      }
    });
  }
});

今回は node-postgres という npm パッケージを使って PostgreSQL にアクセスしています。まず接続情報から取得した値を使って接続文字列を作成します。pg_username(ユーザー名)だけは "admin" で固定になりますが、それ以外の値は上述の作業で接続情報から参照したものや、自分で設定したパスワードを指定します。

次に接続する際に TLS 証明書が必要です。この証明書も上述の作業でダウンロードした TLS 証明書ファイル(cert.crt という名前でダウンロードしたと仮定しています)をファイルパスを指定して読み込み、接続時のパラメータとして含めています。こうすることで node-postgres 経由で証明書を使った接続が可能となります。

接続後は一般的な PostgreSQL 利用と同じですが、接続結果として得られた client オブジェクトを利用して SQL が実行できるようになる、というものです。


↑の「証明書ファイルを指定して接続する」という部分が(手順としては)少し特殊ですが、より安全な接続が実現できるようになるものです。



このページのトップヘ