Our logical configurations are currently kept in Perl (homegrown) and we’re evaluating Ansible as a replacement.
Our configurations are currently “instance” centric not “host” centric. Below is the configuration from 1 test environment. We have 50 test environments each with approximately 20 “application instances” inside each. In our production environment, the Ansible concept of being “host centric” is far easier to map to our infrastructure, but in our test environments I am struggling to map our configurations to “groups” and “hosts” and “vars”.
Challenges:
This environment has 3 hosts, 28 instances, multiple “types”, many ports, subsets and modules.
This environment has port 7000 used on 2 of the hosts for different purposes
This environment deploys multiple different ears/packages to each of the 3 hosts
We like starting all “shop” (module) servers with a single command
We like starting all “fulfillment” (subtype) servers with a single command
We like starting all “apache” (type) servers with a single command
Thoughts and ideas on mapping our config to Ansible would be appreciated.
Our master “config” file looks similar to this (this is 1 environment, remember do this x50):
subset:host:instance:type:sslguiport:guiport:f5pools:depothost:datacenter:modules
admin:ecaretest01:tst01-ecare-admin:weblogic::7000::tstdepot.mysub.domain.org:dc_washdc:esupport
auth:ecaretest01:tst01-ecare-auth:weblogic::7050::tstdepot.mysub.domain.org:dc_washdc: esupport
search:ecaretest01:tst01-ecare-search:weblogic::7030::tstdepot.mysub.domain.org:dc_washdc: esupport
self:ecaretest01:tst01-ecare-self:weblogic::7010::tstdepot.mysub.domain.org:dc_washdc: esupport
odd/even:ecaretest01:tst01-ecareauth-apache:apache::1380::tstdepot.mysub.domain.org:dc_washdc:esupport
main:ecaretest01:tst01-gs-main:weblogic::7610::tstdepot.mysub.domain.org:dc_washdc:globalsearch
wl12:ecaretest01:tst01-wl12-admin:weblogic::7600::tstdepot.mysub.domain.org:dc_washdc:globalsearch
admin:ecomtest01:tst01-admin:weblogic::7000::tstdepot.mysub.domain.org:dc_washdc:
odd/even:ecomtest01:tst01-apache:apache:1443:1080::tstdepot.mysub.domain.org:dc_washdc:
online:ecomtest01:tst01-online-main1:weblogic::7110::tstdepot.mysub.domain.org:dc_washdc:
sales:ecomtest01:tst01-sales-fulfill:weblogic::7140::tstdepot.mysub.domain.org:dc_washdc:
sales:ecomtest01:tst01-sales-main1:weblogic::7020::tstdepot.mysub.domain.org:dc_washdc:
sales:ecomtest01:tst01-sales-sjob:weblogic::7060::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01:tst01-shop-fulfill:weblogic::7040::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01:tst01-shop-main1:weblogic::7010::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01:tst01-shop-sjob:weblogic::7030::tstdepot.mysub.domain.org:dc_washdc:
standalone:ecomtest01:tst01-standalone-main1:weblogic::7210::tstdepot.mysub.domain.org:dc_washdc:
lucid:ecomtest01-author:lucid-data:lucid-data::7158::tstdepot.mysub.domain.org:dc_washdc:lucid,solr_data
lucid:ecomtest01-author:lucid-search:lucid-search::7058::tstdepot.mysub.domain.org:dc_washdc:lucid,search-feed
odd/even:ecomtest01-author:tst01-auth-sales:apache:2443:2080::tstdepot.mysub.domain.org:dc_washdc:
odd/even:ecomtest01-author:tst01-auth-shop:apache:1443:1080::tstdepot.mysub.domain.org:dc_washdc:
odd/even:ecomtest01-author:tst01-auth-stand:apache:3443:3080::tstdepot.mysub.domain.org:dc_washdc:
jservice:ecomtest01-author:tst01-jservice-main1:weblogic::7220::tstdepot.mysub.domain.org:dc_washdc:
sales:ecomtest01-author:tst01-sales-auth:weblogic::8020::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01-author:tst01-shop-auth:weblogic::8010::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01-author:tst01-shop-fosjob:weblogic::7160::tstdepot.mysub.domain.org:dc_washdc:
shop:ecomtest01-author:tst01-shop-ftsjob:weblogic::7150::tstdepot.mysub.domain.org:dc_washdc:
zodiac:ecomtest01-author:tst01-zodiac-fulfill:weblogic::7320::tstdepot.mysub.domain.org:dc_washdc:
zodiac:ecomtest01-author:tst01-zodiac-main1:weblogic::7310::tstdepot.mysub.domain.org:dc_washdc:
Key Term definitions go like this:
CLUSTER
A logical grouping of “application instances”. In production a cluster is used to define only 1 group of instances that all belong to the same application; however, in test environments, one cluster is used to define “all applications that belong to one test environment” (example above).
SUBSETS
A logical grouping of “instances” that is smaller than “cluster”. Subsets are used to determine which “depot” to get files from or to deploy files from.
Subsets are also often used to identify similar servers “within” clusters when doing a “restart of all main instances” or “restart of all apache instances” for example.
TYPE
Type of application server that an instance runs (apache, jboss, web logic, Kara, etc). This is the shrink-wrap middleware type. There is only 1 type for an “instance”. Other specifications of application name or “types” are kept in “attributes".
The “Type” of a server determines which “control script” is used to start/stop/re-load the server.
ATTRIBUTES
Within a “type” of server, the server can run multiple applications. Attributes is where you keep the “application name(s)” that run(s) inside the server type. For example, it can be nessisary for a weblogic (type) server to run “sales” and “fulfillment”. These are good candidates to be used as “attributes”.
Attributes are often used to identify “Similar” servers across clusters. Attributes will likely determine which “runbooks” are appropriate for specific hosts (but the ‘master’ run book for each instance will still be determined by instance “type”.
HOST
An instance of an Operating system (virtual or not) using its “short” hostname. It can contain multiple instances from 1 “environment” or multiple environments. one “instance” can only live on 1 host.
INSTANCE
An instance of an application (apache, nginx, jboss, weblogic, karaf, etc)
GUIPORT and SSLGUIPORT
The port used to view the web-application from a customer-facing experience point of view.
MODULES
Within a specific server, it may be nessisary to deploy multiple “packages”. For example, a given “sales” server may need a security module installed into the weblogic container and/or it may need the “sales.ear” installed. These would be good candidates for use as “modules”. The same ear (module) may go into different “instances” that have different subtypes (fulfillment and shop subtypes). Fullfillment servers need to all restart “together” but each fulfillment server might get a different ear (shop and sales modules). some modules (like JSTL.war) would be deployed inside the web logic container but not run as a “separate instance”.
DEPOT_HOST
Each “instance” will rsync its “modules” down FROM a DEPOT_HOST and/or DEPOT HOSTS will “send” their modules to “instances”.