仮想化ソフトウェアの1つQEMUのターゲットとしてx86_64、QEMUで作成した仮想マシンのゲストOSとしてCoreOSを起動する方法について記します
尚、明示的にQEMU及び関連コマンドを実行する必要はありません。
インストールしてもよいのですが、今回は、CoreOS 472.0.0のQEMU(qcow2)ディスクイメージを使用させて頂きました。
Version: | CoreOS 472.0.0 |
Kernel: | 3.16.2 |
Docker: | 1.3.0 |
etcd: | 0.4.6 |
fleet: | 0.8.3 |
CoreOS(CentOSではない)のサイトの説明によるとCoreOSは、近代的なインフラ(基盤)を実行するのに必要となる機能を提供する為に再設計されたApache 2.0ライセンスで配布される新たなLinuxディストリビューションであり、その戦略とアーキテクチャーは、高い柔軟性とスケールでサービスを展開するGoogle、Facebook、Twitterのような企業及びサービスなどに影響を与えるものであるとあります。
機能を絞り込んだCoreOS自体は、カーネルとユーザーランドを含め、60MB程度であり、CPU1GHz以上、RAM1GB以上もあれば、既存の物理的なPCなどのハードウェアや仮想マシンでも、一方でクラウド環境でも利用できます。
CoreOSにおいて構築するブロックは、主にDockerやアプリケーションと実行するコードから成るLinuxコンテナエンジンであり、Dockerは、各CoreOSマシンごとにそれぞれインストールされます。
要するに1つのCoreOS上で完結させるのではなく、CoreOS上に特定のサービスを構成、各種サービスを構成したCoreOS(から成るコンテナ)を複数起動、連携させることが想定されています。
より具体的には、[etcd]に読み書きすることによってCoreOS上にWEBサーバやデータベースサーバなど提供したいサービスごとにセットアップ、最終的なartifact(成果物)を基準として開始させるために必要となるコンテナを構成、管理する為に[systemd]と[fleet]と共にコンテナを開始する必要があり、サービスを提供する各コンテナ(内のCoreOS)には、sshを利用してリモートでアクセスする前提となっています。
こうしたことから、先の通り、CoreOS自体は最小限の構成にするなど軽量化が図られています。
尚、CoreOS自身は、パッケージマネージャを持っていないため、利用したいソフトウェアがある場合には、コンテナ内で実行しなければならないとあります。
CoreOSが最後に掲げる目標としては、最終的な成果物としてコンテナを出力するビルドシステムを持つことのようです。
Dockerは、2014年06月にバージョン1.0が、執筆時点では、先週(2014年10月16日)にDocker Engine 1.3がリリースされた物理マシン上のOSとは隔離してOS環境の構築やアプリケーションの実行環境を作り出す機能を持ち、コンテナと呼ばれるこの密閉空間に作成したOSやアプリケーションを自動的に展開/配置することも可能なアプリケーションです。
物理マシン上のOSと隔離できるという点でFreeBSDのjailやLinuxのchrootと対比されることもあり、また、一方で物理マシンのOS上で他のOSを実行できることからハイパーバイザー型仮想化ソフトウェアやホストOS型仮想化ソフトウェアとの対比でコンテナ型仮想化ソフトウェアとして捉えられることもあります。
What is Docker?によると
とあります。
ちなみにDockerは、登場当初から執筆時点においてもLinuxカーネルを共有する前提となっていることからDockerを起動、管理できるのは、実質Linuxのみとなっています。
CoreOSのシステム要件としてのメモリ量は、明記されていないようですが、これは、サービス込みでの稼動を前提とすることからでしょう。
尚、今回、QEMU(qcow2)用のイメージを実行するshellスクリプトを見るとVM_MEMORY="1024"とあるのでRAMには、デフォルトで1GBが割り当てられているということだと思いますが、相当の余裕を見てのことでしょう。
CoreOSのQEMU用ドキュメントにあるように次のようにすれば、最新の安定(Stable)版を入手することができます。
先のページのサンプルでは、実行許可を与えてスクリプトを[nographic]オプション付きで実行するようになっています。
ただ、デフォルトでは、KVM/Kernel-based Virtual MachineとQEMUの起動が前提となっており、KVMはLinux上でのみ実行できるという意味では、当サイト検証環境もFedoraなのでマッチしているわけですが、KVMのシステム要件上、Intel VT-x/AMD-Vなどハードウェア仮想化支援機能付きの32bitマシン、もしくは64bitマシンを前提としている為、当サイト検証環境のIntel VT-xのない32bit CPUでは、KVMを利用することができません。
とはいえ、KVMを利用せず、QEMUのみで実行する方法もあるはずと思い、当該shellスクリプトに[h]オプションを付けるとヘルプ表示されるようなので確認してみることにしました。
すると[s]オプション付きで実行すれば、ハイパーバイザであるKVMを使うことなく、シングルCPUとして使えるようなので同一、または、異なるCPUアーキテクチャを実行可能なQEMUだけでいけそうです。
ということで、ここでは、当該shellスクリプトに実行許可を与え、[-s -nographic]とオプションを2つ付けて実行しました。
ログインプロンプトが出るまでは、少し時間がかかりますが、プロンプトが出てきてもその端末上では、ログインしません。
なぜなら、前述の通り、CoreOSでは、SSH/Secure SHellによるリモート接続を前提としているからです。
尚、CoreOSへのssh接続では、パスワードによる認証は利用できず、DSA認証やRSA認証を使用する必要があり、先のページには、[ssh-keygen]の説明があり、これを実行するとデフォルトでは、[~/.ssh/id_dsa.pub]、[~/.ssh/id_rsa.pub]などが生成され、このパスは、ssh実行時に探索され、認識されるとあります。
あとは、CoreOSのログインプロンプトが表示されたら、他の端末を使うなどして先のページの例にもあるようにsshコマンドを実行してログインします。(実行すべき特定の場所はなく、不問。)
PC起動後の初回の起動においては、CoreOSとは別に管理者パスワードを求められる場合がありますが、これで冒頭のスクリーンショットにもあるようにこんな感じでログインできるはずです。
もし、できない場合には、端末を全て閉じてから、再度、shellスクリプトを実行し、CoreOSを起動、他の端末からssh接続してみるとよいでしょう。
ちなみにCoreOSのデフォルトとしてユーザーは[core]、パスワードは[未設定]、ポートは[2222]、ホスト名は[localhost]となっており、このsshコマンドは、ユーザー[core]、ポート[2222]経由で[localhost]にssh接続することを意味します。
CoreOSにおけるデフォルトのログインシェルは、bashです。
/etc/shellsを見ると結構多くのshellが利用できるようになっています。