Weekly LinuxKit dev report for 2017-06-26 to 2017-07-02 (week 26) This report covers weekly developments in the, and repositories. This week, we welcome Avi Deitcher as an official maintainer to the project! The SIG security agenda for 2017-07-05 is now up, with @nduaten due to talk about his Memorizer project, which he also plans to add as a LinuxKit project soon. ( ) Vultr provider: A Vultr.com provider and example is now available in the mainline tree.

( ) Auditing: The auditd userspace components responsible for writing audit records to the disk are now containerised. ( ) Improvements to kernel build: ( ). If a package or the kernel is built from a dirty git repository, add -dirty to the tag and disallow pushing to hub ( ). If the latest commit has a tag, also push an image to hub as /. This should allow us to simplify YAML files once we introduce releases. For packages, don't build the package if it already exists on Hub.

This was already done for the kernel, but for packages, the check was only performed on push. This should make it easier for CI to just attempt to build all packages. For kernel build, merge the sign target into push.

This brings it in line with the package and other builds which do not have a sign target. Update kernels to 4.11.8/4.9.35/4.4.75 ( ) Gettying more obvious: the effort to make it more obvious that Getty and Sshd are namespaced and not running on the host namespace is now merged ( ). We also now ensure ctr works in the getty container ( ) Qemu wih KVM: There is a -enable-kvm option in the linuxkit cli to force (attempted) use (or not) of KVM ( ) Packaging and Blueprints The Docker for Mac Blueprint continues to integrate customisations from the downstream use within Docker:.

Linuxkit/docker-for-mac.yml At Master Linuxkit/linuxkit Github Account

Previously in Docker for Mac we run fstrim /var every 15 minutes from cron to reclaim space. If an image is deleted then it can take a long time for the space to be freed on the host.

LinuxKit now has a helper which watches for Docker events and triggers an fstrim after an image delete. If a batch of image deletes happen within 10s (e.g.

As part of a docker system prune) then only one fstrim will be issued. ( ). Add support for exposing swarm service ports ( ). Add pkg/chronyd and update DfM blueprint ( ). Update Docker CE to 17.06.0 ( ). Bind /etc/docker/daemon.json in examples/docker.yml ( ).

Split DfM blueprint in base and docker yml ( ) Projects The MirageSDK project development continues, with support for a new file descriptor sharing daemon that allows linked containers to drop even more privileges while transmitting data securely between each other. ( ) The overall RFC for point-to-point channels between containers is also available for review and comment ( ). There is also a yml example on how to use fdd to create container channels ( ). Docs and Testing. Makefile: bump rtf version ( ).

Linuxkit/docker-for-mac.yml At Master Linuxkit/linuxkit Github Tutorial

Update AUTHORS ( ). Makefile: Fix bug where network was not disabled ( ). Use custom-2-5120 as recommended by Google ( ). Add timestamps to LinuxKit build logs ( ). Re-add to rebuild ACL ( ). Fix test sorting for mixed tests/subgroups ( ) Other reports in this series can be browsed directly in the repository at.

In my previous blog post I wrote how to build, boot and connect to an OpenSSH server with Docker's toolchain. We now take that to the next logical step which is to package an application with a secure, immutable OS to create an appliance. An appliance is an application in a box that can be deployed to a hypervisor.

In this case we get a bootable image that will work on the cloud, bare metal, our laptop or Docker itself. It can be deployed and booted up in seconds. Pre-requisites I suggest running through (which takes 10 minutes) before proceeding. This will build the Moby and LinuxKit toolchain that is required for the tutorial. This tutorial is designed to be run on Docker for Mac. Minio Minio is an open-source object storage offering which has an API compatible with S3. This means you can take advantage of existing on-prem resources or just bring portability to your storage solutions.

Minio can also be used as a back-end to store. If you'd like an introduction on how to deploy and use Minio, read my tutorial: Putting together the pieces Minio already packages and maintains the server component through their Docker Hub account. We'll use the edge release for all the latest features. If you've not seen Minio before, you can run an S3 server in Docker like this: # docker run -name s3 -p 9000:9000 -v /exports/exports -d minio/minio:latest server /exports You can then use the Minio client utility or your normal S3 client libraries to read/write objects. A UI is also exposed on port 9000. Login/authentication is done through a secret and access key printed to the console when the Minio assembly boots up.

You can find the start-up logs like this: # docker logs s3 1. Build a YAML file Step one is building a YAML file for a base system.

We'll start with the test/test.yml file from the LinuxKit repo and just add in the parts we need for Minio. The LinuxKit format is a technical specification and it's very new - so as a community I'd say we're still getting used to how to read and edit it.