Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat is buying Ansible

venturebeat.com

Post reply on HN
Print view View original

91–100 of 186 posts

Re: Red Hat is buying Ansible

#91

Post by devit »

jjnoakes wrote: post #81
qznc wrote: post #60

Earlier quoted context omitted.

I don't think devit challenges the "automate" part, only the "separate tool" part. In Ansible you specify a sequence of commands just like you do in a shell script.

Take the time to learn a tool like Ansible. It is not about replaying a simple sequence of commands (imperative). It is more about declaring what you want your system to look like, and letting the tool decide which pieces need to run based on the current state of the system. It's like make vs a shell script. If you use scripts to build your programs, you either have to write your own checks to test whether every step…

Most shell commands are actually "declarative" in a sense.

If you run "apt-get -y install foo" that means that you want "foo" to be installed. If it's already installed, it just does nothing.

In Ansible, you'd use "apt: name=foo state=present" which does exactly the same thing as the apt-get command, but requires a web search to figure out how to write (assuming you know normal Linux system usage but haven't memorized Ansible).

The only differences seem to be that Ansible tells you whether the command made a change or not, and that you can parse the Ansible configuration with an external tool (assuming there are no loops/variable/etc.), but both of these things don't really seem that useful in practice.

Re: Red Hat is buying Ansible

#92

Post by wtbob »

devit wrote: post #43

Every time I use some "configuration management" tool I wonder whether it's really better than just using shell. Basically you lose a lot of time searching the web for how to do things that you already know how to do in shell, but the benefits are not so clear.

I think that the big problem with shell is that it doesn't really offer the right abstractions for a lot of this: one doesn't (normally) want to run:

    if [ ! -d /opt/foothing ]
      then rm -f /opt/foothing && mkdir /opt/foothing
    fi
    cd /opt/foothing
    tar xf /tmp/instpkg.tar.gz
    sed -e s/QQQbarvalQQQ/$BAR_SETTING/ -i /opt/foothing/config
    …
Normally, one just wants to install & configure foothing. Abstracting that away in shell is possible but a pain: it doesn't really have a rich language for composing paths and other variable values; quoting is a right royal pain; by the time one's written a fully-working shell script (note that the snippet above has no error-handling, breaks if /opt doesn't exist, breaks if $BAR_SETTING contains whitespace and doesn't enable one to override the foothing installation location), it's nearly impossible to read & understand.

The Right Answer would involve a language which enabled one to create one's own syntactic abstractions in order to satisfy the general and specific needs of software installation. As an example, it'd be nice to have a WITH-INSTALLATION-DIRECTORY construct, which ensures that a directory exists, ensures that it's owned by the appropriate user, ensures that no other package already claims it (except that a previous version of the currently-being-installed package is okay), registers the directory and everything created in it during WITH-INSTALLATION-DIRECTORY as belonging to the currently-being-installed package, handles errors in a well-defined and useful manner for calling code, and so on and on and on.

And of course even that isn't high-level enough: If I'm installing bazit, which depends on foothing and quuxstuff, then I'll want to call something which ensures they exist. Or maybe there's an optional 'dependency,' and I want to do certain things if they exist and certain if not.

And maybe it's not low-level enough either. What if I want to override one particular sort of installation behaviour, but not the rest? What if I want to install a package in my own account, as myself? Wouldn't it be cool if I could set a few variables and the package manager Just Worked™?

As another user indicated, what all these tools really need is to be Lisp: versionable data which is code. As Shiver's work with scsh demonstrated, a Lisp-like language can be very pleasant to write POSIX applications in. Macros enable one to create useful syntactic constructs which make meaning, rather than details, clear. Dynamic variables (as in Common Lisp) easily enable customisation based on the call stack. CL's condition and restart systems are the gold standard for error signalling and recovery.

Re: Red Hat is buying Ansible

#93

Post by dethos »

WestCoastJustin wrote: post #58

If you're new to Ansible. I've created about two hours of free screencasts on it. It's a very simple to use and understand configuration management tool. https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl... https://sysadmincasts.com/episodes/45-learning-ansible-with-... https://sysadmincasts.com/episodes/46-configuration-manageme... https://sysadmincasts.com/episodes/47-zero-downtime-deployme...

Thanks for the videos, I'm starting to learn it right now and they couldn't have come in a better time.

Re: Red Hat is buying Ansible

#94

Post by ufo »

