[HN Gopher] Show HN: Aviary.sh - A tiny Bash alternative to Ansible
___________________________________________________________________
Show HN: Aviary.sh - A tiny Bash alternative to Ansible
Author : dxchester
Score : 178 points
Date : 2020-06-25 17:26 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nyxtom wrote:
| Nice, I plan on using this
| dheera wrote:
| > Install from the command line, on a box to be managed by
| aviary.sh:
|
| 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:
| $ sudo apt-get install aviary $ aviary install my_server
| 192.168.1.25 # a fresh ubuntu 18.04 install
|
| and everything else should just be magic from there.
| freedomben wrote:
| 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).
| ansible wrote:
| I do something sort of similar, also using git to maintain the
| inventory of what to run on what machine.
|
| In my case, I'm using docker-compose.yml files for each machine,
| and then running: docker-compose pull
| docker-compose up -d
|
| We initially wanted to use Watchtower, but it didn't work well
| for us.
| xomodo wrote:
| Try docker contexts: https://www.docker.com/blog/how-to-deploy-
| on-remote-docker-h...
| darkteflon wrote:
| This is a great feature, introduced in Feb this year. It
| addressees a substantial pain point with docker-compose.
|
| Thanks for pointing this out.
| ptrincr wrote:
| Indeed this does look very useful.
|
| I had a quick glance over this, but for contexts which are
| defined as remote ssh hosts, I couldn't see where the
| images are obtained. Are they being built remotely on the
| host, or are they being downloaded from your local machine
| over a tunnel or via a docker registry?
| yonixw wrote:
| Nitpicking: Why pull separately? it will pull if no image
| stored locally or even if the `docker-compose.yml` changed.
| randallsquared wrote:
| Two reasons I've done this in my own Makefiles: predictable
| start times, and separation of failure-prone steps.
| yjftsjthsd-h wrote:
| Stale images can be a reason. If I specify `image:
| foo:latest`, then push new versions, it won't automatically
| pull new versions unless you do an explicit pull.
| Hackbraten wrote:
| I've been waiting for a tool like this.
| dxchester wrote:
| Here you go! Yeah, I've used a bunch of CM tools over the
| years, and it always seems like you're learning a DSL of one
| sort or another, just to have it translate into the bash that
| you already know.
| cloin wrote:
| YAML is a standard for so many different tools now that I
| don't think it's really considered a DSL.
| cloin wrote:
| And don't get me wrong, I love bash. I automated my first job
| using bash. But relying on bash just relegates aviary to a
| certain job description and thus just low value, domain
| specific tasks. Seems like a neat way for a linux admin to
| run a homelab, but not something that's easily adopted for
| larger teams working across OS, network platforms or
| integrating with external services.
| mothsonasloth wrote:
| 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)
|
| Will Aviary be able to solve this?
| whycombagator wrote:
| Maybe you have an involved set up and already do these things,
| but surely you could just write a bash script that installs all
| the software you need and store it with your dotfiles.
|
| After a new Ubuntu install you can just pull down your dotfiles
| and run your install script. Aside from some things like ssh
| keys, gnome tweaks, etc. - this approach would likely get you
| 90% of the way to set up and would take ~15 mins.
|
| Arriving at this set up would take a little bit of time, and
| require periodic maintenance, but given a weekend you could
| have it set up and tested.
|
| Here[0] is an interesting way to store dot files.
|
| [0] https://www.anand-iyer.com/blog/2018/a-simpler-way-to-
| manage...
| simonw wrote:
| 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.
|
| 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.
|
| "Each host periodically fetches the latest version of the
| inventory to see what roles should it be performing" - that's
| exactly what I want.
| VWWHFSfQ wrote:
| Sounds like you're looking for ansible-pull
| miked85 wrote:
| > which runs on a single host (no need for another host just to
| run the scripts)
|
| This isn't a limitation of Ansible, you can run playbooks
| against localhost.
| zhengyi13 wrote:
| True, but I think OP's point at least in part was that an
| awful lot of the tutorials out there start with the
| assumption that the audience are sysads and SREs who want to
| manage a fleet.
| tony wrote:
| If you like this - Fabric is awesome.
|
| https://www.fabfile.org/
|
| 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).
|
| 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.
|
| Can it configure a vanilla server from scratch? Yes, it's helpful
| to bring in a higher level reusable library like
| https://github.com/fabtools/fabtools helps with that.
|
| 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.
|
| 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.
| darkteflon wrote:
| What's the status of the fabtools project? It supports up to
| Ubuntu 14.04 (as in, 2014) and has very little commit activity.
| Without fabtools, fabric operates at a much lower level of
| abstraction than Ansible.
| linuxftw wrote:
| > 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.
|
| This literally describes ansible. In fact, ansible one-ups this
| because you can specify raw commands if python is not installed
| remotely [1].
|
| Ansible provides lots of modules, you don't have to use any of
| them. I have plenty of 1-off ansible playbooks that I don't
| care about idempotency that are just a bunch of 'cmd'
| statements. It's a very flexible tool.
|
| 1:
| https://docs.ansible.com/ansible/latest/modules/raw_module.h...
| maxmalysh wrote:
| Not really. Ansible is a complex DSL based on YAML. Fabric is
| really simple and uses real Python.
| strig wrote:
| I really hate that fabric got rid of roles in the new version.
| I want to be able to still do "fab task -R prod".
| maxmalysh wrote:
| Try fab-classic:
|
| https://github.com/ploxiln/fab-classic
|
| We decided that migrating to Fabric 2.0 doesn't worth it.
| q3k wrote:
| > bash is just fine (yes, it is)
|
| 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.
|
| Unless I'm missing something, this README example already
| contains a bug: template $(dirname
| $0)/motd.template > /etc/motd
|
| This will fail if the script path contains a space.
| dastx wrote:
| Can't say anything about this tool, but compared to ansible,
| bash is mostly fine. In my opinion ansible is a (and pardon my
| language) clusterf __* of a tool compared to the alternatives.
| Certainly, if bash had the likes of inventories, roles and
| other features to make maintenance and reuse easier, I 'd
| choose that over ansible.
| p_l wrote:
| Ansible is writing bash scripts in YAML, templates using
| system that doesn't grok YAML and causes parsing errors due
| to whitespace, interpreted by schizophrenic Python that might
| be 2 or it might be 3.
|
| ... I guess pure bash might be better.
| pnutjam wrote:
| you can run pure bash from ansible, either by copying a
| script or using the shell module: examples: both with sudo
|
| ansible all -m shell -a "hostname" -b
|
| ansible all -m script -a "script=/home/user/myscript.sh" -b
|
| I love to throw together a quick inventory list and run
| adhoc ansible commands against a bunch of servers.
| forty wrote:
| With bash at least I don't have to read the documentation each
| time I want to create a file or anything else...
| __MatrixMan__ wrote:
| Yes it is.
|
| If you have two type systems and you don't want them to
| interact, gluing them together with stringly typed bash is a
| good way to keep their scope small. As a user interacting with
| multiple programs by different authors, that's a very common
| use case.
|
| Giving your type systems boundaries is a good idea. The
| alternative tends towards one-type-system-to-rule-them-all, an
| idea that Russell thoroughly explored in the early 1900's,
| Godel proved to be unmaintainable in the 30's, and that
| everybody except the Java and C# crowd has since abandoned as a
| dead end.
| woah wrote:
| It is a pretty sloppy and archaic language. We need an
| updated version that keeps the string typing and inline
| execution of external binaries, but has modern syntax, plus a
| few more conveniences and guardrails.
| __MatrixMan__ wrote:
| I was only taking issue with the objection to string
| typing. I totally agree that the rest of bash requires a
| bit of stockholm syndrome to love.
|
| I haven't yet taken the time to play with it but I'm hoping
| www.oilshell.org addresses some of the warts.
| _jal wrote:
| > No, it's not.
|
| Then come up with something better.
|
| It will need the same or better ease-of-use for non-
| programmers, should function as a shell (so that their everyday
| use also teaches them scripting), with the same flexibility
| that lets people who don't care about typing or other fancy
| programmer stuff and just need to get work done.
|
| If your first instinct is to say "python", you don't understand
| the problem.
| benbristow wrote:
| A Python script is (generally) easier to read, easier to
| write, easier to modify/maintain, easier to debug and easier
| to test.
|
| Bash programming is not easy and full of loads of gotchas.
|
| Useful for running multiple commands but when you start to
| need to do programming things like
| conditionals/loops/variables then using an actual programming
| language makes more sense.
| linuxftw wrote:
| While I agree with the sentiment that bash is not the
| solution for an ansible-like thing, I also agree with what
| you're saying.
|
| I consider myself an accomplished system engineer and
| software developer. I use bash all the time. Not writing bash
| scripts is like saying not to use the terminal, it's just
| cacophony.
| q3k wrote:
| You are misunderstanding or misrepresenting what I said. If
| it wasn't obvious, I meant that bash scripting is not okay
| _for this sort of complex work/projects_.
| _jal wrote:
| I fail how to see how I could be doing either.
|
| "[W]e need to stop it with the stringly-typed, footgun-
| filled madness that is bash scripting" is pretty
| categorical.
| scrooched_moose wrote:
| On paper I agree with you, but that has not been our
| experience in practice.
|
| Bash "just works" with some very well understood
| limitations. Every one of these "better" solutions
| introduces 10x the complexity with 10x the limitations
| (always undocumented).
|
| After spending dozens of hours configuring them thanks to
| terrible documentation, generally taking multiple support
| tickets (if there's anyone to talk to at all), we get it
| working. Then, after using it for a period of time, they
| fall flat on their face in far worse ways than bash.
|
| Granted I'm only managing hundreds of servers, not
| thousands or more, but more often than not a
| for i in {000..199}; do ssh machine$i "some command"; done
|
| is more reliable, with better error handling, than all of
| the other solutions.
|
| Edit: As long as linux/unix maintains the "everything is a
| (plaintext) file" approach, I have trouble picturing a
| better solution than text/string based interface like Bash.
| You can build more front-end complexity on top of it, but
| you're always going to end up back in the same place.
| notyourday wrote:
| > Granted I'm only managing hundreds of servers, not
| thousands or more, but more often than not a
|
| > for i in {000..199}; do ssh machine$i "some command";
| done is more reliable, with better error handling, than
| all of the other solutions.
|
| This is absolutely not the case:
|
| From the top of my head: there is a network error that
| hits while running this against 5% of machines. What is
| the state of those servers?
|
| If one is managing more than a few machines, one should
| absolutely use something like Puppet/Ansible/Salt/Chef
| with a repo to ensure that nothing is ever lost.
| rejatak wrote:
| Hello
| 0x8BADF00D wrote:
| > No, it's not. It's 2020, we need to stop it with the
| stringly-typed, footgun-filled madness that is bash scripting.
|
| Ansible is written in Python. You could make the same argument.
| sk0g wrote:
| How? Python has an actual type system. A programming language
| that does strings for everything would be, for example, PHP.
| 0x8BADF00D wrote:
| Python has dynamic typing, which can be equally dangerous.
| In fact I'd argue it's more dangerous. You will not throw
| errors until runtime, which will literally blow up in your
| face.
| pizza234 wrote:
| > which can be equally dangerous
|
| Bash is weakly typed, which is a different concept than
| dynamic typing.
|
| Dynamically typed languages prevent bugs that weakly
| typed languages don't, so from this point of view, the
| latter are unambiguously "more dangerous" than the
| former.
| 0x8BADF00D wrote:
| A dynamic type system is an incremental improvement over
| a weakly typed type system, and still will not guard
| against runtime errors. They are equally dangerous w.r.t
| runtime errors.
| ironmagma wrote:
| So does Bash, though.
| sk0g wrote:
| And Bash does not support static typing at all, unlike
| Python. Not sure what their argument even is.
| 0x8BADF00D wrote:
| Right, but Python gives you the illusion of safety. And
| the person I was replying to was trying to dismiss this
| interesting Ansible alternative because it was written in
| a language he doesn't like.
| ironmagma wrote:
| Python with type annotations can actually be pretty safe.
| There are also typechecked Python variants being
| developed. At any rate, I'd say the defect rate in Bash
| is incredibly higher than it is in Python, and 90% of
| that is due to unquoted string expansion. Try putting
| spaces in your paths and you'll quickly see how 75% of
| the Unix stack breaks.
| sk0g wrote:
| It gives you the option to use static typing, if you so
| desire.
|
| I'm not sure how not having a type system is safer than
| having a type system. What makes it feel more dangerous?
| ufo wrote:
| I don't really mind the string typing of Bash. Shell commands,
| their arguments, and their outputs are all strings anyway so it
| makes sense to give special treatment for strings.
|
| That said, features such as word-splitting are terrible
| footguns that only exist because of the burden of backwards
| compatibility. Hackernews, what other languages do you suggest
| as Bash replacements that doesn't have as many opportunities to
| shoot yourself on the foot?
|
| This is an area that I never found something I truly liked. A
| lot of people suggest Python for this kind of task but when I
| have a small script that is mostly doing pipelines and command
| substitutions with "$()" then the python version with
| subprocess is much more verbose.
| acemarke wrote:
| There's a wonderful library called `plumbum` [0] that lets
| you execute external binaries and capture output using Bash-
| like piping syntax, while preserving all the goodness of
| Python's syntax and flow control. Highly recommended.
|
| [0] https://plumbum.readthedocs.io/en/latest/
| ThePhysicist wrote:
| Ha, Ansible parses and 'executes' YAML files using Python, but
| not before passing them (repeatedly?) through a template
| library (Jinja2) originally designed to produce HTML pages.
| They even came up with a way to write for loops in YAML... What
| I'm trying to say is that sometimes great software is written
| using (in some people's opinion) terrible technology. Not
| everything needs to be written in idiomatic Haskell or Rust.
|
| Personally I have to say that I started writing more bash
| scripts again recently, I even wrote one that interfaces with
| the GPIO ports on a Raspberry Pi. Works like a charm, is
| concise and (I find) also quite readable:
| https://gist.github.com/adewes/7a4c20a5a7379e19d78ba54521d3d...
|
| But then again I'm also a person who enjoys Perl, so maybe it
| is time for me to be banished to a lonely island :D
| lux wrote:
| Perl was great for encouraging that kind of thinking with the
| old motto "there's more than one way to do it". I'm glad I
| started with Perl because it's helped me think about
| solutions I may have otherwise dismissed.
|
| Bash is far from perfect, but it's readily available at many
| people's fingertips, and it gets you to some solutions really
| fast. This is cool.
| [deleted]
| the_mitsuhiko wrote:
| > originally designed to produce HTML pages
|
| Jinja2 can produce HTML pages, but it was never exclusively
| designed for that. In fact one of the earliest uses of Jinja2
| was generating LaTeX.
| ThePhysicist wrote:
| I stand corrected, didn't know that!
| [deleted]
| montroser wrote:
| I think you are forgetting that serious operators do not have
| spaces in their paths.
| hk__2 wrote:
| *People who are used to work with bad tools don't have spaces
| in their paths.
| tenebrisalietum wrote:
| "C:\Documents and Settings" still hurts after all these
| years.
| linuxftw wrote:
| "C:\Program Files(x86)". Who ok'd that?
| oblio wrote:
| It's a design decision and a good one, at that. Forcing 1
| million developers to handle spaces properly while they
| spend 1 billion hours developing their software is
| preferable to 1 billion regular users having to remember
| to not use space, a perfectly good separator, in their 1
| billion billions hours of usage of said software.
| GrinningFool wrote:
| I haven't looked in a while, but last I checked you could
| also still get to it via C:\PROGRA~1? (This was years
| ago, that might have been 'fixed'?)
| joombaga wrote:
| These are called 8.3 filenames. They're a filesystem
| feature. They're still created by default in Windows 10
| on NTFS, but can be disabled or stripped using `fsutil`.
| einarin wrote:
| Speculation, but I suspect that Microsoft explicitly put
| both user data and programs in paths with long filenames
| and spaces to help force software to support those
| things. That always seemed like a good thing to me, it's
| ridiculous that we still have software that breaks on
| paths with spaces.
| jedieaston wrote:
| It still hurts today, because Microsoft puts a space
| between your first and last name in your profile if you
| are using a local account but not for a domain account,
| which causes all kinds of weird issues if you ever have
| to use cmd.exe...
| jdxcode wrote:
| _cough_ make _cough_
| ironmagma wrote:
| That's just objectively false.
| jdxcode wrote:
| "Serious operators" never want to put their files into iCloud
| Drive? They must be using butterflies then
|
| https://xkcd.com/378/
| paulchap wrote:
| "Serious operators" probably use a cloud storage solution
| that supports WebDAV/FTP/SFTP, like box.com or Google Drive
| - "real operators", on the other hand, have a self-hosted
| solution (-; And IMHO relying on iCloud for essential data
| storage probably isn't a good idea.
| jdxcode wrote:
| I find iCloud much better than Google Cloud and I'm
| pretty sure I qualify as a "serious/real operator" any
| way you want to call it. I have no time or interest in
| hosting a custom solution. And I _certainly_ have no need
| for FTP.
|
| But even if I wasn't experienced, quit this gatekeeping
| crap. Let people use the tools that work for them. It
| does not in any way reflect on how "serious/real" they
| are.
| paulchap wrote:
| > "Serious operators" probably use a cloud storage
| solution that supports WebDAV/FTP/SFTP, like box.com or
| Google Drive - "real operators", on the other hand, have
| a self-hosted solution (-;
|
| I didn't mean to discredit you for using iCloud - if it
| came across that way, I apologize. My original comment
| was meant to be tongue in cheek. I've got to admit that
| I'm a bit gob-smacked by your reaction... After all, my
| comment was similar in structure to yours. I even quote
| unquoted the terms, and the "real operator" part was a
| reference to the editor war xkcd you mentioned. Taking
| your post literally, I could accuse you of doing the same
| thing by assuming that real operators were Mac users. And
| I'm sure there are many use cases where hosting your own
| cloud storage would be absurd. But, re-reading my
| comment, it didn't read like a flame war instigating
| piece of propaganda "Calling all real sysops to arms
| against the user threat. Grab your cattle prod, fellow
| comrades, and crank up the voltage!"
|
| > And IMHO relying on iCloud for essential data storage
| probably isn't a good idea.
|
| I don't condone gatekeeping (although, to be perfectly
| honest, I don't see how my comment could be interpreted
| as elitist. It's not like the learning curve for GDrive
| or any other solution with a better cross platform
| support is _that_ high), but I don't see a reason why I
| shouldn't voice my opinion on a tool, even if responding
| to something obviously meant as a joke. Of course you're
| free to use iCloud. Personally, I wouldn't feel
| comfortable with the thought of my critical data being
| stored on a platform that, historically, hasn't always
| been known for being extremely stable. Maybe I'm just
| biased. If you feel comfortable using it, then use it. I
| won't stand in your way.
| jdxcode wrote:
| I genuinely apologize as I think I misunderstood. Of
| course I'm fine with a bit of jokes about tech but I
| think I didn't catch any intended sarcasm in your comment
| --in fact I think I took the direct opposite intention.
|
| I'm admittedly sensitive to gatekeeping. I do think it's
| one of the biggest reasons the tech industry is the
| monoculture it is.
|
| Anyhow, I appreciate you clarifying and hope I didn't
| offend too much.
| paulchap wrote:
| No problem. The subtleties of human speech don't carry
| over to text very well ;-)
| pnutjam wrote:
| rsync or btrfsync for the win
| teddyh wrote:
| On the contrary, serious operators write programs to handle
| spaces in the paths.
| tempodox wrote:
| When I open `av` in vim, shellcheck spits out 167 warnings.
| This is not written robustly.
| xyzzy_plugh wrote:
| FWIW shellcheck complains about many false positives.
| gravitas wrote:
| But in this case, their code is comparing strings to ints
| like on line 126: while [[ "$#" -gt 0 ]];
| do
|
| Spot checking code for basic bash mistakes like this tends
| to tell me the quality of the code overall, as these are
| basic mistakes. $0.02
| abathur wrote:
| Is this actually a shellcheck error? It just evaluates to
| the integer number of arguments in $@, so I doubt it is
| (and I doubt it matters whether it's quoted? unless
| there's a bash back-compat issue here?)
| dougwbrunton wrote:
| Is there a bug in the command line parsing there? I can't
| see it.
| hk__2 wrote:
| If $# is a number, aren't "$#" and $# exactly the same in
| Bash? Enclosing things in double quotes doesn't change
| their type, since everything is already treated as a
| string.
|
| https://www.gnu.org/software/bash/manual/html_node/Double
| -Qu...
| gravitas wrote:
| While the other reply to you is correct, the actual
| answer to your question is No -- bash interprets leading
| 0s (zeros) in the C sense, it indicates octal not
| decimal. So this very small bash will fail for you:
| X="08" if [[ "$X" -eq 8 ]]; then echo Y
| fi
|
| Use `bash -x` to run it in debug mode:
| $ bash -x test.sh + X=08 + [[ 08 -eq 8
| ]] test.sh: line 2: [[: 08: value too great for
| base (error token is "08")
|
| This comes into play if you're dealing with things like
| IPv4 address, where it is _technically_ allowable to have
| leading zeros, however by convention it 's never done
| because of code traps which see those leading zeros as
| octal mode, not decimal.
| pizza234 wrote:
| It's true, but you're semantically overloading the
| variable syntax (by hinting that it's treated as string).
|
| Plus, left and single operands, in bash conditions, don't
| require quoting, so a lean style is actually not to use
| them at all.
| pizza234 wrote:
| Do you refer to shellcheck in general or in this specific
| case?
|
| I do a non-trivial amount of shell scripting, and there is
| only one warning I disable in shellcheck on a general basis
| (SC2016).
|
| The author of this script clearly doesn't like quoting
| where the underlying value is guaranteed not to include
| special characters (or space), although this is somewhat
| inconsistent with the fact that he's using quotes in
| several patterns where it's not needed (eg. left or single
| operands in bash conditionals, or in variables
| initialization).
|
| On can consider always quoting a defensive practice. In a
| fragile language like Bash, I personally think defensive
| practices are very important, so the first impression I get
| from a Bash program not adopting them is "not great".
| markstos wrote:
| 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.
|
| Imagine if this grew to support all of Ansibles features and
| modules, but did so in bash.
|
| _shudders_
| arminiusreturns wrote:
| 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.
| drinchev wrote:
| > Installation
|
| > curl https://aviary.sh/install | sudo bash
|
| I would really try to avoid this, especially when it's targeted
| for sysadmins ( I guess DevOps nowadays ).
|
| What's the big deal of having this instead :
|
| > $ wget
| https://gitlab.com/dchester/aviary.sh/-/archive/1.3.2/aviary...
|
| > ./aviary-install.sh
| nerdponx wrote:
| Better still: wget
| https://gitlab.com/dchester/aviary.sh/-/archive/1.3.2/aviary-
| install.sh less aviary-install.sh ./aviary-
| install.sh
| _frkl wrote:
| I like having the option, tbh. I usually self host the install
| scripts, which removes most of the potential issues.
| efrecon wrote:
| I have been working lately on something a bit similar, but in
| pure POSIX sh. It's called primer,
| https://github.com/efrecon/primer, 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.
| easterncalculus wrote:
| Very nice! Ansible can be a little heavyweight for some of the
| things that me and a lot of people do. I'll definitely be taking
| a look at this.
| salasrod wrote:
| > 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!
|
| My god, no, stop. Funkyness in production equals outages.
| ironmagma wrote:
| As bad as Ruby is, it's still better than Bash and you can do
| all the same effortless execution of random commands in your
| script like you would in bash. If one can't be bothered to
| write it in a real language like Rust or even Python, you could
| at least do Ruby.
| cortesoft wrote:
| What makes python more of a real language than ruby?
| ironmagma wrote:
| It's more mainstream for tools like this.
| rad_gruchalski wrote:
| Please explain. Have you heard of chef? That is ruby and
| it can be beautiful. Chef > Ansible. Chef server is meh.
| ironmagma wrote:
| The point wasn't that Python is better than Ruby, they
| are about the same IMO. The point was they are both
| better than Bash, and Ruby actually makes it super
| convenient to write bash-like scripts, so there's no
| excuse to not be using Ruby.
| e12e wrote:
| Eh.. Puppet? [ed: and chef..]
| ironmagma wrote:
| Python and Ruby are both functionally equivalent in my
| book. The difference is prevalence; for systems tools,
| Python is more common because it comes installed by
| default with more Linux distros and in my experience
| anyways, is faster to respond to breaking upstream issues
| and build failures, which is almost certainly just due to
| more widespread usage. I have nothing against Ruby, it's
| a pretty language and does what you need and has good
| metaprogramming support. Just saying for a tool you want
| lots of people to adopt, it's more mainstream to choose
| Python.
| easygenes wrote:
| Ruby has fallen by the wayside in recent years largely
| because its lunch has been eaten by Python and JavaScript,
| but mostly by happenstance, not as a result of the merits of
| the language itself. Ruby has comparable speed and arguably
| more robust niceties for building complex software vs.
| Python. See, e.g., https://leanpub.com/combinators
| https://computationbook.com/
| https://www.toptal.com/ruby/ruby-metaprogramming-cooler-
| than...
| logie17 wrote:
| I'm not sure how bash is considered funky, it's nearly first
| class on all boxes. Nice thing about this tool you just use
| `script` type out your commands, copy it your modules and your
| done.
| nodesocket wrote:
| 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.
| llama052 wrote:
| You can hook ansible roles into your Packer process pretty
| easily. That's what I do at least.
| raffraffraff wrote:
| If you're sticking with hashicorp tools and use consul, then
| something like consul-template should work. Your packer builds
| would just have to copy consul-template configs and template
| files for the things you want to manage. Each template watches
| the consul kv store for matching keys, and rewrites the target
| config file using their values. You can instantly rewrite
| configs and execute follow up actions across your fleet by
| updating a consul key value.
| nodesocket wrote:
| Agree Consul is an elegant solution for managing files, what
| about running commands?
| moondev wrote:
| cloud-init?
| ahnick wrote:
| If you need a simple way to inject secrets into your aviary
| variables you may find encpass.sh
| (https://github.com/plyint/encpass.sh) a convenient choice.
| logie17 wrote:
| That's a pretty cool project. It also is written in bash as
| well!
| trynewideas wrote:
| it requires an agent, so it's a tiny Bash alternative to Puppet,
| but that doesn't sound remotely as cool
| stevekemp wrote:
| I mentioned it above already, but I've been experimenting with
| an agentless puppet-lite:
|
| https://github.com/skx/marionette/
|
| Early days, but the primitives are enough to do useful things
| on my own systems..
| ggregoire wrote:
| Ansible is agentless tho. That's a pretty big difference.
| gjulianm wrote:
| Yeah, it was the thing that made me choose it instead of other
| alternatives. I manage machines in heterogeneous client
| networks without direct Internet access most of the time and
| agents for managing infrastructure are not useful at all.
| xbryanx wrote:
| 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.
|
| 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.
| pampa wrote:
| That is not entirely true. Ansible needs python installed on
| the target host, and a lot of modules (plugins?) require
| additional python libraries on the target.
| soco wrote:
| It doesn't need any python. Ansible opens a regular ssh
| session and can run anything from it - including python if
| available.
| dfinninger wrote:
| Only with the "raw" module... which is what you use to
| ensure Python is installed on a machine managed by Ansible.
| cloin wrote:
| If python is considered an agent, isn't bash now an agent?
| divbzero wrote:
| The av agent that GP refers to is a script that runs
| periodically on target hosts to _pull_ the latest
| configuration using Git. Ansible has a Python dependency but
| no agent running on target hosts, instead relying on SSH to
| _push_ configuration changes.
|
| Ideally, I'd like to see a configuration tool that uses
| Ansible's SSH _push_ model but without the Python dependency.
| pnutjam wrote:
| you can use the "raw" module without python.
| thr0w3345 wrote:
| The agent approach is mostly ok, it tends however to suffer
| when you have more than a few hundred machines (I've found,
| anyway) that your ansible code rots a bit. Say for that one
| server, you know the one, the weird etl thing bi uses, was run
| once and during a prod problem you suddenly have to start
| fixing the ansible code to rebuild it.
|
| With an agent, it's applying all the time and this doesn't
| happen.
|
| We actually moved to salt from ansible and we're happy..
| pnutjam wrote:
| Ansible does create a bunch of temp files. I've even had issues
| where my ansible barfed because my uid changed and the old temp
| files couldn't be accessed anymore.
| stevekemp wrote:
| I've been working on a localhost-only system for automation
| myself, inspired by puppet but with far fewer modules:
|
| https://github.com/skx/marionette/
|
| 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.
|
| Of course I need to add "written in go" to advertise properly!
| ahnick wrote:
| Does this save time in writing your own personal automation or
| make that personal automation less error prone? How would you
| compare it to just writing your own bash scripts or using
| something like Bashible (https://github.com/mig1984/bashible)?
| dastx wrote:
| On first glance this looks awesome. Certainly will be better
| than the bunch of scripts I've written to provision my laptops.
| stevekemp wrote:
| Fingers crossed it will work for you, and others!
|
| It replaces a simpler alternative I wrote in the past which
| used ssh/scp to upload files and run commands:
|
| https://github.com/skx/deployr
|
| Right now I have a git-repository containing per-host config.
| So I can run something like this via cron:
| cd /srv/config/$(hostname --fqdn)/ marionette
| main.in
|
| I should document that, and the inclusion-facility
| explicitly. But otherwise feel free to file bug-
| reports/feature-requests if you have ideas for modules that
| would be useful.
| lifeisstillgood wrote:
| 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 _anything_ (users,
| servers, customers, whatever) you start finding that "simple as
| possible" does not help that much anymore. LDAP support becomes
| useful and so on.
|
| Maybe, I hope maybe, it's not a real portal that we pass through,
| but it does seem so.
| MINIMAN10000 wrote:
| Unfortunately all I could think of was "that sounds cool but I'd
| want to stick to dash instead of bash"
|
| Also didn't realize it wasn't agentless which is pretty critical
| imo
| yjftsjthsd-h wrote:
| > Unfortunately all I could think of was "that sounds cool but
| I'd want to stick to dash instead of bash"
|
| Well, POSIX sh, ideally. That way you get free portability to
| ~everything; it's not a great burden to install bash or dash on
| ex. NetBSD or AIX, but sh is as close to universally
| preinstalled as you're going to get.
|
| > Also didn't realize it wasn't agentless which is pretty
| critical imo
|
| Ouch, yeah that outright disqualifies it for me.
| t0astbread wrote:
| 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)!
___________________________________________________________________
(page generated 2020-06-25 23:00 UTC)