<none>:<none> を消すのは docker image prune とか、 docker rmi {IMAGE ID} でいいんですが、 hoge:<none> をどうしたもんかと。

見た目こんな感じです。

% docker images
REPOSITORY          TAG          IMAGE ID 
hoge                test         1c909cfb0b00
hoge                <none>       e7d92cdc71fe
alpine              latest       e7d92cdc71fe

何をどうしたらこの状況にできるのかよくわかりません。とりあえずなってました。再現方法わからない。<none>:<none> は簡単に作れるんですが……Dockerなにもわからない……。

docker rmi hoge:<none> とかやっても消えないし、docker image prune でも消えてくれないし、 docker rmi e7d92cdc71fe で消しちゃえば消えるんでしょうけど、このイメージ自体は alpine:latest とか他でも使ってるから消したくないし。別にイメージが容量を食ってるわけでもないので放置してもいいんですけど、消せるなら消したい。

とりあえず解決

同リポジトリ名でタグを作ると <none> が消えました。

% docker tag e7d92cdc71fe hoge:latest
% docker images
REPOSITORY          TAG          IMAGE ID 
hoge                test         1c909cfb0b00
hoge                latest       e7d92cdc71fe
alpine              latest       e7d92cdc71fe

この後普通にrmiでお片付けできました。

% docker rmi hoge:latest
Untagged: hoge:latest
Untagged: hoge@sha256:xxxxx

よかったよかった。やりたかったことこのログの通り、単にUntaggedなんですが、docker untagとかないしdocker tagにもなさげなんですよね…… 多分どこか掘ったらuntagするやり方見つかるんでしょうけども。

見るべきポイント

3点です。

バージョン
ソースと実行結果
プロダクトのソースコードや公式ドキュメントへのリンク

これらが記載されていない技術記事は、参照する優先順位を下げるのがいいです。

説明

増え続ける一方の技術情報ですが、あまりにあふれすぎて「何を参照すればいいかわからない」といったことに陥りがちです。これはある程度経験を積まれている方でも同様で、調べ物されているのを眺めていると「ガチャっぽい調べ方してるなぁ」と思うことがしばしばあります。「ガチャっぽい」と言うのは、当たる当たらないの話になっているので、「いつ解決するのか」が全く見当もつかないことを指しています。天井なしのガチャですね。関係ないけど最近のガチャは天井があって親切……よくすり抜けるけど……。

さてそんなわけで技術記事に溢れる昨今、私が言語化できている取捨選択法を書いておこうと思いました。例えばドメインで「このサイトは信用に値しない」とか言うのは簡単なんですが、玉石混交なので流石に厳しいと感じ始めてきました。もしこれができるならHTTPSみたく証明局つくって「この技術記事は信頼できます」とか（妄想）。

調べ方は調べ方で一大テーマなので別枠として、本記事は出てきた後の取捨選択に関わる、上記3点の説明です。「そうだよね」と思われているなら読む必要はありません。技術記事を書く時の基本といえば基本です。

バージョン

まずバージョンは自分の状態と一致するかどうかです。前提として自分がどのバージョンを使用しているか把握しておく必要があります。

バージョンが重要なのは、書いている通りやってうまくいかなかった時にバージョン違いに見当をつけられるからです。バージョン違いはリリースノートやマイグレーションガイドなどを参照すれば解決する可能性があります。「少なくともこのバージョンでは動いていた（らしい）」であれば、同様の問題に衝突している人もいるでしょう。その観点で調べ直せばきっと解決します。

また、記事のバージョンよりも自分の使用しているバージョンが古い場合。これもリリースノートなどを見てからですが、「無いんだな」と諦めることができます。無いものは仕方ない。いやバージョンあげろよって話かもしれませんが、できない事情もありますしね。無い物を探すと言う完全に無駄なコストをかけずに済むようになります。部分的にバックポートとかも選択肢に出てきますし。

ソースと実行結果

ソースは文字通りの「出どころ」くらいの意味で使っています。ソースコードに限らず、設定も含みます。そのまま実行できるコードがGitHubなどにあるとベスト。設定もas Codeできる時代ですしね。

これがあると「動いた（らしい）」から「動いた」に変えられます。「らしい」を外すのは非常に重要なのですが、ものによってはすごく手間です。実行可能状態で公開してくれてると非常に助かるんですよね……自分もそうしようとするんですけど、面倒でついサボってしまう。

「同じバージョンでやってるつもりでも動かない」は往々にしてあります。書いているものと他の何かしらの環境が違うのかもしれませんし、些細なミスかも知れません。この時に自分の手元で動くものを確保できるかで精度は段違いになります。不具合も再現できるかが重要ですよね。あれと同じです。

あと、公開してくれているソースそのままでも動かなかった時、もっと外側の環境要因を疑えるようになります。関係ないけど、この環境要因もコンテナがかなりの部分を解決してくれてますね。

プロダクトのソースコードや公式ドキュメントへのリンク

参照した記事には記者の解釈を多分に含みます。切り捨てられている情報もあることでしょう。なので出典が欲しいところです。「ソースはWikipedia」は技術問題の解決にはちょっと微妙。「最初からソースコードや公式ドキュメントを読め」と言うのは尤もなんですが、それができる方は本記事とは無縁に生きていると思うので割愛。

ソースコードや公式ドキュメントのリンクがあると、正確な一次情報を知れますし、少し応用する場合に対応できる幅が広がります。またとっつきにくい公式ドキュメントであっても「こう読めばいいのか」「この内容はここに書いてあるのか」と言うのが分かります。一次情報に当たれるようになると今後の調査精度も上がりますし、自信を持って答えられるようになります。

蛇足

昨今の富豪的な計算資源により、トライアンドエラーにかかるコストは大幅に減っています。そのため「出てきた情報をとりあえず試す」と言うのはそれほど悪くはない選択肢です。動くのは絶対的な価値です。しかしながら、もし仮にそれで動作したとして「それでいいのか」と言う問題が残ります。少なくとも調べ物をすると言うことは、その知識がない状態の人間（自分）が手を出しているものであり、そう言う人間（自分出なかったとしても組織としてそう言う人を受け入れている）が今後も触ると言うことです。もしうまく動かなくなった際、再び調べる必要が出てくるでしょう。この「将来調べるのにかかるコスト」は負債であり、もしかしたら支払うタイミングは永久にこないかもしれません。

対象によりますが、「動いた」で進んでしまっていいものもあると思っています。私にしてもガチャのような調べ方をすることもあります。さほど重要で無いものの場合もありますが、重要なものであってもなんとかできる自信のあるもの（詳細は忘れたけれど過去に調べたことがあるものなどが該当します）はそんな切り捨て方をしていますね。無限に調べる時間なんてないので。後者は「書いている通りやってみる」と言うより「自分の記憶と符合するか」のフィルタリングがかかっていますので、本記事の「簡易的な取捨選択」のテーマからは外れますね。

本記事は読む時の話ですが、当然そのまま書く時にも転用できます。あと、書く側だとこの辺を読むといい気はします。読んだはずなのに内容すっかり忘れてグダグダになってる私が勧めるのもどうなのよって思いつつ……読み直そう、うん。