Zenn
🗼

Docker ではじめる "ゼロからのOS自作入門"

2021/03/29に公開
Docker
MikanOS
devcontainer
tech

TL;DR

更新情報

  • 2021/03/31: 使い方 に参考記事のリンクを追加

概要

"ゼロからのOS自作入門", ついに発売されましたね！ "30日でできる！OS自作入門" にあまり馴染めなかった[1]私にとって, 待望の一冊でした. 張り切ってやっていきましょう！

環境構築つらい

張り切ってやっていく前に, まずは開発環境の構築が必要です.

本書の開発環境の設定には, EDK2 や qemu のインストール, clang や llvm などのツールのバージョン固定や, コンパイル済みライブラリの配置が必要みたいです.

筆者の方は, これらの設定を容易に行うために, github.com/uchan-nos/mikanos-build に, Ansible Playbook と, その適用手順を公開して下さっており, 環境構築も自動で行うことができます.

...できるはずでした.

Ansible もつらい

Ansible による環境構築にもつらい要素がたくさんあります. 私がとくにつらいと感じたのは以下の点です:

  • 日頃の行いが大事

    Ansible はシステムを直接操作するツールです. ローカルで Playbook を再生すれば, そのままローカルの環境に副作用を与えます. よって, 日頃の行いによって変更されたローカルの環境の状態によっては, Playbook を再生しても意図した開発環境が得られない可能性があります.

    私の場合はそもそも Ansible コマンドがエラー吐いて動かないので嫌になりました.

  • Playbook がディストリビューションに依存しすぎている

    Ansible Playbook でディストリビューション間の差異を吸収するのは大変です.

    例えば, 本書向けに配布されている Ansible Playbook では, Ubuntu への適用を前提として, apt パッケージマネージャを用いて build-essential パッケージをインストールしています.

    しかし, 用いる Linux ディストリビューションが変われば, パッケージマネージャもパッケージ名も変わります. 私がよく用いる Arch Linux では, デフォルトのパッケージマネージャは pacman ですし, build-essential パッケージは存在しません. 当然, 配布された Ansible Playbook をそのまま適用することはできません.

    これら Linux ディストリビューション間の差異を Ansible Playbook で吸収するのは非常に大変です.

Docker ですべて解決

面倒でトラブル続きな環境構築はやめて, Docker ですべてを解決しましょう！

と, いうわけで ゼロからのOS自作入門 (MikanOS) の開発環境を一瞬で展開できる Docker イメージを作りました:

sarisia/mikanos-docker

開発に使用するツールチェインをすべて設定済み, 環境構築無しですぐにOS自作に集中することができます. 本書の最終章終了時の MikanOS がビルド, 実行可能であることを確認しています.

使い方

VSCode devcontainer (推奨)

一番簡単で便利な方法です. devcontainer の設定ファイルを置いておけば, VSCode がコンテナをベースとした快適な開発環境を自動で設定してくれます.

詳細な使い方は GitHub ページを確認して下さい:

sarisia/mikanos-devcontainer

追記 (2021/03/31)

devcontainer の起動方法や, macOS での X11 Server の設定などが大変分かりやすく説明されている記事が公開されています. ありがとうございます！

「ゼロからのOS自作入門」の副読本的記事 | Zenn

追記終

Docker をそのまま使う

考えることが多く, 面倒なのであまりおすすめできませんが, イメージから直接コンテナを作成して作業することもできます. こんな感じで起動して下さい:

$ docker run --privileged -it ghcr.io/sarisia/mikanos /bin/bash
docker run --privileged -it ghcr.io/sarisia/mikanos /bin/bash
vscode ➜ ~ $

この他に, ホストディレクトリのマウントや作成したファイルのパーミッションなど, 面倒事が多いので本当におすすめしません…

QEMU + X11 で動作を確かめる

このイメージにはデフォルトで環境変数 DISPLAY=host.docker.internal:0 が設定されています. よって, ホストに接続を待ち受けている X11 Server が存在すれば, 自作OSを QEMU で起動した際に画面への出力を確認し, マウス・キーボードで操作することができます:

https://user-images.githubusercontent.com/33576079/112739400-29e73880-8faf-11eb-9f59-acca01470a62.png

ただし, Docker ホストが Linux の場合, 追加の設定が必要な可能性があります. 詳細はリポジトリのREADMEを確認して下さい.

何をやっているか

やっていることは至極単純で, 本書の筆者様が提供されている github.com/uchan-nos/mikanos-build の devenv/ansible_provision.yml を Dockerfile に手動で書き起こしただけです[2].

ただし, 筆者様オリジナルの環境と一部異なる点があります:

  • VSCode devcontainer 用の Ubuntu イメージ をベースにしています.
  • dosfstools , python3-distutils , qemu-system-gui をデフォルトでインストールしています.
  • $HOME/osbook/devenv に PATH を通しています.
  • X11 Server のアドレスのデフォルトとして環境変数 DISPLAY=host.docker.internal:0 を設定しています.
    • Docker Desktop for Windows (WSL2 Backend) でも for Mac でもいい感じに動きます.

メリット・デメリット

参考のため, メリットと共に, 思いつくデメリットも書いておきます.

メリット

  • 面倒でトラブル続きな環境構築からの解放
  • ホスト (ローカル) の環境を汚染しない
  • GitHub Codespaces で起動できる → どこでも開発できる！
    • QEMU GUI による動作の確認はできない...

デメリット

  • Docker (dockerd, Docker CLI) に依存する
  • イメージがデカすぎる (展開後で約2.5GB！)
  • Docker は Docker でめんどくさい
    • コンテナ内データの永続化, ホストとの通信, non-root user などなど...
    • devcontainer 最高！

まとめ

環境構築に消耗する日々を終え, やっと第3章に進むことができます. よかった.

今から "ゼロからのOS自作入門" を始める方も, 既に進めている方も, 是非お試し下さい！

それでは, 良いOS自作生活を！

参考

uchan-nos/mikanos-build: Build and run scripts for MikanOS

Developing inside a Container using Visual Studio Code Remote Development

docker run | Docker Documentation

Codespaces

脚注

  1. 開発の至るところで "筆者オリジナルツール" が多用されているのが馴染めなかった... ↩︎

  2. 本当は Ansible Playbook からコンテナイメージを作成したかったのですが, いろいろ試していい感じにならなかったので断念しました. そのうちリベンジ？挫折？記事に残しておきたい. ↩︎

Discussion