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

Maybe we’ve not improved things as much as we think we have with Devops?

biven.org

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#21

Post by boon »

stonogo wrote: post #16
cheeseprocedure wrote: post #15

Earlier quoted context omitted.

Because it's not worth re-implementing the functionality available in Jenkins, Chef, etc. etc. etc.

This is a misunderstanding of the situation. Jenkins specifically has no business being anywhere near a production deployment; it is a development tool, despite "devops" people tending to use it as a web-interfaced crond. Automation should be tooled to the production environment by people who are familiar with the production requirements and -- most importantly -- by the people who will be expected to maintain the en…

What's wrong with using jenkins to invoke the local tooling?

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#22

Post by falcolas »

toomuchtodo wrote: post #6
PaulHoule wrote: post #2

One problem is that existing devops tools are not that good. For instance it seems insane to me that packer and vagrant exist as entirely separate products. As a java programmer I find that vagrant files are way too verbose. I am sure I could write some Ruby functions to take care of that and also to fix zillions of other things that are awful about Vagrant, but then everybody writes their own functions.

Try Docker instead. I can build Docker containers that provide our devs with a full blown dev environment that mimics production, which anyone on the team can then pull down with a simple "docker pull / :latest" command.

Docker has its own issues, and in the end is remarkably similar to Vagrant when it comes to development. Docker's biggest win on the development (not deploy) front is that docker containers are faster to set up and tear down; though with a decent Vagrant setup and a package cache, you can build a brand new Vagrant image in under a minute.

Since I'm on a Mac, and thus going to be running VirtualBox anyways, I prefer to just work with the VMs directly.

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#23

Post by _wmd »

herge wrote: post #20
whistlerbrk wrote: post #14

This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.

