about summary refs log tree commit diff
path: root/users/fcuny/exp/containerd-to-vm (follow)
Commit message (Collapse)AuthorAgeFilesLines
* boot the VMFranck Cuny2022-06-113-4/+256
| | | | | | | | | 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.
* hack: firecracker binary and CNI configurationFranck Cuny2022-06-113-0/+35
| | | | | | | | | 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`.
* git: ignore binaryFranck Cuny2022-06-111-0/+1
|
* add MakefileFranck Cuny2022-06-111-0/+3
|
* check for errorFranck Cuny2022-06-111-0/+3
| | | | | When reading the configuration for the container, if there's an error we return the error to the caller.
* github: add workflowsFranck Cuny2022-06-111-0/+35
| | | | Add a workflows to perform some validation when pushing new commits.
* inject a script for initFranck Cuny2022-06-111-0/+43
| | | | | | | | | 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.
* extract layers to a mounted loop deviceFranck Cuny2022-06-113-1/+128
| | | | | | | | | | | | | 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.
* add a lease to the Go contextFranck Cuny2022-06-111-0/+6
| | | | | | | | | | | | 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 a container into a namespaceFranck Cuny2022-06-114-0/+975
| | | | | | | | | | | | | | | | | | | | 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 ```
* doc: update READMEFranck Cuny2022-06-112-1/+15
|
* Add README.md, LICENSE.txtFranck Cuny2022-06-112-0/+21