Container like ‘anka run’ interface for Anka macOS VM

Anka run command line interface enables command execution inside Anka macOS VMs directly from the host. It’s very similar to container docker run.

Why is this interesting – It allows Devops to take their existing container based Linux CI workflow automation, repurpose it for macOS and use it on Anka Build macOS Cloud infrastructure for iOS CI.

anka run --help

Usage: anka run [OPTIONS] VM_NAME COMMAND [ARGS]...

Run commands inside VM environment

Options:

-w, --workdir PATH Working directory inside the VM [optional]

-v, --volumes-from, --volume PATH Mount host directory (current directory by default) into VM . '--volumes-from' is deprecated form [optional]

-n, --no-volumes-from, --no-volume Use this flag to prevent implicit mounting of current folder (see --volume option). '--no-volumes-from' is deprecated form [optional]

-E, -e, --env Inherit environment variables. '-e' is deprecated form [optional]

-f, --env-file PATH Provide environment variables from file [optional]

-N, --wait-network Wait till guest network interface up [optional]


‘anka run’ by default mounts the current folder from the host into the Anka macOS VM and executes commands on this mount point as the current directory. Upon completion of command execution, the mount directory is automatically released. As a developer, this can be quite useful to be able to execute operations inside the VM environment in an isolated manner using artifacts/code residing on the developer machine. Example,

anka run xcodebuild -sdk iphonesimulator -scheme Kickstarter-iOS build

–volume (-v) – Mount directory into VM. Mountpoint could be specified explicitly in this form:–volume /host/dir:/mountpoint, or assigned dynamically: –volume /host/dir. If no –workdir option is specified, mountpoint will be selected as working directory for running command.

Example : anka run -v ~/Projects/anka:/tmp/anka run build

–no-volume (-n) – By default anka run command mounts current directory into VM, (implicit –volume $PWD option). Specify this option to disable implicit mounting. If no –workdir option is specified, working directory will be set to VM user’s home directory.

Example :

anka run -n xcodebuild -sdk iphonesimulator -scheme Kickstarter-iOS build - Will not mount the current host directory and execute build in the VM current directory.

–workdir (-w) – Specify working directory inside the VM

Example :

anka run -n -w /tmp/workspace/project git clone ${URL} src


anka run -n -w /tmp/workspace/project/src xcodebuild

–env (-E) – Inherit host environment variables in non-overriding mode. Example : CFLAGS=-O2 CC=clang anka run -E ${VM} make test.c

–env-file (-f) – Provide environment variables in overriding mode from file specified. Format of the environment file can be:

VAR=VALUE

VAR2=VALUE2

–wait-network (-N) – Resumed VMs require some time to reconfigure networking interface, so scripts which use networking immediately (e.g: git clone) could fail on network inaccessibility. This option postpones execution of the command till network is up. Incorporate it in your VM bootstrapping automation before starting to access network from inside the VM.

Scaling iOS CI infrastructure with Anka Build

You start with one iOS app and then it morphs into multiple apps, and you are shipping a new version of all these apps frequently to the app store without compromising on quality. How do you do it?

First, you build an application architecture that supports the scale – a large team of developers working on same codebase and flexibility and ability to expose new features quickly to the users. Then, you invest in test automation to have multiple sets of tests for different workflows and features in your app. And, you invest in CI and CD infrastructure that eliminates wait times for developers between builds, faster feedback from tests and quick deployment to the app stores.

In this blog we will focus on how you scale and manage iOS CI build/test infrastructure to support a high velocity of development and increased code quality for releases.

We see users adopting one of three approaches to address the scale challenge of iOS CI infrastructure and introduce a new method outlined in Option 4.

Option 1 – Increase the bare metal mac hardware capacity for build and test machines

This results in increased hardware costs, but also means significantly higher system management overhead. Devops and system management team need to plan for additional complexity in build and test environment configuration management across all the hardware, capacity planning and sharding strategies to test concurrently on multiple versions of application dependencies. Due to imaging-based approach, repeated set of these operations on the same hardware also results in stability issues.

Option 2 – Consuming hosted CI iOS build services

These services are provided as multi-tenant/shared basis and in most cases unable to meet the extensive scale requirements of a single user. Additionally, there is an exponential increase in cost as the usage goes up. You are no longer in the lowest/cheapest service tier but have to move to a custom tier.

Option 3 – Scaling with legacy based virtualized infrastructure

There are some supported and(some unsupported) approaches to set up a virtualized infrastructure on top of Mac hardware which can be used to spin up iOS build and test environments on-demand. The underlying technology to virtualize in such case uses a shared storage infrastructure to support scale(more than one host). With base VM images stored as snapshots in shared storage, new instances of a VM and all the build and test job IO operations execute on shared storage infrastructure. This places extremely short response times demands on shared storage and can only be achieved at a very high cost, low latency shared storage architecture. As you scale up this infrastructure, the prices for shared storage increases exponentially. The long-term TCO of should be considered before starting with this option.

Option 4 – Setup cloud/virtualized infrastructure which can scale linearly and operates as infra-as-a-code.

The concept of containers bring this concept to Linux and Windows infrastructure; however, it’s not yet possible to run macOS inside a container. Anka Build virtualization uses macOS native hypervisor framework to create and run lightweight macOS VMs. Similar to container provisioning, it provides provisioning of macOS environments from ‘macOS.app’ package in a fully programmable manner. Anka Build Cloud exposes features to store, version and manage multiple macOS images in a central registry, similar to container registry and also provides a programmable interface to pull and push these images across various host mac machines. Once the image is pulled on a Mac host machine, immutable VMs on-demand are provisioned by cloning the already pulled image and deleted after the build/test job execution. There is no need for a shared storage architecture attached to each mac host. Additional mac hosts can be added to an existing Anka Cloud setup linearly to scale the CI iOS infrastructure with minimal effort.

Get more details on Anka Build macOS Cloud architecture and registry setup at www.veertu.com.