Atuin Desktop登場！実行可能なRunbookで作業効率爆上げ！？

Dockerの方が簡単って言うけど違うくね？再現性の第一歩は「インターネットからの無制限ダウンロードを禁止」することだよ。Dockerは真逆のことしてるじゃん。

何について話してるかによるけど、Terraformは世界に自分が作ったものしか存在しないと思い込んでる欠陥モデルだよね。他の構成管理ツールはそうじゃない。アイテムが存在することを望んでるだけで、存在すればOK、存在しなければ作成するって感じ。
構成管理ツールのもう一つの問題は、既存のリソースのうち、どれを実際に存在させたいか、変更したいかってこと。
それはもう解決済みの問題だよ。リソースを制御するコンピューターで使うものは全部、キーまたは複合キーでリソースを一意に識別できるはず。そうじゃないと、二度と見つけられないもの作っちゃうことになるからね！
Terraformを例にとると、プロバイダーにはリソースごとに一意の識別子を指定するコードがある。単一のキー（’id’、’ASN’、’Name’など）または複合キー（{’id’ + ’VPC’ + ’Region’}）かもしれない。
ダンプしたコードに一意の識別子がない場合、プロバイダーは決定を下す必要がある。提供されたものに一致する既存のリソースを検索して最も近いものを正しいものと見なすか、一意の識別子がないというエラーを出すか。通常、一意の識別子を最初から検索するのは難しくない（VM:”foo1”、Network:”mynet1”のような複合識別子がある）。でも、完全に間違いがないわけじゃない。
ファイルシステムを考えてみて。実際には2つの一意の識別子がある。完全修飾ファイルパスとinode番号。inode番号はファイルシステム内の実際の一意の識別子だけど、覚えにくいし、別のファイルに再利用される可能性があるし、ファイルシステム間で変わるから、参照しないことが多い。代わりにファイルパスを参照する。でも、ファイルパスは微妙に複雑だ。シンボリックリンク、ハードリンク、バインドマウントがあるから、2つの異なるパスが同じファイルにつながることもあれば、異なるファイルにつながることもある！さらに、ファイルを削除して、まったく同じ名前の新しいファイルを作成することもできる。ファイルの内容が同じでも、削除して新しく作成するのは技術的にはまったく新しいリソースであり、システムに影響を与える（アクセス許可が異なる、削除されたファイルへのファイルハンドルが開いているなど）。
だから、俺たちは皆、毎日、自分自身に嘘をついている。ファイルを認識できる、一意の識別子を持っていると装っている。でも実際にはそうじゃない。複合インデックスを使って推測してるんだ。「正しいファイルパスに正しいサイズ、正しい名前、正しいアクセス許可があるから、正しいファイルに見える」と言う。でも、それが期待どおりのファイルかどうかは絶対にわからない。十分に良さそうなら、それで行く。\nそれがリソースを自動管理する方法。リソースの種類ごとに、一意の（または複合の）識別子として使えるものを使って、推測して、十分に推測できない場合はユーザーに確認を求める。なぜなら、人間もそうしているから。

ローカルファーストだと腐敗しやすいってどういうこと？詳しく教えて。

それって状態のバイナリblobがあって、それがどうしてそうなってるのかの説明がないってこと？それじゃメンテできなくない？Dockerfilesは基本的にこれだけど、その状態になるまでのステップが書かれたファイルがあるだけじゃん。

それってAnsibleのこと言ってない？パッケージのインストール、ファイルの存在、特定の内容の有無などをモジュールで確認するんだよね。宣言的で冪等性もあるし。

再現可能なビルドが目的なら、Dockerfileの設計とイメージのビルドの過程で無制限のダウンロードはしないんじゃない？要件に対してツールの使い方が悪いのはツールの問題じゃない。

