2021年10月31日

docker再びの再び (5)

docker のネットワークについて勉強中。
前回はドライバの bridge で、今回は host だ。

Networking using the host network | Docker Documentation
https://docs.docker.com/network/network-tutorial-host/


ホストとコンテナの分離を削除する、という表現で混乱したのだが、ホストからコンテナのネットワークにアクセスできるということだと思っている。
アクセスだけなら ping でもできていたのだが、ここではもっとアプリ層に近いところだ。

チュートリアルでは nginx (えんじんえっくす、と読むのを知ったのはずいぶん最近のことだ)のコンテナを立ち上げて、ホスト側のブラウザで 80番ポート(デフォルトの http)にアクセスしている。

この手順では、ポート番号が出てきていないのだが、コンテナの外からホスト環境で nginx が立ち上がっているかのようにアクセスできるのだ。私の場合、Windows10 から VirtualBox で Lubuntu をゲストOS として起動し、ゲストOS 上で docker を立ち上げているのだが、Windows10 側から Lubuntu の IPアドレスをブラウザで指定してもアクセスできる。
実体はコンテナ側で動いているので、ポート番号だけ間借りしているというか転送しているというか、そんな感じなのか。


さて、 デフォルトの bridge を使うと他のコンテナやホストの間で通信ができ、ユーザ定義の bridge を使うと特定のコンテナの間で通信ができた。 1つのコンテナが デフォルトとユーザ定義の bridge の両方に接続?することができるので、そうするとどっちにもアクセスできた。

じゃあ、host とか使わずにデフォルトの bridge を使ってもいいんじゃ無いかと思ったのだが、これだと ss -nat | grep :80 などとしても 80番ポートが見当たらない。
docker ps で見ると PORTS に 80/tcp と出てくるので、80番ポートが使われているのは間違いないだろう。
しかし、 host を使った場合に docker ps で見ても PORTS には何も出てこない。

 

これだけだと bridge の意味がよくわからんのだが。。。
と思ったら、ブラウザでコンテナの IPアドレスにアクセスすると ss コマンドで現れた。 Listen していないのにアクセスできる・・・?
いや 80番ポートで Listenしているわけではないというだけかもしれない。
ss -l | grep docker とすると6つくらい出てきたので、今はそういうことにしておこう。


私の今のイメージでは、bridge と host はこんな感じだ。
丸いのがコンテナね。

image

  • bridge に名前を付けて作成すると、それと接続しているコンテナ間で LANを形成できる。
  • コンテナは複数の bridge に接続できる
  • host を指定するとホスト環境のネットワークとして見える

bridge と host も同時にできるかと思ったが、それはエラーになった。

bridge接続済みのコンテナを host につなごうとしたとき
container cannot be disconnected from host network or connected to host network

host接続済みのコンテナを bridge につなごうとしたとき
container sharing network namespace with another container or host cannot be connected to any other network

ホストのネットワークなら bridge のコンテナ内からでもアクセスできるので必要ないのだろう。

Connect a container to a user-defined bridge
https://docs.docker.com/network/bridge/#connect-a-container-to-a-user-defined-bridge

--publish を使うことで特定のポートをホスト側に見せることができる。だから host を使わなくてもよいというか、なるべく bridge を使って公開するポートを限定した方が不安が少ないと思う。


他にもいろいろあるだろうが、テスト環境を作るのであればこのくらいの知識でなんとかなるんじゃなかろうか。

2021年10月30日

docker再びの再び (4)

4回もやっていると何でこんなタイトルだったのか忘れてしまいそうになるが、今回で dockerを勉強するのが3回目になるからだった。


今回はネットワークについて。

Docker コンテナ・ネットワークの理解 — Docker-docs-ja 19.03 ドキュメント
http://docs.docker.jp/engine/userguide/networking/dockernetworks.html

日本語だ。
多少情報が古いかもしれないが、基本的なことは変わってないんじゃなかろうか。まあ、後で調べよう。

 

ifconfig で見えるのは docker0 だけだが、docker コマンドでは書いてあるように 3つ見える。

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
cc02564a80e1   bridge    bridge    local
4dee0c98d161   host      host      local
51c798d9077c   none      null      local

うーん、少し読んだけどさっぱりわからんよ。
もっと概要から説明してほしいのだが。

Networking overview | Docker Documentation
https://docs.docker.com/network/

Dockerのnetworkingサブシステムは、driver を使って追加/削除できる(プラグイン方式)らしい。
デフォルトで存在したりコアネットワークとして提供されているドライバはこれら。

  • bridge
  • host
  • overlay
  • macvlan
  • none

さっきの network ls で出てきたものでも DRIVER として表示されているな。

 

bridge

これがデフォルトのネットワークdriver。
固有名詞じゃなさそうだから「ドライバ」でよいのかな。
どういう意味でデフォルトかというと、普通はこれが使われる、というデフォルトのようだ。そりゃそうだろうと言われそうだが「デフォルトで付属している(けどあまり使われない)」みたいなこともあるので気にしたのだ。

名前からすると、docker コンテナ内のネットワークとリアル環境のネットワークを橋渡ししてくれるのだろうか。
なんというか、そうだったら bridge 以外はいらないような気がするのだが、他は何をするんだろう?

 

host

   うーん?

For standalone containers, remove network isolation between the container and the Docker host, and use the host’s networking directly.
スタンドアロンコンテナの場合、コンテナとDockerホスト間のネットワーク分離を削除し、ホストのネットワークを直接使用します。

