151–160 of 180 posts
Earlier quoted context omitted.
The primary user of your implementation is the next developer to maintain it.
The user of a piece of software is more important than its current or future maintainers.
Earlier quoted context omitted.
Shrug If you want people to use your software -- and you do or you wouldn't be promoting it -- you should consider how you present it. Bad words don't offend me, but they do suggest immaturity and inexperience... qualities I tend to avoid in systems orchestration.
I think they were joking =) > That's why we have perfesionalism, cause prfesionalism is good.
Earlier quoted context omitted.
> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to…
Are there VPS providers that offer NixOS by OOTB?
Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…
In my experience (playing with ansible, on and off, for quite a while) limitations or bugs in the tool often lead to your ansible scripts to become .. shell scripts. The more raw/command/shell modules you have to use, the uglier the whole approach seems to me - and maybe not worth the trouble in the first place. If it can't be done 100% 'right', should I bother? I put my efforts on hold so far. Ansible improved great…
Coauthor here. Well, this is a surprise! This project was mainly borne out of our frustrations with Chef and then Ansible for configuring our servers. A few thoughts: 1) This project is incomplete and is more of a concept than anything. We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time. 2) There is value in what Ansible provides. It does a lot of things for you. FSS did not repl…
hah, this is awesome! thank you. i've used both chef, and puppet. and i still have a puppet standalone bootstrap script that i use every now and then. but I too created a simple shell script bootstrapping process for one of the projects i was working on. it pretty much boils down to this: tar cjf bootstrap.tar.bz2 VERSION library $2 scp bootstrap.tar.bz2 protonet@$1:/tmp ssh -A -t myuser@$1 /bin/bash -c " mkdir -p /t…
It depends on what you're doing, I suppose. Me? I wouldn't want to try to use "simple" bash scripts to manage a large (or even medium) app farm, especially when those servers need ongoing management.
Honestly this is not a bad idea. Since bringing up a new instance VM will always be in exactly the same state, the shell script is completely deterministic. If any line fails to run, you could simply log an error and automatically shut down the VM. The bash script itself is also extremely straight forward and is easily testable with a built in REPL (you know, bash). Anybody who vaguely knows unix is also going to be…
> Honestly this is not a bad idea. Since bringing up a new instance VM will always be in exactly the same state, the shell script is completely deterministic. Wrong, kind of. There are two variables in a VM: 1. Everything not in the VM and 2. The script itself. 1 is mostly dependent on what you're doing. If you're just calculating digits of pi, then yes, it's quite probably deterministic; if you're deploy software th…
Bash is fine, but it's not a sophisticated high-level language. For doing sophisticated things, a simplistic tool is not enough. We need processes that are deterministic and that can act intelligently. The "bash is fine" crowd, in my experience, tends to be the same crowd that thinks that servers are special snowflakes that we must feed and care for. Those days are over.
I originally thought this was a lament about how shell scripts suck, like along the lines of "man, those fucking shell scripts ..." My surprise when I saw this is the exact opposite of that ...
The reason automation, CM, and devops have taken hold is because people are so goddamned tired of serving technology like it's some kind of god to which we owe worship. Screw that. I want the VMs to go make ME a sammich, not the other way around. Trying to build serious infrastructure using nothing but shell scripts is a quick trip to the temple of server-worship.