Jaybanuan's Blog

どうせまた調べるハメになることをメモしていくブログ

コンテナのデバッグで入れたくなるコマンド

はじめに

コンテナイメージには日常的に開発や運用で利用するコマンドが入っていない場合が多い。 毎度パッケージ名を調べるのが大変なので、ここにまとめていく。

ネットワーク

コマンド Debian RedHat
ip iproute2 (調べる)
ping iputils-ping (調べる)
dig dnsutils (調べる)
ssh openssh-client openssh-clients

カレントディレクトリのサブディレクトリに接尾辞をつけるシェルスクリプト

諸般の理由により、そういう処理が必要になったので。 renameという今まで使ったことがないコマンドを知ったので、記録として残しておく。

#!/bin/bash

test -n "$1" || {
    echo "argument must be specified" >&2
    exit 1
}

find -maxdepth 1 -mindepth 1 -type d | xargs -I{} rename -e 's/$/-'$1'/' {}

KubernetesでのHeadless Serviceと普通のServiceの併用について

はじめに

Kubernetesの以下のドキュメントを読んだ時に湧いた疑問。

kubernetes.io

このドキュメントではMaster/Slave構成のMySQLに対して、書き込み用のHeadless Serviceと、読み込み用の普通のServiceの両方を定義している。 Headless ServiceでもDNSラウンドロビンの負荷分散はできそうなのに、あえてそれを避けているのは何故だろうと思った。

DNSラウンドロビン

以下の説明が分かりやすかった。

qiita.com

要するに、DNSラウンドロビンは、クライアント側の挙動に依存したり、障害検知のようなきめ細かい制御ができなかったりするので、避けているのだと分かった。

考察のようなもの

Podを特定したアクセス(Masterへの書き込み)と、Podを特定しないアクセス(Master/Slaveからの読み込み)の、両方がある場合はHeadless Serviceと普通のServiceを併用する。

以下でGalera clusterの例があって、Headless Serviceのみを利用しているが、Peer同士でクラスタを組むためにはHeadless Serviceが必要だが、クライアントがアクセスするためには普通のServiceが実はあったほうがいいように思えた。

qiita.com

SNAPでインストールしたkustomizeは一部機能が使えない

Kubernetesマニフェストファイル関連のツールでkustomizeというのがあるが、利用中に以下のissueで挙げられているものと同じ現象が発生した。

github.com

issueからの抜粋になるが、kustomizeの実行時に以下のエラーが発生した。

$ kustomize build . | kubectl apply -f -
Error: accumulating resources: accumulation err='accumulating resources from 'github.com/ansible/awx-operator/config/default?ref=': evalsymlink failure on '/Users/tjanitsc/github.com/ansible/awx-operator/config/default?ref=' : lstat /Users/tjanitsc/github.com: no such file or directory': git cmd = '/usr/bin/git fetch --depth=1 origin ': exit status 128
error: no objects passed to apply

GitHub上のファイル(正確にはディレクトリ)をkustomizeで直接取り扱おうとしているが、GitHubにうまくアクセスできていない。 回答に以下のように「もしsnap版使ってるなら、バイナリをダウンロードして直接それを使ってみて」とあるので、試したら問題なく動作した。

If you use kustomize with snap, try pure kustomize by downloading binary directly. Refer: https://kubectl.docs.kubernetes.io/installation/kustomize/binaries/

以下でsnap版のVisutal Studio Codeがうまく動作しない件を書いたが、snapは手軽なんだけど時々はまる。

redj.hatenablog.com

Composeファイルでのversion指定は意味なし

はじめに

Docker ComposeのComposeファイルでのversion指定は、現在では意味がないらしい。 ここで言うversionとは、以下に示すようなComposeファイルのversionのことである。

version: "3.8"
services:
  web:
    image: nginx:1.23.1

Docker Composeのドキュメントより

docs.docker.com

上掲のサイトより引用する。

The latest and recommended version of the Compose file format is defined by the Compose Specification. This format merges the 2.x and 3.x versions and is implemented by Compose 1.27.0+.

日本語訳すると以下。

Composeファイルのフォーマットの最新かつ推奨バージョンは、Compose Specificationで定義されています。 このフォーマットは2.xと3.xの両バージョンをマージしたもので、Compose 1.27.0以上で実装されています。

よって、Docker Composeのドキュメントに記載されている2.xと3.xのフォーマットは最新ではなく、最新はCompose Specificationであり、Composeファイルを書く際にはこのフォーマットに従うべし、となる(はず)。 上記引用の「recommended version (推奨バージョン)」は、バージョン番号というよりは、単に「版」という意味合いに思える。

Compose Specificationとは

Docker ComposeはDocker社固有のものだが、Docker Composeの定義ファイルであるComposeファイルの仕様を標準化したものが、Compose Specificationである。

www.docker.com

2020年4月に標準化がアナウンスされている。

www.docker.com

Compose Specificationでのversionの取り扱い

Compose Specificationでのversionの取り扱いについては、以下で言及がある。

github.com

上掲のサイトより引用する。

Top-level version property is defined by the specification for backward compatibility but is only informative.

A Compose implementation SHOULD NOT use this version to select an exact schema to validate the Compose file, but prefer the most recent schema at the time it has been designed.

日本語訳すると以下。

この仕様で定義しているトップレベルのversionプロパティは、後方互換性のために残してあるだけで、参考情報にすぎません。

Composeの実装は、Composeファイルの妥当性検証用の正確なスキーマを選択する目的でversionを利用すべきではなく(SHOULD NOT)、Composeの実装を設計した時点での最新のスキーマを選択すべきです。

つまり、version後方互換性のための飾りで、Docker ComposeはCompose Specificationに則ったスキーマを利用する、ということである。