So, our next talk is going to be about...
Hello, I'm Kohei Tokunaga from NTT Corporation.
I'm a reviewer of container D and a maintainer of Build Kit.
And today, I'm going to talk about an extension of VS Code on Browser for running containers within the browser.
So, this is the summary of this talk.
So, on Browser VS Code lacks Linux terminal running completely inside browser.
And VS Code container wasn't.
Extention enables to run Linux-based containers and its terminal inside browser.
And there are two options available for distributing containers to browsers.
First one is pre-converting containers to wasn't images and distributing them.
And second option is distributing OCI container images to browsers.
So, there are several on Browser VS Code implementations in community.
There is a limitation for that functionality.
This is lack of Linux terminal running completely inside browser.
So, users can edit code inside browser but cannot run them inside browser.
And Linux-based development tools like CompilerS are also unavailable on browser.
And one of root causes for this issue is that browsers don't provide Linux compatible system.
So, Linux-based applications needs to be ported to browser.
If the application is written in language other than JavaScript, WebAssembly or wasn't will be...
will also be used for running them on browser.
But actually, porting apps to WebAssembly is not easy.
So, wasn't lacks compatibility to Linux system.
For example, the binary format is completely different from the existing common binary format like x86-ELEF.
And the app might need to be redesigned for Harvard architecture of wasn't.
So, this might include like eliminating fork and exact related cause from the application.
And some of the issues can be mitigated by CompilerS wasn't target support.
But they still don't provide full compatibility to Linux.
So, can we run a modified Linux terminal and Dev environment inside browser?
So, here VS Code container wasn't. Extension can be used.
This is an experimental VS Code extension for running containers inside browser.
So, the container and the terminal is available on VS Code on browser without preparing remote SSH servers or something.
And this is implemented, levelizing CPU emulators compiled to wasn't.
We will discuss about it later.
And the workspace of the editor is also mounted at slash workspace path.
So, container can refer to the contents on the workspace.
For example, it can compile the code stored on the workspace.
And HTTP or HTTPS networking is also available.
The container runs inside browser. So, the networking functionality is also restricted by browser.
For example, the set of accessible sites from the container is limited by calls.
So, how container images can be distributed to browsers?
There are two options. Option A is pre-converting containers to wasm images.
And option B is distributing OCI container images to browsers.
So, first option for distributing containers to browsers is pre-converting containers to wasm images.
And container to wasm converter provides this ability.
The container to wasm is an experimental converter of container images to wasm images.
It receives an arbitrarily Linux-based container as the input,
and it outputs a wasm image that runs the container on wasm.
So, we can run the containers on wasm-enabled environment like browsers.
As shown in the right figure, the converted wasm image can be uploaded to any HTTP server accessible from the browser.
To use them on VS Code on browser, you can configure the workspace using .vscode slash settings.json file.
And the image location URL to that configuration file.
And so, you need to add the image configuration URL to that configuration file
so that the extension can launch the specified container on browser.
And the pros of this approach is that once the container image is converted to wasm,
it can run on any wasm-enabled environment, not limited to browsers.
For example, the container can run on like washy run times, like wasm time as well.
And cons of this approach is pre-conversion is needed for each container.
If you want to run many kinds of containers on browser, all of them need to be pre-converted to wasm,
so it may take extra cost for development time.
And second option for distributing containers to browsers is to directly
distributing OCI-compatible container images to browsers.
If you use container registry, that registry needs to allow code access from the browser because it's accessed from the browser.
But unfortunately, as of now, well-known public registries don't allow codes,
but so you need to try it on local house registry with code header configured.
Alternatively, you can also use codes-enabled HTTP or HTTPS server.
In this case, the container image needs to be formatted as OCI image layout.
This is the specification of layout of image content to be stored on the file system.
For example, you can get a tar archive of this format using toka-save command newer than v25.
And vscode container wasm supports fetching the image formatted with this spec over HTTP.
In neither case, the image location needs to be written to the workspaces.vscode.settings.json file
so that the extension can launch the specified container on browser.
The pros of this approach is that this doesn't require a pre-conversion of the image,
and a modified container image can be distributed to browsers.
And cons of this approach is that obviously existing public container registries don't allow codes as of now.
So if you don't use OCI layout approach, you need to prepare codes-enabled container registry
or users need to use like a proxy or something to access to the registries.
And this is an example of running container on github.dev.
This is github.dev is an on-browser vscode that allows us editing codes of github-reports on-browser.
This slide shows an example of running gcc installed devian container inside browser,
and workspace is mounted at slash workspace, and HTTP or HTTPS networking is also available.
And so this is a demo for this extension, and we use github.dev here.
And that.
Okay, so here, this is the extension of container wasm, and this is available on Marketplace.
And this is the settings.json file in this repo, and this config file points to the URL of the devian container
converted to wasm using container to wasm converter, and this is served on github pages,
and we use that image on this workspace.
And this is the terminal of the devian container running inside of the browser.
And this is a secret we are going to use in this demo.
And currently, yeah, by executing a command of this extension, this extension quickly loads the image,
and the container image stored on github pages to this browser, and it just booted the Linux kernel and container inside browser with cpu emulation.
And we currently see the devian shell in the browser.
And by executing your name a command, you can see this is the x8664 and Linux environment inside browser.
And this workspace of this, this workspace of this repo is mounted at slash workspace slash, so you can see the files of this repo inside browser, mounted on workspace directly.
And in this container, we have gcc compiler, and we have a hello world pretty simple clanguage source code, so we can compile that c code inside browser using gcc compiler.
Then we can run the compiled binary on browser. So the entire compiling and running steps are done inside browser in this demo.
So how this extension works, the container depends on Linux to learn, so this project runs both of container and Linux inside wasm VM on browser.
And to enable run existing architectures binaries inside wasm VM, we use cpu emulators compiled to wasm. We use box emulator for x8664 containers and tiny emu for risk 5 containers.
So this extension launches all of the emulator Linux kernel and the container inside wasm VM on browser. And we also use microsoft slash vs code dash wasm for wasm and wasm host on browser.
So this is a wasm host integrated to vs code, so this allows wasm VM to access to the terminal on vs code and the workspace directly over wasm compatible APIs like fd APIs.
And how mounting workspaces to containers works. So as mentioned in the previous slide, we use vs code dash wasm for the wasm host and it provides the access to the workspace directly to the wasm VM over wasm compatible APIs.
And emulator running inside wasm VM recognizes workspace directly via wasm APIs, then it shares that directly into the guest Linux via vortio9p.
And that workspace is mounted to the containers slash workspace slash directly so the container can access to the workspace on that file system path.
And container can perform HTTP or HTTPS networking with restrictions by browser. So this is implemented by running the entire networking stack runs inside of the browser.
So additional proxy outside of the browser is not needed. And this networking stack supports forwarding HTTP and HTTPS connection to the outside of the browser using fetch API of the browser.
And HTTPS connection is terminated at the networking stack on browser with its own certificate and the connection is re-encrypted by fetch API. So the container can access to the outside of the browser via HTTP, HTTPS proxy running inside of the browser.
And there are actually some important restrictions by fetch API including accessible sites are limited by browser so code restriction is applied.
And some headers are actually uncontrollable from the container because they are entirely controlled by browser.
And vscode container wasm allows fetching container image directly from remote location without pre-conversion to wasm. So this is implemented by fetching and unpacking the container image in browser.
The unpacked root file system of the container is mounted to the guest Linux via VARTA ION IP.
And not limited to on-browser IDEs, we believe there are some expected use cases or possible use cases of running containers or wasm or browser.
So first one is interactive on-browser Linux based demo. And second one is on-browser development and testing like this extension.
And also sandbox execution environment of containers and application debugger runable on-browser were recorded and replayed debugging.
There are some existing approaches for running unmodified applications on wasm. And I listed some of them here.
First one is V86. This is a x86 compatible on-browser CPU emulator by Fabia Hammer. And it supports wide variety of guest OSs like including Windows.
But it doesn't support for x86 64 now. And tiny emulator is a risk 5 and x86 emulator by Fabia Spillard. It can run on-browser and container to wasm converter actually uses this for risk 5 emulation.
But it doesn't support for x86 64.
And this project is still in a very early stage. So we expect further improvement.
First one is performance analysis and improvement. We heavily rely on CPU emulation. So I think we need to analyze the overhead and I think we need some improvement for it.
And possible integration will be with ELF Conf or ELF Conf. This is an AOT compiler of Linux.
And this is a 64 ELF to wasm by Masashi Yoshimura, my colleague from NTT Corporation.
So at LLVM, tomorrow my colleague Masashi also have this AOT compiler. So please check it out.
And the integration of container ecosystem with browsers is also needed. As I mentioned, container has call to the solution.
So currently accessing OS package repos from browser is not possible. And also in terms of container registries, as long as I know a public registries, container registries doesn't allow calls access.
So on this field, your help is really needed if you know some technologies or repos or registries that allows calls access, please let us know.
And graphic support is also on our milestone.
So this is the summary of this talk. On-browser VS code lacks Linux terminal running completely inside browser. And VS code container wasm, experimental extension is enables to run Linux-based containers and its terminal inside browser.
And there are two options for distributing containers to browsers. First one is pre-converting containers to wasm images. And second one is distributing OCI container images to browsers.
And that's all of my talk. Thank you very much.
Do you have any questions?
Yes.
Yes, please.
Can you run Firefox inside the container?
Okay, so the question was Firefox inside the container. So Firefox inside the container, inside Firefox. All right.
Yeah, I haven't tested yet. But yeah, I believe it's possible. But I don't find any practical use case for this, but I think it's possible.
Yes, of course.
Yes.
Sorry.
QM. Thank you for the question. The question was about using QMU alternatively for like a box and tiny Mule.
Yeah, I think this is very good question. And actually we have a, we have on container to wasm repo, we have an experimental branch that integrated QMU TCI to this extension.
And yeah, in terms of like a TCG, yeah, we haven't integrated yet. So TCI is completely, yeah, so TCG we need to wait for running the generated code.
So we, it is not obvious on wasm environment. But yeah, we are seeking for the way to integrate QMU into container to wasm. So this is, yeah, definitely on our milestone.
Yeah. Thank you very much.
Thank you very much.
Thank you.