通常はコンテナとホストが分離されているけど、それを削除するということは、分離しなくなるということか?

 

overlay

複数の docker daemonをそれぞれ接続し、 swarm service?がそれぞれ通信できるようにする もの らしい。
うん、よくわからん。

1台の PCでは、docker daemonは 1つ動いているということになるんだろうか。
bridge と host では「standalone containers」と書いてあったのだが、それぞれのコンテナで docker daemonが 1つ動いているという扱いにするのなら、これがコンテナ間を直接つないでくれるのかもしれん。
swarm というのは知らん。後回し。

 

macvlan

MacOS 専用のドライバかと思ったが、MACアドレスの方を表しているようだ。
MACアドレスをコンテナに割り当てることができるらしい。ということはマシン外とアクセスするときに使えるということだろうか。それに MACアドレスということなら物理層とか下の方の階層になるはずなので他のドライバと併用できるとかだろうか。

まあ、用途として特殊になりそうだから後回しでいいかな。

 

none

host が外部と接続しないようにするドライバだったが、 none はネットワーク接続をしないというドライバらしい。
ネットワークドライバなのにネットワークに接続しないとは、なんか面白いものだ。

カスタムネットワークドライバと一緒に使うのが普通らしい。
よくわからんが、後回しで良い気がする。ただ、初期設定で動作しているのでよく使うものなのかも。

 

 

説明の中で「standalone containers」という言葉がしばしば出てくる。
スタンドアローンなのにコンテナは複数形なのだ。だから、スタンドアローンのコンテナが複数あって、それを bridge とかで接続するとか、それぞれが host とかで自分の中だけで運用するとか、そういう話なんじゃなかろうか。

あと、「swarm service」という言葉も出てくる。

【swarm】
群れ、群衆。群がる。

swarm mode というページがある。

Current versions of Docker include swarm mode for natively managing a cluster of Docker Engines called a swarm.
Dockerの現在のバージョンには、スウォームと呼ばれるDockerエンジンのクラスターをネイティブに管理するためのスウォームモードが含まれています。

クーベネイティス、だったか、複数のコンテナを使ったシステムをうまいこと立ち上げるのがあったと思うが、それで使うのだろうか? わからんことは後回しだ。


Networking with standalone containers | Docker Documentation
https://docs.docker.com/network/network-tutorial-standalone/

bridge ドライバがデフォルトだとあるが、ここでは「デフォルト bridge ネットワーク」と「ユーザ定義 bridge ネットワーク」の2つが書かれている。ドライバとは書いていないので別の話なのか。
デフォルトの bridge ネットワークは製品版には推奨しないそうだ。

このチュートリアルではどちらも見せてくれるそうなので、やってみるのが良かろう。

 

まず、デフォルトの方。
特に何か特別なことをするわけでもなく、コンテナを2つ立ち上げると IPアドレスがそれぞれホストとは異なるプライベートアドレスが割り当てられた(ホストは 192.168.0.0 だが、コンテナは 172.17.0.0 だった)。
そのコンテナの中からグローバルなIPアドレスにアクセスできるし、相手のコンテナにもアクセスできる。

そういえばホストにもアクセスできるのかは確認していなかった。
docker stop でコンテナを終わらせた状態なのだが「再開」はできるのだろうか? チュートリアルと同じ docker run のコマンドを打ち込んでも名前が既にあるとエラーになった。
コンテナを削除すれば良いそうだが、単に再開させるだけなら docker start でよいようだ。

で、コンテナの中からホストに向けて ping しても成功したし、ホストからコンテナに向けて ping しても成功した。
私の記憶では、ネットワークのことをやるのにポート番号をどうのこうの設定していた気がするのだが... まあ ping だからポート番号は関係ないというだけで、後から出てくるのか。
わからん。

 

次はユーザ定義の方。
docker network create で bridge をベースにして(?)新たなドライバを作っているのか。
この方式だと、ping 先としてコンテナ名を使うことができる(bridge の場合は IPアドレスだけだった)。

デフォルトがなんで製品に向かないかというと、コンテナを立ち上げてしまうだけでネットワークにアクセスできてしまうからだと思う。他にも理由はあるとは思うが、システムごとに network create して作るのが無難だろう。


長くなったので、Hostのチュートリアルは次回にしよう。

2021年10月21日

docker再びの再び (3)

前回、Dockerfile を使って簡単な、本当に簡単なイメージを作るところまでやった。
RUN で実行した内容までイメージに含まれるから、準備はそこでやっておけというところだろう。

つまり、Dockerfile をもらった場合は、それで docker build してイメージを作って、docker run してやればよいということか。
しかし、Dockerfile だけでイメージを作ることができれば良いのだけど、GitHub に上がってるやつなんかは他のファイルもいるだろうから、コードとか気にせず使いたいだけだったらイメージそのものがほしいところだ。

そこで Docker Hubの出番か。


docker run するときも、ローカルにイメージがなければ docker pull でダウンロードしてくると書いてあった。
なので、私も動かしたいものを Docker Hub から探してきて、docker pull して docker run すれば動かせると思う。

 

困ったことに、これを動かしたい、というものが思いつかない。。。
仕方ないので、これにした。

https://hub.docker.com/r/btcpayserver/lightning/tags

