Atuin Desktop: 実行可能な Runbook
(blog.atuin.sh)- Atuin Desktopは、ドキュメントのように見えながらターミナルのように実行できるローカルファーストな runbook エディタで、繰り返される運用手順を共有可能なワークフローにしようとするツール
- シェルコマンド、データベースクエリ、HTTP リクエストをスクリプトブロックと組み込みターミナル、データベースクライアント、Prometheus チャートの中でまとめて扱う
- Atuin CLI が同期・検索可能なシェル履歴を提供していたとすれば、Desktop はチームの知識が個人の記憶や履歴にだけ残らないよう、実行可能なドキュメントへと拡張する
- Atuin チームは、CLI リリース、環境間のインフラ移行、staging/prod での実行、ライブデータベースクエリの管理とコラボレーションにすでに活用中
- 次の段階としてTeam accountsと、シェル履歴から runbook を作成する機能を計画しており、現在 early access を提供中
個人の記憶に依存していた運用手順をドキュメント化
- 多くのインフラ作業は、障害発生時に誰かが覚えているいくつかのコマンドに依存しており、ドキュメントは存在しないか、あっても古くなりがち
- 実際の解決の手がかりは、Slack スレッド、Notion ドキュメント、個人のシェル履歴に散らばっていることがある
- Atuin CLI は同期・検索可能なシェル履歴によってこの問題の一部を解決したが、チームには履歴以上の共有可能なワークフローが必要
- Atuin Desktop は、「runbook は実行されるべきだ」という前提で作られた実行型 runbook エディタ
- ダウンロードはダウンロードページで提供されている
ドキュメント内で実行されるターミナルワークフロー
- Atuin Desktop は、ドキュメント UI の中で実際のターミナルワークフローを実行するように設計されている
-
ひとつの場所にまとまる作業要素
- スクリプトブロック
- 組み込みターミナル
- データベースクライアント
- Prometheus チャート
-
提供機能
- コンテキストスイッチの削減: シェルコマンド、データベースクエリ、HTTP リクエストを連携
- 腐らないドキュメント: ドキュメントから直接実行して最新性を保つ
- 再利用可能な自動化: Jinja スタイルのテンプレートで動的な runbook を作成
- 即時リコール: 実際のシェル履歴から自動補完を提供
- Local-first, CRDT-powered: ターミナルで実行できるものは runbook でも実行できる
- Atuin Hub の同期と共有: デバイス間やチーム間で最新状態を維持
実際のユースケースと提供状況
- Atuin チームは、すでに実務で Atuin Desktop を使用中
- Atuin CLI のリリース
- 環境間のインフラ移行
- staging または prod での実行
- ライブデータベースクエリの管理とコラボレーション
- 今後の機能として、Team accounts とシェル履歴から runbook を生成する機能が予定されている
- 現在提供中で、early access list から参加できる
1件のコメント
Hacker Newsの意見
Emacsに興味がある人なら、org-babelで似たようなことができる
1つのプレーンテキストファイルがプログラムであり、同時にドキュメント／ノートブック／Webサイトにもなり得て、文芸的プログラミングの説得力ある例になっている
よい説明はここにある: https://osem.seagl.org/conferences/seagl2019/program/proposa...
プログラミング本で学ぶときに大いに助けられたし、後でその文芸的プログラムを見返すと、最初に本を読んだときよりずっと早く理解が戻ってくる
文芸的な部分が、当時の推論や自分の考えを100%覚えていないせいで生じる「ばかげた」質問に答えてくれる
もちろん学習曲線はあるので、そういうものを学びたくない人には向いていない
発表動画[0]と、より高度なデモがあるGitリポジトリ[1]も見られる
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/orgdemo2
約7年前にこれを試してみた: https://nurtch.com/
アイデア自体には長所が多く、JupyterCon Paris 2023でも関連する発表をした: https://www.youtube.com/watch?v=TUYY2kHrTzs
ドキュメント内に実行可能なコードがあると、人々はドキュメントにもPRレビューのワークフローを適用したがるが、これはWikiを編集するよりもチームとしての投資がさらに必要になる
AWSにいたとき、まさに自分たちのチームが欲しかったものだ
自動化するには少し危険な運用作業が本当に多いが、これはそうした作業を反復的に自動化へ育てていく道筋を提供してくれる
AWSにいたのがいつなのか気になる
ここ数年、AWSでは運用ランブックをコード化し、安全に自動実行できるよう支援して運用の雑務を減らす内部プラットフォームサービスを作っていた
Atuin Desktopもある面ではそのサービスに似ているが、その内部サービスの方が機能はずっと多かった
CloudWatchクエリやAWS CLIコマンドのようなものをユーザー入力とともに実行しつつ、正しい認証情報を安全に取得し入力を整形する設定の手間をなくす、という形だった
その後GitHubから直接実行できるように作り直し、GitHub Wikiでユーザー入力を使ってLambda関数を4行のコードで呼び出す例はここにある: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
IAM統合のあるホステッドノートブックだった
ローカルのJupyterノートブックとどう違うのか気になる
.ipynbで!や%を使えばこれができるのでは？この会社やCLI製品をよく知らないので、純粋に質問している
pipenv/pyenv/conda/poetry/uv/dependencies.txtと、「このノートブックを動かすにはPythonを上げないといけないのか、ああ…わかった」から始まり、2週間後には「そのアップグレードで古いAnsibleが壊れて、今ではかろうじて動いていた15台のサーバーを直せない」になる流れは地獄だ
基盤となる自動化ではPythonを遠ざけるようにしている
自分が扱うPythonプロジェクトは、依存関係やランタイムの問題で少なくとも年に1回は壊れるし、Ansible、ビルドパイプライン、
deploy.pyのようなものにも当てはまるJupyterノートブックは巨大な依存関係ツリーと要件を引き連れてくるので、そういう重要で基盤となる自動化には使わない
もちろん自分の仕事はコードベースを過剰に多く扱わせるもので、直近2か月だけでもPythonプロジェクトが少なくとも6つあった
あるものはPython 2.7が必要で、あるものは廃止された
lib-something.hのバージョンが必要で、あるものは最先端で、あるものは文書化されていないが実際には非常に厳格で、「担当開発者1人のマシンで何もアップデートしない限り動く」という状態だPuppetやChefもRubyなので同じくらい悪く、同じ問題を抱えているが、Rubyには何十年もの間パッケージ管理システムが1つだけだったという違いはある
普通、Jupyterは柔軟なスクリプティングとOSコマンド対応の両方を提供しているように感じる
!/%やos.system()でも可能だこれはhttps://runme.devと非常によく似て見える
実行可能なドキュメントが好きで、まだ十分に多くないと思っている
面白そうだ
最近、Jupyterノートブックの代替としてhttps://marimo.io/を使い始めたが、いくつも改善点があり、これも似た方向の動きに見える
ローカルファーストなら、すでに腐敗（rot）の対象になっている
すべてをコンテナで実行するのでなければそうだし、コンテナで実行するならローカルであることは重要ではない
ランブックを記録したいなら、ただランブックを記録すればよい
テキストファイル、Confluence ドキュメント、画面録画、シェルスクリプトなど、方法はいくらでもある
人々はすでにそれをやっておらず、UI がより格好よくなったからといって急にやるようにはならないだろう
個人的には、システムを X 状態のようにするために一日中コードや文書を書きたくない
手動で X 状態を作ってからツールで状態をダンプし、後でそのツールをもう一度実行してその状態を作る、または強制したい
コンピュータがその状態に到達する方法をコードで説明したくないし、名前が違うだけのコードである宣言的設定も使いたくない
自分でやって、スナップショットを取り、再生したい
Bash シェルコマンドを監視するような依存なしに、どこでも、どんなシステムでも動作すべきだ
Dockerfile は実質的にこれに似ているが、その状態に到達するためにたどった手順をファイルとして文書化している
https://linux.die.net/man/1/autoexpect
そのくらいなら、X 状態に到達するために必要な手順へ自動変換できる宣言的な記述がすでにあるほうがよい
パッケージがインストールされているか、ファイルが存在するか、または特定の内容を持つかといった一般的な作業にはモジュールを使い、宣言的で冪等的だ
Atuin CLI と同期サーバーのように、これもオープンソースになるのか気になる
製品化される予定なのか？
それでも発表されたのはうれしい
これがなぜ必要なのかよく分からない
私が見落としていることを説明してもらえる？なぜ単純なシェルスクリプトの代わりにこれを使うべきなのか？
複数の対象を担当するチームにいて、そのうちいくつかは非常によく知っていて頻繁に触るが、いくつかは存在をぼんやり知っているだけでほとんど触らない
後者に属する X が壊れる
X を実際に知っている人たちは全員、休暇中／死亡／会議中である
幸い、この状況で何をすべきかを説明する文書がある
ところがその文書は、どういうわけか古くて間違っているという悪い情報の奇跡を見せてくれる
これが解決しようとしている問題だ
作者と少し話したところでは、意図は Jupyter Notebooks と Ansible Tower の中間のようなものを作ることに近い
ドキュメント、スクリプト、指標を互いに近くに置き、何が間違っているのか、どう直すのか、直したことに効果があったのかをより簡単に分かるようにする方式だ
[1] 開示: atuin Discord の運営を手伝っている
だから “Runbooks That Run” なのだ
ある人たちは特定のワークフローやツールの流れが好きで、ただ作るのだ
十分な人に合えば市場性があるかもしれないし、ないかもしれない
個人プロジェクトでは、単にそうしたいから PHP のデプロイ手順を使っているが、自分で別途やる必要なく作業の 60% を処理してくれる
それに対するランブックはツールに組み込まれたタスクであり、サーバー全体のデプロイと同じ Git リポジトリにある
別のコマンドを覚えなければならない任意の場所やシェルスクリプトに入れたくはない
プログラマーにとってコードは、複雑さを避けて単純な関数型スタイルを保てば、本質的に自己文書化される
たまに「MySQL ユーザーを作成し、パスワードをローテーションし、関連サービスに新しいユーザー／パスワードの組み合わせを反映し、VPN の遮断に失敗していた可能性に備えて、解雇された従業員が認証情報を持つ以前のユーザーを削除する」といった単純な流れではない部分にだけコメントを付ければよい
夢見ているツールは、すべてのツールがターミナルインターフェースを提供し、頭の中にある文脈をすべて収めた巨大な本を作れるようになるものだ
Jira、Datadog、GitHub などを一画面に集めるようなものだ
各内部サービス用のコンポーネントを持つ社内 TUI フレームワークがあり、それをレゴのように組み合わせてパーソナライズされた TUI ダッシュボードを作れる、と想像してみるとよい
会社でサイドプロジェクトとして試す価値がありそうで、ものすごく大きな作業になるだろうが、面白そうだ
理想の世界では、すべてのサービス、ツール、アプリケーションが自分が使える API を提供してほしい
例えば冷蔵庫のドアが長時間開きっぱなしなら、API ポーリングや Webhook で検知し、Roomba API を使って閉めに行かせる、という具合だ
なぜできない？API の世界なのだから
開発は 1 年ほど止まっているようだが、だいたいそういうアイデアだ
https://wtfutil.com/