This is the final piece. If 'sources' are defined, tar up
the sources and rewrite them accordingly. Pass it as build
build context to 'docker'.
This allows building from something like this:
├── etc
│ ├── foo
└── foo
├── Dockerfile
├── build.yml
└── main.go
With 'build.yml':
image: foo
extra-sources:
- ../etc:etc
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This commit adds the ability to add a build context to
docker for the package build. The build context is passed
on stdin to the docker process.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If the build.yml specifies 'extra-sources', ie sources
outside the package directory, calculate the hash based on
the tree hash of all source directories and the package
directory.
Note, this requires the source directories to be under
git revision control.
Also clean up the src and dst of the path and stash the
result in the Pkg structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
In e8786d73bb the logwrite package will
automatically append .log to every log.
In 5201049f2c the init package will send
stderr of a service `s` to a log named `s` and the stdout to `s.out`.
Therefore the files we create on disk are `s.log` and `s.out.log`.
This patch modifies the memlogd `logwrite` command-line wrapper to use
the same convention.
Note there is a confusing name clash between `pkg/logwrite` and `cmd/logwrite`
in `memlogd` modified here.
Signed-off-by: David Scott <dave.scott@docker.com>
This commit adds support for authentication for image pulls for
'linuxkit build'. For each image reference we look up credentials
via the docker CLI configuration and use it if defined for
a given registry server. The code caches credentials to avoid
lookups for every image.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
A subsequent commit will enable support for private repositories.
This requires some functions from 'github.com/docker/cli' which
in turn relies on some newer versions of some of the vendored
packages here.
In this commit, update all packages used here to the versions
used by 'github.com/docker/cli' release 18.06 (the latest stable).
This requires vendoring a bunch of additional packages, such
as prometheus
Also run 'sort' over 'vendor.conf' to keep things in order.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- use the mkimage hashes that we had in LinuxKit as more up to date than tool.
- update docs
- move the code from moby under src/cmd/linuxkit
Signed-off-by: Justin Cormack <justin@specialbusservice.com>
These must have fallen through the crack during various
kernel updates. Move everything to the latest 4.14.x kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
When logging directly to files (the not-using-memlogd case) the onboot
services must log to /run/log because /var/log might be overmounted
by a persistent disk. Therefore we create a symlink at the end of
the onboot section.
When logging via memlogd, all logs are buffered until a logwrite service
starts, so no symlink is needed.
Signed-off-by: David Scott <dave.scott@docker.com>
Also simplify the code by directly storing the path to
the log file in the LogFile structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Update the the firmware packages to the latest commit
of the upstream linux-firmware repository.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This process connects to memlogd and streams logs to individual files,
one per log. It keeps track of how many bytes have been written to each
file and rotates when the file size exceeds a defined threshold.
By default the maximum size of each file before rotation is 1MiB and
we keep up to 10 files per log.
Signed-off-by: David Scott <dave.scott@docker.com>
Looks like brtfs-prog v4.17 as shipped with alpine:3.8 requires
a loopback device of 109MB while the containerd tests only
create a 100MB device. This causes the test to fail.
Disable it until https://github.com/containerd/containerd/issues/2447
is fixed.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
This simplifies the example by adding a service which writes to the
log every 1s and a getty for introspection.
To see the logs:
/proc/1/root/usr/bin/logread -F
Signed-off-by: David Scott <dave.scott@docker.com>
Switch to a more formally-specified `kmsg`-style format for reading
the logs.
- update the spec in docs/logging.md
- check for bad names in pkg/memlogd with unit test
Signed-off-by: David Scott <dave.scott@docker.com>
- check writing to the log does not block
- check the log doesn't expand -- it should be finite
- check that client connections don't buffer arbitrary amounts of
data if the client is slow
Signed-off-by: David Scott <dave.scott@docker.com>
Previously we had a per-connection
bytes.Buffer // to be written to the connection
sync.Cond // to allow us to Wait for more data
This had the major disadvantage that the buffer was unbounded and so
a slow client could cause memory exhaustion in the server. This patch
replaces these with a single
chan *logEntry
which is naturally bounded and supports blocking read. We make write
non-blocking using select i.e. we drop messages rather than allocate
more space.
Signed-off-by: David Scott <dave.scott@docker.com>
This is an example external logging service which can be enabled by
adding it to the `init` section of the .yml, for example:
...
init:
- linuxkit/init:35866bb276c264a5f664bfac7456f4b9eeb87a4d
- linuxkit/runc:v0.4
- linuxkit/containerd:f2bc1bda1ab18146967fa1a149800aaf14bee81b
- linuxkit/ca-certificates:v0.4
- linuxkit/memlogd:cc035e5c9e4011ec1ba97a181a6689fc90965ce9
onboot:
...
Signed-off-by: David Scott <dave.scott@docker.com>
If external logging is enabled, this patch sets the stdout and stderr
of the `runc` invocations to one end of a socketpair and the other end is
sent to the logging service. Otherwise we log to files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
An external logging system exists if the socket
/var/run/linuxkit-external-logging.sock
exists.
If an external logging system is enabled then create FIFOs for
containerd and send the other end of the FIFOs to the logging service.
Otherwise use /var/log files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
Previously memlogd would always run in the foreground. This patch
adds a `-daemonize` option which binds the /var/run sockets, forks
and execs itself and immediately returns. Therefore the program won't
block (important for an init.d script) but guarantees the sockets will
be available for any program started afterwards.
This also removes the alpine base from the memlogd image as `init`
"containers" are treated as simple file overlays.
Signed-off-by: David Scott <dave.scott@docker.com>
We will place the control sockets in the root /var/run and then share
with all services who need access.
Signed-off-by: David Scott <dave.scott@docker.com>
Since I struggled to understand and find information about how to
troubleshoot a running linuxkit instance, I propose to add these two
FAQ entries.
The first one explains why it is possible to not see the `containerd` or
`init` outputs at boot in the console.
The second one gives a few `ctr` example to list containers, running
containers or how to open a shell in a given container.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
These were being added to the incorrect directory.
Also move config file to /etc to be more standard.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The previous commit updated to 4.16.18, which is the last
4.16.x kernel. The 4.16.18 kernel was compiled and pushed
but we may as well now remove it as it has been EOLed.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When dealing with apk, `uname -m` doesn't always match the architecture
name that apk uses. Instead `apk --print-arch` is used.
Signed-off-by: Alan Raison <alanraison@users.noreply.github.com>
DNS lookups fail in qemu-user when it is built on Alpine: https://bugs.alpinelinux.org/issues/8131
Until this is resolved, we fetch the binaries from Debian and use those instead. The final stage
of the Dockerfile is still based on scratch.
We can revert this once the Alpine issue is fixed.
Signed-off-by: Justin Barrick <jbarrick@cloudflare.com>
For some reason, bind mounting does not always seem to work,
sometimes the filesystem is empty. Mounting a fresh copy seems
a better solution, and simplifies things. The container does
need `CAP_SYS_ADMIN` but only on boot.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This attempts to work around a CI issue where we're running out of disk
space when rebuilding the init package.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
When busybox's reboot processing occurs in init, it runs all SHUTDOWN
actions that are defined in inittab. Once those are complete, it will
trigger either a halt, poweroff, or reboot, depending upon what signal
is received. The mechanism that's used to shell out through inittab
does not allow us to pass through exactly which invocation was
requested.
Due to the way that rc.shutdown works, it invokes the poweroff action
for any and all SHUTDOWN callbacks, whether they're a reboot, poweroff,
or halt. Instead of handling the reboot(2) syscall in rc.shutdown,
return after killing and unmounting and let busybox's init process
decide which reboot(2) action to use.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
With PR #3030 the behaviour of poweroff/halt is changed. This
test relies on on-shutdown containers to be executed to display
the test result (service containers have their stdout redirected).
Use 'poweroff' (note, no '-f') to ensure that:
- the machine actually powers off
- the on-shutdown container is executed
Note, there are subtle differences between 'poweroff' and 'halt'
between hypervisors. With HyperKit, 'halt' actually works, but with
qemu/kvm, with 'halt' the process does not exit.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Previously name and image were always the same so running two hosts
from one image was not possible!
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
While we can re-create the kernel source code we don't have it
handily available in one place. This commit stashes the kernel
and the WireGuard source as /src/linux.tar.xz and
/src/wireguard.tar.xz in the kernel package.
This increases the size of the hub image by around 100MB.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Trying to keep the number of kernels we compile for these
platforms small and 4.16 is likely to be EOLed soon anyway.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The kernel configs are the 4.16.x configs run through
a 'make defconfig && make oldconfig' cycle.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Originally, Memorizer kernel fed inputs to add boot printouts from a debug tool, however, it creates unnecessary output. Remove the kernel boot option parameter.
Signed-off-by: Nathan Dautenhahn <ndd@cis.upenn.edu>
Note, we skip 4.14.45 because 4.14.46 only has 3 patches
in it which unbreak 'perf' compilation.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This microcode bundle comes with a file called "list"
which seems to confuse the 'iucode_tool', so we just
remove it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
the 4.14.38 kernel backported the Spectre mitigation requiring
a change of the kernel config.
Might as well enabled the mitigations by default.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is useful for some baremetal configs, such as using
USB sticks on a RPi3. I enabled it for x86_64 as well
to keep the differences smaller.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Note, the depeding SERIAL_DEV_CTRL_TTYPORT defaults to
'N' with the 4.14.x kernel and 'Y' for the 4.16.x kernel.
I chose to stick with the defaults.
This may fix the serial console issue, I've seen on the RPi3
with 4.14.x kernels.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
src/cmd/linuxkit/vendor/github.com/moby/tool/src/moby/linuxkit.go embeds a yaml
fragement with some hashes in it, so avoid updating that since that would make
the vendoring unclean.
Signed-off-by: Ian Campbell <ijc@docker.com>
This updates to support updating things like `linuxkit/runc:v0.3` to a new hash
(or tag).
Running:
./scripts/update-component-sha.sh --image linuxkit/runc 100d0d046c
Still DTRT and updates runc to that (bogus) sha.
Furthermore, running:
./scripts/update-component-sha.sh --image linuxkit/runc v0.4
Updates runc to that (bogus) release (this worked before) but now running:
./scripts/update-component-sha.sh --image linuxkit/runc acba8886e4
Inverts things and puts them back.
(this is not quote a nop because
src/cmd/linuxkit/vendor/github.com/moby/tool/src/moby/linuxkit.go has a
different sha in it which is not put back)
Signed-off-by: Ian Campbell <ijc@docker.com>
Right now the difference is rather minor, but I'm about to make this case more
complicated.
Running:
./scripts/update-component-sha.sh --image linuxkit/runc 100d0d046c
Still DTRT and updates runc to that (bogus) sha.
Signed-off-by: Ian Campbell <ijc@docker.com>
I think the intention was to use "" for bits with substititions and '' for bits
without, but that makes it hard to read and the bits in '' are safe in the ""
context anyway.
Running:
./scripts/update-component-sha.sh --image linuxkit/runc 100d0d046c
Still DTRT and updates runc to that (bogus) sha.
Signed-off-by: Ian Campbell <ijc@docker.com>
The default Go tar has restrictions on filename length for example.
PAX is recommended over GNU.
Requires Go 1.10
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The s390x build VM we have access to is quite slow. Dropping
the 4.15.x kernel, which soon will be EOLed anyway, to
save some time.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Since we are building containerd v1.1.0 with go 1.10 (as it requires) to the
same for init and runc too for consistency. In the case of init it is actually
required since we use the containerd client library there.
The subreaper interfaces have been removed from containerd and replaced with a
similar interface in runc/libcontainer, update init to use that now.
Signed-off-by: Ian Campbell <ijc@docker.com>
I am doing some upstream `runc` work with kernel keys and have
various other uses. No urgency so not updating the package
builds yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
crosvm is a VMM written on Rust which can run the device
backends in secomp isolated processes.
This adds build support for crosvm for x86 and arm64 as well
as some instructions on how to run LinuxKit built images on crosvm.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For example kernel module signatures if you do not provide a key. So add
to the dependencies for kernel builds.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Unlike the hyperkit runner, the qemu runner already had better
support for auto-detecting the boot method so the changes
are less invasive (and backward compatible).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Previous commits added support for building 'kernel+squashfs'.
This commit adds support for booting this build format on hyperkit.
The changes are a little bigger because some restructuring of the
code was required to support a third (after kernel+initrd and EFI
ISO) boot method.
To keep the code simpler this commit also removes some auto-detection
code for ISO booting. Users now have to specify '-iso -uefi' on the
command line to boot an EFI ISO. Previously, only '-uefi' was
required.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This contains a small fix to the disk binadings and allows
booting with a kernel alone (no initrd).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This includes two improvements:
- being able to specify the packages used for building images
- support for building squashfs images.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This utility image takes a tarball as input and places the
contents into a read-only, compressed squashfs filesystem
which is produced on stdout.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For the initrd we only want to extract kernel, cmdline, and
the ucode CPIO archive. Skip whatever is left in ./boot
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This output produces a kernel and a root filesystem
in squashfs format. squashfs is a read-only, compressed
filesystem.
The 'kernel+squashfs' output can be used in a similar way as
the default 'kernel+initrd' output format with the benefit
that the rootfs does not consume any memory.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We currently hardcode the Linuxkit/mkimage- images. This has the
unfortunate consequence that, if we update the LinuxKit image used
to generate the output, we have to update the Moby tool and then
vendor it back into the LinuxKit repository.
This commit introduces UpdateOutputImages() which allows a client
of the Moby tools package to selectively overwrite the packages
used to generate the outputs.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
$ git diff linuxkit.yml
diff --git a/linuxkit.yml b/linuxkit.yml
index e2ec829db..21b84e4ad 100644
--- a/linuxkit.yml
+++ b/linuxkit.yml
@@ -1,6 +1,6 @@
kernel:
image: linuxkit/kernel:4.14.32
- cmdline: "console=tty0 console=ttyS0 console=ttyAMA0"
+ cmdline: "console=ttyS0 console=foobar"
init:
- linuxkit/init:v0.3
- linuxkit/runc:v0.3
$ linuxkit build linuxkit.yml
[...]
$ linuxkit run linuxkit
[...]
getty: cmdline has console=foobar but /dev/foobar is not a character device; not starting getty for foobar
linuxkit-2ae2c420a11c login: root (automatic login)
Welcome to LinuxKit!
NOTE: This system is namespaced.
The namespace you are currently in may not be the root.
(ns: getty) linuxkit-2ae2c420a11c:~# ls -l /proc/1/root/dev/foobar
-rw-r--r-- 1 root root 311 Apr 9 13:19 /proc/1/root/dev/foobar
(ns: getty) linuxkit-2ae2c420a11c:~# cat /proc/1/root/dev/foobar
Welcome to LinuxKit
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
{ / ===-
\______ O __/
\ \ __/
\____\_______/
Also added quotes around $tty for good measure.
Signed-off-by: Ian Campbell <ijc@docker.com>
This option was removed in 4.16.x in favour of
CONFIG_CC_STACKPROTECTOR_AUTO. We do not check for
this option as we also force CONFIG_CC_STACKPROTECTOR_STRONG.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The kernel config is based on the 4.15.x kernel config
run through 'make defconfig && make oldconfig' and then
tweaked a little by hand.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If you happen to be exactly on a tag then:
$ linuxkit pkg build --dev pkg/init
Building "ijc/init:dev"
Cannot release "v0.3" if not pushing
Do not try and infer a release if not pushing so this is possible again.
The subsequent check for `bo.release != "" && !bo.push` remains since the
caller could have used `WithRelease` but not `WithPush`. Our CLI never does
this, but a hypothetical other user of the library might.
Signed-off-by: Ian Campbell <ijc@docker.com>
static pie only seems to work on Alpine currently, but static is
a good default. Give the user choices...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Now that these are the only namespace tests, there is no
need to have them in their own subgroup.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
We do not run these tests as part of CI and when running them
manually it is easy to just change the kernel image common.yml.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
We had the relevant fixes in all kernels for quite some
time, so no need to call it out explicitly at the top
level.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Prior to notary 0.6.0, notary expected a terminal and only accepted
username/password interactively. With notary 0.6.0 this can now be
passed as en environment variable 'NOTARY_AUTH' in the form of
a base64 encoded 'username:password'.
This commit removes the ugly 'expect' hack in favour of the much
cleaner use of an environment variable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
There are too many kernels to compile and arm64 takes a bit
too long to compile even on a beefy arm64 server.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
It is quite confusing that from the host or another container that
binds `/containers` you cannot see the bind mounts, you have to enter
the container namespace. I think `rshared` is a better default. You
can always be explicit and add `private` if you want a private bind mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Go commit https://github.com/golang/go/issues/23672 introduced a
whitelist ofr flags passed into gcc to prevent arbitrary code
execution (CVE-2018-6574). The x86 rngd code uses two CFLAGS
not on the whitelist. Add them to 'CGO_CFLAGS_ALLOW'.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
These fix some issues around hot-unplugging devices which may be the cause
of some LCOW issues we are seeing.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
the kernel series name. Otherwise the script in kernel/Dockerfile
will not apply it. So the example file name should be
`config-4.9.x-x86_64-foo` instead of `config-foo`.
Signed-off-by: functor <meehow@gmail.com>
Most of the tools packages are not usable on s390x so
explicitly list them.
Also removed arm64 from mkimage-gcp as GCP does not
support arm machines and fixed a minor inconsistency
the way the architecture was specified in mkimage-raw-bios.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Enable the Integrity Measurement Architecture (IMA) for 4.14.x
and 4.15.x kernels. This pretty much uses the defaults except we
also enable INTEGRITY_ASYMMETRIC_KEYS and IMA_READ_POLICY. The
latter may be useful for debugging.
For s390x we also needed to enable TPM support.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Disable all network device driver apart from Mellanox, which
is the only support NIC on s390x
- Disable Fusion MPT
- Disable DAX/NVMEM/NVME
- Disable USB
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
While this now has some duplication, it is clearer as to which
kernels are compiled for each architecture.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Without the privileged flag, the tcsd daemon does not have
access to the mounted host device files, especially the tpm
device file.
Signed-off-by: Pratik Mallya <pratik.mallya@gmail.com>
Update building process to add s390 support.
The patch serial-forbid-8250-on-s390.patch has been added to disable
8250 serial for s390.
The patch is available upstream https://patchwork.kernel.org/patch/10106437/
but it is not backported.
Signed-off-by: Alice Frosi <alice@linux.vnet.ibm.com>
- On macOS, docker-credential-osxkeychain.bin was renamed to
docker-credential-osxkeychain
- Pass --ignore-missing to the manifest-tool invocation.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is temporary to un-break the build until we have pushed
a alpine base image for s390x.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Currently, there is a conflict in musl versions between stable
(used for tools/alpine) and edge (where wireguard-tools is).
This cased the tools/alpine build to fail.
With this commit we build our own wireguard-tools package,
using the APKBUILD file from edge, against the libraries
libraries from stable. We then add the wireguard-tools package
to the mirror.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Add support for s390 architecture for linuxkit/alpine and the
other docker images in tools and pkg.
Signed-off-by: Alice Frosi <alice@linux.vnet.ibm.com>
Starting a virtualbox vm in bridged networking mode requires the host's
network interface to attach to the bridge being specified. This commit
adds command line option '--bridgeadapter iface' to 'linuxkit vbox run',
where 'iface' is the host's network interface to use in bridged mode.
Fixes: #2929
Signed-off-by: Olaf Bergner <olaf.bergner@gmx.de>
We tried to to build an OS with all the TICK stack
(https://www.influxdata.com/time-series-platform/): InfluxDB,
Chronograf, Kapacitor, Telegraf.
Very easy but I was curious to try it out after few months just reading
about linuxkit.
You can build the image with:
```
linuxkit build --format iso-bios examples/influxdb-os
```
And you can run it:
```
linuxkit run qemu -iso influxdb-os.iso -publish 8888:8888/tcp -publish
8086:8086/tcp
```
After that you can open your browser on `localhost:8888` to see
Chronograf (the dashboard up and running).
All the services are configured to talk with each other.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
Co-authored-by: Lorenzo Fontana <lo@linux.com>
Also remove the 4.4 patch which should have been removed by
231cead2cc ("kernel: Update to 4.15.4/4.14.20/4.9.82/4.4.116")
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
There is a hopefully temporary error with nginx:alpine
not being available for amd64. Pick a version which is...
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We may soon get another arch, so wanted to set the template
for having per arch list of kernels to compile.
While at it also drop the 4.4.x kernel for arm64. We never really
tested it and folks should be on 4.9 or 4.14 anyway. I'll leave
4.4.x for x86 for now as it might be useful to test for regressions.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
In order to cut the number of kernels we build, remove the debug
kernel for the now non-default 4.9.x series.
Also remove the -rt debug kernel. Users who need it can build
it themselves with 'make EXTRA=-rt DEBUG=-dbg build_4.14.x'
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The kmod tests pull the kernel image to make sure they
have the latest version to build images against. Unfortunately
they were pulling the wrong kernel for non-4.9.x kernels.
This is not a big issue in most cases, but may have caused issues
when two different kernels packages were pushed with the same tag.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These are part of the Meltdown/Spectre mitigations for arm64
now available for 4.14 and 4.15
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The 4.14.20 update has Meltdown/Spectre fixes for arm64
The 4.4.116 update incorporates the proper fix for the
div by zero crash in the firmware loader, so the patch
with the hackish workaround was dropped.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Pulls in a bumper crop of updates from last year and some recent improvements:
$ git log --oneline 3e8ed35ca934..f2409214ca3b | cat
f240921 Merge pull request #38 from ijc/timestamp-precision
f626ffe Preserve full precision in nanoseconds part of log timestamp
29c89e8 Merge pull request #37 from rn/ps1
600ea59 Update documentation with new powershell features
9fed685 Add powershell test and group templates and a stub library
3ada6bd Don't use '#!/bin/sh' in tests or group initialisers
dd187b4 Add test cases for powershell scripts
4892754 Add support for writing tests in powershell (on Windows)
00cdd1f Add the ability to execute powershell scripts
00906da Add TestFilePath to the Test struct
e6fdcb7 Add GroupFilePath to the Group struct
c590dbc Make group member names for Pre/Post test scripts clearer
5ca3d4f Add setEnv test
d178af2 Improve environment variable setting in executeScript
9c7cc94 Merge pull request #35 from rn/circle
d464092 Use container builds on CircleCI and stash artefacts
9a09cd5 Move CircleCI config file to .circleci
9429279 Merge pull request #33 from rn/poule
4de1f2c Add poule config
88dcc27 Merge pull request #32 from mor1/extra-extra
bfabb8a flags: update README for `-x` now as a local flag
3f574c7 flags: make `-x` work
ba442d6 Merge pull request #31 from dave-tucker/fix-panic
6c7f09b local: Fix panic when no pattern is supplied
617e977 Merge pull request #30 from dnephin/add-latest-link
5829b2b Merge pull request #29 from dnephin/fix-command-descriptions
d09a317 Add a link to the latest directory within results.
c9a9a2a Remove some duplication between commands.
7904cc7 Remove unused flags, and move run flags to run command.
94e56a7 Update command descriptions
faedeef Merge pull request #28 from dave-tucker/prepost
a5f92ae local: Fix panic in PostTest
23fbbea Merge pull request #26 from dave-tucker/fix-osx-vers
156281e sysinfo: Fix OSX version parsing
Signed-off-by: Ian Campbell <ijc@docker.com>
This should make debugging a lot easier. Note, 991f8f1c6eb6
("hyper-v: trace channel events"), patch 18, required some
minor modifications from upstream as another patch was not easy
to cherry-pick.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Drop the hack for the microcode division by 0 on GCP as
a proper fix is in upstream as:
2760f452a718 ("x86/microcode: Do the family check first")
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These kernels have significant changes/addition for Spectre
mitigation as well as the usual other set of fixes.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The YAMLs in ./test/hack enumerated the images to pull with
content trust. All images in the 'linuxkit' org should
now have trust enabled.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The CONFIG_BPF_JIT_ALWAYS_ON option has now been back-ported
to 4.4.115 as well. Enable it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This adds a patch to avoid a division by zero panic for 4.4.x
and 4.9.x kernels on single vCPU machine types on Google Cloud.
4.14.x and 4.15.x kernels seem to work fine.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This option is not enabled by default, but disables the
BPF interpreter which can be used to inject speculative
execution into the kernel. Enabled it as it seems
like a good security measure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The 4.14 and 4.9 kernels have a significant number of
fixes to eBPF and also a fix for kernel level sockets
and namespace removals, ie fixes some aspects of
https://github.com/moby/moby/issues/5618
"unregister_netdevice: waiting for lo to become free"
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Upstream qemu supports accelerators other than kvm. Allow the user
to choose. On Linux we still default to 'lvm' if available. On
macOS we try the new 'hvf' accelerator, if available.
Disable acceleration if the host arch does not match requested
qemu arch.
Also change the LINUXKIT_QEMU_KVM env var to LINUXKIT_QEMU_ACCEL
and use the functions in utils.go for env var overrides.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
It still defaults to whatever is in your PATH but it's
useful to override when experimenting with different
qemu builds.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This adds a namespace field to override the LinuxKit containerd
default namespace, in case you want to run a container in another
namespace.
Needs a patch in LinuxKit to implement this that I will open soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Annotations do not do anything by default but get passed through to the runtime,
which can be useful. I never metadata I didn't like...
Also fix sysctl to be a map in the validation, not an array. I can't see any
examples using this in LinuxKit, but this matches OCI so is correct.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This prepends 'ucode.cpio' to the initrd if present. Padding
should not be necessary as the ucode.cpio should be padded
to the right size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For now the backends for the different formats do not yet
use the extracted ucode cpio archive, but '// TODO' are
placed for the backends which should eventually handle it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This extends the kernel filter to also look for the CPU microcode
file if specified in the YAML. If found, the ucode cpio archive
is placed into the intermediate tar file as '/boot/ucode.cpio'.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This optional option will allow users to specify a CPU
microcode cpio archive to be prepended to the initrd file.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
User specified mounts should be able to rely on the rootfs being mounted, in
particular for a writeable container they should expect the writeable overlay
to already be in place.
Signed-off-by: Ian Campbell <ijc@docker.com>
Since that bumps to gogo protobuf v0.5 too do the same.
Note that there are no actual containerd changes here, although there are some
gogo proto ones.
Signed-off-by: Ian Campbell <ijc@docker.com>
Rather than queueing up into a `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) compared with the previous patch from 2.8G to 110M. The
tar output case goes from 2.1G to 110M also. Overall allocations are ~715M in
both cases.
Signed-off-by: Ian Campbell <ijc@docker.com>
All of the `output*` functions took a `[]byte` and immediately wrapped it in a
`bytes.Buffer` to produce an `io.Reader`. Make them take an `io.Reader` instead
and satisfy this further up the call chain by directing `moby.Build` to output
to a temp file instead of another `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) from 6.7G to 2.8G and overall allocations from 9.7G to
5.3G. When building a tar (output to /dev/null) the Maximum RSS fell slightly
from 2.2G to 2.1G. Overall allocations remained stable at around 5.3G.
Signed-off-by: Ian Campbell <ijc@docker.com>
Following https://golang.org/pkg/runtime/pprof/. When attempting to build
images in https://github.com/linuxkit/kubernetes CI the process is mysteriously
being SIGKILL'd, which I think might be down to OOMing due to the resource
limits placed on the build container.
I haven't done so yet but I'm intending to use these options to investigate and
they seem potentially useful in any case, even if this turns out to be a
red-herring.
Signed-off-by: Ian Campbell <ijc@docker.com>
The syntax used for the yaml definitions is changed by the need to include the
substruct in the struct literal.
For the label switch to `ImageConfig` directly, which is actually more correct
in that it avoids spurious `name` and `image` fields in the label.
Signed-off-by: Ian Campbell <ijc@docker.com>
Where "config-related" here means "ones you might find in the
"org.mobyproject.config" label on an image.
By making this new struct an anonymous member of the existing Image struct the
Go json parser does the right thing (i.e. inlines into the parent) when parsing
a complete image (from a yml assembly) by default. The Go yaml library which we
use requires a tag on the anonymous field to achieve the same.
Signed-off-by: Ian Campbell <ijc@docker.com>
It appears that the `$GOPATH` in `working_directory` is being treated as a literal
`GOPATH` at least when processing the `state_artifacts.path`. Inlining it seems
to have worked, at the cost of some duplication.
Signed-off-by: Ian Campbell <ijc@docker.com>
Solv: Updated documentation to point out limits of
files section regarding /var, /run, and /tmp dirs.
Signed-off-by: Tristan Slominski <tristan.slominski@gmail.com>
Looks like a6b89f1137 ("Update linuxkit/mkimage-*") updated to a
non-existing tag.
linuxkit pkg show-tag tools/mkimage-iso-bios
linuxkit/mkimage-iso-bios:165b051322578cb0c2a4f16253b20f7d2797a502
and docker pull of that image works.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These versions were created by https://github.com/linuxkit/linuxkit/pull/2607
which enables content trust, so drop the sha256 from all of them and ensure
DOCKER_CONTENT_TRUST is unconditionally set when running, since these
references are hardcoded we know they must be signed.
Signed-off-by: Ian Campbell <ijc@docker.com>
AFAICT none of the callers (which all involve one of `linuxkit/mkimage-*`) have
any reason to hit the network.
Signed-off-by: Ian Campbell <ijc@docker.com>
If the YAML file contains:
- path: etc/linuxkit.yml
metadata: yaml
in the fil section, the image was build with content trust,
then the linuxkit.yml file image contains fully qualified
image references (including the sha256).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Instead of passing the image name as string use the a reference
to a containerd reference.Spec. This allows us, for example,
to update the reference in place when verifying content trust
with more specific information, such as the sha256
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When constructing a Moby structure from a YAML also
extract a containerd reference.Spec for each image
and the kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We want to modify some of the content of the Image structure
and thus have to pass them by reference.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is a tarball of the kernel, initrd and cmdline files, suitable for
sending to the mkimage images that expect this format.
Note you can't currently stream this output format using `-o` will clean this
up in future commits.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The next commit will start using some components of containerd
so vendor the latest version.
The latest vndr also removed some un-needed files previously vendored.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We are going to phase out the LinuxKit build option, in favour of keeping Docker
or a native Linux build option for CI use cases, as it is faster. So the
hyperkit option that only worked in one very limited use case is not needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously any Runtime specified in yml would completely override anything from
the image label, even if they set distinct fields. This pushes the merging down
to the next layer, and in the case of BindNS down two layers.
Most of the fields involved needed to become pointers to support this, which
required a smattering of other changes to cope. As well as the local test suite
this has been put through the linuxkit test suite (as of cc200d296a).
I also tested in the scenario which caused me to file #152.
Fixes#152.
Signed-off-by: Ian Campbell <ijc@docker.com>
This puts the build side in charge of the runtime layout, which enables
additional optimisations later, like sharing the rootfs if it is
used multiple times.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This could be used in LinuxKit now, as there are some examples, eg
https://github.com/linuxkit/linuxkit/blob/master/blueprints/docker-for-mac/base.yml#L33
which are creating containers to do a mount.
The main reason though is to in future change the ad hoc code that generates
overlay mounts for writeable containers with a runtime config which does
the same thing; this code needs to create both tmpfs and overlay mounts.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a `runtime` section in the config that can be used
to move network interfaces into a container, create directories,
and bind mount container namespaces into the filesystem.
See also https://github.com/linuxkit/linuxkit/pull/2413
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than using an initrd, unpack full filesystem for ISO BIOS.
Stream docker output direct to file rather than via a buffer, to save
memory.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
When we converted these to cpio we were not noticing that they
were invalid as they had incorrect paths as we converted the
path to a symlink anyway. Only the busybox images have hard links
in, the Alpine ones are symlinks anyway, which is why it was
less visible too.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do some code cleanup.
Related to #131 we need to read the OCI config to find if the container
is read only, not rely on the yaml, as it may just be set in the label.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
To work with truly immutable filesystems, rather than ones
we sneakily remount `rw`, we are going to use overlay for
writeable containers. To leave the final mount as `rootfs`,
in the writeable case we make a new `lower` path for the read
only filesystem, and leave `rootfs` as a mount point for an
overlay, with the writable layer and workdir mounted as a tmpfs
on `tmp`.
See https://github.com/linuxkit/linuxkit/issues/2288
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Unfortunately there are a lot of issues with resolv.conf as we
cannot actually write it into the image from any docker image, as docker will
always have something bind mounted in.
In addition, normally we expect the filesystem to br read only for images
that moby generates, so the actual etc/resolv.conf is likely not to be writeable.
Previously we were adding in a default resolv.conf into every image pointing at
Google's name servers but that is really a bad idea.
Instead, normal images now get an empty default, while images in the `init`
section will get a symlink, currently hard coded to `/run/resolvconf/resolv.conf`
but you can override this with the `files` section to be static or a different
link.
In future, if we have an easy way to build and extract images with user control
of this, we can drop this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Some of these are arbitrary and just syncing for the sake of it, however the
image- and runtime-spec are relevant. Interesting changes:
- runtime spec:
- LinuxRLimit is now POSIXRLimit.
- Specs.Config is now a pointer.
- LinuxResources.DisableOOMKiller moved to
LinuxResources.LinuxMemory.DisableOOMKiller
- image spec:
- Platform.Features is removed (unused here).
Signed-off-by: Ian Campbell <ijc@docker.com>
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
Fix https://github.com/linuxkit/linuxkit/issues/1988
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Currently this supports "yaml" as the only option, which will output
the yaml config (as JSON) into the file specified in the image.
Fix#107
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously I was forcing them to be strings, which is horrible. Now you
can either specify a numeric uid or the name of a service to use the
allocated id for that service.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes the `lint` dependency from building Moby.
I've also added ineffassign to check ineffecutal assignments alongside
checks to ensure that both it and golint are installed.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This includes https://github.com/moby/moby/pull/34040 which fixes Windows build
issues.
Note that this pulls in more than 500 (non merge) commits as well as the fix we
are interested in. A couple of new deps are pulled in, versions taken from
vendor/github.com/docker/docker/vendor.conf.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Continue to allow onboot to have duplicates as we do not run simultaneously
so that is ok (and we number them anyway), but services are run together
so we will get a runtime error if duplicated as this is the containerd/runc
id.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We were pulling in this whole stack of packages just for `trust.ReleasesRole`.
Just define it locally.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Note that various fields have changed moved around in the JSON as a result:
* `Platform` has been removed.
* `Process` is now a pointer.
* `OOMScoreAdj` has moved into `Process`, from `Linux.Resources` (resolving a
TODO here).
Also updates golang.org/x/sys which is less critical.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This adds the OCI parts needed into the yaml, but there are still
permissions issues in practise so marked as experimental.
It may just need further documentation to resolve the issues.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In order to support not running containers as root, allocate
each of them a uid and gid, a bit like traditional Unix system
service IDs. These can be referred to elsewhere by the name of
the container, eg if you wish to create a file owned by a
particular esrvice.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Allow setting ambient capabilities, as a seperate option to the standard
ones. If you are running as a non root user you should use these.
Note that unless you add `CAP_DAC_OVERRIDE` and similar permissions you
need to be careful about file ownership. Added support to set ownership
in the `files` section to help out with this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than build the image and have something weird happen, let's check
that the capabilities specified are actually valid capabilities.
Signed-off-by: Tycho Andersen <tycho@docker.com>
- this is pretty much the smallest change to split this out and it
exposes a few things that can be improved later
- no change to logging yet
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- enable the hyperkit option by default on MacOS
- use it for creating raw disk images
fix#68
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This disables the code in LinuxKit's `/bin/rc.init` which attempts to detect an
unconfigured hostname and generate a unique (ish) version from the MAC address.
Anyone who wants a specific fallback hostname can populate `etc/hostname`
through the `files` stanza in their `yml` file.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
In the WIP code in `moby` we now have a standard base tarball format,
that includes the kernel and cmdline as files in `/boot` so that the
entire output of the yaml file can default to a single tarball. Then
this can be split back up by LinuxKit into initrd, kernel and cmdline
as needed. This will probably become the only output of the `moby build`
stage, with a `moby package` stage dealing with output formats.
We may remove the output format specification from the yaml file as well,
and just have it in the command.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Instead, make a hard link a symlink. This isn't much better, but it allows
some cases (e.g. installing GCC on moby via alpine) to work.
Signed-off-by: Tycho Andersen <tycho@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also keep track of directory creation there, so you can explicitly
set directory permissions if required, and to avoid duplicates.
We should really keep track of files created elsewhere in the build
as well as we still might create some extras, but at least you can
set the write permisisons.
We can add uid, gid support too if required...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This will add a Dockerfile which will build the contents into an
image and then call `tinit` to start it.
This is fairly experimental, but is a prototype for other non
LinuxKit outputs. The container will need to run as `privileged`
as `runc` needs quite a few capabilities and `containerd` needs to
mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- generally people refer to a plain disk image as `raw`
- `gcp` is shorter and it is the only image type supported
- remove `img-gz` as it is not needed. It does not really save space
as you have to build the full image and compress it anyway. On
many platforms the `raw` image will be a sparse file anyway,
even on the Mac soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a little ugly in terms of the validation now, but it is a move towards
splitting "build" and "package".
The "tar" output (and soon others) can output direct to a file or to stdout.
Obviously you can only build a single output format like this.
The LinuxKit output formats that build disk images cannot stream as they
have to build whole images. These allow multiple outputs.
In future we will probably change to
```
moby build | moby package
```
or similar, but that is a bit ugly, so currently have a compromise where
there are essentially two output types.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP does not recognise the images, even though they appear identical to those made
by libguestfs and work on qemu fine. Their validation code does not like them for some
reason.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Each section will be appended in order of the CLI, other then
kernel where last specified one wins.
This is useful if you eg want to have a base version for (say)
AWS and GCP and then add your own image on top.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- does not require docker if user has qemu natively, will still fall back to docker
- allow specifying size for fixed size disk images
- add a raw disk output format
- more dogfooding
- marginally slower, but can be improved later
The images used to do the build are cached to make the process quicker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Default to sharing net, ipc, uts namespaces between containers in config.
This makes most sense, as this is normal other than if we want to specifically
isolate system containers, in which case we will specify in config.
- explicitly support the value "new" if you want to isolate
- support the synonym "root" for "host" as in non LinuxKit setups it may
not actually be the host, it will be the current namespace.
- only support "none" as a synonym for "new" for network namespace where it is
carried over from Docker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes outputs from yaml, instead you can do
```
moby build -output tar -output qcow2 file.yaml
```
or alternative syntax
```
moby build -output tar,qcow2 file.yaml
```
In future we may change this to be available in a `moby package`
step, but lets try this for now.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Using the label `org.mobyproject.config` will use that JSON
(or yaml, but it is very hard to get yaml into a label as newlines are
not respected) for parameters that are not explicitly set in the yaml file.
Had to change parameter definitions so override behaves as expected.
fix#16
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a fairly generic bootable disk with syslinux. Should
work if you dd it onto a USB stick, and should also work for AWS.
You need to uncompress it of course! Default size is 1G.
Will add cli option to set the size once I split out `moby build`
and `moby package` shortly.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Due to a missing else the tool would previously terminate with an error
message showing that the kernel or init image didn't exist, even if it
was pulled successfully. Invoking the tool again would continue to the
next image.
Signed-off-by: Magnus Skjegstad <magnus@skjegstad.com>
Add a canonical single tarball output format. This
adds kernel and cmdline to `/boot` where LinuxKit output
formats will find them.
Make the other output formats use that as a base.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
`docker create` will not pull an image so we need an additional fallback.
Rework the pull and trust code so it is in one place to facilitate this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do not require `tar` to be in container, use the standard
image export code that we already have and find the files we
want.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This currently only changes the `gcp` target, but is the new
model - the `build` command will only do things locally, then
you need to `push` to an image store such as GCP or other ones
in order to `run` for platforms that cannot boot directly from
a local image.
Fix#1618
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP defines some "standard" environment variables for project and
zone. Use them for 'moby run gcp'. Change the other environment
variables to follow the same pattern.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This uses the Packet.net API and iPXE to boot a Moby host.
There are several enhancements coming soon, such as SSH key
customisation, but this PR is sufficient to boot a host and
then use the web interface to get console access.
The user must currently upload the built artefacts to a public
URL and specify it via --base-url, e.g.:
moby run packet --api-key <key> --project-id <id> \
--base-url http://recoil.org/~avsm/ipxe --hostname test-moby packet
See #1424#1245 for related issues.
Signed-off-by: Anil Madhavapeddy <anil@docker.com>
This makes gcp behave in a similar way to the qemu backend.
The minimum size on GCP 1GB, whereas qemu uses 256MB.
Without this, the LTP tests fail on GCP.
Signed-off-by: Dave Tucker <dt@docker.com>
Adds an "access config" with a type of "ONE_TO_ONE_NAT" that
allows an instance to obtain an ephemeral IP address and access the
internet
Signed-off-by: Dave Tucker <dt@docker.com>
As suggested by @shykes these are clearer
- onboot for things that are run at boot time to completion
- services for persistent services
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This allows overriding the name used of the file in google storage,
image name or instance name. This will vary depending on how much `moby
run` is doing which is goverened by whether the positional argument
contains an `.img.tar.gz` or not.
For example:
`moby run gcp -img-name test-ea34d1 test` creates an instance called
`test-ea34d1` from the image `test`
`moby run gcp -img-name test-ea34d1` test.img.tar.gz` will upload the
file as `test-ea34d1.tar.gz`, create image `test-ea34d1` and create an
instance called `test-ea34d1`.
The use case for this is for CI to be able to spawn many concurrent test
machines and provide it's own name for them.
Signed-off-by: Dave Tucker <dt@docker.com>
- masked paths
- readonly paths
- allow attaching to existing namespaces, eg if bind mounted by a system container
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Pass version and git commit hash from the Makefile
into main.go. Add a 'version' subcommand to print
the information.
While at it also tweak the help output to only print the
command name and not the entire path.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Something like "moby-4.10.yml" did not work when invoked
like "moby build moby-4.10".
While at it, also allow .yaml as an extension.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This refactors the mount handling, without changing any defaults.
Any specification of a mount destination will override the default,
so if you want to make `sysfs` read only you can add
```
mounts:
- type: sysfs
options: ["ro"]
```
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit implements `moby run gcp` which allows for testing of moby
images on the Google Cloud Platform
This backend attaches (via SSH) to the serial console.
It generates instance-only SSH keys and adds the public key to the
image metadata. These are used by the `moby` tool only.
It will also automatically upload a file and creates an image if the prefix
given to `moby run` is a filename
Signed-off-by: Dave Tucker <dt@docker.com>
This commit uses the older GCP API as it supports both compute and
storage. As a result, we can now use either Application Default
Credentials that are generated using the `gcloud` tool or by supplying the
service account credentials in JSON format
Signed-off-by: Dave Tucker <dt@docker.com>
This adds every capability. We had this before the OCI changes as we
passed these values to Docker. Makes fully privileged containers less verbose.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In the riddler change I changed "command" in the yaml to "args"
but did not change the files. In fact we basically used the
default command everywhere so this did not actually break.
Remove the unnecessary "command" lines to simplify yaml.
Revert the command to args change for now as I think I prefer
command, but its easier to switch now. Need to think if the
entrypoint/command distinction matters before finalizing.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We are generally outputting to stdout pipe which the log driver does
not cope with very well; always did this in older builds.
Saves another 5% of build time.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Generated largely from the specified config; small parts taken from `docker image inspect`,
such as the command line.
Renamed some of the yaml keys to match the OCI spec rather than Docker Compose as
we decided they are more readable, no more underscores.
Add some extra functionality
- tmpfs specification
- fully general mount specification
- no new privileges can be specified now
For nostalgic reasons, using engine-api to talk to the docker cli as
we only need an old API version, and it is nice and easy to vendor...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is compatible with containerd 8353da59c6ae7e1933aac2228df23541ef8b163f
which was picked up by d2caae4c1a.
This required jiggering with riddler output some more to update to new OCI
config.json format for capabilities.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Add a -data option to the HyperKit "run" backend. This either
adds a string or a file to a ISO which is attached to the VM.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Separating command line option parsing from executing hyperkit
makes the code awkward with many parameters passed between functions.
Having everything in one function makes the code simpler.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This provides a consistent UX between build and run:
moby build foo # build from foo.yml
moby run foo # boot, e.g., foo-bzImage, foo-initrd.img
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Some users seem to have Docker for Mac/hyperkit in a non-standard
path. Allow them to specify the path to the hyperkit executable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Move HyperKit code into a separate file. It should be compilable
on all supported OSes now.
- Add a (optional) subcommand to "moby run" to select a backend
i.e., "moby run hyperkit [options] [prefix]"
- On macOS the default is "hyperkit" so that:
"moby run [options] [prefix]"
just works
- Add enough command line parsing to make it easy to add new
backends to the run command
Update help messages.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This formatter strips the prefix from Info() events to
make the default output of "moby build" more readable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This adds log.Info() to the main steps of the "moby build"
process. By default the Info() output is shown to the user
so it provides some idea of progress and what is happening.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
docker-compose and other utilities use the .yml extension.
For consistency rename all .yaml to .yml
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- this removes the use of riddler to extract the rootfs, use code
we were using for rootfs. riddler now just geenrates the config,
next stage is to generate this ourselves
- change the naming of the daemons so no longer include number as we
do not guarantee ordering as they start up simultaneously
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Corrected naming from vmware->vmdk and fixed Makfile
Fixed mistake outputting a vhd instead of a vmdk in output.go
Build vmdk image and added to Docker Hub, corrected link in output.go
Modified directories to confirm to standard mkimage-<imgType>
Signed-off-by: Dan Finneran <dan@thebsdbox.co.uk>
Removing the left over indirect creates that use the Docker socket
and run in containers not directly.
See #1347
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
'moby run' will use the kernel and initrd image produced
by 'moby build' and, on macOS, will run it inside a
hyperkit VM. This assumes that you have a recent version
of Docker for Mac installed as it re-uses the hyperkit
and VPNKit from it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Trying to find the relevant yaml file was an issue as we now support
`--name` and it might be in a different directory, so although it is
a bit verbose outputing a whole file at least it is more consistent.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- this needs improvements to make it more "platform native", in
particular GCP supports multiple users and more ssh key mangement
options.
- at present you can login as root with any platform ssh key
- add support for uts=host and ipc=host
- set the hostname from the metadata as well
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- the `public` option was not previously implemented
- add `replace` only for GCP images which will error otherwise. Only
recommended for use in development, in production use the `--name` option
to provide a different name eaxch time. Note only applies to GCP images,
will document these options properly soon.
- add a `family` option; this allows you to upload many images and the
user can select the latest using the `family` option instead of a specific
image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This sets the base name of the built images which otherwise
defaults to the basename of your yaml file. This allows
building different versions easily eg adding git sha to the
output names.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This requires switching to the dosfstools from alpine:edge since neither the
busybox nor alpine:3.5 dosfstools supports the -C option (in fact alpine:3.5
only has mkfs.fat and not mkfs.vfat).
The 511k slack seems like a lot to me, but 256k was somehow not enough.
Fixes#1304.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
- the image upload uses the cloud API
- currently auth and image creation need the `gcloud` CLI tool.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- VHD is uncompressed VHD. Currently hard coded at 1GB, which may need to change. Use `format: vhd`
- GCE is the GCE compressed tarred raw image. Use `format: gce-img` - reserving `gce` for actually
uploading the image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
from:
2017/03/07 09:59:30 Failed to extract kernel image and tarball
to
2017/03/07 10:06:04 Failed to extract kernel image and tarball: Unable to find image 'mobylinux/kernel:7fa748810d7866797fd807a5682d5cb3c9c98111' locally
Signed-off-by: Tycho Andersen <tycho@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Note that the EFI ISO is not yet automatically sized, and the
kernel command lines are currently hard coded in the builders.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- split out config processing a bit
- just use `capabilities` not `cap-add` and `cap-drop`
- allow use of CAP_ prefix on capabilities, as this is what `runc` uses
- add nginx to example config
- fix bind mounts
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
**Security Update 17/01/2018: All current LinuxKit `x86_64` kernels
have KPTI/KAISER enabled by default. This protects against
[Meltdown](https://meltdownattack.com/meltdown.pdf). Defences against
[Spectre](https://spectreattack.com/spectre.pdf) are work in progress
upstream and some have been incorporated into 4.14.14/4.9.77 onwards
but work is still ongoing. The kernels 4.14.14/4.9.77 onwards also
include various eBPF and KVM fixes to mitigate some aspects of
Spectre. The `arm64` kernels are not yet fixed. See [Greg KH's
excellent
blogpost](http://kroah.com/log/blog/2018/01/06/meltdown-status/) and
this [LWN.net
article](https://lwn.net/SubscriberLink/744287/1fc3c18173f732e7/) for
details.**
**If you run LinuxKit kernels on x86 baremetal we also strongly
recommend to add `ucode: intel-ucode.cpio` to the kernel section of
your YAML if you are using Intel CPUs and `linuxkit/firmware:<hash>` if
you are using AMD CPUs.**
LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.
- Secure defaults without compromising usability
@@ -34,9 +15,15 @@ LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.
- Designed to be managed by external tooling, such as [Infrakit](https://github.com/docker/infrakit) or similar tools
- Includes a set of longer-term collaborative projects in various stages of development to innovate on kernel and userspace changes, particularly around security
LinuxKit currently supports the `x86_64`, `arm64`, and `s390x` architectures on a variety of platforms, both as virtual machines and baremetal (see [below](#booting-and-testing) for details).
## Subprojects
- [LinuxKit kubernetes](https://github.com/linuxkit/kubernetes) aims to build minimal and immutable Kubernetes images. (previously `projects/kubernetes` in this repository).
- [LinuxKit LCOW](https://github.com/linuxkit/lcow) LinuxKit images and utilities for Microsoft's Linux Containers on Windows.
- [linux](https://github.com/linuxkit/linux) A copy of the Linux stable tree with branches LinuxKit kernels.
- [virtsock](https://github.com/linuxkit/virtsock) A `go` library and test utilities for `virtio` and Hyper-V sockets.
- [rtf](https://github.com/linuxkit/rtf) A regression test framework used for the LinuxKit CI tests (and other projects).
## Getting Started
@@ -71,29 +58,27 @@ linuxkit build linuxkit.yml
to build the example configuration. You can also specify different output formats, eg `linuxkit build -format raw-bios linuxkit.yml` to
output a raw BIOS bootable disk image, or `linuxkit build -format iso-efi linuxkit.yml` to output an EFI bootable ISO image. See `linuxkit build -help` for more information.
Since `linuxkit build` is built around the [Moby tool](https://github.com/moby/tool) the input yml files are described in the [Moby tool documentation](https://github.com/moby/tool/blob/master/docs/yaml.md).
### Booting and Testing
You can use `linuxkit run <name>` or `linuxkit run <name>.<format>` to execute the image you created with `linuxkit build <name>.yml`.
This will use a suitable backend for your platform or you can choose one, for example VMWare.
See `linuxkit run --help`.
You can use `linuxkit run <name>` or `linuxkit run <name>.<format>` to
execute the image you created with `linuxkit build <name>.yml`. This
will use a suitable backend for your platform or you can choose one,
- [Raspberry Pi Model 3b](docs/platform-rpi3.md)`[arm64]`
#### Running the Tests
@@ -106,7 +91,7 @@ To run the test suite:
```
cd test
rtf -x run
rtf -v run -x
```
This will run the tests and put the results in a the `_results` directory!
@@ -115,13 +100,13 @@ Run control is handled using labels and with pattern matching.
To run add a label you may use:
```
rtf -x -l slow run
rtf -v -l slow run -x
```
To run tests that match the pattern `linuxkit.examples` you would use the following command:
```
rtf -x run linuxkit.examples
rtf -v run -x linuxkit.examples
```
## Building your own customised image
@@ -130,7 +115,7 @@ To customise, copy or modify the [`linuxkit.yml`](linuxkit.yml) to your own `fil
generate its specified output. You can run the output with `linuxkit run file`.
The yaml file specifies a kernel and base init system, a set of containers that are built into the generated image and started at boot time. You can specify the type
of artifact to build with the `moby` tool eg `linuxkit build -format vhd linuxkit.yml`.
of artifact to build eg `linuxkit build -format vhd linuxkit.yml`.
If you want to build your own packages, see this [document](docs/packages.md).
@@ -144,7 +129,7 @@ The yaml format specifies the image to be built:
-`services` is the system services, which normally run for the whole time the system is up
-`files` are additional files to add to the image
For a more detailed overview of the options see [yaml documentation](https://github.com/moby/tool/blob/master/docs/yaml.md)
For a more detailed overview of the options see [yaml documentation](docs/yaml.md)
@@ -30,3 +30,49 @@ of dependencies and functionality that we do not need. At present we are using t
`init` process, and a small set of minimal scripts, but we expect to replace that with a small
standalone `init` process and a small piece of code to bring up the system containers where the
real work takes place.
## Console not displaying init or containerd output at boot
If you're not seeing `containerd` logs in the console during boot, make sure that your kernel `cmdline` configuration doesn't list multiple consoles.
`init` and other processes like `containerd` will use the last defined console in the kernel `cmdline`. When using `qemu`, to see the console you need to list `ttyS0` as the last console to properly see the output.
## Troubleshooting containers
Linuxkit runs all services in a specific `containerd` namespace called `services.linuxkit`. To list all the defined containers:
```sh
(ns: getty) linuxkit-befde23bc535:~# ctr -n services.linuxkit container ls
CONTAINER IMAGE RUNTIME
getty - io.containerd.runtime.v1.linux
```
To list all running containers and their status:
```sh
(ns: getty) linuxkit-befde23bc535:~# ctr -n services.linuxkit task ls
- Derived from well-known (and signed) sources for repeatable builds.
- Built with multi-stage builds to minimise their size.
## CI and Package Builds
When building and merging packages, it is important to note that our CI process builds packages. The targets `make ci` and `make ci-pr` execute `make -C pkg build`. These in turn execute `linuxkit pkg build` for each package under `pkg/`. This in turn will try to pull the image whose tag matches the tree hash or, failing that, to build it.
We do not want the builds to happen with each CI run for two reasons:
1. It is slower to do a package build than to just pull the latest image.
2. If any of the steps of the build fails, e.g. a `curl` download that depends on an intermittent target, it can cause all of CI to fail.
Thus, if, as a maintainer, you merge any commits into a `pkg/`, even if the change is documentation alone, please do a `linuxkit package push`.
## Package source
A package source consists of a directory containing at least two files:
@@ -25,6 +37,7 @@ A package source consists of a directory containing at least two files:
-`image`_(string)_: *(mandatory)* The name of the image to build
-`org`_(string)_: The hub/registry organisation to which this package belongs
-`arches`_(list of string)_: The architectures which this package should be built for (valid entries are `GOARCH` names)
-`extra-sources`_(list of strings)_: Additional sources for the package outside the package directory. The format is `src:dst`, where `src` can be relative to the package directory and `dst` is the destination in the build context. This is useful for sharing files, such as vendored go code, between packages.
-`gitrepo`_(string)_: The git repository where the package source is kept.
-`network`_(bool)_: Allow network access during the package build (default: no)
-`disable-content-trust`_(bool)_: Disable Docker content trust for this package (default: no)
@@ -60,9 +73,9 @@ should also be set up with signing keys for packages and your signing
key should have a passphrase, which we call `<passphrase>` throughout.
All official LinuxKit packages are multi-arch manifests and most of
them are available for amd64 and aarm64. Official images *must* be
build on both architectures and they must be build *in sequence*, i.e.,
they can't be build in parallel.
them are available for `amd64`, `arm64`, and `s390x`. Official images
*must* be build on both architectures and they must be build *in
@@ -4,19 +4,27 @@ The `qemu` backend is the most versatile `run` backend for
`linuxkit`. It can boot both `x86_64` and `arm64` images, runs on
macOS and Linux (and possibly Windows), and can boot most types of
output formats. On Linux, `kvm` acceleration is enabled by default if
available.
available. On macOS, `hvf` acceleration (using the Hypervisor
framework) is used if your `qemu` version supports it (versions
released after Jan/Feb 2018 should support it). `s390x` is currently
only supported in `kvm` mode as the emulated `s390x` architecture (aka
`tcg` mode) does not seem to support several required platform
features. Further, on `s390x` platforms you need to set
`vm.allocate_pgste=1` via `sysctl` (or use `echo 1 >
/proc/sys/vm/allocate_pgste`).
## Boot
By default `linuxkit run qemu` will boot with the host architecture
(`x86_64` on `x86_64` machines and`aarch64` on `arm64` systems). The
architecture can be specified with `-arch` and currently accepts
`x86_64` and `aarch64` as arguments.
(e.g.,`aarch64` on `arm64` systems). The architecture can be
specified with `-arch` and currently accepts`x86_64`, `aarch64`, and
`s390x` as arguments.
`linuxkit run qemu` can boot in different types of images:
-`kernel+initrd`: This is the default mode of `linuxkit run qemu` [`x86_64`, `arm64`]
-`kernel+initrd`: This is the default mode of `linuxkit run qemu` [`x86_64`, `arm64`, `s390x`]
-`kernel+squashfs`: `linuxkit run qemu -squashfs <path to directory>`. This expects a kernel and a squashfs image. [`x86_64`, `arm64`, `s390x`]
-`iso-bios`: `linuxkit run qemu -iso <path to iso>` [`x86_64`]
-`iso-efi`: `linuxkit run qemu -iso -uefi <path to iso>`. This looks in `/usr/share/ovmf/bios.bin` for the EFI firmware by default. Can be overwritten with `-fw`. [`x86_64`, `arm64`]
-`qcow-bios`: `linuxkit run qemu disk.qcow2` [`x86_64`]
@@ -25,6 +33,10 @@ architecture can be specified with `-arch` and currently accepts
The formats `qcow-efi` and `raw-efi` may also work, but are currently not tested.
The default `kernel+initrd` boot uses a RAM disk for the root
filesystem. If you have RAM constraints or large images we recommend
using one of the other methods, such as `kernel+squashfs` or booting
* You have to set `root=/dev/vda` in the `cmdline` to have the right device set on boot
* The metadata package is not only used to set the metadata, but also to signal Scaleway that the instance has booted. So it is encouraged to use it (dhcpcd must be set before)
## Push image
You have to do `linuxkit push scaleway scaleway.iso` to upload it to your Scaleway images.
By default the image name is the name of the ISO file without the extension.
It can be overidden with the `-img-name` flag or the `SCW_IMAGE_NAME` environment variable.
**Note 1:** If an image (and snapshot) of the same name exists, it will be replaced.
**Note 2:** The image is region specific: if you create an image in `par1` you can't use is in `ams1`.
### Push process
Building a Scaleway image have a special process. Basically:
* Create an `image-builder` instance with an additional volume, based on Ubuntu Xenial (only x86_64 for now)
* Copy the ISO image on this instance
* Use `dd` to write the image on the additional volume (`/dev/vdb` by default)
* Terminate the instance, create a snapshot, and create an image from the snapshot
**Note 1:** An image is linked to a snapshot, so you can't delete a snapshot before the image.
**Note 2:** You can specify an already running instance to act as the image builder with the `-instance-id` flag. But if you don't specify the `-no-clean` flag it will be destroyed upon completion.
## Create an instance and connect to it
With the image created, we can now create an instance.
```
linuxkit run scaleway scaleway
```
By default, the instance name is `linuxkit`. It can be overidden with the `-instance-name` flag.
If you don't set the `-no-attach` flag, you will be connected to the serial port.
You can edit the Scaleway example to allow you to SSH to your instance in order to use it.
git commit -a -s -m "Update package tags to $LK_RELEASE"
```
### Final preparation steps
- Update AUTHORS by running `./scripts/generate-authors.sh`
- Update the `VERSION` variable in the top-level `Makefile`
- Create an entry in `CHANGELOG.md`. Take a look at `git log v0.3..HEAD` and pick interesting updates (of course adjust `v0.3` to the previous version).
- Create a PR with your changes.
## Releasing
Once the PR is merged we can do the actual release.
- Update your local git clone to the lastest
- Identify the merge commit for your PR and tag it and push it to the main LinuxKit repository (remote `upstream` in my case):
```
git tag $LK_RELEASE master
git push upstream $LK_RELEASE
```
Then head over to GitHub and look at the `Releases` tab. You should see the new tag. Edit it:
- Add the changelog message
- Head over to the Circle CI page of the master build (try the Circle CI badge in the top level `README.md`)
- Download the artefacts and SHA256 sums file.
- Add the downloaded binaries to the release page (drag-and-drop below the editor window)
- Add the `sha256` sums to the release notes on the release page
Hit the `Publish release` button.
This completes the release, but you are not done, one more step is required.
## Post release
Create a PR which bumps the version number in the top-level `Makefile`
to `$LK_RELEASE+` to make sure that the version reported by `linuxkit
The `linuxkit build` command assembles a set of containerised components into in image. The simplest
type of image is just a `tar` file of the contents (useful for debugging) but more useful
outputs add a `Dockerfile` to build a container, or build a full disk image that can be
booted as a linuxKit VM. The main use case is to build an assembly that includes
`containerd` to run a set of containers, but the tooling is very generic.
The yaml configuration specifies the components used to build up an image . All components
are downloaded at build time to create an image. The image is self-contained and immutable,
so it can be tested reliably for continuous delivery.
Components are specified as Docker images which are pulled from a registry during build if they
are not available locally. The Docker images are optionally verified with Docker Content Trust.
For private registries or private repositories on a registry credentials provided via
`docker login` are re-used.
The configuration file is processed in the order `kernel`, `init`, `onboot`, `onshutdown`,
`services`, `files`. Each section adds files to the root file system. Sections may be omitted.
Each container that is specified is allocated a unique `uid` and `gid` that it may use if it
wishes to run as an isolated user (or user namespace). Anywhere you specify a `uid` or `gid`
field you specify either the numeric id, or if you use a name it will refer to the id allocated
to the container with that name.
```
services:
- name: redis
image: redis:latest
uid: redis
gid: redis
binds:
- /etc/redis:/etc/redis
files:
- path: /etc/redis/redis.conf
contents: "..."
uid: redis
gid: redis
mode: "0600"
```
## `kernel`
The `kernel` section is only required if booting a VM. The files will be put into the `boot/`
directory, where they are used to build bootable images.
The `kernel` section defines the kernel configuration. The `image` field specifies the Docker image,
which should contain a `kernel` file that will be booted (eg a `bzImage` for `amd64`) and a file
called `kernel.tar` which is a tarball that is unpacked into the root, which should usually
contain a kernel modules directory. `cmdline` specifies the kernel command line options if required.
To override the names, you can specify the kernel image name with `binary: bzImage` and the tar image
with `tar: kernel.tar` or the empty string or `none` if you do not want to use a tarball at all.
Kernel packages may also contain a cpio archive containing CPU microcode which needs prepending to
the initrd. To select this option, recommended when booting on bare metal, add `ucode: intel-ucode.cpio`
to the kernel section.
## `init`
The `init` section is a list of images that are used for the `init` system and are unpacked directly
into the root filesystem. This should bring up `containerd`, start the system and daemon containers,
and set up basic filesystem mounts. in the case of a LinuxKit system. For ease of
modification `runc` and `containerd` images, which just contain these programs are added here
rather than bundled into the `init` container.
## `onboot`
The `onboot` section is a list of images. These images are run before any other
images. They are run sequentially and each must exit before the next one is run.
These images can be used to configure one shot settings. See [Image
specification](#image-specification) for a list of supported fields.
## `onshutdown`
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
## `services`
The `services` section is a list of images for long running services which are
run with `containerd`. Startup order is undefined, so containers should wait
on any resources, such as networking, that they need. See [Image
specification](#image-specification) for a list of supported fields.
## `files`
The files section can be used to add files inline in the config, or from an external file.
```
files:
- path: dir
directory: true
mode: "0777"
- path: dir/name1
source: "/some/path/on/local/filesystem"
mode: "0666"
- path: dir/name2
source: "/some/path/that/it/is/ok/to/omit"
optional: true
mode: "0666"
- path: dir/name3
contents: "orange"
mode: "0644"
uid: 100
gid: 100
```
Specifying the `mode` is optional, and will default to `0600`. Leading directories will be
created if not specified. You can use `~/path` in `source` to specify a path in the build
user's home directory.
In addition there is a `metadata` option that will generate the file. Currently the only value
supported here is `"yaml"` which will output the yaml used to generate the image into the specified
file:
```
- path: etc/linuxkit.yml
metadata: yaml
```
Because a `tmpfs` is mounted onto `/var`, `/run`, and `/tmp` by default, the `tmpfs` mounts will shadow anything specified in `files` section for those directories.
## `trust`
The `trust` section specifies which build components are to be cryptographically verified with
[Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) prior to pulling.
Trust is a central concern in any build system, and LinuxKit's is no exception: Docker Content Trust provides authenticity,
integrity, and freshness guarantees for the components it verifies. The LinuxKit maintainers are responsible for signing
`linuxkit` components, though collaborators can sign their own images with Docker Content Trust or [Notary](https://github.com/docker/notary).
-`image` lists which individual images to enforce pulling with Docker Content Trust.
The image name may include tag or digest, but the matching also succeeds if the base image name is the same.
-`org` lists which organizations for which Docker Content Trust is to be enforced across all images,
for example `linuxkit` is the org for `linuxkit/kernel`
## Image specification
Entries in the `onboot` and `services` sections specify an OCI image and
options. Default values may be specified using the `org.mobyproject.config` image label.
For more details see the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md).
If the `org.mobylinux.config` label is set in the image, that specifies default values for these fields if they
are not set in the yaml file. You can override the label by setting the value, or setting it to be empty to remove
the specification for that value in the label.
If you need an OCI option that is not specified here please open an issue or pull request as the list is not yet
complete.
By default the containers will be run in the host `net`, `ipc` and `uts` namespaces, as that is the usual requirement;
in many ways they behave like pods in Kubernetes. Mount points must already exist, as must a file or directory being
bind mounted into a container.
-`name` a unique name for the program being executed, used as the `containerd` id.
-`image` the Docker image to use for the root filesystem. The default command, path and environment are
extracted from this so they need not be filled in.
-`capabilities` the Linux capabilities required, for example `CAP_SYS_ADMIN`. If there is a single
capability `all` then all capabilities are added.
-`ambient` the Linux ambient capabilities (capabilities passed to non root users) that are required.
-`mounts` is the full form for specifying a mount, which requires `type`, `source`, `destination`
and a list of `options`. If any fields are omitted, sensible defaults are used if possible, for example
if the `type` is `dev` it is assumed you want to mount at `/dev`. The default mounts and their options
can be replaced by specifying a mount with new options here at the same mount point.
-`binds` is a simpler interface to specify bind mounts, accepting a string like `/src:/dest:opt1,opt2`
similar to the `-v` option for bind mounts in Docker.
-`tmpfs` is a simpler interface to mount a `tmpfs`, like `--tmpfs` in Docker, taking `/dest:opt1,opt2`.
-`command` will override the command and entrypoint in the image with a new list of commands.
-`env` will override the environment in the image with a new environment list. Specify variables as `VAR=value`.
-`cwd` will set the working directory, defaults to `/`.
-`net` sets the network namespace, either to a path, or if `none` or `new` is specified it will use a new namespace.
-`ipc` sets the ipc namespace, either to a path, or if `new` is specified it will use a new namespace.
-`uts` sets the uts namespace, either to a path, or if `new` is specified it will use a new namespace.
-`pid` sets the pid namespace, either to a path, or if `host` is specified it will use the host namespace.
-`readonly` sets the root filesystem to read only, and changes the other default filesystems to read only.
-`maskedPaths` sets paths which should be hidden.
-`readonlyPaths` sets paths to read only.
-`uid` sets the user id of the process.
-`gid` sets the group id of the process.
-`additionalGids` sets a list of additional groups for the process.
-`noNewPrivileges` is `true` means no additional capabilities can be acquired and `suid` binaries do not work.
-`hostname` sets the hostname inside the image.
-`oomScoreAdj` changes the OOM score.
-`rootfsPropagation` sets the rootfs propagation, eg `shared`, `slave` or (default) `private`.
-`cgroupsPath` sets the path for cgroups.
-`resources` sets cgroup resource limits as per the OCI spec.
-`sysctl` sets a map of `sysctl` key value pairs that are set inside the container namespace.
-`rmlimits` sets a list of `rlimit` values in the form `name,soft,hard`, eg `nofile,100,200`. You can use `unlimited` as a value too.
-`annotations` sets a map of key value pairs as OCI metadata.
There are experimental `userns`, `uidMappings` and `gidMappings` options for user namespaces but these are not yet supported, and may have
permissions issues in use.
In addition to the parts of the specification above used to generate the OCI spec, there is a `runtime` section in the image specification
which specifies some actions to take place when the container is being started.
-`cgroups` takes a list of cgroups that will be created before the container is run.
-`mounts` takes a list of mount specifications (`source`, `destination`, `type`, `options`) and mounts them in the root namespace before the container is created. It will
try to make any missing destination directories.
-`mkdir` takes a list of directories to create at runtime, in the root mount namespace. These are created before the container is started, so they can be used to create
directories for bind mounts, for example in `/tmp` or `/run` which would otherwise be empty.
-`interface` defines a list of actions to perform on a network interface:
-`name` specifies the name of an interface. An existing interface with this name will be moved into the container's network namespace.
-`add` specifies a type of interface to be created in the containers namespace, with the specified name.
-`createInRoot` is a boolean which specifes that the interface being `add`ed should be created in the root namespace first, then moved. This is needed for `wireguard` interfaces.
-`peer` specifies the name of the other end when creating a `veth` interface. This end will remain in the root namespace, where it can be attached to a bridge. Specifying this implies `add: veth`.
-`bindNS` specifies a namespace type and a path where the namespace from the container being created will be bound. This allows a namespace to be set up in an `onboot` container, and then
using `net: path` for a `service` container to use that network namespace later.
-`namespace` overrides the LinuxKit default containerd namespace to put the container in; only applicable to services.
An example of using the `runtime` config to configure a network namespace with `wireguard` and then run `nginx` in that namespace is shown below:
command: ["sh", "-c", "ip link set dev wg0 up; ip address add dev wg0 192.168.2.1 peer 192.168.2.2; wg setconf wg0 /etc/wireguard/wg0.conf; wg show wg0"]
runtime:
interfaces:
- name: wg0
add: wireguard
createInRoot: true
bindNS:
net: /run/netns/wg
services:
- name: nginx
image: nginx:alpine
net: /run/netns/wg
capabilities:
- CAP_NET_BIND_SERVICE
- CAP_CHOWN
- CAP_SETUID
- CAP_SETGID
- CAP_DAC_OVERRIDE
```
### Mount Options
When mounting filesystem paths into a container - whether as part of `onboot` or `services` - there are several options of which you need to be aware. Using them properly is necessary for your containers to function properly.
For most containers - e.g. nginx or even docker - these options are not needed. Simply doing the following will work fine:
```yml
binds:
- /var:/some/var/path
```
Please note that `binds` doesn't **add** the mount points, but **replaces** them.
You can examine the `Dockerfile` of the component (in particular, `binds` value of
`org.mobyproject.config` label) to get the list of the existing binds.
However, in some circumstances you will need additional options. These options are used primarily if you intend to make changes to mount points _from within your container_ that should be visible from outside the container, e.g., if you intend to mount an external disk from inside the container but have it be visible outside.
In order for new mounts from within a container to be propagated, you must set the following on the container:
1.`rootfsPropagation: shared`
2. The mount point into the container below which new mounts are to occur must be `rshared,rbind`. In practice, this is `/var` (or some subdir of `/var`), since that is the only true read-write area of the filesystem where you will mount things.
Thus, if you have a regular container that is only reading and writing, go ahead and do:
```yml
binds:
- /var:/some/var/path
```
On the other hand, if you have a container that will make new mounts that you wish to be visible outside the container, do:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
