3 ms·

The native libraries just need to be included onto the fs. Every interpreted language out there is like this. Also, the gem install step can be done outside of

by eyberg 6y ago

The native libraries just need to be included onto the fs. Every interpreted language out there is like this. Also, the gem install step can be done outside of the unikernel and then have the artifacts loaded on. We have current ESXi VSphere support today - both for 6.7 and 7.0. There are some docs here: https://nanovms.gitbook.io/ops/vsphere https://nanovms.gitbook.io/ops/vsphere . When you deploy a unikernel it's packaged as a virtual machine so it's not like you are deploying a linux vm and then running this on top - you are deploying your application as it's own isolated vm and it is hardware accelerated. Without hardware acceleration the "cloud" wouldn't exist, however instead of running 2 layers of linux (hypervisor and guest) we recognize that we're virtualized and that we don't need an extra full blown linux running as guest.

core-questions 6y ago
Fantastic, I will try something out against the Vsphere. So I guess I'm creating a VM template with this, similar to what I'd do with Packer, and then theoretically I should still be able to use Terraform to spin one up. What about passing run-time configuration? Is that all supposed to just be built-in, or is a well-designed program expected to reach out and get it somehow (e.g. from Consul)? Am I supposed to bake in keys to give it access to things?
- eyberg 6y ago
  You can use terraform to spin it up but a lot of that becomes un-necessary as that is assuming you are deploying a linux vm or something similar. Packer itself would be totally replaced with something like OPS - https://ops.city https://ops.city as ops produces machine images for the various hypervisors - but to be clear - you don't have to use ops but nothing else gives you a cloud deploy in 2 min and 2 commands. OPS allows you to pass quite a lot of configuration related switches/options/etc: https://nanovms.gitbook.io/ops/configuration https://nanovms.gitbook.io/ops/configuration and config files that you need on disk can be copied in at build time too. Env vars and such can be injected as well. If you want to keep using a secret store like Vault that's totally fine and up to you and your application needs. As mentioned in the article some companies use volumes to rotate certs every few hours/day via volumes so the sensitive stuff is separated from deploys.

by eyberg 6y ago

core-questions 6y ago

Fantastic, I will try something out against the Vsphere. So I guess I'm creating a VM template with this, similar to what I'd do with Packer, and then theoretically I should still be able to use Terraform to spin one up. What about passing run-time configuration? Is that all supposed to just be built-in, or is a well-designed program expected to reach out and get it somehow (e.g. from Consul)? Am I supposed to bake in keys to give it access to things?

eyberg 6y ago
You can use terraform to spin it up but a lot of that becomes un-necessary as that is assuming you are deploying a linux vm or something similar. Packer itself would be totally replaced with something like OPS - https://ops.city https://ops.city as ops produces machine images for the various hypervisors - but to be clear - you don't have to use ops but nothing else gives you a cloud deploy in 2 min and 2 commands. OPS allows you to pass quite a lot of configuration related switches/options/etc: https://nanovms.gitbook.io/ops/configuration https://nanovms.gitbook.io/ops/configuration and config files that you need on disk can be copied in at build time too. Env vars and such can be injected as well. If you want to keep using a secret store like Vault that's totally fine and up to you and your application needs. As mentioned in the article some companies use volumes to rotate certs every few hours/day via volumes so the sensitive stuff is separated from deploys.