testcontainers / testcontainers/testcontainers-python
Making a container to test SaltStack, is this pattern reasonable?
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 2.3k
- フォーク
- 386
- 平均マージ
- 4時間 40分
- マージ済み PR(30日)
- 1
説明
Hi! I'm have been working on a testcontainer for SaltStack, which is a OS configuration tool.
My motivation is that configuration tooling also needs to test its modules, and the normal system, salt-kitchen makes some assumptions that breaks with what i would call common structuring of the system :)
So I've made a workable solution extending the regular DockerImage with extra functionality to generate the correct configuration and mount of the roots we need, but what I'm a bit stuck at is what the running command should be. As this is a setup where the actual command (apply state) runs once and exits. From what i see/understand, by exiting the container I'm not able to start the next step of testing where i actually validate the state with help of for example testinfra
So right now I've opted for a two stage approach: Where the DockerFile stays alive with CMD [ "tail", "-f", "/dev/null" ] and the user invokes the state apply command after container.start()
def get_salt_call_args(self, command: str = "state.apply") -> list[str]:
return [
"salt-call",
"--local",
f"--config-dir={self.config_dir}",
f"--id={self.config_file['id']}",
f"{command}",
]
def exec_salt_call(self, command: str = "state.apply") -> tuple[int, bytes]:
return self.exec(self.get_salt_call_args(command))
How wrong of a pattern is this for a testcontainer? From what i see all others are mainly focusing on starting services to support, and not directly being used.
Would it make sense to run a init container that runs the apply, then a new instance that i can run the state inspection tests on afterwards? Or maybe run the apply as a part of the Image building?
PS: I know it does not make a lot of sense to use a Config management tool inside a container, the point here is simply to quickly test modules that will later be used on proper operating systems :)
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、container.start() と exec() 周辺の DockerImage のライフサイクルを確認し、次に提案されている tail -f アプローチと、2 段階の init-container という案を比較してください。この issue ではファイルやテストが指定されていないため、実装前に、想定されるコンテナのライフサイクルと、testinfra を使って完了をどのように検証すべきかを明確にしてください。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- docker, python
- 領域
- devops, testing-qa
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100