Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] "Stack Script" (shell script) to build Ubuntu LAMP + on Linode



Greg Rundlett
http://eQuality-Tech.com
http://freephile.org

On Wed, Apr 8, 2015 at 7:01 AM, Edward Ned Harvey (blu) <blu at nedharvey.com>
wrote:

> > From: greg.rundlett at gmail.com [mailto:greg.rundlett at gmail.com] On Behalf
> > Of Greg Rundlett (freephile)
> >
> > So, now that I'm looking at Vagrant, Juju [1], Ansible [2], Puppet [3]
> and
> > others as well as revisiting the general virtualization landscape (e.g.
> LXC,
> > Docker, CoreOS).
> >
> > Does anyone have their favorite deployment tips, playbooks or stories to
> > share?
>
> One of my coworkers is absolutely in love with vagrant, but I don't like
> it because it only plays easily nice with a local virtualbox.


I was introduced to Vagrant through MediaWiki-Vagrant.  It really helped me
develop the HTML2Wiki extension for MediaWiki (
https://www.mediawiki.org/wiki/Extension:Html2Wiki).  And while you're
developing, you can instantly share your environment with a simple 'vagrant
share' which proxies your local development through vagrantcloud.com  Now
this is replaced by 'Atlas' (https://atlas.hashicorp.com/) and I don't know
much about it so I won't comment further on that.  But, one of the pain
points that I ran into was the fact that I couldn't deploy my development
work to AWS.  I tried, but fell short since it was easier to just build out
an instance in AWS and deploy the code normally.


> For him, he's doing experimental or development drupal work, that works
> great.  For me, I'm operating infrastructure to support people, I need to
> interact with a much broader set of vmware, aws, digital ocean - which
> vagrant technically *can* do, but the added complexity negates the
> benefit.  It's just a wrapper around ansible/whatever anyway.  So I just
> use ansible and forget vagrant.
>
> The thing I like about ansible, besides the obvious - Ok, here's the
> obvious - In the past, machines were sometimes not well documented, and
> even if they were well documented, following the documentation was manual
> and error prone (hence you writing your script).  By writing executable
> documentation, you get repeatability and it becomes trivial to spin up a
> development machine that exactly clones the production system, then make a
> change on development and test, and apply the change to production.
>
> Ok, so besides the obvious, I like the fact that I don't need a dedicated
> control machine.  I can do stuff locally on my mac, which ssh's out to the
> target machines to do my work for me.  I find, however, that if you have
> any windows administrators on your team, it becomes worthwhile to build a
> dedicated control machine - some linux box that everyone ssh's into in
> order to run ansible commands.  Because even with cygwin, there is no
> ansible on windows.  (Last I knew, as far as I know.)
>
> All that script stuff you wrote is how I used to do things.  The language
> in ansible makes a lot of that stuff trivial.  For example, how do you
> script "Go into the my.conf file, find the [FooBar] section, and if the
> 'whizbang' feature is in there, edit it to 5, otherwise create a line
> 'whizbang=5'" ...  Yes it can be done, but it's a pain.  But this type of
> configuration setting is just a line in ansible.  Because that's what it's
> designed for.  And what if assumptions were made in your script that are no
> longer correct when you run the script?  The shell script is likely to fail
> horribly doing terrible things.  Ansible will just report the error on the
> specific machine, and stop running on that machine.
>

I'm checking out Ansible now.

I tried Juju, in part because it's Ubuntu "native"; and also because I have
some experience with it in the past.  I find Juju to be pathetic.  Not
necessarily in the technology itself -- which I didn't delve into -- but in
the implementation; ie. their Charm store.  There are several charms for
each 'service'.  No way to rate them or comment -- you have to judge them
by how many times they've been tried.  It is literally an "app store"
experience (only worse) for infrastructure services.  What's next?  "App
store" solutions for cancer?  https://freephile.org/wiki/index.php/Juju#TLDR



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org