higuruchi / injesh

injesh

概要

• distrolessやscratchなどのシェルが無いコンテナ内に入り込みデバックするためのアプリケーション
• cgroup、ipc、net、pid、user、utsなどの名前空間をデバック対象コンテナと共有することでコンテナ内に入り込むことができる

利用方法

設定ファイルや.injeshディレクトリなどを初期化

injeshをインストールした後、一度だけ実行する

$ injesh init

デバッグコンテナを新規作成し、デバックコンテナ内に入る

NAMEはデバックコンテナの名前。指定がない場合は自動生成。

• デバックコンテナを生成した際に実行するコマンド。CMDの指定がない場合、デフォルトのシェルを利用

  $ injesh launch　[CONTAINER_ID or CONTAINER_NAME] [NAME] [CMD]

• 指定PATHのrootfsを基に起動

  $ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs=/path/to/rootfs [NAME]　[CMD]

• lxd image server からrootfsをDLしてから起動

  $ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-image=<image-name> [NAME]　[CMD]

• 指定docker containerのrootfsを基に起動

  $ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-docker=<docker-container-id> [NAME]　[CMD]

• 指定lxd containerのrootfsを基に起動

  $ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-lxd=<lxd-container-name> [NAME]　[CMD]

既存の任意のコンテナに入りCMDを実行する

CMDがない場合は設定値ファイルのシェルを起動

$ injesh exec [NAME]　[CMD]

デバッグコンテナを削除

$ injesh delete [NAME]

デバッグコンテナを一覧表示

$ injesh list

デバッグコンテナの指定ファイルをDL

$ injesh file pull [NAME]:/path/to/file /path/to/dest

ホストの指定ファイルをデバッグコンテナの指定PATHにupload

$ injesh file push /path/to/file [NAME]:/path/to/dest

ディレクトリ構造

.
|--config            # sample config file
|--images
|  |--busybox-1.32.1.tar.bz2  # lxd image server からDLして作成したrootfs
|--containers
|  |--bbox-goweb      # debug container name
|  |  |--setting.yaml # config file
|  |  |--merged
|  |  |--rootfs       # base rootfs
|  |  |--target_id    # docker container id (名前からIDを特定するため)
|  |
|  |--ubuntu-goweb
|  |  |--rootfs -> /path/to/custom/rootfs  # カスタムrootfsが散らばると汚いのでリンクを張る
|  |  |--target_id
|  |  |--upper
|  |  |--setting.yaml

injesh's Issues

src/parser.rsを綺麗にする

injeshのコンテナ名からdockerのコンテナを特定したい

execするとき、引数は、injeshのコンテナ名と実行コマンドのみ。
実行にはdockerコンテナのpidが必要。
よって、injeshのコンテナ名からdockerコンテナの名前を算出する必要がある。どうすればよいか？

モックでは、dockerコンテナidを記述したテキストファイルを、~injesh/containers/<name>/target_idとして保存したものを使っていた。
（container.rsからpid出せるからいらんかなと思って仕様に入れなかった）

• 引数を増やすのは避けたい
• Fileでも使いそうだし、utilsあたりに公開関数として実装したほうがいいかも

提案1

~/.injesh/containers/<name>/target_idからidを取得する

メリット:

• 単純
• 実装が楽
  デメリット:
• launch時にファイル生成処理が追加で必要になる
• 安直

提案2

mount情報から、~/.injesh/containers/<name>/rootfs/をlowerdirとするマウントポイントを取得し、
dockerコンテナ総当りでContainer::new()?.mergeddirと一致するか探索する

メリット:

• 仕様変更の必要がない
  デメリット:
• 計算量がデカすぎる

提案3

引数のinejshコンテナ名 == dockerコンテナ名にしてしまう

メリット:

• 単純
• ユーザから見てデバッグ対象が明確になる
  デメリット:
• injeshコンテナ : dockerコンテナ = 1 : 1 の制限がつく
• launchの引数が一つ減る変更が生じる

Summary

	実装が楽か	仕様変更が少ないか	使いやすいか	備考
提案1	O	O	O	安直。read onlyにすべき
提案2	X	◎	O	総当りは計算量が多すぎ
提案3	O	△	◎	injesh : docker = 1 : 1 となってしまう

意見求ム

settings.yamlの書式を決める

実行コマンドだけでなく、#41 にあるように、docker contanier idのメモなどの機能もほしい

imageを管理するモジュールの実装

