Dockerコンテナ
Dockerコンテナを使用したCLIの実行
イメージの取得
まず CLI イメージを取得します。
docker pull keeper/keeper-secrets-manager-cli:latestイメージはlinux/amd64とlinux/arm64に対応しており、ホストに合ったものが自動的に取得されます。
こちらのDockerウェブサイトでイメージをご覧ください。
コンテナの実行
次にコンテナを実行します。デフォルトでは、シェルモードで ksm を起動するように設定されています。
docker run \
--rm \
-it \
-v $PWD:/wd --workdir /wd \
-v $HOME/.config:/etc/keeper -e KSM_INI_DIR=/etc/keeper \
keeper/keeper-secrets-manager-cli:latestdocker runコマンド。実行が完了したときにコンテナを削除するフラグ。非アクティブなコンテナが増え続けるのを防ぎます。
コンテナとの対話操作を可能にするフラグ。
カレントディレクトリをコンテナ内の
/wdにマウントし、作業ディレクトリも/wdに設定します。/wdへの書き込みは、コンテナ外のカレントディレクトリに反映されます。ファイルのダウンロード先にするときなどに便利です。keeper.iniを置きたい、またはすでに置いてあるディレクトリをマウントします。続けて、keeper.iniの読み書き先をCLIに伝える環境変数を渡します。イメージの名前。
エイリアス
docker run コマンドは毎回入力するには長すぎるため、エイリアスの作成をおすすめします。
上記を実行すると、ksm のシェルが起動します。
以下のエイリアスでは、run コマンドの末尾にアプリケーション ksm を付けます。これにより、ksm はシェルモードでは起動しません。
組み込みバイナリ
KSM CLIのDockerイメージには、GLIBC (ほとんどのLinuxディストリビューション) 用とMUSL (Alpine Linux) 用のCLIバイナリをまとめたボリュームマウントが含まれています。マウントポイントは /cli です。このディレクトリは、docker-composeの volumes_from またはDockerコマンドラインの -v で、別コンテナから取り込めます。ksm の実行ファイルは、利用するCライブラリの種類ごとのディレクトリに分かれています。
/cli/glibc/ksm- Ubuntu、Debian、Fedora、CentOSなど、一般的なGLIBC環境向け/cli/musl/ksm- Alpine Linux向け
どちらのバイナリも、プルしたイメージのCPUアーキテクチャ向けにビルドされています。Dockerイメージはマルチアーキテクチャ (linux/amd64およびlinux/arm64) なので、docker pull でホストに合ったイメージが取得されます。initコンテナ方式では、/cli 内のバイナリはプルしたイメージのアーキテクチャ向けです。対象コンテナでのクロスコンパイルやエミュレーションは不要です。
/cli/glibc/ksm の実行には、対象コンテナにglibcが必要です。/cli/musl/ksm にはmusl 1.2.5以降 (Alpine Linux 3.20以降) が必要です。古いベースイメージでは、コピーしたバイナリを実行できない場合があります。
Alpine Linuxベースの構成向けには、専用のAlpineイメージも用意されています。Docker Hubの該当ページをご参照ください。
以下は、別コンテナからCLIバイナリを参照する手順の一例です。
init サービスは、CLI用のDockerイメージを読み込みます。コンテナは起動してCLIのスプラッシュ画面を表示したあと終了します。コンテナが停止したあとも、/cli ボリュームにはアクセスできます。
main サービスは、volumes_from でCLI用イメージのボリュームを /cli にマウントします。command を上書きし、GLIBC版のKSM CLIを実行します。CLIの exec 機能により、Keeper表記法を使った環境変数の値がシークレットに置き換わります。ここではCLIの exec から printenv を起動し、Keeper表記法で設定した環境変数 MY_LOGIN の展開結果を表示しています。
最終更新

