| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Change-Id: I4d229d0f4a9142e3bd427a8e63733426f5ca5bd9
Reviewed-on: https://cl.fcuny.net/c/world/+/412
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
| |
|
|
|
| |
We add a new argument to the CLI to collect the path where we want to
publish the firecracker metrics.
|
| |
|
|
|
|
|
| |
To help working on this project in the future, let's try to install
dependencies and configurations with `make`. For now we know that we
need the firecracker binary, the CNI configuration and the CNI plugin
for TAP.
|
| | |
|
| |
|
|
|
|
|
| |
By specifying these options we can speed up the boot process from 0.9
second to 0.15 seconds. Without these options, the linux kernel spends a
few milliseconds probing the device, which is useless in our context
(see https://github.com/firecracker-microvm/firecracker/blob/main/docs/api_requests/actions.md#intel-and-amd-only-sendctrlaltdel)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The binary needs a few more arguments: the path to the firecracker
binary, the path to a linux kernel.
Using the image that was generated, we can now boot the VM with
firecracker. This will rely on a CNI configuration to create the
network, and will use the provided kernel to boot.
|
| |
|
|
|
|
|
|
|
| |
Add a target to the Makefile to download a version of firecracker and
extract it under the repository hack/firecracker. We will then use this
binary for running the VM.
Add a CNI configuration under hack/cni. This configuration will need to
be copied to `/etc/cni/conf.d`.
|
| | |
|
| | |
|
| |
|
|
|
| |
When reading the configuration for the container, if there's an error we
return the error to the caller.
|
| |
|
|
| |
Add a workflows to perform some validation when pushing new commits.
|
| |
|
|
|
|
|
|
|
| |
Once we will be ready to boot our VM, we will need an init script in
place. For this, we create a simple shell script which we populate using
the environment variables and command extracted from the container.
The init script is stored in /init.sh within the new image, and we will
configure the boot parameter to find it there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We create a loop device by pre-allocating space to a file on disk. This
file is then converted to an ext4 partition, which we mount to a
temporary path on the host.
Once this is done, we extract all the layers from the given container on
that mounted path. We also add a few extra files to the image
(`/etc/hosts` and `/etc/resolv.conf`).
When we're done extracting and writing, we run resize2fs in order to
resize the image to a more reasonable size.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This will ensure that our container will not be deleted while we work on
it. In addition, a default expiry of 24 hours will be set on it once the
lease is released (once the program is completed).
See [1] for more details.
[1] https://github.com/containerd/containerd/blob/261c107ffc4ff681bc73988f64e3f60c32233b37/docs/garbage-collection.md
Signed-off-by: Franck Cuny <franck@fcuny.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pull an image provided as an argument to the program. We're only
interested in images for Linux/amd64 at the moment.
We setup a default namespace for containerd named `c2vm`. Images that
will be pulled by containerd will be stored inside that namespace.
Once the program is build it can be run like this:
```
; sudo ./c2vm -container docker.io/library/redis:latest
pulled docker.io/library/redis:latest (38667897 bytes)
```
And the image is indeed in the namespace:
```
; sudo ctr -n c2vm images ls -q
docker.io/library/redis:latest
```
|
| | |
|
| |
|
