Hacker Newsnew | past | comments | ask | show | jobs | submit | melezhik's commentslogin

nice screenshots are attached


Tomtit is a cli task runner when you need to run repetitive tasks / tools around your project. It’s similar to make, but with more generic approach, not exactly tied to build tasks only


TL;DR how to write data flows / data pipelines with Raku and Sparky. An example of porting simple Nextflow pipeline to Rakulang/Sparky is shown


For what for Cinc/ Ansible used in your solution ? I guess immutable containers do not need provision stage ?


Good question! So, there's actually clear separation of concerns between Ansible and Cinc that makes a lot of sense for this LXC-based approach.

First, these aren't immutable containers – they're LXC containers treated as persistent, stateful systems (more VM-like than Docker-like).

Here's how the tools are used:

Ansible handles the "outside" (Proxmox host level): - Container provisioning via Proxmox API (`base/roles/container/`) - LXC lifecycle management (create, start, stop, destroy) - Base infrastructure setup (SSH keys, networking, storage mounts) - Host-to-container bootstrapping

Cinc (Chef) handles the "inside" (within each container): - Application-specific configuration (`config/recipes/`, `libs//recipes/`) - Service management and desired state enforcement - Runtime configuration updates - Cross-container state coordination (like the Git service managing repositories)

*Why this makes sense for LXC:* Unlike Docker's "build once, deploy everywhere" philosophy, LXC containers in this system are *long-lived infrastructure pieces* that need ongoing configuration management. Each container might run for months/years and needs to adapt to changing requirements, handle updates, manage state, etc.

The recursive self-containment aspect is particularly clever – the control plane (running in its own LXC container) uses the exact same base configuration and tooling as the containers it manages, ensuring consistency and enabling the whole system to bootstrap itself.

So while you're right that immutable containers don't typically need provisioning stages, this isn't really following the immutable container pattern – it's more like "Infrastructure as Code" for persistent container-based services, which absolutely benefits from both provisioning and configuration management layers.


TLDR, How to use Sparrow automation framework to automate: - containers - container templates - networks - timers - services


Thanks


TL;DR

Sparrow is a lightweight automation framework that could be used as drop-in replacement to Ansible or other frameworks suffering from complexity and extra abstraction layers. Sparrow could be an efficient glue allowing people use their preferable scripting languages (Bash/Perl/Python) while adding useful features via Sparrow SDK - scripts configuration, testing, distribution


TL;DR - How to invert k8s deployments using application less containers design


Time for Hashicorp Nomad to make its comeback?


To install Sparrow on alpine just:

apk add --no-cache --wait 120 -u --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community raku-sparrow6

And then to run utility:

git clone https://github.com/melezhik/apkbuild-strict.git &&

cd apkbuild-strict && s6 —task-run .@path=/path/to/apkbuild-file


The utility is written on Rakulang and Sparrow


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: