HI, I am currently using virtual box and dowloaded a fedora iso on my Mac so that i can run a jar on that and test it on a linux box. I recently heard about docker.

And also that you dont need large iso files for linux like the way you do in virtual box. You have small images here. I have setup my docker terminal. I want to replicate what i use to do in Virtual box for a fedora iso file. Linux terminal. Here are the things i did in the linux terminal there: 1) Set up github 2) checkout your repo 3) run mvn package rpm:rpm This basically builds a jar file and packages it in rpm 4) yum install (the generated rpm) My rpm created a user and ran the jar file as a daemon with that user.

This rpm will start a web application on 8080 Is it possible to do that with docker? How can i install a fedora image and then run the above things there? Please guide n give some commands and steps. Also am i using docker for the right thing here or is it better to download that big iso file and run my java application there?

Linuxkit is a new project presented by Docker during the DockerCon 2017. If we look at the description of the project on: A secure, portable and lean operating system built for containers I am feeling already exited.

I was an observer of the project when and the other was working on a private repository. I was invited as part of ci-wg group into the CNCF and I loved this project from the first day.

You can think about linuxkit as a builder for Linux operating system everything based on containers. It’s a project that can stay behind your continuous integration system to allow us to test on different kernel version and distribution. You can a light kernels with all the services that you need and you can create different outputs runnable on cloud providers as Google Cloud Platform, with Docker or with QEMU. Continuous delivery, new model I am not really confident about Google Cloud Platform but just to move over I am going to do some math with AWS as provider. Let’s suppose that I have the most common continuous integration system, one big box always up an running configured to support all your projects or if you are already good you are running containers to have separated and isolated environment.

Let’s suppose that you Jenkins is running all times on m3.xlarge: m3.xlarge used 100% every months costs 194.72$. Let’s have a dream. You have a very small server with just a frontend application for your CI and all jobs are running in a separate instance, tiny as a t2.small. T2.small used only 1 hour costs 0.72$.

I calculated 1 hour because it’s the minimum that you can pay and I hope that your CI job can run for less than 1 hour. Easy math to calculate the number of builds that you need to run to pay as you was paying before. 194.72 / 0.72 270 builds every month.

If you are running less than 270 builds a months you can save some money too. But you have other benefits:. More jobs, more instances. Very easy to scale. Easier that Jenkins master/slave and so on. How many times during holidays your Jenkins is still up and running without to have nothing to do? During these days you are just paying for the frontend app.

And these are just the benefit to have a different setup for your continuous delivery. LinuxKit CI implementation There is a directory called that contains some linuxkit use case but I am going to explain in practice how linuxkit is tested.

Because it uses itself, awesome! In first you need to download and compile linuxkit. $ moby Please specify a command. USAGE: moby options COMMAND Commands: build Build a Moby image from a YAML file run Run a Moby image on a local hypervisor or remote cloud version Print version information help Print this message Run 'moby COMMAND -help' for more information on the command Options: -q Quiet execution -v Verbose execution At the moment the CLI is very simple, the most important commands are build and run.

Linuxkit is based on YAML file that you can use to describe your kernel, with all applications and all the services that you need. Let’s start with the. Virtio-net-vpnkit: initialising, opts='path=/Users/gianlucaarbezzano/Library/Containers/com.docker.docker/Data/s50' virtio-net-vpnkit: magic=VMN3T version=1 commit= Connection established with MAC=02:50:00:00:00:04 and MTU 1500 early console in extractkernel inputdata: 0xf2c3b4 inputlen: 0x67b1e5 output: 0x000000 outputlen: 0x595280 kerneltotalsize: 0x18a000 booted via startup32 Physical KASLR using RDRAND RDTSC.

Virtual KASLR using RDRAND RDTSC. Decompressing Linux. Performing relocations.

