27 ポイント 投稿者 GN⁺ 2024-03-08 | 2件のコメント | WhatsAppで共有
  • Dockerイメージを独立実行型のポータブルなバイナリにコンパイルするツール
  • ユーザーに docker runpip installnpm i などのコマンドなしで実行可能なバイナリを提供可能

特徴

  • Dockerイメージを移植可能なバイナリにコンパイル。
  • root権限が不要なコンテナ。
  • macOSとWindowsをサポート予定(QEMUを使用)
  • x86_64をサポート(arm64は対応予定)
  • 引数をサポート
  • -e を使った環境変数指定をサポート。
  • -v を使ったボリューム指定をサポート。

使い方

  • 最新リリースからdockercをインストール。
  • Docker Hubのイメージ、またはローカルDockerデーモンストレージのイメージを使って出力バイナリを生成。
  • 生成されたバイナリは通常のバイナリのように呼び出し可能。
  • -e-v オプションを docker run 使用時と同じ方法で指定可能。
  • コンテナ内で実行されるネットワークサービスに直接アクセス可能で、-p の指定は不要。
  • イメージの読み込みにはSkopeoを使用。その他の場所については該当ドキュメントを参照。

GN⁺の意見

  • dockercはDockerの使い勝手を大きく向上させる可能性があるツールで、複雑なインストール手順なしにアプリケーションを実行できるようにする。これは特に非技術者にとって非常に有用となり得る。
  • Dockerイメージをバイナリにコンパイルする機能は配布とデプロイを簡素化し、開発者やシステム管理者に時間の節約と効率性をもたらす。
  • ただし、この技術が広く採用されるには、セキュリティ、性能、互換性に関する問題が十分に解決される必要がある。たとえば、コンパイルされたバイナリが元のDockerイメージと同程度に安全か、あらゆるシステムで円滑に動作するかといった検証が必要。
  • Dockerと似た機能を提供する別のプロジェクトとしてPodmanがあり、これはroot権限なしでコンテナを実行できる機能を提供する。
  • dockercを導入する際には、既存のDockerワークフローとの統合、イメージの更新および管理方法、そしてコンパイルされたバイナリのサイズや性能などを考慮する必要がある。この技術を選ぶことで得られる利点は、配布の簡素化と使いやすさだが、一方でコンパイル過程で発生し得るオーバーヘッドや潜在的な互換性問題を慎重に考慮すべきである。

2件のコメント

 
cosine20 2024-03-11

おお、かなり興味深いですね。

 
GN⁺ 2024-03-08

Hacker Newsの意見

  • これは本当にすごい。

    • あるユーザーは、自分の Docker をもっと配布しやすくしようとしている。現状では、QEMU コンテナの中の Docker コンテナの中の Python 環境にある単純な Python スクリプトでクリックを自動化し、netcat を使っている。ファイルサイズは 20GB で、現代の基準ではかなり軽量。
  • 以前、私は nix-bundle¹ やその公式対応版である nix bundle² を使って勧めていた。

    • これらのツールを使うと、Docker イメージを直接管理する段階を省ける。特に Docker イメージの作成が難しかったり、その手順が忘れられた秘術のようになっている場合に便利。
    • nix bundle は巨大な実行ファイルだけでなく、Docker イメージ、AppImage、そしていくつかの別形式のイメージ/実行ファイルも作成できる。
  • 内蔵 OS 付きのポータブル実行ファイルに戻るのは本当に良い。

    • 「自分のマシンでは動く」を、問題解決の新たな地獄のレベルへ引き上げている。それでもこのプロジェクトはすばらしい。
  • あるユーザーは、人々がこうしたものを動かす Docker コンテナを生成する Dockerfile を送り始めるのを待っている。

  • ここには壮大な宇宙的アイロニーがある。

    • ビルドやインストールなしで実行ファイルだけ欲しい、というセクションの直後に、このプロジェクトをビルドするための zig の呪文が続いている。
  • これはすばらしい進展だ、Nils! AGI House で話して以来、このプロジェクトの進捗を見られてうれしい。

    • dockerc は Zig + crun + squashfs/overlayfs を使っている。Nils(作者)がこのスレッドでもっと詳しい情報を共有していた。
  • 依然として、別アーキテクチャ向けには別のものが必要。

    • この時点では、静的コンパイルして仮想ファイルシステムを含めるほうがよいと思う。実質的には、これは 90 年代に Sun が作ったものと同じ。
  • 良いアイデアだ! これは実際にはどう動くのか?

    • あるユーザーは、これはカスタムローダー + Docker + イメージを実行可能バイナリに包んでいるのではないかと推測している。
  • ラントの図を使っているのが良い。

    • 次のラントの図は、「実行ファイルを実行したら、そのアプリケーションを含むウィンドウが開くべきだ」という内容になりそう。
  • これはどういう意味? Ruby をインストールしていないユーザーにも、ポータブルな Ruby 実行ファイルを配布できるようになるの?