Anka version update 1.0.2.73 for HiSierra GA release support

We are publishing an updated version 1.0.2.73 for both Anka Build and Anka Flow packages. For the past two months, we have been testing Anka with the HiSierra macOS and have supported the HiSierra beta versions. Today, with this release update, we are supporting the HiSierra GA version.

Some of the things that you can do specifically for HiSierra are as follows:

  1. Run Anka packages on machines running HiSierra macOS and create and run HiSierra Anka VMs.
  2. Create HiSierra Anka VMS and run them on top of Sierra machine


In addition to HiSierra related fixes, this release includes fixes to additional issues reported by our users. Download the new packages from the download page or contact us at support@veertu.com to get details on the download.

https://ankadoc.bitbucket.io/release-notes/

Deep Dive into Anka Registry – Version and Distribute macOS virtual machines at scale

One of the key differentiators in Veertu’s Anka solutions packages (Build And Flow) is Anka Registry for macOS virtual machines. When you look at current DevOps workflows for development on Linux, containers significantly increase CI efficiency by ensuring consistency across multiple developments and release cycles with repeatable development, build, and test environments. For individual developers, containers eliminate the “it works on my machine” problem by ensuring parity for the entire team. This parity exists across the entire environment, on CI, and on the developer machine.

Containers achieve parity with a common repository that contains the artifacts which can be used to build and run container images in a host-agnostic manner and through version management. Anka registry architecture maps this design to managing and distributing environments for development on macOS platform.



macOS natively doesn’t support the concept of running macOS containers and layered container image architecture, however, with Anka Registry we were able to superimpose the registry-based workflow on macOS VM architecture.

Let’s look at how Anka Registry achieves this. When you set up a macOS private cloud with Anka Build virtualization and cloud components, you also set up Anka registry module. Anka registry is a Ubuntu service written in Go. It’s packaged to run as a Docker container for easy deployment, but you can also run it on an Ubuntu VM or any other Linux flavor. It supports both HTTP and HTTPS communication between the registry backend and client. HTTPS is configured with NGINX.

After deploying Anka Registry, engineers can push macOS Anka VMs from the machines running the Anka client package (Anka Flow or Anka Build). In traditional VM storage concepts that exist today, the entire VM is packaged, copied over, stored and managed. This fails to provide benefits of efficiently managing images for dev/test and ensuring consistency across all systems. Anka Registry `push` breaks the macOS VM into the VM configuration and into delta image files. First time push for a macOS VM moves over the VM configuration and the entire VM together. Any subsequent changes to this Anka macOS VM get tagged for version management, and registry `pull` analyzes the VM images and moves only the deltas. The result is a significant reduction in the network requirements and a swift push operation.

Anka also provides the ability to “Instant Start” macOS VMs, which is critical for when you want to set up on-demand provisioning for macOS VMs for development and test CI jobs. For these operations, Anka Build works with macOS VMs stored in the suspended state in the Registry. Things get very interesting when you push and pull suspended-state VMs. In addition to managing the deltas in images for the macOS VMs, with suspended VMs Anka Registry also maintains the state of the VM so that when it’s pulled, it comes over in the same state and is available right away for job execution.

Anka registry pulls also operate similarly to registry push. The first-time pull of an Anka macOS VM will get the entire VM configuration and images. Any subsequent pull request for the same VM analyzes the dependencies and pulls only the deltas.



More optimizations occur when you clone Anka macOS VMs and store and manage them in Anka registry. Registry pull and push use the same concepts of managing deltas and dependencies to reduce the overall footprint on client machines and provide flexibility for easily reproducible macOS environments that start instantly.

We are working on some other exciting ideas for the future roadmap, which will bring this concept even closer to a real container architecture for creating and managing macOS environments for development test. Stay tuned.

Moving from static iOS CI infrastructure to an agile, scalable macOS private cloud

