dogwood008の開発メモ！

最近のマイブームは機械学習, Ruby on Rails。中でも機械学習を使った金融商品の自動取引に興味があります。

【Shell】timeを使うとコマンドの実行時間を計測できる

Shell 
$ time pwd
/tmp

real    0m0.001s
user    0m0.000s
sys     0m0.000s

このように、かかった時間が表示される。3つの行はそれぞれ、次の通りの意味を持つ。

  • real: 起動から終了までに経過した実時間 (real time) (iii) システム CPU 時間
    • times(2) が返す struct tms の tms_stime と tms_cstime の値の合計
  • user: ユーザー CPU 時間
    • times(2) が返す struct tms の tms_utime と tms_cutime の値の合計
  • sys: システム CPU 時間
    • times(2) が返す struct tms の tms_stime と tms_cstime の値の合計

https://linuxjm.osdn.jp/html/LDP_man-pages/man1/time.1.html (C) JM Projectより。

【Docker】FROMより前の段階でARGを使う

Docker

要旨

  • Dockerfile には、FROMより前の段階でARGを置くことができる
  • FROMより後の段階でそのビルド引数を使用したければ、再度宣言が必要

詳細

下記記事より。

blog.dogwood008.com

github.com

# Dockerfile

# 使用するDebianのバージョンを固定
ARG DEBIAN_CODENAME=bullseye
# 使用するRubyのバージョンを固定
ARG RUBY_VERSION=3.1.2
FROM ruby:${RUBY_VERSION?}-${DEBIAN_CODENAME?}
（中略）
ARG DEBIAN_CODENAME
ARG RUBY_VERSION

一般的に、DockerfileはFROMで始めることが多い。ただし、ARGを先に置くこともできる。

今回の用法がまさにそれで、使用するイメージのタグをビルド引数として与えるようなときに使用できる。

1点注意が必要で、 FROMより前に宣言したARGは、ビルドステージの外にあるため、FROM より後で再利用したい場合は、再度宣言しない限り使えない1。上記の例だと、ARG DEBIAN_CODENAME ARG RUBY_VERSION が該当する。

根拠

An ARG declared before a FROM is outside of a build stage, so it can’t be used in any instruction after a FROM. To use the default value of an ARG declared before the first FROM use an ARG instruction without a value inside of a build stage:

https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact

  1. 次の通り。https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact↩

【Docker Compose】docker-compose.yml はもう古い、今は compose.yaml

要旨

推奨されるのは、compose.yaml である。

ただし、後方互換のために docker-compose.ya?ml もサポートされる実装であるべき(SHOULD)と公式ドキュメントに記載がある。

なお、 compose.yml も使用できる。

詳細

まず、下記は Docker 公式による説明である。

docs.docker.com

The default path for a Compose file is compose.yaml (preferred) or compose.yml in working directory. Compose implementations SHOULD also support docker-compose.yaml and docker-compose.yml for backward compatibility. https://docs.docker.com/compose/compose-file/#compose-file

続いて、下記は上記の日本語訳である。訳は筆者による。

Composeファイルのデフォルトパスはワーキングディレクトリの compose.yaml （好ましい）、 または compose.yml である。 Composeの実装は docker-compose.yaml と docker-compose.yml も後方互換のためサポートすべき(SHOULD)である。

つまり compose.yaml を使っておけば、間違いなさそうである。

【Docker】Docker Composeの run と exec の違い

docker DockerCompose

Docker Composeの run と exec は、どちらも同じような効果が得られる。つまり、コンテナの中に入ったり、コンテナ上でプログラムを実行したりできる。

 

しかし、もう少し異なった視点で見ると、それぞれ異なる機能を持っているのがわかる。

 

docker compose runは、新たにイメージからコンテナを作って実行する。この時、--service-ports というオプションをつけておけば、予めdocker-compose.yml や compose.yml で指定したポートをバインドした状態で実行してくれる。

 

一方、docker compose execは、既に docker compose up で動いているコンテナを使ってコマンドを実行できる。

 

使い分けとしては、既に docker compose up しているこんてながあれば、exec がおすすめである。run はコンテナ作成のオーバーヘッドがあるので、やや時間がかかる。

 

runは、他のターミナルと独立して何か実行したいときに便利である。ボリュームをマウントしていない限り、他のコンテナでファイルに加えた変更が連動する事はない。

【Shell】カレントディレクトリ内のファイル数を知る

Shell

ls -1 でカレントディレクトリ内のファイルとディレクトリの一覧を、1エントリ1行で出力する。

wc -l は、標準入力に与えられたテキストの行数をカウントしてくれる。

これらを組み合わせると、カレントディレクトリにファイルがいくつあるかを知ることができる。

下記はその実行例。

$ ls -1 | wc -l
       6