Terraformが自分が作ったものしか存在しないと思い込んでるってのは違うと思うな。Terraformは状態のスナップショットに基づいて動作する。それは通常ローカルにあるけど、リモートにも置ける。現在のリソースの状態に基づいて状態を更新する仕組みがある。例えばterraform refreshとか。
構成管理ツールの問題は、既存のリソースのうち、どれを実際に存在させたいか、変更したいかってことじゃないってこと？それは違うな。その問題は構成管理ツールが解決するように設計された多くの類似したサブ問題の1つにすぎない。そして、その分野のすべての問題の中で、特に面白くも難しい問題でもない。
希望する状態Xと実際の状態Yがある場合、XのようにするためにYに適用する必要がある操作をdiffで確認すればいい。Terraformはterraform planで3方向の和解マージ/diffでこれを行う。簡単じゃん。
アイテムが存在するかどうかっていうほど単純じゃない。リソースを一意に識別できることが最初のステップなのは確か。でも、安定した識別子を持つ単一のリソースは、異なるプロパティを持つことができる。リソース定義全体（識別子、プロパティ、その他すべて）は、記述して保存してコミットしてプッシュして、最終的に真実にしたいこと（X）として宣言するもの。それはコードではなく、状態（定義）だ。コードは、宣言された状態（X）と実際の状態（Y）をdiffして、一連のデルタ操作を生成するために実行されるもの。または、それらのデルタ操作そのもの。
ダンプしたコードに一意の識別子がない場合、プロバイダーは、提供されたものに一致する既存のリソースを検索して、最も近いものを正しいものと見なすかって言うけど、まずコードじゃなくて状態をダンプする。もっと重要なことは、構成管理システムは、1つの識別子を取得して、別の識別子と照合してはいけない。\nそれか、一意の識別子がないというエラーを出す。通常、一意の識別子を最初から検索するのは難しくない（VM:”foo1”、Network:”mynet1”のような複合識別子がある）。それについても理解できないし、これらのシステムのメンタルモデルも理解できない。俺のVMの例に複合識別子vm:foo1 network:mynet1はない。識別子は直感的にはfoo1だ。識別子をオブジェクトと見なす場合でも、提案するオブジェクトにはメモリサイズがない。さらに重要なことに、foo1 VMをnetwork:mynet1からnetwork:othernet2に変更しても、既存のVMを破棄して、新しいネットワークで新しいVMを再プロビジョニングする効果はないはず。構成変更には、この種の完全な解体/スピンアップが必要な場合もあるけど、これらの条件は一般にまれであり、最新の構成管理ツールはすべて、この種の破壊的な作業を可能な限り回避する。
それがリソースを自動管理する方法。リソースの種類ごとに、一意の（または複合の）識別子として使えるものを使って、推測して、十分に推測できない場合はユーザーに確認を求める。なぜなら、人間もそうしているから。
繰り返すけど、変更を加えるときに「推測」する構成管理ツールは知らない。当然だ。

ほとんどの人が「ローカル」と言うとき、それは「自分のラップトップで何かを実行している」という意味。つまり、ランダムなオペレーティングシステム、ランダムにセットアップされた環境、ランダムにインストールされたツールってこと。同じ名前でも互換性のないオプションを持つツールがあるかもしれない。バージョン3がバージョン4と互換性がないかもしれないし、コマンドの名前は同じかもしれない。そして、それは確実に時間とともに変化する。
これにより、記録した手順は、1) 既存の「ローカル」マシンで動作しなくなり、2) 他の人の「ローカル」マシンと互換性がなくなる。だから、手順は「腐敗」する。
これを避けるためには、すべてのツールをインストールして構成するためにAnsible/Puppetを書くこともできるけど、それも時間とともに壊れ、メンテナンスが面倒になる。唯一の信頼できる解決策は、コンテナを使ってすべてを実行すること。それはすべて同じバージョンであることを保証する。しかし、その時点では、それはもはや「ローカルで実行」されているのではなく、コンテナ内で実行されている。そのコンテナはそれ自体が問題になる。\nそれなら、コンテナまたは何かでクラウド環境でrunbookを実行するためのSaaSツールを使用する方がはるかに簡単だ。ansible/puppetや、みんなのマシン上のDockerよりもセットアップと管理が簡単だ（コンテナを理解していない技術「エンジニア」がまだ100万人もいる）。

親コメントはDockerが再現性に役立つって言ってるけど、それは違うんだよね。Docker自体は何もしてくれない。再現性のあるDocker imageが欲しいなら自分で頑張るしかない。よくあるのは、多くのbuild scriptが何も検証せずにダウンロードすること。NPM packageのpost install scriptとかマジでヤバいことするし。そういうのを全部キャッチするのは大変だよ。Dockerfilesでapt install fooとか平気でやってるしね。

build時の再現性とrun timeの再現性を混同してるよ。Docker images（filesじゃなくて）はrun timeの一貫性には役立つ。Docker (files)はbuildの再現性の表面をなぞる程度。ほとんどのアプリはdistribution package manager(apt, apkとか)とlanguage package manager(npm, cargoとか)に依存してて、どっちも依存関係の解決に課題があるんだよね。build stepの順番とか、動いてないremote serviceへのRPC callとかもあるし。

Dockerを注意深く使うより、再現性のあるbuildを作るのが楽なtoolって何？

そうじゃなくて、全部手動で宣言するシステムが面倒だって言ってるんだよ。理想的には、変更を加えた時に変更を記録して、重複を排除して、不要なものを削除して、必要な時にreplayできるplaybookができればいいんだよね。

それってautoexpectのことじゃない？https://linux.die.net/man/1/autoexpect

Ansible configurationなんて書きたくないんだよね。設定は何も書きたくない。ただstateをdumpしてrestoreしたい。（別の言い方をすると、既存のシステムに基づいてAnsible configurationを自動生成して、それを後でapplyしたい）

