gaulthiergain
commented
5 years ago Yes, it is the idea of Unikraft/UNICORE. Its purpose is to help users by considerably decreasing the development time that arises from the development of unikernels. It will include a set a tools to gather dependencies from existing application(s) and build a unikernel for one or multiple target platform(s) (e.g., a hypervisor such as Xen or KVM). Furthermore, the tool will use the dependencies to select the relevant micro-libs, link them against the app and produce a unikernel image which can be deployed using standard provisioning tools such as Openstack, Docker, or Kubernetes. Finally, the unikernel will be automatically profiled and the configuration parameters for the micro-libs changed to improve performance, in an iterative process driven by the optimization tool.
Your comparisons concerning Unik and HermiTux are right. The key idea behind Unikraft/UNICORE is to automatically create specialized, purpose-built virtual machines without "any" or very few interaction. Therefore, the automatic download of Unikraft will be integrated to a next iteration of the toolchain.
The goal of this project is to succinctly decrease the development time that arises from the creation of unikernels so much so that the entire process is abstracted away from the developer. To this end, the tool also largely targets operators who deploy software. In this issue I propose also downloading
unikraft/unikraftas well as any auxiliary libraries in aim of decreasing the overhead in building a self-contained unikernel image of the target application.Whilst it's no secret that developing unikernels requires time and effort which are a non-neglible cost to the developer and to the development time, the current approach found in the unicore toolchain is largely convoluted by the facilities presented in its CLI and auxiliary programs necessary to accomplish the compilation of a unikernel. Hence this proposal. :)
It's also no secret that this type of project been attempted before, namely and initially by unik which attempts to abstract much of the process of building unikernels with Dockerfiles which contain the toolchain and relevant sources and tools of other libOS projects by targeting the application's source code's primary language. This approach, however, still relies on the developer (and not the operator) to be aware of build process of the unikernel since the appliance's source code is tightly coupled with the selected libOS.
With Unicore, the approach appears to resemble the work done by HermiTux where a binary is statically analysed in aim of including the necessary libraries and pairing them with libraries compatible within the Unikraft framework. Whilst HermiTux was able to discuss generally the approach in "binary rewriting" and introducing a method hooking functitonality between return calls without changing the filesize (which I believe is important in the ELF header format -- please correct em if I'm wrong) the downfall was, subsequrntly, largely reliant on calling shared library functitonality. Thus not formaly, in my opinion, a "unikernel" that which si completetly encapsulated, itself, itsown, and with its needs and depdenencies it relies on. I believe this is the aim with Unicore where relevant application requirements are included into the OS image. In addition to this, HermiTux and HermitCore do not target Xen as a PV guest, where Unikraft does.