$ docker pull btcpayserver/lightning:v0.10.1-2
v0.10.1-2: Pulling from btcpayserver/lightning
a330b6cecb98: Pull complete
d18683af84c4: Pull complete
d089f3521651: Pull complete
00b9a3bf1da8: Pull complete
c6394cf1c296: Pull complete
241733e1daf6: Pull complete
de9614f35f2b: Pull complete
735eb65d54fb: Pull complete
8047f9f53e51: Pull complete
c9ed1993582a: Pull complete
Digest: sha256:929386072091408c8574fdda9c5e059cf2846fdef82b194f810ddb2281e09ac9
Status: Downloaded newer image for btcpayserver/lightning:v0.10.1-2
docker.io/btcpayserver/lightning:v0.10.1-2

$ docker run btcpayserver/lightning:v0.10.1-2
Invalid combinaion of LIGHTNINGD_NETWORK and LIGHTNINGD_CHAIN. LIGHTNINGD_CHAIN should be btc or ltc. LIGHTNINGD_NETWORK should be mainnet, testnet or regtest.
ltc regtest is not supported

イメージは取ってくることができたが、単に docker run するだけではダメだった。
環境変数かな?

Docker run reference | Docker Documentation
https://docs.docker.com/engine/reference/run/#env-environment-variables

docker run の後に -e "xxx=yyy" の形か、export された環境変数なら -e xxx で指定できるようだ。

$ docker run -e "LIGHTNINGD_NETWORK=regtest" -e "LIGHTNINGD_CHAIN=btc" btcpayserver/lightning:v0.10.1-2
network=regtest added in /root/.lightning/config
rpc-file=/root/.lightning/lightning-rpc added to /root/.lightning/config
Installing bundled plugins
C-Lightning starting, listening on port 9735
2021-10-20T10:31:52.693Z UNUSUAL lightningd: Creating configuration directory /root/.lightning/regtest
2021-10-20T10:31:52.693Z UNUSUAL lightningd: Creating configuration directory /root/.lightning/regtest
2021-10-20T10:31:52.920Z INFO    database: Creating database
2021-10-20T10:31:53.000Z UNUSUAL hsmd: HSM: created new hsm_secret file

ちゃんとした動作環境を用意していないからここで止まってしまうが、 -e で指定すれば動くことは分かった。
ついでに bitcoind も動かせることを確認しよう。

https://hub.docker.com/r/btcpayserver/bitcoin/tags

$ docker pull btcpayserver/bitcoin:22.0-1-amd64
22.0-1-amd64: Pulling from btcpayserver/bitcoin
07aded7c29c6: Pull complete
d17b51f7cfe8: Pull complete
6d6d52f12809: Pull complete
e47859bdfcf2: Pull complete
a57e01ab8b33: Pull complete
Digest: sha256:aacdcf9419dc88d80fd130fc7d51dda46b1be323967798c113ff77b6b6eea74c
Status: Downloaded newer image for btcpayserver/bitcoin:22.0-1-amd64
docker.io/btcpayserver/bitcoin:22.0-1-amd64

$ docker run btcpayserver/bitcoin:22.0-1-amd64
2021-10-20T10:40:41Z Ignoring unknown configuration value mainnet
2021-10-20T10:40:41Z Bitcoin Core version v22.0.0 (release build)
2021-10-20T10:40:41Z Assuming ancestors of block 00000000000000000008a89e854d57e5667df88f1cdef6fde2fbca1de5b639ad have valid signatures.
(略)

立ち上がる。
立ち上がるのだが、設定ファイルを書き換えて動かしたい。しかしイメージは既にできあがった状態だ。
たしか、ボリュームをマウントする方法があったはずだ。


docker runのオプションにある。

VOLUME (shared filesystems)
https://docs.docker.com/engine/reference/run/#volume-shared-filesystems

-v=ローカルのディレクトリ:コンテナ側のディレクトリ、という形だ。
指定すると、確かにローカルのディレクトリにコンテナ側で作成されたファイルが入ってくることが分かった。

が、どうもこの Dockerfile というかイメージは設定ファイルも一緒に作るようで、設定ファイルを先に置いていても上書きされてしまう。

こういうのはどうしようもないな。
幸いなことに、設定ファイルを作る部分は Dockerfile の RUN ではなく CMD 側で実行されているようなので、例えば regtest用にしたいならこんな感じで変数を与えてやると良い。

$ docker run -e "BITCOIN_NETWORK=regtest" -v=`pwd`/bitcoin:/home/bitcoin/.bitcoin btcpayserver/bitcoin:22.0-1-amd64

"entrypoint.sh" のような名前のファイルは、コンテナ起動時の設定をするためによく使われると Dockerの本にも書いてあったような気がする。今思えば、会社にあったオライリーの Docker本はなかなかよさそうだったのでもっと読んでおけば良かった。

ともかく、docker pull して楽ができるとしても、カスタマイズをしたいならオリジナルが何をしているのかを知っていないといかん。
とは思ったものの、今回は Docker Hubのリポジトリとほぼ同じ名前で GitHub のリポジトリがあったからたどり着けたのだが、普通はどうするのだろうか? IMAGE LAYERのところを見ても詳細はわからんし。


あとは、ポート番号だ。
単に docker run だけした場合、どうもコンテナで起動したアプリのポート番号はホスト側には出てこないようなのだ。

EXPOSE (incoming ports)
https://docs.docker.com/engine/reference/run/#expose-incoming-ports

こういう「incomming」って、誰に向けての説明か悩むよね。コンテナを起動するコマンドが主体なのか、コマンドを実行するのはホストだからホストが主体なのか。

オプションは -p ホスト:コンテナ らしい。「Publish a container's port or a range of ports to the host」なので、コンテナのポートをホストに公開するオプションになるようだ。