In this blog, we will describe the path to move from static, physical hardware-based build and test iOS CI infrastructure to one that is agile, scalable, and enables infrastructure-as-code for macOS. In short, you will be able to setup an AWS-like self-service macOS private cloud to run your iOS CI jobs in container-like environments to support your iOS developers.

After a broad survey of existing blogs on iOS CI and discussions with multiple iOS development teams, we have reached the following conclusion on the current state of iOS CI infrastructure.

There are only a handful of ways in which teams that are doing on-prem iOS CI (not just builds, but build and automated tests followed by continuous deployment) can set up their macOS infrastructure to support the iOS CI pipelines/jobs. This limitation exists not due to lack of intention to have a more flexible cloud setup, but due to a lack of availability of cloud technology for enterprises to set up macOS dev/test private cloud, which can also extend to iOS developer machines.

Let’s compare and outline the steps to move from existing status quo to a dynamic, infrastructure-as-a-code setup for development on the macOS platform.

iOS CI on Physical Infrastructure Anka Build Cloud iOS CI Infrastructure
Hardware – Mac hardware allocated for Build and test. Hardware – Mac hardware allocated for Build and test.
Prepare the hardware – Keep the macOS versions/updates consistent on all the CI machines. Some users do it with periodic re-imaging. Re-imaging is no longer needed, simply run software update to take advantage of the latest Anka features.
Prepare the machines to act as a build/test node – This step requires installing all dependencies etc. Most users run configuration management tools on CI mac hardware for this. Install Anka Build.pkg on all Build/Test mac hardware, henceforth called Anka Build nodes.
Create macOS Anka VM and provision (installing dependencies) for the CI jobs. You can fully automate this step with ‘anka create’ & ‘anka run’ (even use existing config mgmt scripts).
Version and push the macOS VM prepared in the earlier step to the Anka registry.
Install and setup Anka Build Controller module on a linux machine or container.
Join all Anka Build nodes with the Anka Build Controller.
Add the prepared build/test node to the CI system. Setup Anka Build cloud in CI system of choice (For Jenkins, use Anka plugin).
Every execution of Build/Test CI job first baselines the configuration on the build mac machine and then starts the actual job. Build/test CI job sends a request to Anka Build controller to pull from the registry and provision clean and sandboxed copies of Anka VMs on the Anka build nodes. VMs are preconfigured with all the dependencies.
After job completion, the machine is left in dirty state. After job completion, the VM can be deleted with no traces left on the hardware or kept alive in an isolated state for debugging.
Next job execution consumes job cycles cleaning the machine first, before running the job. Next job run just provisions clean pre-loaded Anka VMs of particular type, pulled from the registry.
Any issues in configuration management during job runs can result in inconsistent build/test environments. Anka VMs are preloaded with all dependencies for a consistent, immutable environment every time.
Total job time for every run gets extended due to the necessity to run configuration management to prepare the environment with all the dependencies. Total job time is actual build/test time with no overheads. First-time pull of a particular build/test Anka VM can be time-consuming, but this can be resolved by “warming up” the Anka Build nodes (pre-warm the Anka Build node by pulling the VM ahead of time).
Any update to dependencies means tweaking configuration management scripts, with no recourse to go back for troubleshooting. Any update to dependencies means, pulling the last good Anka VM build/test environment from the Registry, updating it with new dependencies and pushing it back to the Registry with a new version. Easy to pull an older version to troubleshoot issues or revert to a previous version of infrastructure.
Not easy to replicate the same CI config mgmt on the developer machines. Eliminate “Works on my machine” issue, with developers pulling the same build/test Anka VMs (reproducible envs) from the Registry and using them to build and test on their workstations locally.


Notes:
  • Anka Build product contains all software modules to setup and configure macOS private cloud for iOS CI.
  • Anka Flow product contains all software modules to enable iOS developers to have the same consistent build and test environments as the CI system.
Start with Anka Build first and then, add Anka Flow.