We released #Rex last year, which was really a dream come true for us. As historians, it was a thrill to return to the Roman regal period and bring together sources, the big questions about that time, and a good dose of our humour.
Meet #Rex, a light #Perl framework to perform devop operations, which can be easily customized for multiple use cases. And it's not a single-company show, which is a nice plus.
Automation challenges often focus on remote endpoints, while several use cases require automating locally as well. Typical situations range from managing a personal machine, through setups where the managed fleet includes the host managing the whole, to pull-style models where each node manages itself.
#Rex, the friendly automation framework supports any combination of local and remote execution. This post summarizes the main orientation points about local management:
how do you manage your dotfiles in your ~? I am using a set of custom shell scripts to install them, but found that #Rex is handy (can also install them on remote targets). I know of GNU Stow (the symlink manager), but never used it. Of course, all dotfiles are kept in a git repository. For work, we use #Puppet and have modules for dotfiles management.
I now manage my dotfiles in #Rex, the friendly configuration management system. I can install my dotfiles on my local box and also on remote servers. I looked at other solutions as well, and they would be suitable too. But I think Rex is the most flexible approach as, after all, it is a #Perl@Perl DSL and I can bend it the way I want. https://codeberg.org/snonux/rexfiles/src/branch/master/dotfiles
A lot of my time spent working on my #homelab started as an excuse to work on my config management skills.
I try very hard to keep all the important stuff coded in #ansible playbooks . Recently I've been trying to switch things up and run services on #microk8s instead of bare metal so I'll be toying with #helm a lot more.
I've noticed a lot of people in the fediverse talking about their adventures in #selfhosting. What are you using for CM?
@nicr9 I use #Rex since a decade both personally and professionally – and I am also a long-term maintainer of it.
Professionally I also used Ansible, Puppet, Chef, and Terraform in various situations.
My approach is:
if it's a learning project, then just go for it; automation is a useful skill, and can be fun!
if it's a long-term investment beyond learning, then approach it like any other development work: start with the simplest thing that solves your situation, then iterate from there
@philsplace@mjgardner Based on my memories of early #Rex development, the (R)?ex form is a purely stylistic choice by the original author and already used in the first commit.
In writing I refer to the distribution/project as Rex, and to the executable as rex (in the same spirit as Perl vs perl). In several places of web presence, it stays stylized as (R)?ex.
I tend to think of it as the remote part being optional, and the result/output being captured.
@davehodg@mjgardner@Perl I'm currenrly thinking about automating a few small hobby projects, have nearly no experience with autmoation - but I enjoy working with Perl very much, so I'm a bit hopeful 😊
Rex let's you decide a lot about what to automate and how, is friendly for incremental automation, and its "DSL" is pure Perl. IOW, developing automation solutions with the building blocks provided by Rex can be treated as any other Perl software development project.
@yenzie@mjgardner@Perl Also, built-in dry-run capabilities not planned for #Rex, but various hooks can be used for such purposes, depending on the use case at hand.
A GitHub discussion or a Matrix/IRC chat sounds ideal to me to learn about exact requirements and find ideas before investing too much in implementation.
I also provide professional services, including #Rex support and #opensource office hours, so feel free to book a chat directly at https://cal.com/ferki 🤙