Booting the kernel. 0.000000 Linux version 4.9.21-moby (root@84baa8e89c00) (gcc version 6.2.1 20160822 (Alpine 6.2.1) ) #1 SMP Sun Apr 9 22:21:32 UTC 2017 0.000000 Command line: earlyprintk=serial console=ttyS0 0.000000 x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' 0.000000 x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' 0.000000 x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' 0.000000 x86/fpu: xstateoffset2: 576, xstatesizes2: 256 0.000000 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. 0.000000 x86/fpu: Using 'eager' FPU context switches. 0.000000 e820: BIOS-provided physical RAM map: 0.000000 BIOS-e820: mem 0x000000-0x09fbff usable 0.000000 BIOS-e820: mem 0x100000-0x000000003fffffff usable When the VM is ready LinuxKit is starting all the init, onboot, the logs is easy to understand as the test.yml is starting containerd, runc. Welcome to LinuxKit ##.

## ## ## ## ## ## ## ## /' / / - o / / / / # INFO0000 starting containerd boot. Module=containerd INFO0000 starting debug API. Debug='/run/containerd/debug.sock' module=containerd INFO0000 loading monitor plugin 'cgroups'. Module=containerd INFO0000 loading runtime plugin 'linux'. Module=containerd INFO0000 loading snapshot plugin 'snapshot-overlay'. Module=containerd INFO0000 loading grpc service plugin 'healthcheck-grpc'. Module=containerd INFO0000 loading grpc service plugin 'images-grpc'.

Module=containerd INFO0000 loading grpc service plugin 'metrics-grpc'. Module=containerd The last step is the check that runs the real test suite. Kernel config test succeeded!

Info: reading kernel config from /proc/config.gz. Generally Necessary: - cgroup hierarchy: properly mounted /sys/fs/cgroup - CONFIGNAMESPACES: enabled - CONFIGNETNS: enabled - CONFIGPIDNS: enabled - CONFIGIPCNS: enabled - CONFIGUTSNS: enabled - CONFIGCGROUPS: enabled - CONFIGCGROUPCPUACCT: enabled - CONFIGCGROUPDEVICE: enabled - CONFIGCGROUPFREEZER: enabled - CONFIGCGROUPSCHED: enabled.

Moby test suite PASSED ##. ## ## ## ## ## ## ## ## /' / / - o / / / 3.578681 ACPI: Preparing to enter system sleep state S5 3.579063 reboot: Power down The last log is the output of files. If you are on linux you can do the same command but by the default you are going to use an open source machine emulator. /usr/bin/qemu-system-x8664 -device virtio-rng-pci -smp 1 -m 1024 -enable-kvm -machine q35,accel=kvm:tcg -kernel test-bzImage -initrd test-initrd.img -append console=ttyS0 -nographic By default is testing on x8664 but qemu supports a lot of other archs and devices. You can simulate an arm and a rasperry pi for example.

At the moment LinuxKit is not ready to emulate other architecture. But this is the main scope for this project. It’s just a problem of time. It will be able soon! Detect if the build succeed or failed is not easy as you probably expect. The status inside the VM is not the one that you get in your laptop.

At the moment to understand if the code in your PR is good or bad we are parsing the output. Define checktestlog @cat $1 grep -q 'Moby test suite PASSED' endef Explain how linuxkit tests itself at the moment is the best way to get how it works. It is just one piece of the puzzle, if you have a look here has a GitHub Status that point to a website that contains logs related that particular build.

That part is not managed by linuxkit because it’s only the builder used to create the environment. All the rest is managed. I will speak about it probably in another blogpost. Conclusion runc, docker, containerd, rkt but also Prometheus, InfluxDB, Telegraf a lot of projects supports different architecture and they need to run on different kernels with different configuration and capabilities.

They need to run on your laptop, in your IBM server and in a Raspberry Pi. This project is in an early state but I understand why Docker needs something similar and also, other projects as I said are probably going to get some benefits from a solution like this one. Have it open source it’s very good and I am honored to be part of the amazing group that put this together. I just did some final tests and I tried to understand how it’s designed and how it works. This is the result of my test.

Using Linuxkit Generated Iso In Docker For Mac

I hope that can be helpful to start in the right mindset. My plan is to create a configuration to test InfluxDB and play a bit with qemu to test it on different architectures and devices. Stay around a blogpost will come! Some Links:. Reviewers.