我最近部署了一个带有docker的小型Haskell应用程序,使用"scratch-haskell"作为基本映像.
然后我读到了关于Unikernels和HALVM的内容.我有点困惑.
我的码头工人容器大约6MB.Unikernel(使用相同的haskell应用程序)大小与我猜的大致相同.
Unikernel直接在Xen管理程序上运行,而docker Image(或通用LXC)在普通的Linux发行版上运行,该发行版在裸机上运行.
现在,我有"选择"运行具有多个最小容器的Linux或具有多个小Unikernel的Xen机器.
但这两种解决方案的优点和缺点是什么？一个比另一个更安全吗？它们之间是否存在显着的性能差异？
我不太明白,例如HaLVM或类似技术在(OS)线程方面做了什么.
我理解在使用-threaded选项编译代码时,Haskell多线程RTS将使用OS线程重新分配现有的Haskell线程,从而避免阻止外部调用的行为.现在,当您使用HaLVM时,您可能不必进行任何外来呼叫.但是,我想知道这一切是如何混合的,以及HaLVM运行的工作线程数.是否没有其他情况下OS工作线程的缺失可能导致阻塞或其他不良行为？
Docker如何与MirageOS等exokernal方法相关？
有关MirageOS的一些信息,请参阅:
有许多项目可以从您的应用程序生成完整的图像,可以在xen上作为计算机启动.例如Xen,OpenMirage,HaLVM等上的Erlang.
为什么Xen是他们的默认管理程序？它是否提供了一些使这些项目更容易的界面(与KVM,VmWare等相反),还是只是项目开发人员的选择？
我编写了一个简单的基于MirageOS的Unikernel来执行基本的HTTP GET调用.虽然当我将它作为Unix二进制文件运行时它没有任何问题,但是当我为XEN(mirage configure --xen)配置它并启动make命令时,我得到以下错误:
ocamlbuild -use-ocamlfind -pkgs lwt.syntax,cohttp.lwt,cohttp.lwt-core,mirage-console.xen,mirage-http,mirage-types.lwt -tags "syntax(camlp4o),annot,bin_annot,strict_sequence,principal" -tag-line "<static*.*>: -syntax(camlp4o)" -cflag -g -lflags -g,-linkpkg,-dontlink,unix main.native.o
+ ocamlfind ocamlopt -g -linkpkg -dontlink unix -output-obj -package mirage-types.lwt -package mirage-http -package mirage-console.xen -package cohttp.lwt-core -package cohttp.lwt -package lwt.syntax -syntax camlp4o unikernel.cmx main.cmx -o main.native.o
File "_none_", line 1:
Error: No implementations provided for the following modules:
Unix referenced from /home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_engine),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_unix),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_io),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_log),
/home/mirage/.opam/system/lib/ipaddr/ipaddr_unix.cmxa(Ipaddr_unix),
/home/mirage/.opam/system/lib/xenstore_transport/xenstore_transport_lwt_unix.cmxa(Xs_transport_lwt_unix_client),
/home/mirage/.opam/system/lib/conduit/conduit-lwt-unix.cmxa(Conduit_lwt_unix),
/home/mirage/.opam/system/lib/cohttp/cohttp_lwt_unix.cmxa(Cohttp_lwt_unix_debug),
/home/mirage/.opam/system/lib/cohttp/cohttp_lwt_unix.cmxa(Cohttp_lwt_unix)
Command exited with code 2.
Compilation unsuccessful after …海市蜃楼是使用OCaml而不是C的unix内核的新实现吗？或者海市蜃楼只在Ocaml中实现了unix内核的一部分？
谢谢.
我阅读本文档(http://openmirage.org/wiki/hello-world)并尝试构建一个xen unikernel,如下所示:
mirage configure --xen
make depend
make
但编译失败:
ocamlbuild -classic-display -use-ocamlfind -pkgs lwt.syntax,mirage-console.xen,mirage-types.lwt -tags "syntax(camlp4o),annot,bin_annot,strict_sequence,principal" -tag-line "<static*.*>: -syntax(camlp4o)" -cflag -g -lflags -g,-linkpkg,-dontlink,unix main.native.o
ocamlfind ocamldep -package mirage-types.lwt -package mirage-console.xen -package lwt.syntax -syntax camlp4o -modules main.ml > main.ml.depends
ocamlfind ocamlc -c -g -annot -bin-annot -principal -strict-sequence -package mirage-types.lwt -package mirage-console.xen -package lwt.syntax -syntax camlp4o -o main.cmo main.ml
ocamlfind ocamlopt -c -g -annot -bin-annot -principal -strict-sequence -package mirage-types.lwt -package mirage-console.xen -package lwt.syntax -syntax camlp4o -o main.cmx main.ml
pkg-config --print-errors …我是 unikernels 的新手，以下链接对我理解它们没有多大帮助：
最近，系统开发界对Unikernels感到兴奋。简而言之，Unikernel是将应用程序编译为独立的可引导操作系统，而不是现有操作系统中的进程的应用程序。
从像Google的Go这样的垃圾收集语言编译Unikernel是否有任何理论上的问题或实际的警告？