Live data from Hacker News

Show HN: Ansible Crash Course

news.ycombinator.com

41–50 of 55 posts

Re: Show HN: Ansible Crash Course

#41

This won't be really helpful to you since you've already built it, but I'm the kind of person who doesn't like videos. I AM interested in Ansible, but I don't want to sit through videos about it; I want to read and follow the examples as I do. Actually, I wonder what the split is between people who prefer videos vs people who prefer reading?

I know at this point this has been stated, but since this thread has effectively turned into a poll, here's my vote :)

I love videos if I'm starting out from scratch or if I'm trying to go an exhaustive course on something I've learnt on an ad-hoc basis.

However, if I know the tech or have done a course before, I can't bring myself to finish the video.

Regarding Ansible. I'm new so I'd probably take your course :)

Re: Show HN: Ansible Crash Course

#45

Earlier quoted context omitted.

Not op but it is mentioned in the Show HN blurb above: > Just note an email address is required to register for the course - this is a limitation of the platform I'm using to host the course. Sorry about that!

That doesn't quite seem like an answer. Can I put in a fake address? If I put in a real address, will the platform decide to spam me?

Yes you can.

Re: Show HN: Ansible Crash Course

#46

This won't be really helpful to you since you've already built it, but I'm the kind of person who doesn't like videos. I AM interested in Ansible, but I don't want to sit through videos about it; I want to read and follow the examples as I do. Actually, I wonder what the split is between people who prefer videos vs people who prefer reading?

I prefer video as it shows. Text only leaves too much ambiguity to interpretation. Having taken multiple courses in coursera, edx and other online learning platforms, the video in this course is pretty well made.

Re: Show HN: Ansible Crash Course

#47
very few people understand the basics and you hit right on the point it is a state management with configuration as code and others can contribute to your work and approve the changes you are going to make rather than just you go make them, you can test the configurations on test machines before throwing into real world so you are adding extra set of eyes to prevent catastrophe.

Re: Show HN: Ansible Crash Course

#48
post #34
post #32

Earlier quoted context omitted.

How about plain old SSH? like all those low-end-boxes, you know ;).

I could write a provider to do so in a couple hours if one doesn't already exist. But frankly, if you're using those boxes you've already decided that your time is worth less than your money and spending time on automation is probably lower ROI than moving to something, anything, with an API. Anything that isn't IBM, anyway.

Cool, if your provider will have a tested way to install packages, copy/template files and setup services beyond docker. Basically Ansible/Saltstack/Puppet/Chef _are_ the API for plain UNIX.

As for the great "time worth less than money"-argument - I host my own nextcloud (for me and my family) on such a VPS for ~USD9. I get some 100GB of storage, ample RAM and CPU; sure that's probably oversubscribed, but after setup I can leave it running for years without worrying to check my bandwidth/storage quota in addition to it being cheaper than any big cloud-provider. Initial setup works with cloudinit and managing the VMs itself has an API. And I suppose for everyone not running a customer-facing business, the ROI of such solutions is basically unparalleled ;).

Re: Show HN: Ansible Crash Course

#49
post #48
post #34

Earlier quoted context omitted.

I could write a provider to do so in a couple hours if one doesn't already exist. But frankly, if you're using those boxes you've already decided that your time is worth less than your money and spending time on automation is probably lower ROI than moving to something, anything, with an API. Anything that isn't IBM, anyway.

Cool, if your provider will have a tested way to install packages, copy/template files and setup services beyond docker. Basically Ansible/Saltstack/Puppet/Chef _are_ the API for plain UNIX. As for the great "time worth less than money"-argument - I host my own nextcloud (for me and my family) on such a VPS for ~USD9. I get some 100GB of storage, ample RAM and CPU; sure that's probably oversubscribed, but after setup…

Thanks for the lecture; I didn't spend three years teaching Chef at a Fortune 100, I promise.

You get that one can just write a thing to kick off instance-level CM if it doesn't exist, yeah? Like I don't know if it does for Pulumi because Pulumi doesn't seem to care much about trailing-edge systems--for now at least, it seems, they have a big enough market without having to stretch backwards--but it's not complicated; Terraform already has provisioners to do exactly that, so the pattern exists.

Re: Show HN: Ansible Crash Course

#50
post #34
post #32

Earlier quoted context omitted.

How about plain old SSH? like all those low-end-boxes, you know ;).

I could write a provider to do so in a couple hours if one doesn't already exist. But frankly, if you're using those boxes you've already decided that your time is worth less than your money and spending time on automation is probably lower ROI than moving to something, anything, with an API. Anything that isn't IBM, anyway.

Dunno, in my experience there is a long tail of use-cases where it is a more practical to work closer to system level (for different reasons: less complexity, political issues, legacy systems, etc.), so I don't think it's as black and white as you make it out to be. But I agree that there is a threshold after which 'everything API' is the way to go. Where that threshold is if often guesswork.

Overall, I don't think our tooling is quite there, and we haven't found the right abstractions yet. Terraform and Pulumi are nice enough, but to me it looks like they are only treating the symptoms, instead of looking at the issues on a more holistic level. I don't have any good solution for that, but I think we'll need to try to look at everything we're doing from different perspectives than the ones we are used to. That's hard (at least for me), and it's getting harder the deeper we dive into the current layers of complexity wrapped into more complexity.

Post reply on HN