Replace moby build with linuxkit build throughout

Signed-off-by: Justin Cormack <[email protected]>

README.md

@@ -47,14 +47,14 @@ Build requirements from source:
 Once you have built the tool, use
 
 ```
-moby build linuxkit.yml
+linuxkit build linuxkit.yml
 ```
-to build the example configuration. You can also specify different output formats, eg `moby build -format raw-bios linuxkit.yml` to
-output a raw BIOS bootable disk image, or `moby build -format iso-efi linuxkit.yml` to output an EFI bootable ISO image. See `moby build -help` for more information.
+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.
 
 ### Booting and Testing
 
-You can use `linuxkit run <name>` or `linuxkit run <name>.<format>` to execute the image you created with `moby build <name>.yml`.
+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`.
 
@@ -105,11 +105,11 @@ rtf -x run linuxkit.examples
 
 ## Building your own customised image
 
-To customise, copy or modify the [`linuxkit.yml`](linuxkit.yml) to your own `file.yml` or use one of the [examples](examples/) and then run `moby build file.yml` to
+To customise, copy or modify the [`linuxkit.yml`](linuxkit.yml) to your own `file.yml` or use one of the [examples](examples/) and then run `linuxkit build file.yml` to
 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 `moby build -format vhd linuxkit.yml`.
+of artifact to build with the `moby` tool eg `linuxkit build -format vhd linuxkit.yml`.
 
 If you want to build your own packages, see this [document](docs/packages.md).
 

blueprints/README.md

@@ -27,7 +27,7 @@ An initial blueprint for the open source components of Docker for Mac is availab
 To build it with the latest Docker CE:
 
 ```
-$ moby build -name docker-for-mac base.yml docker-ce.yml
+$ linuxkit build -name docker-for-mac base.yml docker-ce.yml
 ```
 
 To run the VM with a 4G disk:

docs/platform-aws.md

@@ -22,7 +22,7 @@ export AWS_REGION=eu-west-1
 AWS requires a `RAW` image. To create one:
 
 ```
-$ moby build -format aws examples/aws.yml
+$ linuxkit build -format aws examples/aws.yml
 ```
 
 ## Push image

docs/platform-azure.md

@@ -2,7 +2,7 @@
 
 This is a quick guide to running VMs based on LinuxKit images on Azure. Please note that these images currently do not include the [Azure Linux Agent](https://github.com/Azure/WALinuxAgent). As a result, after creating the VM, the portal will report that the creation failed. If you created the VHD properly, you will still be able to SSH into the machine.
 
-When running `linuxkit run azure`, the image you created using `moby build` will be uploaded to Azure in a resource group, and a VM will be created, along with the necessary resources (virtual network, subnet, storage account, network security group, public IP address).
+When running `linuxkit run azure`, the image you created using `linuxkit build` will be uploaded to Azure in a resource group, and a VM will be created, along with the necessary resources (virtual network, subnet, storage account, network security group, public IP address).
 
 Since Azure does not offer access to the serial output of the VM, you need to have SSH access to the machine in order to attach to it. Please see the example below.
 
@@ -23,7 +23,7 @@ here](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-gro
 
 ## Build an image
 
-Create a new `azure.yml` file [based on the Azure example](../examples/azure.yml), generate a new SSH key and add it in the `yml`, then `moby build -format vhd azure.yml`.
+Create a new `azure.yml` file [based on the Azure example](../examples/azure.yml), generate a new SSH key and add it in the `yml`, then `linuxkit build -format vhd azure.yml`.
 
 
 This will output a `azure.vhd` image.

docs/platform-gcp.md

@@ -50,11 +50,11 @@ Make sure to download the credentials in JSON format and store them somewhere sa
 
 ## Build an image
 
-When using `moby build ...` to build an image, specify `-format gcp` to
+When using `linuxkit build ...` to build an image, specify `-format gcp` to
 build an image in a format that GCP will understand. For example:
 
 ```
-moby build -format gcp myprefix.yml
+linuxkit build -format gcp myprefix.yml
 ```
 
 This will create a local `myprefix.img.tar.gz` compressed image file.

docs/platform-packet.md

@@ -55,15 +55,15 @@ For example, to boot the [example](../examples/packet.net)
 with a local HTTP server:
 
 ```sh
