How to set up a development environment?
Opened this issue · 3 comments
How should I set up my development environment (which tools, CI etc.) to be able to build functional "local" versions of the pkgs like kubelet used in this project? - If I simply build the kubelet pkg using 'docker build .' , put its id into yml/kube.yml and build new image it seems that the files and folders like '/var/lib/kubeadm' which are created by other service containers are not visible.
I'd be happy to help on fixing issues like #71 and #72 but first I need to get a working development environment. :)
You should use linuxkit pkg build «path» not docker build «path», that will incorporate the settings from build.yml and produce a working package. You can install the tool from the linuxkit/linuxkit repo, or brew, I think.
You might like to use the --dev flag which will build a $USER/$pkg:dev instead of linuxkit/$pkg:$HASH. Otherwise you might find linuxkit pkg show-tag handy for extracting the right tag to use.
For CI you can use rtf (installed by linuxkit/linuxkit repo, or perhaps brew too?) then cd tests && rtf run will do a smoke test of the 4 combinations or runtime and network, or you can give the name of a specific test to run to speed things up (or just build and boot manually for debug).
linuxkit pkg build «path» was the missing trick. Thanks for advise! This took me at least one step further.
It seems that doing such a simple step as adding a file in to this system is not as straight forward as I first thought; thanks to binds, mounts and files - What would be the best way to get understanding how and which files and folders are linked together and in which order that happens (what overwrites what) ?
What would be the best way to get understanding how and which files and folders are linked together and in which order that happens (what overwrites what) ?
I'm afraid there's no magic bullet for this (or any docs, sorry!). Your best bet is probably to boot a system and have a poke around using ctr to enter the various container environments and looking at /proc/xxx/mountinfo and friends.