みんなが100% buildの再現性を求めてるわけじゃなくて、Dockerfilesはだいたい”run stable”で、OSの抽象化とprocess encapsulationを提供してくれるからいいんだよね。

いや、それも結局は一連のstepを監視して最終的にthingにたどり着くってことじゃん。一連のstepを記録したいんじゃなくて、thingの既存のstateをdumpしたいんだよ。

Ansibleで結構複雑なもの書いてるけど、ほとんどdeclarativeだけど、idempotencyについては注意した方がいいよ。特にcommunity moduleを使う場合はね。

Vagrantは再現可能なVMを作るんだよね。もちろん全く同じものじゃないけど。https://developer.hashicorp.com/vagrant

確かにその通りだけど、ちょっと考えれば、Dockerfileを簡単に移植したりアップデートしたりできるんだよね、何年も経っても。\n「今どう動いているか」をドキュメント化するのに一番簡単でいい方法だと思うんだ。変な「自分の環境では動く」みたいなことがないし。だから、この考え方にはすごく近いと思ってる。完全に再現できるのが一番いいけど、普通は20行くらいの短いファイルにはできないし。(Nixとか言う人もいるけど、複雑すぎるから「apt-get install docker ＆＆ docker build .」みたいに簡単とは言えないよね)

そういうプロセスは移植性が低いことが多いし、システムごとに繰り返す必要があるよね。だから、状態Xになるための手順を自動的に変換できる宣言的な記述があれば最高だよね。

Dockerfileって基本的に外部にアクセスできるシェルスクリプトだよね。ネットワークアクセスも自由だし、ローカルのハードウェアやファイルシステムにもアクセスできる。でも、外部から持ってきたものがビルド間で同じかどうかは確認しない。DockerfileがApache httpdをビルドしたりNginxをビルドしたりしてもDockerは気にしないんだ。これ以上再現性がないものはないよね。\nでもなぜかDockerは再現可能だって言う人がいるけど、それはDocker registryからギガバイト単位のバイナリblobをダウンロードできるからだって言うんだ。それって、何でも再現可能ってことにならない？\nDocker imageは従来のFHSディストリビューションを対象としたバイナリに比べて移植性があるかもしれないけど、再現性はないよね。

これってAtuin CLIやsync serverみたいにオープンソースになるのかな？製品化されるのかな？

オープンソースになるみたいだよ。https://news.ycombinator.com/item?id=43766200#43766584

サーバーは違うんじゃないかな。

無料じゃない可能性が高いね。とにかく、発表されて嬉しいよ！

プラットフォームにrug pulledされる心配はない？

わかる、最近は何でも「enshittification」される可能性を考えちゃうんだよね。特に製品を導入するときは。オープンソースならまだ安心できるけど。

runbookに関する俺の経験談：うちのチームは色々管理してて、俺が詳しいものもあれば、名前くらいしか知らないものもある。で、Xっていう後者のカテゴリの何かが壊れる→詳しい人は休暇or死亡or会議中→ドキュメントがある！→でも時代遅れで間違ってる、っていうね…　だから、これはそういう問題を解決しようとしてるんだって。Jupyter NotebooksとAnsible Towerの中間みたいなものらしいよ。ドキュメント、スクリプト、メトリクスが全部まとまってて、何が悪いか、どう直すか、直ったかどうかが分かりやすい、みたいな。

そうあるべきだけど、そうじゃないことってよくあるよね…　もしかしたら、これ系のrunbookの方が、コメントが一切ない1000行のスクリプトより扱いやすいかもよ。
もちろん、理想の世界ではそんなことないんだろうけど、インシデントなんて起こらないんだろうけどね！

＞時代遅れで間違ってる、っていうね
Atuinでどう解決するの？間違った情報や古い情報が、テキスト文書とかwikiにあるのと同じくらい簡単にAtuinドキュメントにも入ると思うんだけど…　何か見落としてる？

俺はただのコミュニティmodだから、話半分に聞いてほしいんだけど…
ドキュメントとターミナルの間で双方向の選択的同期ができるようにする意図があると思う。だから、ドキュメントの内容が古かったり間違ってたりしたら、実際に修正するためにやったことをドキュメントに同期して、ドキュメントを更新する手間を減らすことができる、ってことじゃないかな。

説明ありがとう。理解できた。

俺的に、修正してるものが実際に実行されてる”runbook”だからじゃないかなって思う。ドキュメントとコードを分離する代わりに、一緒にすることで、ちょっとした変更を加えたときに、別の場所にあるドキュメントを編集することを忘れずに済むようにしてるんだと思う。個人的にはまだ試してないけど、ちょっと気になる。