$ docker run -e "BITCOIN_NETWORK=regtest" -v=`pwd`/bitcoin:/home/bitcoin/.bitcoin -p 18444:18444 -p 18443:18443 btcpayserver/bitcoin:22.0-1-amd64

こうするとホスト側で ss -nat などでポート番号の使用状況を確認すると 18443, 18444 が出てくるようになる。

ちなみに、実行中のコンテナにログインしてコマンドを実行したいと思うなら docker exec を使うとよいだろう。

$ docker ps
$ docker exec -it d33e6ab4e04f /bin/bash

"d33...04f"は実行中のコンテナIDで、doker ps などで確認できる。

 

ネットワーク関係は次回だな。

2021年10月20日

docker再びの再び (2)

さて、docker本体のことをやっていこう。

あれからちょっと本を読んで勉強したのだが、私は「まずDockerfileから!」と思っていたのだが、コマンドラインからでもできるけどいちいち面倒だからDockerfileにする、という感じなのだな。
まあ、そういう意味ではDockerfileから始めるのも間違いではないのか。

今回はこういうバージョンで進めます。

$ docker --version
Docker version 20.10.7, build 20.10.7-0ubuntu1~20.04.2


基本に忠実にいこう。
というよりも、本家のドキュメントが一番わかりやすい気がする。

Docker overview | Docker Documentation
https://docs.docker.com/get-started/overview/

Docker objectsのところに動かし方の例が載っていた。 "docker run" でいろいろやってくれるそうだ

$ docker rm `docker ps -qa`
$ docker rmi `docker images -qa`
$ docker run -i -t ubuntu /bin/bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
7b1a6ab2e44d: Pull complete
Digest: sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322
Status: Downloaded newer image for ubuntu:latest
root@972d70ba7c5b:/#

最初の2コマンドは、残っていたコンテナやイメージを全部消したかっただけだ。
3つめのコマンドがサイトに書いてあった例である。
Dockerfile がなくても使えるのだが、引数が多くなると面倒だから Dockerfileにしよう、というところだろう。

コンテナはメインプロセス?が終了すると実行が終わると言うことだった(本に書いてあった)。
ここでは /bin/bash がそれに当たる。シェルだからユーザが何もしないと生き続ける。 exit などで終了するとコンテナも終了する。

root@972d70ba7c5b:/# exit
exit
$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND       CREATED          STATUS                      PORTS     NAMES
972d70ba7c5b   ubuntu    "/bin/bash"   14 minutes ago   Exited (0) 27 seconds ago             kind_austin

docker ps は結果が長くなって折り返して見づらいのだが、STATUS が Exited になっていることがわかる。

 

docker runのオプション

-i ... Keep STDIN open even if not attached
-t ... Allocate a pseudo-TTY

シェルを動かしているから、ターミナルを動かさないといかんし、入力させるから STDIN を開いたままにしないといかんし、ということかな。


イメージを自分で作るのはいずれやるとして、コマンドラインの使い方を覚えるのが面倒そうだから Dockerfile の書き方を先に調べよう。

Best practices for writing Dockerfiles | Docker Documentation
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Dockerfile はイメージを自動的にビルドするためのテキストファイルと書いてあるので、実行を簡単にするものではない?
でも「contains all commands」と書いてあるので、なんとかなるのか?

$ cat Dockerfile
FROM ubuntu:20.04
CMD /bin/bash

こんな Dockerfileを作った。
CMD と RUN の違いがよくわからんが、RUN が事前準備で CMD が実行するメインプロセスだと思う。

$ docker build -t test:v1 .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM ubuntu:20.04
20.04: Pulling from library/ubuntu
7b1a6ab2e44d: Pull complete
Digest: sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322
Status: Downloaded newer image for ubuntu:20.04
  ---> ba6acccedd29
Step 2/2 : CMD /bin/bash
  ---> Running in 4500cd01b011
Removing intermediate container 4500cd01b011
  ---> b3180f0f44d8
Successfully built b3180f0f44d8
Successfully tagged test:v1

これで終わりだ。
CMD で書いたものが実行されたりはしていない・・・? いや Step 2/2 でやろうとしているな。

サンプル通りにやってみよう。

$ cat Dockerfile
FROM ubuntu:20.04
COPY /hello.txt /
RUN cat /hello.txt

$ cat hello.txt
Hello, World!

hello.txt はあらかじめカレントディレクトリに作ってある。

$ docker build -t test:v1 .
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM ubuntu:20.04
  ---> ba6acccedd29
Step 2/3 : COPY /hello.txt /
  ---> cbc39019824a
Step 3/3 : RUN cat /hello.txt
  ---> Running in 178ad7dff873
Hello, World!
Removing intermediate container 178ad7dff873
  ---> b66dc3af8f2a
Successfully built b66dc3af8f2a
Successfully tagged test:v1

おお、実行されているではないか!
シェルはちょっと特殊だと思うから、なんかオプションがあったような気もする。

docker run したのと違い、これで実行すると docker images で test というリポジトリが見えた。

$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
test         v1        b66dc3af8f2a   14 minutes ago   72.8MB
< none>       <none>    9cdcb8314e60   16 minutes ago   72.8MB
< none>       <none>    b3180f0f44d8   20 minutes ago   72.8MB
ubuntu       20.04     ba6acccedd29   4 days ago       72.8MB

イメージを自動的に作るという、あれだろう。
サイズが全部同じなのは、これらは ubuntu という layer の上に全部載っかってるからということでよいのかな?
わからん。

 

