Skip to content

Composability: Orchestrating Infrastructure with Babashka and BigConfig Package

ansible

In the world of Clojure and DevOps, Babashka has become the gold standard for fast, scripted automation. Today, we’re exploring how to leverage the BigConfig Package with Babashka to create highly composable infrastructure workflows that are as flexible as they are powerful.

One of BigConfig Package’s greatest strengths is its CLI-first approach. You can invoke the walter package directly from your terminal to run complex sequences in a single line. For example, to cycle through an environment lifecycle:

Terminal window
bb walter create delete create delete
  • bb: The Babashka runtime.
  • walter: The specific task defined in your configuration.
  • create/delete: Individual steps within the workflow. You can chain these steps in any order or frequency required by your pipeline.

To integrate walter package into your project, define your dependencies and tasks in your bb.edn file. This acts as the central configuration for your automation.

bb.edn
{:deps {io.github.amiorin/walter {:git/sha "4ea205299cf34c29fa289eacb512a31bfe604d93"}}
:tasks
{:requires ([io.github.amiorin.walter.package :as package]
[io.github.amiorin.walter.tools :as walter]
[io.github.amiorin.alice.tools :as alice])
tofu {:doc "Render and apply OpenTofu (Terraform) plans"
:task (walter/tofu* *command-line-args* (package/walter-opts {:big-config.workflow/params {:hyperscaler "oci"}}))}
ansible {:doc "Run Ansible playbooks"
:task (walter/ansible* *command-line-args* (package/walter-opts {}))}
ansible-local {:doc "Run local Ansible playbooks via the 'alice' package"
:task (alice/ansible-local* *command-line-args* (package/walter-opts {}))}
walter {:doc "Primary Walter workflow"
:task (package/walter* *command-line-args* {:big-config.workflow/params {:hyperscaler "oci"}})}}}
  • :deps: Targets the specific Git SHA of the walter package for reproducible builds.
  • Workflow Structure: A package typically splits logic between package.clj and tools.clj. The former composes multiple tools—like OpenTofu and Ansible—into a unified, high-level workflow.

The walter task utilizes a primary parameter: :hyperscaler. Currently, the package offers out-of-the-box support for Oracle Cloud (OCI) and Hetzner.

The function (package/walter-opts ...) is the “glue” of the system. It handles two critical requirements:

  1. Directory Mapping: Every tool needs a specific location to render configuration files. This function ensures these are correctly mapped based on the parent workflow.
  2. Options Consistency: By populating the :big-config.workflow/params, it ensures that all tasks—whether tool-specific or package-wide—share the same options.

BigConfig Package excels at mixing and matching. While tofu and ansible are defined inside the walter package, you can seamlessly pull in tasks like ansible-local from entirely different packages (such as alice).

Developer Tip: Even when nesting workflows inside a larger process, you retain the ability to invoke sub-workflows interactively. This makes debugging specific infrastructure segments significantly faster.

By transforming standard Terraform and Ansible code into a managed workflow, you gain the ability to invoke resources multiple times with surgical precision. Since the only persistent state is the Terraform state (ideally stored in an S3 backend), your entire team can operate the same resources from different machines.

Beyond standard deployment, BigConfig Package provides built-in coordination steps like git-check, git-push, lock, and unlock-any. These utilities ensure that whether you are working in a tool-specific workflow or a massive package-wide deployment, your team remains in sync and your iing and configuration management, BigConfig Package removes the friction typically found in multi-cloud deployments. This modular anfrastructure remains stable.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.