On Sat, May 02, 2020 at 04:12:11PM +0200, Stefan Hornburg (Racke) wrote:
> On 5/2/20 3:35 PM, Marc Haber wrote:
> > On Tue, Apr 28, 2020 at 09:48:23AM +0200, Stefan Hornburg (Racke) wrote:
> >> On 4/27/20 10:12 AM, Marc Haber wrote:
> >>> Let's assume I have a service that can listen on different combinations
> >>> or host/port:
> >>>
> >>
> >> Hello Marc,
> >>
> >> nice to see you here :-). This is certainly doable:
> >>
> >> ---
> >> - hosts: all
> >>
> >> vars:
> >> host:
> >> service:
> >> hostname: "google.com"
> >> ports:
> >> - "80"
> >> - "443"
> >> tasks:
> >> - name: Get DNS records
> >> set_fact:
> >> ip_addresses: "{{ ip_addresses | default([]) + lookup('dig',
> >> host.service.hostname + '/' + item, wantlist=True) }}"
> >> loop:
> >> - A
> >> - AAAA
> >> when: "'listen' not in host.service"
> >
> > This sets a local fact to the list of IP addreses pulled from DNS.
> > Adding the IPv6 addresses is an easy enogh exercise.
>
> It already contains the IPv6 addresses (AAAA record).
Idiot me, of course, I missed the loop.
> >> - name: Determine all combinations of IP address and ports
> >> set_fact:
> >> ips_ports: "{{ ip_addresses | product(host.service.ports) | list
> >> }}"
> >> when: "'listen' not in host.service"
> >
> > That's magic. Cute, indeed. This returns a list, alternating between IP
> > adress and port, like [ ip1, port1, ip2, port2, ip3, port3 ]
>
> It contains all IP and port combinations as nested list:
>
> [[ip1,port1],[ip1,port2],[ip2,port1]]
Now it all makes sense to me. Thanks for explaining. I'm still wondering
whether it would be possible for a more complex of variable data
definition.
> > Can a custom inventory plugin access what the previously running
> > inventory plugins have parsed, and can it augment structure that was
> > build by the predecessors? This way, I could have all processing power
> > and flexibility of imperative programming. I could think of a gazillion
> > of other places where this could be useful to simplify my templates
> > _AND_ my inventory.
> >
> > Having this done inside ansible would allow me to take advantage of the
> > inventory reading logic that is already present in ansible. I could
> > write a preprocessor writing out the "augmented inventory" before
> > ansible is started, but I'd have to manually process the inventory file
> > -and- the contents of the host_vars and group_vars directories. I'd like
> > to avoid this.
Any idea whether this would work?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/20200509053605.GA18228%40torres.zugschlus.de.