まず、簡単に分かることからやろう。
さっきは RUN で cat したが、 CMD でもいいんじゃなかろうか。

$ docker build -t test:v1 .
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM ubuntu:20.04
20.04: Pulling from library/ubuntu
7b1a6ab2e44d: Pull complete
Digest: sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322
Status: Downloaded newer image for ubuntu:20.04
  ---> ba6acccedd29
Step 2/3 : COPY /hello.txt /
  ---> 4522c706bb17
Step 3/3 : CMD cat /hello.txt
  ---> Running in e50e77c5baa6
Removing intermediate container e50e77c5baa6
  ---> e71d4d3c2fe5
Successfully built e71d4d3c2fe5
Successfully tagged test:v1

うーん、Running と出力されているので、動いていないことは無いのだと思う。
こちら側の標準出力に出力させる理由がなかったとかだろうか。

RUN
https://docs.docker.com/engine/reference/builder/#run
RUN命令は、現在のイメージの上にある新しいレイヤーでコマンドを実行し、結果をコミットします。

CMD
https://docs.docker.com/engine/reference/builder/#cmd
CMDの主な目的は、実行中のコンテナーにデフォルトを提供することです。

CMDのデフォルトは、上で書いたメインプロセスと同じ意味だろう。
RUNの「結果をコミットします」は、イメージを作るときに実行結果もイメージに含めますよ、ということだろう。

$ docker run test:v1
Hello, World!

ほら、動いた。

2021年10月3日

docker再びの再び (1) - 無料プランの話

2016年、2019年とdockerのことを勉強しては忘れる日々。

hiro99ma blog: docker ? (1)
https://hiro99ma.blogspot.com/2016/08/docker-1.html

hiro99ma blog: docker ? (2)
https://hiro99ma.blogspot.com/2016/08/docker-2.html

hiro99ma blog: Docker再び (1)
https://hiro99ma.blogspot.com/2019/05/docker-1.html

hiro99ma blog: Docker再び (2)
https://hiro99ma.blogspot.com/2020/03/docker-2.html

今も忘れた状態を維持している。
コマンドであれば、メモを残しておいてまねすれば良いのだが、dockerみたいなのはそうもいかないと思う。

いや、dockerもそういうレベルで落とし込まないと忘れるに決まっている。忘れないという前提で勉強するのに意味が無いことは、今までの記事でも分かる。

今シリーズは、なるべくそういう記事になるようがんばろう。


記事の前提だが、Linuxのみとする。
うちだとWindows10がホストで Virtual Boxに Ubuntuをインストールしていることが多い。今週には Windows11 がリリースされるようだが、うちのPCたちはどれも推奨環境を満たせなかった。ThinkPad T460sは期待したのだが、まさかCPUが引っかかるとは。。。
そういうのはともかく、Windows上での dockerではなく、Ubuntu上での dockerとする。

あとは、ハードウェアを操作するようなのはあまり考えないことにする。
VirtualBox でハードウェアとなると USBデバイスを動かしたいこともあるのだが、そういうのは無しだ。


こちらがGet Startedページ。

Get Started with Docker | Docker
https://www.docker.com/get-started

Windowsで見ているので、Docker Desptop(for Windows)と Docker Hubが見えている。
Ubuntuで動かすときにはコマンドしか使ったことがないのだが、そうなると Linux Engineというのがそれになるのか?

image

Linux Engineのページに行くと、Fedora, CentOS, AWS, Azure, Ubuntu, Debianが一覧に出てきた。

Explore Docker's Container Image Repository | Docker Hub
https://hub.docker.com/search?offering=community&operating_system=linux&q=&type=edition

ちなみに Desktop は、Windows と Macが 1つずつだ。

Dockerの利用が企業規模によっては有料になったという記事を見たのだが、2021年8月31日のブログに書いてあるのは Docker Desktopについてだけのように見える。

Docker is Updating and Extending Our Product Subscriptions - Docker Blog
https://www.docker.com/blog/updating-product-subscriptions/

「No changes to Docker Engine」とも書いてあるので、Linux Engineを使うだけなら気にしなくてよいかもしれない。

 

ただ、Docker Hubというものについても今年アナウンスが出ていた記憶がある。
実のところ、Docker Hubのこともよく知らないのだが、Dockerのコンテナ?イメージ?を公開して置いておいたり、自分の開発しているものを置いておいたりできるようなものじゃなかったか。

ふだん、よく「dockerからコンテナを取ってきて」みたいな感じで、どこからか動かすものを取得しているのだけれども、あれは Docker Hubに公開してくれている誰かのリポジトリを使わせてもらっているのだと思っている。

とりあえず、1つアカウントを作ってみた。もちろん無料版だ。

image

このアンダーラインを引いたのが、Docker Hubに自分のリポジトリを持つことができる上限なのだろう。
「public」については unlimited としか書いていないが、設定を見るとこうなっていたので「private」は1つまでしか持てないのだろう。

image

お仕事で使うとなると、なんでもかんでも public にするわけにはいかんので、有料プランを選択するという選択もあるのだろう。


Dockerが、いや Docker社がここまで一般的に使用できる環境を提供し続けているというのは、非常に驚くべきことだと思っている。

