I'm not sure if I am understanding this (aviary.sh) correctly, but it looks like this requires an agent to run on the configured hosts.<p>One of the things that I love about Ansible's model is that we never need an agent on the host. Once you configure something with Ansible, there's no artifact of the configuration left on the machine.
If you need a simple way to inject secrets into your aviary variables you may find encpass.sh (<a href="https://github.com/plyint/encpass.sh" rel="nofollow">https://github.com/plyint/encpass.sh</a>) a convenient choice.
This looks really promising. I've been wanting a very lightweight solution for this which runs on a single host (no need for another host just to run the scripts) and pulls its configuration from a GitHub repository periodically.<p>I ended up writing my own - and hating that I had to do that - because I couldn't figure out how to use any of the existing options. Their documentation all seems to assume multiple hosts and a separate machine that you run the scripts on.<p>"Each host periodically fetches the latest version of the inventory to see what roles should it be performing" - that's exactly what I want.
> Install from the command line, on a box to be managed by aviary.sh:<p>It would be even cooler if I didn't need to do anything to do the box besides install openssh-server. I should be able to:<p><pre><code> $ sudo apt-get install aviary
$ aviary install my_server 192.168.1.25 # a fresh ubuntu 18.04 install
</code></pre>
and everything else should just be magic from there.
If you like this - Fabric is awesome.<p><a href="https://www.fabfile.org/" rel="nofollow">https://www.fabfile.org/</a><p>Use python over SSH. Super fast to begin, if you can ssh into the server, you can run the equivalent of shell commands (subprocess calls in python) remotely. With python, you can abstract and reuse, with the scriptability of bash, but higher level niceties of the language, libraries and toolchain (linting, formatting, autocompletion, imports).<p>Can it pull the latest version of your app, build it on your server? Yep. Restart daemons? Update libraries (npm, python, etc)? Update system packages? All work fine.<p>Can it configure a vanilla server from scratch? Yes, it's helpful to bring in a higher level reusable library like <a href="https://github.com/fabtools/fabtools" rel="nofollow">https://github.com/fabtools/fabtools</a> helps with that.<p>When does it hit limitations? More complex orchestration where you have multiple servers (and variations of them) with configuration to talk to each other over networks. Eventually you get to the kind of setup where having a tool like Ansible / Salt / Puppet / etc. makes sense.<p>For a basic PHP/python/ruby/node site that's just running on a single cloud server? A declarative config manager would be overkill for me.
This was written by team.video who is in a hyper competitive space. Every hour spent on Aviary is an hour not spent on differentiating customer features. Why? There are a ton of open source CM tools that give you same functionality and do it better. This is a problem you should have solved after you were a) profitable b) at scale and c) probably not even then.
Unfortunately all I could think of was "that sounds cool but I'd want to stick to dash instead of bash"<p>Also didn't realize it wasn't agentless which is pretty critical imo
Now this is something I can get behind! Very cool work. I think bash gets a bit of a bad rap and it's very popular to bandwagon hate on it, but it's one of my favorite tools ever.
I don't care what language or paradigm the tool is written with, Configuration Management tools are evil and should be avoided at all costs. I would literally rather maintain a crappy server and fragile software install manually and treat it as a pet, than use any CM tool at all and pretend my servers are cattle. In reality, the CM becomes the pet.<p>The solution to CM is to use immutable infrastructure, and versioned immutable artifacts. With these paradigms, state never drifts, so there is never a need for configuration management at all. Everything becomes stable and predictable and you no longer have to maintain a finicky pet.<p>But how do you bootstrap your systems, you say? The simplest way possible: make a crappy procedural program that bootstraps the very beginning of your system just enough to push versioned immutable artifacts and run arbitrary commands (essentially just "scp", "reboot", "docker pull", "exec"). With cloud-based systems, you shouldn't need to bootstrap anything at all. Build your versioned system images and containers, deploy them, destroy them, re-deploy them.<p>No offense meant to Aviary, I'm sure there are still legacy systems that require some CM before they can be abandoned, but I really hope people building new systems will abandon them ASAP.
This looks really effective! I do something similar to keep track of what's on my workstations: I just have one large idempotent shell script to set up all the software I use. To help myself not loose track of updating it I have a little helper script to detect packages that aren't tracked in the config. I've recently thought about breaking it up into smaller "module-style" scripts. Maybe this could be a good fit (with minor adoptions)!
Really neat. I still need to evaluate it more, but this is the kind of thing I've looking for for small infrastucture that isn't likely to grow (like home services or small office, etc).
I'm all for trying simpler approaches and have written some tooling in bash myself, but at this point Python is pre-installed on many servers like bash is, a large benefit of Ansible is the VAST number of modules already written for Ansible.<p>Imagine if this grew to support all of Ansibles features and modules, but did so in bash.<p><i>shudders</i>
Currently I do a fresh install of Ubuntu every time I do new work (every 6months). Normally I spend about 6 hours getting my machine configured up (installing softwarem configuring my terminal, etc)<p>Will Aviary be able to solve this?
I've been working on a localhost-only system for automation myself, inspired by puppet but with far fewer modules:<p><a href="https://github.com/skx/marionette/" rel="nofollow">https://github.com/skx/marionette/</a><p>As of this week it can now pull down docker-images from dockhub, which was something I'd been needing to rebuild my own systems. Early days, and it is as much proof-of-concept as anything else, but it seems robust and reliable in my own use.<p>Of course I need to add "written in go" to advertise properly!
> Installation<p>> curl <a href="https://aviary.sh/install" rel="nofollow">https://aviary.sh/install</a> | sudo bash<p>I would really try to avoid this, especially when it's targeted for sysadmins ( I guess DevOps nowadays ).<p>What's the big deal of having this instead :<p>> $ wget <a href="https://gitlab.com/dchester/aviary.sh/-/archive/1.3.2/aviary-install.sh" rel="nofollow">https://gitlab.com/dchester/aviary.sh/-/archive/1.3.2/aviary...</a><p>> ./aviary-install.sh
Wow, perfect timing. I was just looking for something like this. I haven't looked at it too in-depth yet, but the design goals align with what I want. Minimal configuration management that pulls config from git and runs locally. Ansible pull, salt masterless, chef solo, etc. work, but they weren't designed to be run that way, so have unneeded complexity (and are kind of heavy for what I want).
I have been working lately on something a bit similar, but in pure POSIX sh. It's called primer, <a href="https://github.com/efrecon/primer" rel="nofollow">https://github.com/efrecon/primer</a>, has no agent, cannot work on remote host but supports amalgamation for easy remote installation and operation. Primer is very much docker oriented in the sense that it seeks to automate the installation of all tools before a docker project, then supposes you run docker-compose for the rest of your projects, or orchestrate in any other way.
Looked good but I needed to leave the site after seeing they suggested doing<p>curl <a href="https://aviary.sh/install" rel="nofollow">https://aviary.sh/install</a> | sudo bash
I think there is an Genuine Enterprise Need explosion at certain scales. It is not box ticking exercises or empire building but sometime after (my guess) 1,000 units of <i>anything</i> (users, servers, customers, whatever) you start finding that "simple as possible" does not help that much anymore. LDAP support becomes useful and so on.<p>Maybe, I hope maybe, it's not a real portal that we pass through, but it does seem so.
If you like rerun, drist or bashing. I made a short Go program to replicate the experience.<p><a href="https://github.com/tongson/rr" rel="nofollow">https://github.com/tongson/rr</a><p>Yeah, naming conflict with the debugger. Was a simpler replacement for rerun so the shorter command name made sense to me.
I do something sort of similar, also using git to maintain the inventory of what to run on what machine.<p>In my case, I'm using docker-compose.yml files for each machine, and then running:<p><pre><code> docker-compose pull
docker-compose up -d
</code></pre>
We initially wanted to use Watchtower, but it didn't work well for us.
More modular, smaller, simpler than aviary is rrconf
<a href="https://github.com/rrconf/rrconf" rel="nofollow">https://github.com/rrconf/rrconf</a>
How is this idempotent?<p><pre><code> cat <<EOF > /etc/motd
"Ever make mistakes in life? Let’s make them birds. Yeah,
they’re birds now."
--Bob Ross
EOF</code></pre>
Typically I use Packer + Terraform and it works generally well (if you going with the immutable servers philosophy). However, often times immutable servers is hard to actually do in practice. If Hashicorp added a new product similar to Ansible / Aviary.sh / Fabric I think it would complete the entire DevOps loop under a single ecosystem.
> bash is just fine (yes, it is)<p>No, it's not. It's 2020, we need to stop it with the stringly-typed, footgun-filled madness that is bash scripting. We deserve better than this.<p>Unless I'm missing something, this README example already contains a bug:<p><pre><code> template $(dirname $0)/motd.template > /etc/motd
</code></pre>
This will fail if the script path contains a space.
> But it's too funky you say. Well, yes, bash can have its quirks. But we need some funk every now and then. Let's just embrace it!<p>My god, no, stop. Funkyness in production equals outages.