-moby build packet.yml
+linuxkit build packet.yml
 # run the web server
 # run 'ngrok http 8080' in another window
 PACKET_API_KEY=<API key> PACKET_PROJECT_ID=<Project ID> \
 linuxkit run packet -serve :8080 -base-url <ngrok url> packet
 ```
 
 To boot a `arm64` image for Type 2a machine (`-machine
-baremetal_2a`) you currently need build using `moby build packet.yml packet.arm64.yml` and then un-compress both the kernel and
+baremetal_2a`) you currently need build using `linuxkit build packet.yml packet.arm64.yml` and then un-compress both the kernel and
 the initrd before booting, e.g:
 
 ```sh

docs/platform-rpi3.md

@@ -22,7 +22,7 @@ build. See the [`kernel`](./kernels.md) documentation for details.
 
 We use the mainline Linux kernels for the Raspberry Pi and it is
 booted via [`uboot`](https://www.denx.de/wiki/U-Boot). The `moby`
-tool, via `moby build -format rpi3 <YAML>`, currently produces a `tar`
+tool, via `linuxkit build -format rpi3 <YAML>`, currently produces a `tar`
 archive which can be extracted onto a FAT32 formatted SD card to boot
 your Raspberry Pi.
 

docs/platform-vmware.md

@@ -21,7 +21,7 @@ Supported (Tested) versions:
 ## Run
 ### VMware Workstation/Fusion
 The backend `vmware` currently supports the booting of a `.vmdk` file that is
-created through the `moby build -format vmdk` command and is typically called with
+created through the `linuxkit build -format vmdk` command and is typically called with
 `linuxkit run vmware <args> ./path`.
 
 The WS/Fusion backend will construct a config version 8 (Hardware version 12)
@@ -30,7 +30,7 @@ use the `vmrun` utility to start the virtual machine.
 
 ### VMware vSphere/vCenter
 The backend `vsphere` currently supports booting through an `iso` file that is
-created through the `moby build -o iso-bios` and is started with `linuxkit run
+created through the `linuxkit build -o iso-bios` and is started with `linuxkit run
 vcenter <args> ./path`.
 
 The vSphere/vCenter backend requires a user to have `pushed` a linuxkit `iso` to

pkg/swap/README.md

@@ -78,6 +78,6 @@ An example yml file is included in [examples/swap.yml](../../examples/swap.yml).
 The sample command to run the enclosed is:
 
 ```
-moby build swap.yml
+linuxkit build swap.yml
 linuxkit run -disk size=4G swap
 ```

projects/clear-containers/README.md

@@ -67,7 +67,7 @@ To generate the kernel image called `clear-containers-bzImage`, enter the
 following command:
 
 ```
-./bin/moby build ./projects/clear-containers/clear-containers.yml
+./bin/linuxkit build ./projects/clear-containers/clear-containers.yml
 ```
 
 3. Test kernel

projects/clear-containers/tools/Makefile

@@ -26,7 +26,7 @@ qemu-lite: docker_image $(KERNEL_FILE) $(CMDLINE_FILE)
 		bash
 
 $(KERNEL_FILE):
-	$(MKFILE_DIR)/../../../bin/moby build $(MKFILE_DIR)/../clear-containers.yml
+	$(MKFILE_DIR)/../../../bin/linuxkit build $(MKFILE_DIR)/../clear-containers.yml
 
 push: docker_image
 	docker push clearcontainers/$(IMAGE)

projects/compose/Makefile

@@ -22,11 +22,11 @@ push: tag
 
 dynamic:
 	mkdir -p dist
-	moby build -name compose-dynamic -dir dist/ compose-dynamic.yml
+	linuxkit build -name compose-dynamic -dir dist/ compose-dynamic.yml
 
 static: cache-images
 	mkdir -p dist
-	moby build -name compose-static -dir dist/ compose-static.yml
+	linuxkit build -name compose-static -dir dist/ compose-static.yml
 
 run-dynamic:
 	linuxkit run dist/compose-dynamic

projects/etcd/README.md

