Ever find yourself trawling Google for blog posts on how to setup a software or service that does not really fall into your core-competency as a developer, but you need to do it anyway? And once you set up that thing -- by copy-and-pasting several pieces of code from stack-overflow -- you are never quite sure what exactly you did, and why it works? And for how long it will continue to do so?

freckles is build around the idea of a central repository of all those tasks, some of them very standard, some of them too niche or specialized to have any obvious, 'official' place to be documented. The idea is that, even though in a lot of situations there are a few different ways to achieve something, there is always a default way that should work for most people. And if there are several ways to do a thing, with different drawbacks and advantages, then all of those should be recorded, in a structured way, and easy to find. Those recipes should be easy to read, but should also offer low-level insight into what they do, for the cases where people want or need to know.

I always thought it'd be great if everybody with a minimum of command-line knowledge could setup a reasonable secure instance of a Wordpress server (or similar) without having to spend a day looking for code to copy and paste.

Some, probably on Reddit, will say 'if you don't know what you are doing you shouldn't be doing it, this is a terrible idea'. Maybe, but I tend to not agree in most cases: I think that is really just a question of abstractions, and how well/terrible the abstraction one is working on was designed and implemented. For some reason, people always seem to assume that the abstraction they are working on is the exact right one, not too low-level, and not too dumbed down. I think we are all kidding ourselves, but that's a different topic... :-)

Anyway, the default and community frecklet indexes are my first attempt at creating such a stdlib-type thing. They record, currently, only my own expertise in setting up software and services, and because of that, are limited in their quality and usefulness. I do hope there is already some usefulness to be found by people who are less experienced in this area than I am though.

My hope is to find other people, ones who know how to do a few of those things better than I do, and who will improve on what I put there. And to find people who know how to do things I have no clue at all about, and add those over time. Just your basic open-source kind of workflow, really. I always hoped Ansible galaxy would become such a thing, but, alas, it has not (yet).

frecklets can be used the same way a Dockerfile is used for docker image provisioning, but within a range of different technologies instead of just Docker:

• physical machines, local or remote
• VMs
• containers (Docker/LXC/LXD/others)
• cloud-init
• Terraform, Packer
• CI services like Gitlab CI, Jenkins, travis, etc.

Depending on the target, slight adjustments might be necessary (for example, Docker does not support systemd or any other init system), but the main part of a frecklet is re-usable within all of those options.

Once freckles supports orchestration backends like Kubernetes or OpenShift, frecklets can also act as sort of Dockerfiles for infrastructure. That's for later though.

This falls into the 'Infrastructure as code'-area: there might be cases where you want to be able to adapt your infrastructure very quickly depending on certain outside factors (not the usual suspects like load-spikes -- those are well catered for by Kubernetes and co).

One example would be to auto-deploy one new custom-build container (holding some app, or database) per new customer in cases where images can't be easily re-used. Or maybe you would like to set up virtual consoles for all participants of a tutoring session, depending on some preferences of each one of them. And do that repeatedly, for every one of those sessions. You would write some logic to get facts out of a database, and then provision customized environments into your Kubernetes cluster, or on DigitalOcean, or wherever else, dynamically, based on certain criteria.

Auto-generating testing environments, maybe even randomly, would be another example. freckles would be a good candidate here, as there is less overhead than with any of the more heavy-weight alternatives. NimbleOps!

Going with the 'Infrastructure as code'-theme, freckles would be a good choice for quick rapid prototyping of infrastructure architectures. Which would later be implemented, for production, using any of the more established products. With a few sprinkles of freckles left in, if appropriate.

Ever despaired with keeping documentation up to date on how to do certain tasks (like setting up dev environments, creating a backup for a service, ...) around your project or company infrastructure? Do you find wikis good in theory, but in practice there always seems to be lots of rank growth, and not many gardeners around?

This is similar to the stdlib for devops case from above, but instead of trying to focus on making a collection of task-recipes that everyone can reuse, we focus on task-recipes that are useful in certain contexts, and which contain institutional or domain-specific knowledge.

freckles provides a way to quickly record common short and atomic tasks and lets you combine those seamlessly. All you need is a git repository and a few yaml/json files. As long as you provide basic metadata, freckles will auto-generate documentation on the commandline for you (or on the web, like the default frecklet index).

Unfortunately this issue can't be fixed without some effort. You'll always have to provide and maintain some metadata and documentation. By allowing this metadata and documentation to be very minimal, by positioning it close to the 'code', and by not requiring any sort of technology apart from a folder (and, if you want, a git client) to organize your tasks, freckles makes things a bit easier at least.

This should also help with standard procedures that are not directly covered by your devops-setup (if you have one, in the first place). Like for example project- or company- on-boarding, regular testing of backup-restores, etc.

frecklets could be used as descriptions of computational research pipelines. Those would be useful in all stages of a research project:

• support personnel initially develops the environment a compute job will eventually run in
• Researchers test and develop with test and actual data
• research jobs are run on HPC infrastructure
• the same research jobs are run on cloud infrastructure, if HPC capacity or capability is insufficient
• frecklets are included in published papers, and alongside the data that was produced by the compute jobs
• frecklets are used to reproduce findings and data later on

Obviously there is more involved than just that, but considering the current state of affairs in that area, every little bit helps...

The original reason for writing freckles was that I wanted a dotfile manager that would do more than check out and symbolically link a few dotfiles in a dotfile repository. I wanted to be able to use a single command, and have my usual working environment setup (or parts thereof) available on a new machine, be it physical or virtual.

This is possible with freckles, and it is especially useful for project-specific setups. freckles can setup and configure external (system) dependencies and project-specific package management systems (pip, maven, gradle, npm, etc), then use those systems to create the development-environment for a project. Those descriptions can be as easily shared as they can be executed, and they can be included in the project repository.

In a similar vein, freckles can be used to quickly provision user environments for Qubes VMs, or other systems that need to be braught up reproducably. Imagine re-installing a wiped Laptop after crossing a border or somesuch.

Consider writing a blog-post where you go through a few steps to setup a certain service. Would it not be nice to be able to provide -- along with the blog-post -- a little script that readers can use directly, and have whatever you were writing about setup in the same way?

As an example, take this blog post about setting up a simple self-hosted alternative for ngrok, a ssh-tunnel service.

After reading it, it took almost no time to create this frecklet which lets you setup a service like this easily. And which can even be used as command-line script to provision several of those ssh-tunnels on the same server.

Thinking this further, in the future I'd like the be able to actually create blog-posts like the one mentioned directly from a frecklet. As a first step, and to illustrate, try out something like:

freckles --community frecklet describe ssh-tunnel-over-nginx -a

I strongly believe it is important for us to try to re-de-centralize the internet. I think this is an area where something like freckles can help: the easier it is to setup a secure and stable Mastodon-server, or Seafile/Nextcloud, or whatever else, the more people might actually do it.

freckles provides a way to crowd-source techniques and strategies around the setup, securing and configuring of software that actually runs the de-centralized services. It also makes building tooling in this area much simpler, as we only need to worry about the user-interface now, then call freckles once all the user-input is gathered.

When organizing some sort of tutorial, it is often a problem to get every participant started on their own hardware. Participants laptops usually come in all shapes, colors and sizes, and it always takes a sizable chunk of time to get everyone to a stage where they can finally type in the first lines of example code.

frecklets can help here, as they can be prepared in advance, tested on different platforms, and then executed by each participant easily at the start of a session (or even in advance).

All right, this is a bonus use-case, and I admit this one is a bit out there. But I don't think it's toooooo crazy. Seriously, if nobody else is going to try out something like that, I will do it myself!

Imagine you'd package up freckles with some code that inspects (and maybe can also change) some infrastructure state description somewhere (maybe on a blockchain?), and depending on what it finds, it creates and provisions new host systems, copies itself onto it, and does the same thing again if certain conditions are met. You could have something like Kubernetes, but without any central controlling infrastructure. Secrets management might be a bit cumbersome with this one, though :-)