ansible on 'brownfield' sites
Dick Davies
(devs, staging, prod) from kickstart to production, and I imagine
that's how most folks here would use it.
My current mission is to add some automation onto a lot of 'handbuilt'
environments that have grown up from scripts. As you'd expect, each
new environment has learned from the lessons of the previous one and
the scripts have evolved.
Unfortunately, that means each environment is different, sometimes
radically - not just in scale of a given service but often in the
presence or absence of it. There's a lot of commercial software
deployed too, which results in the inevitable "we don't have enough
licenses for $TECHNOLOGY to run it in all the dev. environments" and
more drift.
Basically "a maze of twisty environments, non alike" ..
I'm making some headway in getting inventories written up to at least
start to use adhoc tasks for some of the routine tasks. Next phase is
"roads and sewers" - fairly straightforward services that are simple
to setup but essential (e.g. NTP, SNMP, yum repos).
I'm hoping to tackle some of the inconsistencies with liberal use of
$inventory/group_vars folders to enable/disable roles based on where
I'm running.
I had a look around but haven't seen much discussion about
retrofitting Ansible to try to tame this kind of sprawl. Would be
interested in how others have tackled the challenge - "nuke the site
from orbit" and "run away screaming" excluded.
Mark Janssen
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK5eLPQao_NYjxGxU4eB0hkuGJifWSbTr7pm2HYYar9d%2BrOS1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Unix / Linux Open-Source and Internet Consultant
Maniac.nl Sig-IO.nl Vps.Stoned-IT.com
pixel fairy
we keep different inventory files for some stuff, and sometimes a vagrant file with its own inventory as "dev/test" for smaller or personal projects. one folder will have roles downloaded from galaxy. the others next to it have be for their own sections instead of one big ansible tree for everything. for example, all the routers and firewalls are in their own tree, so if you want to look at the changelog for those, its easy. so your tree could look like this. if you want to keep them all in one big repository, you'll probably want git submodules.
ansible
|--roles
| |--jcarmack.doomserver
| |--jdoe.ircd
|
|--routers
| |--ansible.cfg
| |--inventory
| |--site.yml
| |--.git
|
|--production
| |--ansible.cfg
| |--inventory
pixel fairy
On Thursday, June 16, 2016 at 5:15:38 AM UTC-7, Dick Davies wrote:
Adam Morris
If I get to the point where I have spare time I will start slowly fixing the old systems. One (or at least one batch) at a time. I don't intend to modify everything but if I can take over the management of the basic infrastructure then at least that will be uniform across all systems. DNS, NTP, monitoring, backups, SA accounts,...
Brian Coca
Adam Morris
Resistance from co-workers is a big problem...
Legacy systems is another one but can be dealt with...
In some cases their are other issues though...
But equally it is not always possible to replace manual installations. I am not an Oracle DBA and in the organisation I work for the DBAs are a separate team. While it might be possible for me to automate Oracle installation and configuration, I don't know what to do, and I don't think that they would let me. (Heck, they don't listen when I tell them that asmlib is not needed, is a hack, and we should use the OS equivalent which is better supported)
Some of our installs could be automated, but when you only install the app once on two machines and the vendor supplied instructions are several hundred pages, I am not going there. If the vendor wants to automate their install process then great, but in that case I am not. (The application, database, message bus, DNS entries, file systems, network settings, etc are all detailed. The application alone consists of several hundred daemons and has its own registry...)
Finally I also have to deal with some systems which have been approved by a regulatory agency. Those ones cannot be changed without a lot more approval work. In those cases we are mostly at the mercy of the application vendor.
Brian Coca
Adam Morris
Indeed. I am talking about a large organisation (several hundred Unix/Linux servers alone, across five states, six major data centres) which has a lot of cruft, some very large, very complex applications, some federal regulation, and so on.
Even in this situation though we can introduce standardised server builds for all new servers, roll the infrastructure pieces under configuration management on (most of) the existing servers, and so on. Even if the applications look different on every machine (and some of those will be rolled out with the same configuration management tool, increasing as the apps get lifecycled) the operating systems themselves will become more and more uniform.
While it would be nice to be able to just rebuild everything it isn't always possible. But starting with one or two changes and rolling those out, then moving on to the next one might seem like small victories but over time they all add up. When you know that you can log on to a server and have standard tools and configurations it feels much better than not knowing who hand crafted the artisanal server you now have to deal with and what their preferences are.
Of course management likes the fact that I can roll out a new Linux server in 15 minutes compared to the old "two weeks" and they were all different.
Mikael Sandström
Dick Davies
There's plenty of buy in from the new team, it's just deciding which
sequence of bites we use to eat the elephant. Agree with earlier
points that the key to this is knowing when to stop (Oracle team have
actually got their act together, but they're happy using
Oracle-specific management and I have no intention of changing that
for changes sake).
Another interesting point is there are at least 3 other CM systems in
play here, all of which are doing a bit of the management roles (and
yes that's as interesting as it sounds). I'm still finding servers I
'miss' because they aren't in the official inventory (I have a nasty
feeling there are several official inventories >_< ).
I'm also expecting some talks with architects when it comes time to
start decommissioning e.g. the puppet layer; the on call teams are
always the ones who see the benefit but when you start to revisit the
Agreed Solution you need to be careful :)
I'm wary of stepping on toes and coming across as a zealot, so I think
it's time to meet up with a few teams and see who's keen to migrate
first. With a bit of luck that'll get us some momentum.
It's a redhat/satellite shop so the upcoming Ansible integration with
Satellite is hopefully going to make this an easier sell (plus the
change windows I've been putting in are waay smaller and management
have started to notice that).
Wish me luck, should be interesting :)
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit