111–120 of 180 posts
"Wanna just use fucking shell scripts to configure a server? Read on!" Step 0: Install the gem # gem install fucking_shell_scripts # gem: command not found wat.
works for me! http://rubygems.org/gems/fucking_shell_scripts
* Depends on Ruby.
Earlier quoted context omitted.
I can imagine someone proposing this at some meeting with managers. "For our next product, we're going to use FUCKING SHELL SCRIPTS for configuration and deployment". What would the managers' faces look like... I wonder if this is what you guys had in mind when you came up with the name
The name came about when we were writing the majority of our ansible code. We mentioned to each other in frustration multiple times, "Man, this would be so much easier if I could just use fucking shell scripts."
I spent the last year and a half cross-training from dev to ops. One of the most important lessons I learned: use operating system packages for production; don't compile from source. Compiling from source: - Wait minutes for each instance to come up, as each time requires a fresh compile - Have to download from ruby-lang.org -> you have a dependency on this site being up, bad idea when you hit a load spike, need to s…
The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you can just write in whatever scripting language you like/gets the job done and not need to worry about learning a new domain-specific configuration language. Does anyone else here see value in a configuration management system that centers around installing files a…
This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons. Bottom line, if you are just running a small startup with a few servers a…
Servers are now disposable.
Earlier quoted context omitted.
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…
I agree. It does in fact make me smile a little bit when the puppet installation script is longer than the script to do whatever it is that needs to be done to install the app itself. :) Over time, it may make sense to move to a more deterministic solution, but to start there (IMO) is often a case of premature optimization.
> Over time, it may make sense to move to a more deterministic solution, but to start there (IMO) is often a case of premature optimization.
I mostly agree with this though.
Guiys, the fucking swearing in the name suks alot. Not all the managers like it. That's why we have perfesionalism, cause prfesionalism is good. Guiys, we haf to get along. We cant do it with swearing. Please, think about pleasing everyone and offending none. Otherwise ur milenials, ruining our designated corprate productivity spaces.
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.
> That's why we have perfesionalism, cause prfesionalism is good.
Got a good laugh out of me, seems a little hypocritical to depend on ruby (which chef et al. use) So far I only have experience with puppet, and it seems really annoying to tie phases like "install postgres" -> "Reinitialize the database in UTF-8, but known to work on ubuntu" -> "Update the configs so non-localhost connections can actually connect" -> "Okay, now it can start." The above problem is something I do not…
Author here: fair point. Ruby is only required for the client that's building machines. Ruby is our primary language so it's on all of our servers and laptops. Less about thought and more about lowest barrier to entry ;)
Earlier quoted context omitted.
"I think the answer is still shell scripts and then add on CM afterwards." I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.
you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.
If you deploy more than a few systems a year and don't have a PXE boot environment (or at least the equivalent of a network accessible kickstart config to be manually selected) or a golden image to deploy from, then I can see how CM tools may seem a pain, because you haven't tackled the initial manual pain point yet, the actual install.
I haven't really used any CM tools, so maybe I'm getting the point where kickstart would traditionally leave off and ansible or chef would take over slightly wrong, but I can't see it being all that complex to automate configuring one after install.
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…
Well not blow your brains out difficult but "learn a new syntax, behavior, rules, depend on a new package" difficult if a few shell commands is all you want to do.
I can see where they are coming from. I can go a long way just using shell script to configure (and yes, you can make them idempotent too).
From your site:
> You already have a religious passion for a particular CM tool
Aren't you doing the same against Chef and Puppet then? It sounds like. Oh "comparison" -- yeah just use Ansible.