Bash scripts (to pick the most popular shell language) are hard to write, hard to debug (no stack traces), have weird historical artifacts, like not having named arguments to functions, or [[ $foo == true ]] or a whole slew of gotchas that make writing and maintaining them unpleasant. If your application is written in ruby or python, why should you learn another (worse scripting, but that's just my opinion) language…

> hard to write, hard to debug (no stack traces), have weird historical artifacts

Only slightly being sarcy, but this perfectly describes my experience of Salt, Ansible and Chef, but instead of a handful of 'ps' commands to figure out what's going on, you have Python/Ruby interpreters on both sides of the SSH connection, giant gumps of weird SSH command lines, a big C++ library and multitudes of TCP ports and home-grown crypto (Salt+ZeroMQ), perfectly descriptionless error messages like "Timed out", "command failed", or even worse, something you never had to deal with in shell: "template syntax error".

I have a personal axe to grind in this department (been thinking about this style of system since the mid 2000s, but never dared start yet another project), so it's entirely possible my expectations are higher than normal here. Still.. processing YAML with Jinja2? Seriously, bash or the most arcane old Makefile syntax was better than this.

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#24

Post by chimeracoder »

whistlerbrk wrote: post #14

This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.

> Not trying to be too snarky, but why can't people just use shell scripts for automation?

This is why I love Ansible.

Unlike many of the alternatives, Ansible doesn't try to invent a radically different DSL. Instead, ansible uses YAML playbooks that degrade very nicely to shell commands[0]. You can literally take almost any shell script and turn it into an Ansible playbook with a series of Vim regexes - or heck, write a simple sed script to translate it automatically.

Of course, if you use Ansible modules instead of the `command` directive, you get a lot of performance benefits and guarantees of idempotency. But it doesn't try to reinvent the wheel; it just builds on top of it.

It makes it really easy to hack together an Ansible script that is immediately understood by anyone who's used bash/sh and it makes it possible to improve upon it incrementally by replacing shell commands with the relevant Ansible modules.

I've used other automation tools, and the thing that I really disliked about them was that it was so difficult to migrate an existing workflow to a new paradigm. In 2015, systems work is still very imperative, so while declarative syntax is philosophically attractive, I still find it way more practical to use the tools that require smaller mental leaps.

[0] e.g., this thing was hacked together from a shell script, and I never bothered to clean it up, but it's still already more readable than the equivalent shell script: https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/ma...

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#25

Post by falcolas »

whistlerbrk wrote: post #14

This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.

For the same reason we don't write all of our backend tools in C: there are better languages for this domain, and better libraries which we can leverage.

For example, when running Puppet or Salt, I don't have to worry about which package manager is installed, or mucking about with checksums to see if a file needs to be replaced, or templating, or variables, or...

If I'm being honest, just the thought of writing dozens of sed and awk commands to mimic the templating offered by Jinja gives me hives.

That said, after fighting for a few years with Puppet, then Ansible, then Salt, I'm thinking that bash and make files are sorely underestimated for some of the simpler provisioning tasks. Bootstrapping a Salt Minion or a salt master is a lot more straightforward in bash than it is in Salt itself.

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#26

Post by herge »

_wmd wrote: post #23
herge wrote: post #20

Earlier quoted context omitted.

Bash scripts (to pick the most popular shell language) are hard to write, hard to debug (no stack traces), have weird historical artifacts, like not having named arguments to functions, or [[ $foo == true ]] or a whole slew of gotchas that make writing and maintaining them unpleasant. If your application is written in ruby or python, why should you learn another (worse scripting, but that's just my opinion) language…

> hard to write, hard to debug (no stack traces), have weird historical artifacts Only slightly being sarcy, but this perfectly describes my experience of Salt, Ansible and Chef, but instead of a handful of 'ps' commands to figure out what's going on, you have Python/Ruby interpreters on both sides of the SSH connection, giant gumps of weird SSH command lines, a big C++ library and multitudes of TCP ports and home-gr…

Yeah, I agree with you, the tools are lacking. My favorite to date is ansible, but it's a pain to guess the syntax to the magic language that ansible has encoded inside yaml. But then that's maybe that's more of an ansible 1.1 or 1.2 issue, not sure if it's relevant anymore. I kinda wish I could just write python scripts that would use ansible as a library.

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#27

Post by billybofh »

whistlerbrk wrote: post #14

This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.

Having been doing sysadmin duties for more years than I care to remember and having gone through the gradual process of manual configuration -> shell scripts -> cfengine -> puppet, I'd say despite problems in tools like puppet/salt/etc they are way, way more reliable and sysadmin friendly than shell scripts.

For just one example, I've recently begun deploying CentOS 7 boxes whereas previously we mostly used 6 (and some 5). Largely the existing puppet modules kept on working despite major OS changes (hello systemd!). If I'd been maintaining a set of bash (or as used to be, csh) scripts I'd hate to imagine the amount of spaghetti I'd have to have mashed up.

We've also got almost every Linux distribution out there you can think of, versions going back a decade or more, Solaris boxes, BSD's and not long got rid of our last AIX box (and I'm going to ignore the last couple of OpenVMS machines). Handling it with hand-rolled scripts was really not fun compared to puppet.

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#28

Post by falcolas »

chimeracoder wrote: post #24
whistlerbrk wrote: post #14

This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.

> Not trying to be too snarky, but why can't people just use shell scripts for automation? This is why I love Ansible. Unlike many of the alternatives, Ansible doesn't try to invent a radically different DSL. Instead, ansible uses YAML playbooks that degrade very nicely to shell commands[0]. You can literally take almost any shell script and turn it into an Ansible playbook with a series of Vim regexes - or heck, wri…

My biggest problem, well two problems with Ansible:

The maintainer is unusually hostile to user contributions, especially when compared to, say, Salt. A colleague of mine tried to contribute a (fully functional, tested, and documented) change to the MySQL user module to support passing in hashes for user creation - the pull request was closed with a comment like "this can go in a community module". Nevermind that the MySQL user module is a core module...

It's also horrendously slow when your playbooks grow. The constant copying back and forth over SSH can be downright crippling. Just running a "green" (the server is in the target state and no changes need to be made) playbook against a local vagrant instance can take over a minute for my current monitoring server playbook. As a point of comparison, Salt completes in about 5 seconds.

That said, it's still one of the best "no setup" tools, for the cases where you can't install a minion of one flavor or another. (Yes, theoretically the salt-ssh command line tool exists, but it requires NOPASSWORD sudo on the target server to run)

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#29

Post by chimeracoder »

falcolas wrote: post #28
chimeracoder wrote: post #24

Earlier quoted context omitted.

> Not trying to be too snarky, but why can't people just use shell scripts for automation? This is why I love Ansible. Unlike many of the alternatives, Ansible doesn't try to invent a radically different DSL. Instead, ansible uses YAML playbooks that degrade very nicely to shell commands[0]. You can literally take almost any shell script and turn it into an Ansible playbook with a series of Vim regexes - or heck, wri…

My biggest problem, well two problems with Ansible: The maintainer is unusually hostile to user contributions, especially when compared to, say, Salt. A colleague of mine tried to contribute a (fully functional, tested, and documented) change to the MySQL user module to support passing in hashes for user creation - the pull request was closed with a comment like "this can go in a community module". Nevermind that the…

I haven't had any interactions with the maintainer(s), but I absolutely agree with the point on performance from SSH[0]. That said, I do like that Ansible makes no assumptions about your target server's initial state except that it is accessible over SSH (the rest can be bootstrapped from Ansible).

My use case is admittedly much simpler than what Ansible allows for: I use it almost exclusively to provision a host for containers (and then to initialize/start those containers). As a result, my playbooks tend to remain small.

I don't think this use case is realistic for everyone yet, but I think that's the direction we're headed (more containerization), and that it won't be too long before this becomes the norm in devops.

[0] Seriously, the "copy" command is the best illustration of this - thank God that "synchronize" also exists!

Re: Maybe we’ve not improved things as much as we think we have with Devops?

#30

Post by rev_bird »

stonogo wrote: post #16
cheeseprocedure wrote: post #15

Earlier quoted context omitted.

Because it's not worth re-implementing the functionality available in Jenkins, Chef, etc. etc. etc.

This is a misunderstanding of the situation. Jenkins specifically has no business being anywhere near a production deployment; it is a development tool, despite "devops" people tending to use it as a web-interfaced crond. Automation should be tooled to the production environment by people who are familiar with the production requirements and -- most importantly -- by the people who will be expected to maintain the en…

> Jenkins specifically has no business being anywhere near a production deployment

I'm curious about this -- what's wrong with using the same deployment tool for running dev _and_ the other environments? Jenkins itself is a life-saver for, like you said, doing development builds/testing/reporting, but if we've got one script that deploys an image to production, why not trigger it with a Jenkins job, if only to keep everything centralized and maintain coherent deployment histories?

Post reply on HN