静的で継続的なコンピューティング環境であるLinuxがあるとしましょう。一方向SSH接続があり、インフラストラクチャが信頼できます。それは私のものです。
プリインストールされたルーチンに付属しているansibleなど、いくつかのブランドの「エンタープライズ」ツールがあります。最終的に誰かがそれを修正しようとすると、苦しむでしょう。
次に、airflow（dags）とLuigis（Pythonのgnu-makeレプリカ、Pythonはmakeおよびbashよりも低いレベルの言語であり、makeとは異なり、アプリケーションバイナリインタフェースのサポートはありません）があります。高レベルの作業のために低レベルのコードを書く必要があり（Pythonは入力問題とバージョン管理の問題がある低レベルの言語になりました）、Python手荷物（仮想環境/ anaconda /クロスプラットフォーム相互運用性）を使用して何でも使用できます。
これらの「製品」、ソリューション、およびツールの周りには、「ただ動作する」基本的なUnix / LinuxオペレーティングシステムとDockerイメージがあります。
これらのドッカーイメージとサブシステム（Linux用のWindowsサブシステム）内には、50年前のプロジェクト「Make」とzsh/bash。parallelssh
makeluigi実際、これは完全に汎用性があり、迅速な自動化を作成したいときに1〜2週間で実行したものよりはるかに高速ですairflow。これは、新しいツールを識別する方法としても使用されます。何かが複雑すぎる場合は、明らかに低レベルの言語用にパッケージ化されたツールでなければなりません。
また、さまざまなLinuxディストリビューションとWindowsの間でPythonの依存関係を引き付けるため、固定コストは発生しません。
しかし、欠けている部分があるようです。リモートシステムで実行されるジョブを自動化したい場合は、makeの効率が低下します。試してみましたが、ssh -c "..."結果は少し汚れていました。
pachydermソリューションを検索しながら（データサイエンスのためのデータバージョン管理）、luigi（複製を作成）、airflow（面白くない）、ansible（再び：Pythonベースのパッチタイムレシーバー）などを見つけました。
expect私はまた1980年代/90年代に出てきたandというツールを見つけましたautoexpect。このツールは基本的なツールであるように見え、linuxLinux、cygwin、リモートLinuxシステムなどのWindowsサブシステムで「正常に動作する」カテゴリに属します。
それはあなたの声明に合うようで、さらにmake私のスタイルの自動化方法とうまく機能します。全体的に、automation.expスクリプト内のノイズは自動的に生成されるため、まったく問題はありません。重要なのは、人間が作ったコンポーネントです。これらの小さなコンポーネントはcomponents.exp複雑ではありません（すべてのプロセス制御、設定、ユーザーログイン、ドキュメント、およびニューエイジツールに関連するインストール手荷物）。
ただし、autoexpectこれはマクロレコーダーであるため、これを使用して実行できる多くの操作には、リモートコンピュータからの非決定的な応答が含まれます。expect専門家になるために時間をかけない限り、これは問題を引き起こします。
autoexpectすべての序文を取り除いて、これらのシステム内で「公正な」作業カテゴリに属する選択肢があるかどうか疑問に思います。
そして、明白なことを制限するために、自動化されたシステムにPython仮想環境をインストールして維持するためにコンピュータの周りを動かす必要がないことを確認してください。混乱を処理するのに疲れました。
ベストアンサー1
リモート実行の場合は、次のことを確認できますenv_parallel。
dostuff() {
mystuff "$@"
}
alias mystuff='echo $my'
my=My
env_parallel -S server dostuff ::: a b c
ここでのアイデアは、GNU Parallelに環境をリモートサーバーにコピーさせることです。したがって、発生する可能性のある参照サーカスを処理することなく、ローカルサーバーで複雑な機能を定義してリモートで実行する方が簡単ですssh -c "..."。
相互作用が必要かどうかはわかりませんexpect。もしそうなら、これはあなたの要件を満たさないでしょう。