Bob: A build system for microservices powered by Nix

blaggacao · August 29, 2022, 1:13am

Thanks for the detailed reply! I was actually just on the lookout for some code pointers…

I just tried to capture our current best practices (@ IOG / IOHK) in a publicly available pattern explainer:

divnix/std/blob/de39e5736392a7dc626265d5ea2be21f9ac71cf3/docs/patterns/four-packaging-layers.md

> _This is an opinionated pattern._
>
> _It helps structure working together on microservices with `std`._

# The 4 Layers of Packaging

## The Problem

We have written an application and now we want to package and run it.
For its supply chain security benefits, we have been advised to employ reproducible and source-based distribution mechanisms.
We furthermore need an interoperability platform that is generic and versatile: a _configuration "lingua franca"_.
Our peers who write another application in another language should share that same approach.
Thereby, we avoid the negative external effects of DevOps silos on integrators and operators, alike.
Short: we make adoption of our application as easy as possible for our consumers.

## The Actors

_Note, that each actor persona can be exercised by one and the same person or a group of persons.
Although possible, and even frequently so, it doesn't imply that these roles are necessarily taken by distinct individuals._

This file has been truncated. show original

The workings on how to obsolete CI description for all parts of the workflow except any “Probing & Attestation” stages (such as e2e testing, benchmarking, load testing, monkey testing, property testing, fuzzying, etc) is the following:

All involved organelles (packages.nix, entrypoints.nix, oci-images.nix & <shed>Charts.nix) are inherently typed and easily discoverable by a pipline tooling ootb (there is even already a hidden implementation of an after keyword in std that can by used to construe a DAG across cells, organelles and targets).

Each of these typed organelles (types are called esoterically “clades”) have well-known clade actions. For example, for clades.containers, there is copy-to-registry, or in full on the CLI: std //cell/oci-images/myimage:copy-to-registry.

Consequentially, for the core parts of building, testing up to publishing artifacts, the CI already could “know” what to do without any further instructions as a collateral side effect of code organization and nix-based (source-based) distribution.

So this is where I see a strong value of a “Bob preset for Standard” or something like that.

The beauty of Bob here is, that it can be made gradual: start with a bob.yaml and only adopt the stdized “4 Layers of Packaging” with some help from the “big boys” (in the subject of source-based distribution) in your organization… And it’ll be still bob run and feel magically the same. Just now, your downstream integrators also can experience the joy.

EDIT: in this context, please also have a look at the following draft doc on how to make OCI-image building a truly emergent property of the “entrypoint discussion” (between Devs & Ops).

github.com

divnix/std/blob/f64c112aa4c98f76663abe96ac27552920875f73/cells/std/lib/writeShellEntrypoint.md

# `writeShellEntrypoint`

... is a function to write Standard OCI-image entrypoints.

The function signature is as follows:

```nix
{
  # the installable that is wrapped by this entrypoint (re-exported)
  package,
  # the literal bash string of the entrypoint that will be wrapped
  entrypoint,
  # initialize environment variables with these defaults
  env ? {},
  # runtime installables that the entrypoint or liveness/readiness probe uses (re-exported)
  runtimeInputs ? [],
  # domain specific debugging utilities (re-exported)
  debugInputs ? [],
  # domain specific liveness probe literal bash fragment (re-exported)
  livenessProbe ? null,

This file has been truncated. show original