gerbilly wrote: post #87
anton_gogolev wrote: post #38

Earlier quoted context omitted.

Spot on. I'm constantly amazed at how many projects use _serialization formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.

It seems like parsing is becoming a lost art. Maybe because it can't be easily approached by the iterative development style that is in fashion these days.

The real lost art here is scripting languages. Even if you parse things yourself, configuration files still have a natural tendency to evolve into a crappy programming language over time. So instead of writing your own config file format you should just make a couple a quick bindings for a scripting language like Lua, Python or Ruby.

Re: Red Hat is buying Ansible

#96

Post by falcolas »

JonnieCache wrote: post #48
ABS wrote: post #39

Earlier quoted context omitted.

I interviewed a few folks on the topic some time ago and published the results here: https://highops.com/insights/immutable-infrastructure-6-ques... I particularly like the definition that emerged: 'I see it as conceptually dividing your infrastructure into "data" and "everything else". Data is the stuff that's created and modified by the services you're providing. The elements of your infrastructure that aren't mana…

This is all well and good, but the devil is in the details. Like rdeboo says, what happens when you do need to change the datastore config? Databases famously need plenty of care and attention to achieve optimal performance. They are decidedly not fire and forget systems. How do I tweak my postgresql performance parameters in the immutable world?

Not to mention the mere act of transferring data as part of the migration from old to new can take hours on its own.

Re: Red Hat is buying Ansible

#97

Post by gnurag »

stonogo wrote: post #77
dspillett wrote: post #28

Earlier quoted context omitted.

To me "did not immediately respond to requests for comment" smacks of neediness and self importance on the reporter's part (answer me now, you fools, don't you know who I am and what power I behold?!) and the people that would respond to such comments being in the middle of dealing with something more important at the time (perhaps answering a queue of queries that came in first, or queries from people who are more i…

I have always read it as "did not respond to requests for comment, but we didn't give them much time."

More like "Both companies didn't immediately respond to requests for comment. Its 8:30PM and no one's taking my calls or responding to my emails, but we're an online publication and want our content to go viral and get maximum eyeballs, so we'll run this story anyway."

Re: Red Hat is buying Ansible

#98

Post by bryanlarsen »

leg100 wrote: post #26

This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarative' and easy to read, yet piling on loops and conditional statements and an unintuitive inheritance tree of global and local variables.

You missed the quoting mess, adding their own compact list and map grammar, the convention of having a comment on every line, and there's more I can't think of right now.

I hate ansible, it's just better than any of the alternatives for different reasons. Luckily we're moving away from needing any of them. Scripting an image build is a lot easier than updating a machine using CI: you start from a blank slate every time, and an out of date script isn't the catastrophe it is with CI since you have the images saved.

Re: Red Hat is buying Ansible

#99

Post by falcolas »

crdoconnor wrote: post #79
KarlPlatt wrote: post #78

My experience with Ansible has not been so pleasant. Especially performance is a jobstopper. In my environment it takes 20 min for 12 Servers to be setup with some Redis, Elasticsearch stuff. Quite some become_user directives, but 20 min for this kind of stuff is just not acceptable. After all, application settings needs to be tuned and iterated over, too. My idea was to develop the infrastructure with Ansible, e.g.…

>After all, settings needs to be tuned and iterated over, too. That's why it has tags. So you can run just the settings states rather than running the whole 20 minute thing over and over again.

You can just run portions of the playbooks, but then you lose the value of a descriptive infrastructure. What does X look like? Depends on when each tag was run.

Re: Red Hat is buying Ansible

#100

Post by falcolas »

jjnoakes wrote: post #81
qznc wrote: post #60

Earlier quoted context omitted.

I don't think devit challenges the "automate" part, only the "separate tool" part. In Ansible you specify a sequence of commands just like you do in a shell script.

Take the time to learn a tool like Ansible. It is not about replaying a simple sequence of commands (imperative). It is more about declaring what you want your system to look like, and letting the tool decide which pieces need to run based on the current state of the system. It's like make vs a shell script. If you use scripts to build your programs, you either have to write your own checks to test whether every step…

It's not that hard to make a shell script idempotent - I've done it quite a bit. You check for the artifacts of an install and branch based on the results.

I still use Salt instead of shell scripts, but that's mostly to have the authenticated/encrypted channels and only have to push my code to one place to run it globally.

Post reply on HN