デファクトスタンダードというか、dockerを利用しても環境縛りに思われないくらいの立ち位置にいるというのはすごい。
環境を作るということに特化しているのに「コンパイルはgccでやります」みたいなノリで「環境はdockerでつくります」になっているので、そのことに恐怖すら覚えるところだ。だいたい数年するといくつも同じようなサービスが立ち上がるものだけど、Dockerがこの立ち位置を維持できているのは不思議な気がする。

2021年9月4日

[js]JSONっぽいデータをJavaScriptで読みたい

JSONのデータはこんな感じだ。

{
  "name": "Yoshio",
  "age": 92
}

 

JSONっぽいデータと書いたが、今回はこういうデータのことである。

{
  name: "Yoshio",
  age: 92
}

「key: value」と呼ぶとしたら、keyの部分にダブルクォーテーションがないタイプのデータである。
JavaScriptのコード中に書くようなデータと言えばよいか。

 

何でか知らんが、サーバがこういうデータを返してくるようなのだ。
それをJavaScriptで読んで処理をしたい。


一応取り込めたのだが、この方法はあまりよろしくないとさんざん書かれている。

const VALUE = "{name: 'Yoshio', age: 92}";
const result = eval(`(${VALUE})`);
console.log(JSON.stringify(result));

$ node ev.js
{"name":"Yoshio","age":92}

 

よろしくない理由は eval() を使うと危険なためである。

置き換えの例としてFunctionを使うよう書かれていた。

const VALUE = "{name: 'Yoshio', age: 92}";
const result = Function(`return ${VALUE}`)();
console.log(JSON.stringify(result));

$ node ev.js
{"name":"Yoshio","age":92}

 

このシンプルなデータだとFunctionで置き換えられたのだが、複雑になるとそうもいかないようなのだが、どうしたらよいかわからん。。。

2021年7月4日

[js]import * は普通

前回、namespace にして export default して import させていた。
namespace は無しにして import * でも同じことはできるのだが、わざわざ namespace にしてみたのだ。

その理由は「ワイルドカードよりも特定の namespace を使った方がよいのではないか」という気持ちがあったからだ。ほら、不特定なものよりも特定した方が好まれるじゃないか。

しかし。。。

TypeScript: Documentation - Namespaces and Modules
https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html

太字で

we recommended modules over namespaces in modern code.

最新のコードでは、名前空間よりもモジュールを推奨しました。
(Google翻訳)

と書いてある。
「最新のコードでは」だから将来変わるのかもしれんが、2021/07/04 19:23 ではそうなっていた。

 

なので、ワイルドカードで指定しているとかそういうのはあんまあり考えなくて良いんだろうね。変に気を回して時間を掛けてしまったよ。

[js]ファイルを分けたい

大きいプログラムを作ると、ファイルを分けたくなるだろう。そうじゃなくても、機能ごとにファイルを分けたいだろうし。
まあ、私が分けたいのだ。


index.ts

01: import * as greet from './greet';
02: 
03: const hello: greet.Greet = greet.hello();
04: if (hello != null) {
05:     console.log(`hello: ${JSON.stringify(hello)}`);
06: }

greet/index.ts

01: export type Greet = {
02:     greet: string;
03:     time?: string;
04: };
05: 
06: export function hello(): Greet {
07:     return {greet: 'hello', time: 'allday'};
08: }
09: 
10: export default {}
  • greet ディレクトリにファイルがあるので、 import の from はそこを指定する。
    • ファイル名が index.ts なのでディレクトリの指定だけで済んでいる。
  • greet/index.ts は export default {} としたので、ファイルの中にある export 指定したものは同じ名前で export される。

という理解で正しいだろうか?

 

import の from より前の部分があまりわかってない。
こうか?

  • 個別に import するなら、 import {個別にコンマ区切り} from '~~'
  • 全部 import するなら、 import 名前 from '~~'

 

greet/index.ts から個別に importすると、こうなる。