command.rsでのpid出す処理にてpsコマンドから脱却する

外部コマンドへの依存は避ける

ciでdockerコンテナを使ったテストを可能にする

shellあり/なし をそれぞれ起動しておく．

• name:
  • test_nginx
  • test_scratch_web

scratchはこちらで適当に作成する．

ciでrustのcrateをキャッシュする

デバック対象コンテナの呼び名をbデバックコンテナかinjeshコンテナどちらに統一する

デバック対象コンテナの呼び名をbデバックコンテナかinjeshコンテナどちらに統一する？

#58 (comment)

debug_containerでどうでしょ
convert_debug_container_name_to_docker_idみたいになりそう

#58 (comment)

再起コピー関数をutilsかどっかで共通化したい

launchで再起コピーしているが
deleteでも使いたい(#53 )ので、共通化したい

utilsが適当だろうか

image_downloader_lxdのアーキテクチャが固定値になっている

execコマンドを実装する

utils.rsに便利関数を実装

• docker container name/id から pid
• image server から rootfs を 作成 別のissueで対応

コマンドのインタフェースを作成

CIを追加

push,pullreq

• test
• build
• clippy
• doc

とりあえずこれぐらい？

rustdocをgithub.ioに公開も必要ならやるが，
現状ドキュメント書いてないからな～

どうすべ？

deleteコマンドの実装

コマンドラインの解析処理を実装する

# 設定ファイルや.injeshディレクトリなどを初期化
# injeshをインストールした後、一度だけ実行する
$ injesh init

# デバッグコンテナを新規作成し、デバックコンテナ内に入る (overlayfsのマウントなど)
# 設定ファイルに記述されたコマンドの実行ファイルや依存ライブラリを取ってきてrootfsを作成してから起動(ペンディング)
# NAMEはデバックコンテナの名前。指定がない場合は自動生成
# デバックコンテナを生成した際に実行するコマンド。CMDの指定がない場合、デフォルトのシェルを利用
$ injesh launch　[CONTAINER_ID or CONTAINER_NAME] [NAME] [CMD]
# 指定PATHのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs=/path/to/rootfs [NAME]　[CMD]
# lxd image server からrootfsをDLしてから起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-image=<image-name> [NAME]　[CMD]
# 指定docker containerのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-docker=<docker-container-id> [NAME]　[CMD]
# 指定lxd containerのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-lxd=<lxd-container-name> [NAME]　[CMD]

# 既存の任意のコンテナに入りCMDを実行する
# CMDがない場合は設定値ファイルのシェルを起動
$ injesh [NAME]　[CMD]

# デバッグコンテナを削除
$ injesh delete [NAME]

# デバッグコンテナを一覧表示
$ injesh list

# デバッグコンテナの指定ファイルをDL
$ injesh file pull [NAME]:/path/to/file /path/to/dest

# ホストの指定ファイルをデバッグコンテナの指定PATHにupload
$ injesh file push /path/to/file [NAME]:/path/to/dest

Cargo.lockをgitignoreから消す

CIでキャッシュするときにCargo.lockをcache keyとして使いたい．
また，バイナリクレートなので．

参照:

• https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
• https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

テスト用ディストロレスコンテナを追加

initコマンドの実装を行う

仕様

# 設定ファイルや.injeshディレクトリなどを初期化
# injeshをインストールした後、一度だけ実行する
$ injesh init

deleteできないバグを修正する

copyが再起的にできてないことが原因のよう。

listコマンドの実装を行う

最低限:

ctn1
ctn2

理想:

CONTAINER ID   IMAGE          COMMAND                  CREATED       STATUS                   PORTS     NAMES
f890c8cba838   44193032942f   "/bin/sh -c '#(nop) …"   3 weeks ago   Created                            ctn1
7f8959277f44   a7e17988fc4e   "/bin/sh -c '#(nop) …"   3 weeks ago   Created                            ctn2

…みたいなリッチな表示

launchコマンドの実装を行う

仕様

# デバッグコンテナを新規作成し、デバックコンテナ内に入る (overlayfsのマウントなど)
# 設定ファイルに記述されたコマンドの実行ファイルや依存ライブラリを取ってきてrootfsを作成してから起動(ペンディング)
# NAMEはデバックコンテナの名前。指定がない場合は自動生成
# デバックコンテナを生成した際に実行するコマンド。CMDの指定がない場合、デフォルトのシェルを利用
$ injesh launch　[CONTAINER_ID or CONTAINER_NAME] [NAME] [CMD]
# 指定PATHのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs=/path/to/rootfs [NAME]　[CMD]
# lxd image server からrootfsをDLしてから起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-image=<image-name> [NAME]　[CMD]
# 指定docker containerのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-docker=<docker-container-id> [NAME]　[CMD]
# 指定lxd containerのrootfsを基に起動
$ injesh launch [CONTAINER_ID or CONTAINER_NAME] --rootfs-lxd=<lxd-container-name> [NAME]　[CMD]

実装状況

• --rootfs
• --rootfs-image
• --rootfs-docker
• --rootfs-lxd

デモ

$ sudo ./target/debug/injesh  launch {Contaioner ID}  --rootfs-image ubuntu/focal <DContainer_Name> /bin/bash
cmd"/bin/bash"
root@aef30e90a84b:/# ls
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@aef30e90a84b:/# 

Delete struct の使用を提案

delete メソッドの引数は せいぜい名前だけだろうということで &strにしていたが，--forceなどのフラグの追加が考えられるため structにまとめるのはどうか．

 pub trait Delete {
-    fn delete(&self, delete: &str);
+    fn delete(&self, delete: &command::Delete);
 }

初期化確認処理をlistのメイン処理の前に実装

#19 (comment)

utilsに定義したのをつかう

NotInitializedエラーを返す

README.mdを書く

sudoで実行してもrootでなくsudo_userのhomedir以下に.injeshを作成させたい

why

sudo ./injesh launch ...などを実行すると、/root以下に.injesh/が作成される。
各ユーザのinjeshコンテナがrootユーザのディレクトリに統一されてしまうのは、rootユーザのホームディレクトリを汚すことになるだけでなく、injeshコンテナ名の重複が発生することも考えられる。
また、cargo testなどローカルでのデバッグもしづらい。

how

環境変数HOMEは/rootなので、
環境変数SUDO_USERのホームディレクトリを/etc/passwdから特定し、
user::User::new()で生成するホームディレクトリのpathに設定する。

user.rsあたりで，ユーザーのCPUアーキテクチャを取得する

現在はハードコードしている．

---

おそらくの対応表

uname	architecture
x86_64	amd64
aarch64	arm64
armv7l	armhf
armv6l	armhf
...

RPI 4はaarch64で，arm64に対応しているっぽい(aptのパッケージソースがarm64だった)ことが確認できた．

他のarmアーキテクチャはarmv7lなどarm*のバリエーションがあるっぽい．
さらにそれらはarmhfにあたりそう．RPI 3あたりで試してみたい．

---

unameシステムコールを使えばCPUアーキテクチャの種類がとれた

#include <stdio.h>
#include <sys/utsname.h>

int main() {
        struct utsname buf[32];
        uname(buf);
        printf("%s\n", buf -> machine);
        return 0;
}

[CI] cargo fmtをpush時に自動化する

忘れるので

actionsでcargo fmtして自動pushする

container.rsにreloadモジュールを追加

内容

デバック対象コンテナをreloadするためのモジュールをcontainer.rsを追加

injesh homedirを表す変数の共有化

各サブコマンドで環境変数homeから~/.injesh/*を生成して使うのは，処理が重複してるので共通化したい

案

1. command.rsかどこか に const INJESH_HOME = ~/.injesh, const INJESH_HOME_IMAGE = INJESH_HOME/images などを設定する

• HomePath みたいな structかenumか 作ってそれにまとめるのでもいいかも

2. 環境変数からPathを生成する関数を定義し，各サブコマンドの実行時にそれを呼び出す

実行ごとに変数が初期化されるなら1.でよさそう．
struct等にまとめるか否か．まとめて使うのがめんどくさくなるなら，変数だけでいいと思うがどう？

launch内でデバック対象コンテナのreloadを行う

User構造体にはinjeshのホームディレクトリとその関連Pathを入れる

User.home は ホームディレクトリになっているが，
コマンドで使うのはそれ以下の~/.injesh/*なのでそのPathを格納します

[hotfix] listのテストを一旦消す あとメソッド名のgetを消す

なぜかlistのテストが失敗している(mainからブランチ切って何も変更していないのに！)
それに，今後，ディレクトリに依存するテストはやりづらいので，体制を整えてからテストを再開したい

get_user()メソッドはC-GETTERに沿うようにする