@@ -85,7 +85,7 @@ docker run --rm -ti etcd.local etcdctl member list
 docker run --rm -ti etcd.local etcdctl cluster-health
 ```
 
-You can perform rolling updates, by for example, switching the kernel version in `etcd.yml`, build a new moby, e.g., `moby build -name etcd-4.10 etcd`, update `infrakit.json`, and then commit the new configuration to InfraKit: `infrakit group commit infrakit.json`.
+You can perform rolling updates, by for example, switching the kernel version in `etcd.yml`, build a new moby, e.g., `linuxkit build -name etcd-4.10 etcd`, update `infrakit.json`, and then commit the new configuration to InfraKit: `infrakit group commit infrakit.json`.
 
 
 ## Infrakit GCP setup

projects/ima-namespace/Makefile

@@ -3,7 +3,7 @@ run: ima-namespace-kernel
 	../../bin/linuxkit run ima-namespace
 
 ima-namespace-kernel: ima-namespace.yml
-	../../bin/moby build -format kernel+initrd ima-namespace
+	../../bin/linuxkit build -format kernel+initrd ima-namespace
 
 .PHONY: clean
 clean:

projects/miragesdk/README.md

@@ -50,7 +50,7 @@ the hardware support is available.
   development directions.
 
 - We are also packaging up the Alpine `dhcpcd` with the same configuration conventions
-  as the MirageSDK replacement, so that they can swapped in a `moby build` with a single
+  as the MirageSDK replacement, so that they can swapped in a `linuxkit build` with a single
   line change in the YAML file.
 
 - We will engage external reviewers on the security architecture once we have the first
@@ -63,6 +63,6 @@ the hardware support is available.
 # Getting Started
 
 ```