01: import {Greet,hello} from './greet';
02: 
03: const msg: Greet = hello();
04: if (msg!= null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

列挙するのが面倒ではあるが、使用しているものがはっきりするので場合によってはわかりやすい。


じゃあ全部 import するので import Hello from './greet' でよいかというと、これはダメそうだ。
Hello.Greet や Hello.hello という指定ができなかったのだ。
「Cannot find namespace 'Hello'」というエラーになる。

namespace を使う場合はこういう書き方になるようだ。
import するときに「import Hello from './greet'」としたが、別に namespace名と同じにする必要はなさそうだった。

あと、namespace も export を指定しないと個別に import できない(個別の話。export default指定しているなら関係ない)。namespace を export しても、namespace の中身が全部 export されたことになるわけではなく、その中でも export を付けたものだけが外部から見えるようだ。

index.ts

01: import Hello from './greet';
02: 
03: const msg: Hello.Greet = Hello.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

greet/index.ts

01: namespace Hello {
02:     export type Greet = {
03:         greet: string;
04:         time?: string;
05:     };
06: 
07:     export function hello(): Greet {
08:         return {greet: 'hello', time: 'allday'};
09:     }
10: }
11: export default Hello;

 

この greet/index.ts を import * した場合は namespace 名を使わなくても済むようだ。

index.ts

01: import * as Pochi from './greet';
02: 
03: const msg: Pochi.default.Greet = Pochi.default.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

 

 

namespace を付けるなら、 export default ではなく個別にした方がよいのかな?と思ったが、そうすると import側でも個別にしないといけなかった。
1ファイルで複数の namespace を入れ込むことは(私の実装だと)やらないので、これは default のままの方が使い勝手がよいか。

index.ts

01: import {Hello} from './greet';
02: 
03: const msg: Hello.Greet = Hello.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

greet/index.ts

01: namespace Hello {
02:     export type Greet = {
03:         greet: string;
04:         time?: string;
05:     };
06: 
07:     export function hello(): Greet {
08:         return {greet: 'hello', time: 'allday'};
09:     }
10: }
11: export {Hello};

 


import の後ろは、 * as xx だったり name だったり {name} だったりといろいろあるが、いったいなんなんだ。

ECMAScript 2015 Language Specification – ECMA-262 6th Edition
https://262.ecma-international.org/6.0/#sec-imports

たくさんあるので from を使うパターンだけ見ていこう。
以下、イタリック&下線の部分はさらに展開されるという意味である。

import ImportClause FromClause;

FromClause の方は種類がないので、先にそちらを。

from StringLiteral

順番に展開すると ModuleSpecifier → StringLiteral なのだが、まあよかろう。
つまり文字列だ。

ImportClause は5種類に分かれる。

  • ImportedDefaultBinding
  • * as BindingIdentifier
  • { ImportsList }
  • ImportedDefaultBinding , * as BindingIdentifier
  • ImportedDefaultBinding , { ImportsList }

たぶん BindingIdentifier は「勝手に割り当てて良い名称」だと思う。bind だから紐付ける名称になるのかな。

上3つが import でよく見る形式で、残り2つはその組み合わせだ。
使えるものを展開してるのはこちら。

import - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/import

まあ、こっちの方がわかりやすいな。日本語だし。


これで基本的なところはできたんじゃなかろうか。

もう1つやりたいのが、export するファイルとそうじゃないファイルを分ける作業だ。
実装を見られて困るとかではなく、C言語で言うところのヘッダファイルとソースファイルに分けたいというだけである。

できるのだろうか?
なお、tsconfig.js は isolatedModules:true を指定しているものとする。

 

re-export というのでやってみた。

 

greet/index.d.ts

01: export type Greet = {
02:     greet: string;
03:     time?: string;
04: };

greet/hello.ts

01: import {Greet} from './index.d';
02: 
03: export function hello(): Greet {
04:     return {greet: 'hello', time: 'allday'};
05: }

 

greet/index.ts

01: export {hello} from './hello';
02: export type {Greet} from './index.d';

 

index.ts

01: import {hello,Greet} from './greet';
02: 
03: const msg: Greet = hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

うーん、無理やりやりましたという感じが拭えない。
それに呼び出し元の index.ts の方に修正が入るのはダメだ。

 

これは書き方としてダメだった。namespace 内ではダメだそうだ。

01: export namespace Hello {
02:     export {hello} from './hello';
03:     export type {Greet} from './index.d';
04: };
05: export default Hello;

 

これならいけるようだ。

01: import {hello as myHello} from './hello';
02: import {Greet as myGreet} from './index.d';
03: 
04: export namespace Hello {
05:     export const hello = myHello;
06:     export type Greet = myGreet;
07: };
08: export default Hello;

うーん・・・。もっとよいやり方がありそうな気がする。

 

というわけで、あきらめて本を買うことにした。

O'Reilly Japan - プログラミングTypeScript
https://www.oreilly.co.jp/books/9784873119045/

本の中身は書かないのだが、私が import あたりをうまく理解できない理由が分かってきた気がする。

「JavaScript」とか「TypeScript」とかで検索しながらやっていたけど、import というかモジュールの扱いについて過去の経緯がいろいろあり、ネットで見つけた情報はどの時点の JavaScript について書いているかによって変わってくるからだと思う。そういうのを知らずにネットで調べていたので、あっちの情報とこっちの情報をまぜこぜにしてうまくいかなかったとか、そんな感じになったんじゃなかろうか。

本の内容で勉強することの利点は、よくも悪くも情報が混ざらないことだと思うので、あやふやな知識でふらふら調べるよりはましなんじゃなかろうか。せっかくお金出したんだから、ましであってほしい。

2021年7月3日

[js]nullチェックとtruthy

JavaScript で null チェックする際、私はこう書くことが多い。

let val;

...

if (val) {
  // not null
  ...
} else {
  // null
  ...
}

C言語だと 0 以外の値なら真なのでアドレス値が入っているかどうかを判定するし、 Java だとそういう書き方は興られたような気がする。

で、JavaScript の場合はどういう仕様なのか?

 

Truthy - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Truthy

falsy として定義された値以外は truthy 扱いで、 truthy は boolean 判定するところに出てきたら true として扱うという仕様だった。

falsy はこれら。

  • false
  • 0
  • -0
  • 0n
  • ''(空文字列)
  • null
  • undefined
  • NaN

オブジェクトの場合は null か undefined かそれ以外になるはずなので、 if (オブジェクトの変数) だけで事足りるはずだ。


あとは、その書き方が一般的なのかどうか、だ。
私は if (変数) や if (!変数) の書き方で見慣れているのだが、一般的にそうでないなら使いどころは絞った方がよいと思うのだ。

nullとundefined - TypeScript Deep Dive 日本語版
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined

うーん「== null」って書いてあるな。

確かに、 != null だと null か undefined だけだが、変数名だけだと幅が広すぎるのか。
x && x.length > 0 とか x && x !== 0 だったら変数名だけでよいかもしれないが、やっぱりちゃんと書いた方が無難だろう。

 

というわけで、 null / undefined のチェックにはきちんと == null のように条件を書くことにしよう。


ついでに読んでいてわからなかったのがこちら。

ルートレベル(root level)のundefinedのチェック
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined#rtoreberuroot-levelnoundefinednochekku

null だろうと undefined だろうと、 x.y を参照するのに x が どこも指していないのだったらダメだろう。

undefined かどうかをチェックするには確かに typeof するしかないのだが、 null は別によいってことなんだろうか。

うーん、わからん。。。

 

ごにょごにょ考えたが、あれは x.y != null みたいなチェックをいきなりするのではなく、先に x をチェックしろということを言いたいだけなんだろうか。
それならわかるけど、やっぱり x != null だけでよいと思うのだ。

Checking for root level undefined
https://basarat.gitbook.io/typescript/recap/null-undefined#checking-for-root-level-undefined

原文も同じ。

まあいいや。
ルートレベルより下のプロパティやメソッドにアクセスする前にはルートレベルのチェックをするか try-catch を考慮するようにしておけば良かろう。

TypeScriptとnull/undefinedチェック

JavaScript のことを書いているサイトであればほぼ書かれていると思われる null/undefined チェック問題。問題というよりは FAQ なんだろうけど、私は何度やっても覚えられない。


まず、 null と undefined の型だが、これはオブジェクトではなくプリミティブ型とのこと。昔ちょっと JavaScript を書いたときは 'undefined' と文字列になっていたような気がするが、そう書いてある()からそうなんだろう。

にもかかわらず、 typeof null は "object" だ。 typeof undefined は "undefined" である。
nullは「プリミティブ値」と表現されていたし、undefined も同様だ。

Primitive (プリミティブ) - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Primitive

undefinedはプリミティブデータ型なので typeof で "undefined" になるが、 null は「プリミティブに見える」と微妙な表現をされている特殊なオブジェクトだそうな。あらゆるオブジェクトは nullから派生するらしい。

 

等値演算子(==, !=)を使う場合、null と undefined は同類と見なされる。

01: let val = null;
02: 
03: if (val) {
04:   console.log('defined');
05: } else {
06:   console.log('undefined');
07: }

これはどっちを通ったかというと、"undefined" の方を通った。 1行目が undefined でも同じだ。

null と undefined を区別したいなら同値演算子(===, !==)を使う。

A user name of null?
https://developer.mozilla.org/ja/docs/Learn/Getting_started_with_the_web/JavaScript_basics#a_user_name_of_null

この例は (!myName || myName === null) となっているのだが、 !myName だけでよいのでは?
もし && だったら myName === null だけでよいだろうし。

 

  • undefined はプリミティブデータ型でありプリミティブ値である
  • null はプリミティブ値のようでありオブジェクトのようであり、特殊な扱い
  • undefined と null を同じ扱いにして良いなら等値演算子(==, !=)で扱える
    • x == null とか x == undefined とか
    • !x でもよい
  • undefined かどうかを調べたいなら typeof === 'undefined' にする
    • null の typeof は 'object' になる

 

ちなみに、変数に undefined を与えて console.log したのが上、 'undefined' を与えて console.log したのが下。

image

null だとどっちで与えても白い文字で出力された。 うーん。

console.log なのか JavaScript 全体なのか分からないけど、人間寄りになるように動いてしまうのが苦手意識を持ってしまう原因かもしれん(私がね)。


TypeScript は型定義があるため、もうちょっと複雑になりそうだ。

nullとundefined - TypeScript Deep Dive 日本語版
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined

等値演算子で null チェックすればよいよ、ということだ。

といっても、ここは TypeScript の仕様説明ではないので、もうちょっと確認しよう。

 

まず、 null が型の方として扱われるようだ。

let val: number = null;

これはコンパイルエラーだ。どうしても代入したければ、私は null も OKですよ、ということにするしかないのか。

let val: number | null = null;

ちなみに、これもダメだ。

let val: number = null as number;

 

null は型扱いなので、変数を null型で指定できるようだ。

let val: null = null;
val = 'hello';

こんなのは代入する行でコンパイルエラーになる。 undefined もそうだった。

let val: undefined;
val = null;

使い道はないけどね。

 

だから、 null や undefined を代入したいのなら型のところで | null のような形にすることになる。
なるのだが、 undefined はデフォルト値になるので、ちょっと特殊な扱いかもしれない。その代わり、代入しないまま使おうとしたら、 | undefined になっていない限りはエラーになる。型と異なる変数が入っている、という扱いかもしれないが、TS2454 コンパイルエラーは before being assigned なので別エラーにはなっている。


C言語をよく使う人からすると、使い終わった変数に null を代入したいという気持ちに駆られることがある。

開いたファイルを扱うオブジェクトの変数があって、その変数が null だったら先にオープンしてから処理を続ける、みたいな。それをやろうとすると、最初は undefined だからよいとして、一度オープンして、クローズしたら null にしたくなる。しかし null を代入させるなら | null で許容させる必要がある。

私の期分の問題かもしれないが、 | null というか、型を複数割り当てるというのがどうも苦手だ。 string | number とかされたら「どっちが入ってんだよ!」ってなるからやらないけど、似たような気持ちになってしまう。

なら指定しなければ良いのだが、そうじゃなかったら boolean の変数を用意して判断するみたいなことになるだろう。でも、そこまでするのはなんか大げさな気がしてしまう。

なので、あまり選びたくない2択のどちらかをせねばならぬ。
あるいは、そういう設計の仕方自体が JavaScript らしくないということかもしれない。

 

そういう、言語仕様ではなく、センスというかお作法というかがよくわかっていないというのが最大の悩みであった。