2015-05-28 13 views
8

Nel mio script Ansible, voglio generare UUID al volo e usarli in seguito.Generazione casuale UUID casuale

Ecco il mio approccio:

- shell: echo uuidgen 
    with_sequence: count=5 
    register: uuid_list 


    - uri: 
     url: http://www.myapi.com 
     method: POST 
     body: "{{ item.item.stdout }}" 
    with_items: uuid_list.result 

Tuttavia ottengo il seguente errore:

fatal: [localhost] => One or more undefined variables: 'str object' has no attribute 'stdout' 

Come posso risolvere questo problema?

risposta

12

In ansible 1.9 c'è un nuovo filtro: to_uuid, che data una stringa che restituisce un UUID specifico dominio ansible, è possibile trovare l'uso qui https://docs.ansible.com/playbooks_filters.html#other-useful-filters

+4

Con lo stesso input i risultati sono sempre gli stessi, quindi avresti bisogno di qualcosa come '{{ansible_date_time.iso8601_micro | to_uuid}} 'per ottenere un vero uuid. – J0hnG4lt

+2

J0hnG4lt questo approccio non produrrà un uuid casuale. –

4

Questo è molto vicino. Ho solo dovuto cambiare alcune cose. L'ho capito usando l'attività "debug: var=uuid_list" e iterando.

- shell: uuidgen    # note 1 
    with_sequence: count=5 
    register: uuid_list 
- uri: 
    url: http://www.myapi.com 
    method: GET 
    body: "{{ item.stdout }}" # note 2 
    timeout: 1     # note 3 
    with_items: uuid_list.results # note 4 

Note:

  1. echo causato la stringa uuidgen da stampare. rimosso echo, mantenuto uuidgen.
  2. item.item.stdout doveva essere item.stdout
  3. Ho utilizzato un breve timeout in modo da poter verificare ciò senza disporre di un endpoint di riposo. Questo dà errori messaggi di errore, ma è chiaro che è corretto.
  4. uuid_list.stdout doveva essere uuid_list.results
6

Come indicato da Xingxing Gao, c'è to_uuid che può essere utilizzato con un numero abbastanza grande e il filtro random per produrre un UUID casuale. Maggiore è il numero maggiore è la casualità. ad esempio:

{{ 99999999 | random | to_uuid }} 

o

{{ 9999999999999999999999 | random | to_uuid }} 
0

essere a conoscenza se si utilizza la soluzione di Willem, Jinja e Ansible potranno memorizzare nella cache il risultato per più esecuzioni dello stesso filtro, quindi è necessario cambiare il numero fonte ogni volta

api_key_1: "{{ 999999999999999999995 | random | to_uuid }}" 
    api_key_2: "{{ 999999999999999999994 | random | to_uuid }}" 

e per le situazioni in cui è necessario un normale md5 anziché to_uuid, hash ('md5') non accetta un numero intero. Il modo più conveniente per convertire il casuale per una stringa che ho trovato è quello di utilizzare to_uuid:

api_key_3: "{{ 999999999999999999999 | random | to_uuid | hash('md5') }}" 
    api_key_4: "{{ 999999999999999999998 | random | to_uuid | hash('md5') }}" 
+0

Mentre può essere generalmente vero che Jinja memorizza nella cache il risultato dei filtri nel modo in cui descrivi, non sembra essere il caso quando viene utilizzato con Ansible. Ho provato questa tecnica per definire una variabile casuale specifica di esecuzione e ottenere valori diversi per il posizionamento della stessa variabile in diversi modelli, ad esempio. Sto usando Ansible 2.3.0 in questo caso. –

1

Una soluzione che dovrebbe essere immune da caching/raduno fatto stantio e vi darò un UUID ragionevolmente casuale ogni volta che si utilizza è:

{{ 999999999999999999999 | random | string + (lookup('pipe', 'date +%s%N')) | to_uuid() }}

si concatena un numero casuale compreso tra 0 e 999999999999999999999 con nanosecondi attuale dal epoca Unix e feed che attraverso to_uuid di Ansible() filtro (disponibile a partire dalla versione 1.9). La memorizzazione dei fatti non dovrebbe causare problemi poiché le ricerche vengono sempre valutate ogni volta che vengono invocate.

Se si desidera un UUID che rimane costante durante i giochi in un playbook (ma non persistono tra più invocazioni del Playbook - anche con effetti caching acceso) quindi utilizzare:

set_fact: uuid={{ 999999999999999999999 | random | string + (lookup('pipe', 'date +%s%N')) | to_uuid() }}