今はPendulumとは逆の方向に行ってて、分離はもう流行ってなくて、全部1箇所にまとめるのがトレンドって感じだよね。ターミナルがあんまり好きじゃないから、もっと見た目が良くて、履歴とかコメントが充実してるのは嬉しい。Atuinがそれを実現する最良の方法かどうかは分からんけど。

なるほどねー､言いたいことは分かった｡技術者じゃなくても､何が起きてるか分からなくても､指示通りにコード実行できるのはマジで良いかも｡全部一緒にあるし｡でも､ドキュメントが古くなったり間違ったりする問題は解決しないよね｡結局runbookが正しいか確認する必要があるし｡スクリプトを一箇所にまとめるのは良いけど､これローカルのデスクトップ版だし…

これってshell scriptのためのリテラシープログラミングって感じ？まさに“Runbooks That Run”じゃん｡

Rustで書かれてるからHacker Newsで話題になるんだよ｡

PowerShell使おうと思ってたけど､RustってことでNushellも良いな｡個人的にはこっちの方が好きかも…

そもそもデプロイをAnsibleとかDeployerで作る目的って何？よくあるタスクのためにPythonスクリプトをgit repoに突っ込むのもそうだけど｡\n人それぞれ好きなやり方があるってことだよね｡それで上手くいくなら市場があるかも｡俺は個人的なプロジェクトでPHPのデプロイプロセス使ってて､60%は自動化できてる｡runbookはツールに組み込まれてて､git repoにある｡別の場所に置いたり､コマンドを覚えたりする必要ない｡コードはシンプルで関数型なら､コメントなくても自己文書化されるべき｡

俺の夢は､全てのツールにターミナルインターフェースがあって､頭の中にあるコンテキストを全部まとめてメガブックを作れるようにすること｡例えばJira､Datadog､Githubとか全部一つの画面で見れるように｡

それ良いね｡個人的にはTUIも好き｡もっとユーザーフレンドリーになるし｡内部サービスごとにコンポーネントがあるTUIフレームワークを組み合わせて､自分だけのTUIダッシュボードを作れたら最高じゃん｡サイドプロジェクトで作りたいかも｡大変だけど面白そう｡

それな｡TerraformがIaCの共通言語になったみたいに､TUIでも同じことが起きて欲しい｡ベンダーが独自のCLIを作るんじゃなくて､共通のTUIフレームワークのプラグインを作ってくれれば良いのに｡

APIがあれば十分だと思う｡ツールはAPIの上に作れば良いし｡理想は全てのサービス､ツール､アプリがAPIを持ってること｡例えば冷蔵庫が開けっ放しだったら(APIポーリングかAPI webhook)､Roombaに閉めてもらう(RoombaのAPIを使って)｡APIの世界最高｡

どういう意味？GithubとDatadogは公式のCLIツールあるじゃん｡

Jiraにも公式CLIがあるよ。それ以外にも非公式なものがたくさんあるみたい。

wtfutilみたいなものかな？（開発は1年止まってるけど、コンセプトは近いかも）

＞MCPを気に入るかもって、GPが求めてるものと全然違うじゃん。
＞全てのツールにターミナルインターフェースがあって、頭の中にあるコンテキストを全部まとめられるメガブックを作りたいんだよね。例えば、Jira、Datadog、GitHubとかを一つの画面に。
要するに、Jira/Datadog/GitHubとかをCLIにプラグインできるようにして、標準のbashコマンドやパイプを自由に使えるようにしたいんだ。（Yahoo Pipesみたいな感じで）
MCPはLLMがユーザーのリクエストを分析して、MCPサーバーで実行するクエリを作ることに特化してる。求めてるものは、LLM中心じゃないんだよね。

そんなに遠くないと思うよ。確かにMCPはLLMとの連携を前提に設計されてるけど、汎用的なAPIとしても使えるんだ。だから、計算処理をパッケージ化して、MCP、REST、JSON-RPC over WSからアクセスできるようにしたんだ。
ロジックを一度作れば、クライアントがどんな方法で使っても、標準化された方法でアクセスできる。CLIでjqとかにパイプして分析したりもしてるよ。

いいね！どんな技術スタックを使ってるの？オープンソースになる予定はある？

ありがとう！クライアントはTauri(https://v2.tauri.app/)、サーバーはElixir + Phoenix（Rustler経由でRustも少し）を使ってるよ。
Tauriのおかげで、既存のRustコードを再利用できて、必要なシステム処理も簡単にできるし、軽くて速いものが作れるんだ。Elixirも最高で、リアルタイム同期のバックエンドを簡単に作れる。
今はまだ開発初期段階だからオープンソースじゃないけど、デスクトップアプリは後で公開する予定だよ。

Phoenix LiveBookみたいなものとの連携予定はある？

＞デスクトップアプリは後で公開する予定ってことは、Functional Software Licenseみたいなのもあり得るね。