-../../bin/moby build examples/mirage-dhcp.yml`
+../../bin/linuxkit build examples/mirage-dhcp.yml`
 ../../bin/linuxkit run mirage-dhcp
 ```

reports/2017-03-19.md

@@ -37,7 +37,7 @@ Welcome everyone, looking forward to your contrinutions and working with you. Pl
 
 ## This week
 
-We are working towards a simpler and better documented basic flow. Early next week the `moby` tool will be changed to have `moby build` and `moby run` subcommands. At least initially the `moby run` flow will only be targeted at running locally (hyperkit and kvm, qemu). We may add a third cluster run option later, using infrakit. @rneugeba has been working on Go hyperkit bindings to make this easier in [#1327](https://github.com/docker/moby/pull/1327).
+We are working towards a simpler and better documented basic flow. Early next week the `moby` tool will be changed to have `linuxkit build` and `moby run` subcommands. At least initially the `moby run` flow will only be targeted at running locally (hyperkit and kvm, qemu). We may add a third cluster run option later, using infrakit. @rneugeba has been working on Go hyperkit bindings to make this easier in [#1327](https://github.com/docker/moby/pull/1327).
 
 There is a `--name` option to the `moby` tool to allow configuring of the image names that are built see [#1318](https://github.com/docker/moby/pull/1318) rather than just using the yaml file name.
 

reports/2017-03-26.md

@@ -18,14 +18,14 @@ A WIP PR for the HPE OKernel work was added [#1373](https://github.com/docker/mo
 
 ## This week
 
-The big change this week was reworking the command line tool, so it now has `moby build` and `moby run` options. The aim of the `moby run` option is to cover the simple cases
+The big change this week was reworking the command line tool, so it now has `linuxkit build` and `moby run` options. The aim of the `moby run` option is to cover the simple cases
 where you want to test out an image you have built; it is not intended as a production tool, just as a simpler workflow for testing. The aim is to have a default option per
 platform, such as the hyperkit option there is for MacOS now, so we will add Qemu/KVM support for Linux and Hyper-V support for Windows. In addition there will be support for
 optional drivers, such as local VMWare Fusion, as discussed in [#1357](https://github.com/docker/moby/pull/1357) which can have their own custom options; we will probably add the GCE
 support here too to make it even simpler to run.
 
-In addition to `moby build` and `moby run` we have previously discussed adding a `moby cluster` type option to simply create a cluster, by default with infrakit, essentially as a
-simple infrakit wrapper. Again this is not intended for production use but just to run simple test and development cases. For production that plan is that `moby build` can produce
+In addition to `linuxkit build` and `moby run` we have previously discussed adding a `moby cluster` type option to simply create a cluster, by default with infrakit, essentially as a
+simple infrakit wrapper. Again this is not intended for production use but just to run simple test and development cases. For production that plan is that `linuxkit build` can produce
 the artifacts you need for your production ops tooling.
 
 A whole lot more code has been moved to Go code this week; in addition to the hyperkit bindings, some of the Docker containers that we were using for build have been removed. The next

reports/2017-04-02.md

@@ -30,7 +30,7 @@ Small changes:
 - `.yaml` files were renamed to `.yml` for consistency with common usage elsewhere
 - fixes for console handling
 - kernel updates, additional driver support
-- `moby build` now logs what it is doing by default, to help debugging. There is a quiet option to disable.
+- `linuxkit build` now logs what it is doing by default, to help debugging. There is a quiet option to disable.
 
 ## Planned for next week
 

reports/2017-04-30.md

@@ -12,7 +12,7 @@ Quite a few changes post DockerCon as we started making more breaking changes.
 
 ### Command move and rename
 
-The `moby` command was split up, into [`moby/tool`](https://github.com/moby/tool/) for just the assembly phase, ie `moby build` and the `linuxkit` tool in the LinuxKit repo for the parts that are specific to VM images. This is not the final arrangement, in particular the build process will probably be reworked into more phases, and be made more modular. The `linuxkit` command had a `push` stage added, which can push VM images to remote store; currently this supports pushing images to Google Cloud but more will be added. A lot of rework is planned with the `moby` tool, and it will move to [https://github.com/moby/moby](https://github.com/moby/moby) soon.
+The `moby` command was split up, into [`moby/tool`](https://github.com/moby/tool/) for just the assembly phase, ie `linuxkit build` and the `linuxkit` tool in the LinuxKit repo for the parts that are specific to VM images. This is not the final arrangement, in particular the build process will probably be reworked into more phases, and be made more modular. The `linuxkit` command had a `push` stage added, which can push VM images to remote store; currently this supports pushing images to Google Cloud but more will be added. A lot of rework is planned with the `moby` tool, and it will move to [https://github.com/moby/moby](https://github.com/moby/moby) soon.
 
 ### CI
 

reports/2017-05-22.md

@@ -51,7 +51,7 @@ Documentation:
 ## Issues of interest
 
 - [linuxkit/linuxkit#1835] Build  my own kernel was closed ([@rneugeba] [@justincormack] [@yankunsam])
-- [linuxkit/linuxkit#1841] Windows moby build failed was closed ([@rneugeba] [@tippexs])
+- [linuxkit/linuxkit#1841] Windows linuxkit build failed was closed ([@rneugeba] [@tippexs])
 - [linuxkit/linuxkit#1845] [Question] Run service container with elevated privileges was closed ([@radu-matei])
 - [linuxkit/linuxkit#1846] Can busybox in the root fs be stripped down more? was closed ([@rneugeba] [@justincormack] [@avsm])
 - [linuxkit/linuxkit#1847] Selection of architecture in config by `moby` tool was closed ([@mor1])
@@ -78,7 +78,7 @@ Documentation:
 - [linuxkit/rtf#13] Add ability to run a single test or a group had 3 events ([@rneugeba] [@dave-tucker])
 - [linuxkit/linuxkit#1839] After halt, it will been blocked  and have no response had 4 events ([@yankunsam] [@avsm] [@rneugeba] [@thebsdbox])
 - [linuxkit/linuxkit#1837] `ctr exec -t` hangs had 6 events ([@FrenchBen] [@avsm] [@rneugeba] [@justincormack])
-- [linuxkit/linuxkit#1421] Add build support for Azure to `moby build` had 7 events ([@justincormack] [@radu-matei])
+- [linuxkit/linuxkit#1421] Add build support for Azure to `linuxkit build` had 7 events ([@justincormack] [@radu-matei])
 
 Other reports in this series can be browsed directly in the repository at [linuxkit/linuxkit:/reports](https://github.com/linuxkit/linuxkit/tree/master/reports/).
 

reports/2017-06-19-summit.md

@@ -5,7 +5,7 @@
 - `moby` tool producing disk images
 - Currently moby tool calls out to linuxkit to do the build
 - moby tool was initially just for building linux images but now it supports docker and other formats
-- Could make `moby build` into a library and other tools like Infrakit could use it [PR opened](https://github.com/moby/tool/pull/91)
+- Could make `linuxkit build` into a library and other tools like Infrakit could use it [PR opened](https://github.com/moby/tool/pull/91)
 - Currently Infrakit shells out to Moby tool
 
 ### What platforms do people want to support for Linuxkit?

reports/sig-security/2017-06-21.md

@@ -43,7 +43,7 @@ Scribe: @mgoelzer
     - integrity
     - freshness
     - survivability after key compromise
-  - Linuxkit yaml files container `trust:` block - tells moby builder that you want to verify all images in a given organization or per image control
+  - Linuxkit yaml files container `trust:` block - tells linuxkit builder that you want to verify all images in a given organization or per image control
   - Moby builder will first check the signatures for all images and validate expiration dates before pulling images
   - Future directions:
     - key pinning for signed packages

test/Makefile

@@ -5,15 +5,11 @@ pr: check-deps test-pr
 # TODO: should have a separate target
 all: check-deps test-pr ltp
 
-MOBY:=$(shell command -v moby 2> /dev/null)
 LINUXKIT:=$(shell command -v linuxkit 2> /dev/null)
 RTF:=$(shell command -v rtf 2> /dev/null)
 
 .PHONY: check-deps
 check-deps:
-ifndef MOBY
-	$(error "moby is not available. please install it.")
-endif
 ifndef LINUXKIT
 	$(error "linuxkit binary not found. please install it.")
 endif
@@ -31,7 +27,7 @@ gcp-hack: ../artifacts/test.img.tar.gz
 ../artifacts/test.img.tar.gz:
 	rm -rf ../artifacts
 	mkdir -p ../artifacts
-	$(MOBY) build -format gcp -pull -name ../artifacts/test hack/test.yml
+	$(LINUXKIT) build -format gcp -pull -name ../artifacts/test hack/test.yml
 
 define check_test_log
 	@cat $1 |grep -q 'test suite PASSED'
@@ -40,7 +36,7 @@ endef
 .PHONY: ltp
 ltp: export CLOUDSDK_IMAGE_NAME?=test-ltp
 ltp: $(LINUXKIT) test-ltp.img.tar.gz
-	$(MOBY) build -format gcp -pull hack/test-ltp.yml
+	$(LINUXKIT) build -format gcp -pull hack/test-ltp.yml
 	$(LINUXKIT) push gcp test-ltp.img.tar.gz
 	$(LINUXKIT) run gcp -skip-cleanup -machine n1-highcpu-4 $(CLOUDSDK_IMAGE_NAME) | tee test-ltp.log
 	$(call check_test_log, test-ltp.log)

test/cases/000_build/000_outputs/000_kernel+initrd/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format kernel+initrd -name "${NAME}" ../test.yml
+linuxkit build -format kernel+initrd -name "${NAME}" ../test.yml
 [ -f "${NAME}-kernel" ] || exit 1
 [ -f "${NAME}-initrd.img" ] || exit 1
 [ -f "${NAME}-cmdline" ] || exit 1

test/cases/000_build/000_outputs/001_iso-bios/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format iso-bios -name "${NAME}" ../test.yml
+linuxkit build -format iso-bios -name "${NAME}" ../test.yml
 [ -f "${NAME}.iso" ] || exit 1
 
 exit 0

test/cases/000_build/000_outputs/002_iso-efi/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format iso-efi -name "${NAME}" ../test.yml
+linuxkit build -format iso-efi -name "${NAME}" ../test.yml
 [ -f "${NAME}"-efi.iso ] || exit 1
 
 exit 0

test/cases/000_build/000_outputs/003_gcp/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format gcp -name "${NAME}" ../test.yml
+linuxkit build -format gcp -name "${NAME}" ../test.yml
 [ -f "${NAME}.img.tar.gz" ] || exit 1
 
 exit 0

test/cases/000_build/000_outputs/004_aws/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format aws -name "${NAME}" ../test.yml
+linuxkit build -format aws -name "${NAME}" ../test.yml
 [ -f "${NAME}.raw" ] || exit 1
 
 exit 0

test/cases/000_build/000_outputs/006_vhd/test.sh

@@ -17,7 +17,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format vhd -name "${NAME}" ../test.yml
+linuxkit build -format vhd -name "${NAME}" ../test.yml
 [ -f "${NAME}.vhd" ] || exit 1
 
 exit 0

test/cases/000_build/000_outputs/007_vmdk/test.sh

@@ -16,7 +16,7 @@ clean_up() {
 
 trap clean_up EXIT
 
-moby build -format vmdk -name "${NAME}" ../test.yml
+linuxkit build -format vmdk -name "${NAME}" ../test.yml
 [ -f "${NAME}.vmdk" ] || exit 1
 
 exit 0