github.com/lclarkmichalek/rfsb
Package rfsb provides the primitives to build configuration management systems. As a starting point, a very basic usage example: This is a complete rfsb config management system that defines a resource to be created, and then creates it (materializes it). The atomic units of computation in the RFSB model are types implementing the Resource interface. This is a pretty simple interface, basically being 'a thing that can be run (and has a name, and a logger)'. RFSB comes with most of the resources a standard configuration management system would need, but if other resources are required, the interface is simple to understand and implement. Resources can be composed together via a ResourceGraph: Which can be then composed further, building up higher level abstractions: Resources (and ResourceGraphs) can also have dependencies between them: The `When` and `Do` methods here set up a Dependency between the filesystem provisioning resource and the admin users provisioning resource. This ensures that admin users will not be provisioned before the filesystem has been set up. When all of the Resources have been defined, and composed together into a single ResourceGraph, we can Materialize the graph: And there we have it. Everything you need to know about rfsb. Puppet/Chef/Ansible (henceforth referred to collectively as CAP) all suck. For small deployments, the centralised server of CP is annoying, and for larger deployments, A is limiting, P devolves into a mess, and C, well I guess it can work if you devote an entire team to it. RFSB aims to grow gracefully from small to large, and give you the power to run it in any way you like. Let's take a look at some features that RFSB doesn't force you to provide. A popular feature of many systems is periodic agent runs. RFSB doesn't have any built in support for running periodically, so we'll need to build it ourselves. Let's take a look at what that might look like: Here we've used the radical method of running our Materialize function in a loop. But what you don't see is all the complexity you just avoided. For example, Chef supports both 'interactive' and 'daemon' mode. You can trigger an interactive Chef run via "chefctl -i". I think this communicates with the "chef-client" process, which then actually performs the Chef run, and reports the results back to chefctl. I think. In RFSB, this complexity goes away. If I want to understand how your RFSB job runs, I open its main.go and read. If you don't ever use periodic runs, you don't ever need to think about them. Another common feature is some kind of fact store. This allows you to see in one place all of the information about all of your servers. Or at least, all of the information that Puppet or Chef figured might be useful. In RFSB, we take the radical approach of letting you use a fact store if you want, or not if you don't want. For example, if you have a facts store with some Go bindings, you might use it to customize how you provision things: Now, this might be the point where you cry out and say 'but I can't have a big if else statement for all of my roles!'. The reality is that you probably can, and if you can't you should cut down the number of unique configurations. But anyway, assuming you have a good reason, RFSB has ways to handle this. Mostly, it relies on an interesting property, known as 'being just Go'. For example, you could use an interesting abstraction known as the 'map': Now you might say "but that's basically just a switch statement in map form". And you'd be correct. But you get the point. You have all the power of Go at your disposal. Go build the abstractions that make sense to you. I'm not going to tell you how to build your software; the person with the context needed to solve your problems is you.
Readme
Because sometimes you don't want to reprovision every machine in the fleet to add a sysctl
The workflow of Ansible meets the feature set of cloud-init plus the ease of deployment of bash script.
Let's compare deployment technologies on the market today:
| Name | Do you really like it? | Is it really wicked? |
|---|---|---|
| Kube | We're loving it like this | We're loving it like that |
| everything else | Doesn't even know what it takes to be a garage MC | Can't see any hands in the air |
Unfortunately, none of these quite hit the mark of "we're loving it loving it loving it". To hit the triple L, we need to break it down:
I like my machines. Sometimes I log onto them. When I do, I like stuff to be available. RFSB lets me make things available without introducing overhead.
I add myself as a user.
addLCM := &rfsb.UserResource{
User: "lcm",
UID: 1000,
GID: 1000,
Home: "/home/lcm",
Shell: "/bin/bash",
}
rfsb.Register("addLCM", addLCM)
I add my key.
addLCMSSHKey := &rfsb.FileResource{
Path: "/home/lcm/.ssh/authorized_keys",
Mode: 0400,
Contents: `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAL5YH0a+pKd8E8Be97+gN/kn+U71JCapIH8uysrecKB lcm@lcm-mbp`,
UID: addLCM.UID,
GID: addLCMGroup.GID,
}
rg.When(addLCM).Do("addLCM", addLCMSSHKey)
Now I can log onto my machines.
Sometimes I lose my machines. In these cases I have to get new machines. When I do, I want to install stuff without complications.
I make the machine mine.
$ GOOS=linux go build -o dist/bootstrap ./example/bootstrap
$ scp dist/bootstrap lcm@schutzenberger.generictestdomain.net:~/bootstrap
$ ssh lcm@schutzenberger.generictestdomain.net ~/bootstrap
The bond between me and my machine is now strong.
But does this scale?
I want features
RFSB is designed to be simple and self sufficent. RFSB binaries should be able to bootstrap systems where /usr/bin has gone walkabouts.
RFSB gets out of your way. By presenting a very thin abstraction, RFSB hopes you will immediately see the weaknesses in its core abstractions, and stop using it.
All features not contained in the current version of RFSB are misfeatures until I decided I need them.
RFSB has a DAG and feels guilty about it.
Check out example/bootstrap/main.go for an example of 100% of the functionality that rfsb supports along with our
documentation for more explanations and examples.
FAQs
Package rfsb provides the primitives to build configuration management systems. As a starting point, a very basic usage example: This is a complete rfsb config management system that defines a resource to be created, and then creates it (materializes it). The atomic units of computation in the RFSB model are types implementing the Resource interface. This is a pretty simple interface, basically being 'a thing that can be run (and has a name, and a logger)'. RFSB comes with most of the resources a standard configuration management system would need, but if other resources are required, the interface is simple to understand and implement. Resources can be composed together via a ResourceGraph: Which can be then composed further, building up higher level abstractions: Resources (and ResourceGraphs) can also have dependencies between them: The `When` and `Do` methods here set up a Dependency between the filesystem provisioning resource and the admin users provisioning resource. This ensures that admin users will not be provisioned before the filesystem has been set up. When all of the Resources have been defined, and composed together into a single ResourceGraph, we can Materialize the graph: And there we have it. Everything you need to know about rfsb. Puppet/Chef/Ansible (henceforth referred to collectively as CAP) all suck. For small deployments, the centralised server of CP is annoying, and for larger deployments, A is limiting, P devolves into a mess, and C, well I guess it can work if you devote an entire team to it. RFSB aims to grow gracefully from small to large, and give you the power to run it in any way you like. Let's take a look at some features that RFSB doesn't force you to provide. A popular feature of many systems is periodic agent runs. RFSB doesn't have any built in support for running periodically, so we'll need to build it ourselves. Let's take a look at what that might look like: Here we've used the radical method of running our Materialize function in a loop. But what you don't see is all the complexity you just avoided. For example, Chef supports both 'interactive' and 'daemon' mode. You can trigger an interactive Chef run via "chefctl -i". I think this communicates with the "chef-client" process, which then actually performs the Chef run, and reports the results back to chefctl. I think. In RFSB, this complexity goes away. If I want to understand how your RFSB job runs, I open its main.go and read. If you don't ever use periodic runs, you don't ever need to think about them. Another common feature is some kind of fact store. This allows you to see in one place all of the information about all of your servers. Or at least, all of the information that Puppet or Chef figured might be useful. In RFSB, we take the radical approach of letting you use a fact store if you want, or not if you don't want. For example, if you have a facts store with some Go bindings, you might use it to customize how you provision things: Now, this might be the point where you cry out and say 'but I can't have a big if else statement for all of my roles!'. The reality is that you probably can, and if you can't you should cut down the number of unique configurations. But anyway, assuming you have a good reason, RFSB has ways to handle this. Mostly, it relies on an interesting property, known as 'being just Go'. For example, you could use an interesting abstraction known as the 'map': Now you might say "but that's basically just a switch statement in map form". And you'd be correct. But you get the point. You have all the power of Go at your disposal. Go build the abstractions that make sense to you. I'm not going to tell you how to build your software; the person with the context needed to solve your problems is you.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A hospital in Mobile, Alabama, agreed to a settlement in a landmark ransomware death lawsuit, but is now reportedly reconsidering the agreement and refusing to pay.
Security News
A new report explores how advancements in LLMs are enhancing cyber threats, including polymorphic malware, personalized spearphishing, and the risk of hijacking customer service bots.
Security News
ESLint has approved an RFC that adds support for TypeScript configuration files, which is aimed at improving the developer experience and recognizing changes in the evolving JavaScript ecosystem.