Kann Ansible unarchive dazu gebracht werden, Änderungszeiten für statische Ordner zu schreiben?

Question 1

Ich schreibe einen Build-Prozess für eine WordPress-Installation mit Ansible. Es hat im Moment kein Build-System auf Anwendungsebene, und ich habe mich für Ansible entschieden, damit es sich sauber in Server-Build-Skripte integrieren lässt, sodass ich auf Knopfdruck einen funktionierenden Server aufrufen kann.

Die meisten meiner WordPress-Plugins werden mit installiert unarchive Funktion, die auf versionierte Plugin-Builds auf dem offiziellen Installationsserver von wordpress.org verweist. Ich habe nur bei einem davon ein Problem festgestellt, nämlich dass es immer als “geändert” markiert wird, obwohl die Dateien genau gleich sind.

Nach Prüfung des Zustands ls -Rl Vorher und nachher bemerkte ich, dass dieses Plugin (WordPress HTTPS) das einzige ist, das interne Unterverzeichnisse verwendet, und bei jeder Dekomprimierung wird die Änderungszeit von Ordnern angestoßen.

Es kann hilfreich sein zu wissen, dass dies ein Projekt-Build-Skript ist, mit a connection von local. Ich vermute daher, dass SSH nicht verwendet wird.

Hier ein Ausschnitt aus meinem Playbook:

- name: Install the W3 Total Cache plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/w3-total-cache.0.9.4.1.zip
    dest=wp-content/plugins
    copy=no

- name: Install the WP DB Manager plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/wp-dbmanager.2.78.1.zip
    dest=wp-content/plugins
    copy=no

# @todo Since this has internal sub-folders, need to work out
# how to preserve timestamps of the original folders rather than
# re-writing them, which forces Ansible to record a change of
# server state.
- name: Install the WordPress HTTPS plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/wordpress-https.3.3.6.zip
    dest=wp-content/plugins
    copy=no

Eine hackige Methode, dies zu beheben, ist die Verwendung ls -R vorher und nachher, Verwenden von Optionen zum Einschließen von Dateigrößen, aber nicht von Zeitstempeln, und dann md5sum diese Ausgabe. Ich könnte es dann als geändert markieren, wenn sich die Prüfsumme ändert. Es würde funktionieren, ist aber nicht sehr elegant (und ich möchte das für alle Plugins tun, um die Konsistenz zu gewährleisten).

Ein anderer Ansatz besteht darin, die Aufgabe abzubrechen, wenn eine Plugin-Datei bereits vorhanden ist, aber das würde zu Problemen führen, wenn ich die Plugin-Versionsnummer auf die neueste Kopie erhöhe.

Daher suche ich idealerweise nach einem Schalter, an dem ich mich präsentieren kann unarchive zu sagen, dass ich den Ordner mal aus der Zip-Datei modifizieren möchte, nicht aus der Playbook-Laufzeit. Ist es möglich?

Update: Ein Kommentator fragte, ob sich der Dateiinhalt in irgendeiner Weise geändert haben könnte. Um festzustellen, ob dies der Fall ist, habe ich dieses Skript geschrieben, das eine Prüfsumme für (1) alle Dateiinhalte und (2) alle Datei-/Verzeichniszeitstempel erstellt:

#!/bin/bash

# Save pwd and then change dir to root location
STARTDIR=`pwd`
cd `dirname $0`/../..

# Clear collation file
echo > /tmp/wp-checksum

# List all files recursively
find wp-content/plugins/wordpress-https/ -type f | while read file
do
    #echo $file
    cat $file >> /tmp/wp-checksum
done

# Get checksum of file contents
sha1sum /tmp/wp-checksum

# Get checksum of file sizes
ls -Rl wp-content/plugins/wordpress-https/ | sha1sum

# Go back to original dir
cd $STARTDIR

Ich habe dies als Teil meines Playbooks ausgeführt (mit Tags isoliert ausgeführt) und Folgendes erhalten:

PLAY [Set this playbook to run locally] ****************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]

TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
    "checksum_before.stdout_lines": [
        "374fadc4df1578f78fd60b1be6758477c2c533fa  /tmp/wp-checksum", 
        "10d66f7bdbbdd3af531d1b11a3db3059a5868838  -"
    ]
}

TASK [jonblog : Install the WordPress HTTPS plugin] ***************
changed: [localhost]

TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]

TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
    "checksum_after.stdout_lines": [
        "374fadc4df1578f78fd60b1be6758477c2c533fa  /tmp/wp-checksum", 
        "719c9da94b525e723b1abe188ee9f5bbaf121f3f  -"
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=6    changed=3    unreachable=0    failed=0

Die Debug-Zeilen geben den Prüfsummen-Hash des Inhalts der Dateien wieder (dieser ist identisch) und dann den Prüfsummen-Hash von ls -Rl der Dateistruktur (dies hat sich geändert). Dies steht im Einklang mit meiner früheren manuellen Feststellung, dass sich Verzeichnisprüfsummen ändern.

Was kann ich also als Nächstes tun, um herauszufinden, warum Ordneränderungszeiten diesen Vorgang fälschlicherweise als geändert kennzeichnen?

Question 2

Anstatt jedes Mal alle Dateien zu überschreiben und einen Weg zu finden, das gleiche Änderungsdatum beizubehalten, möchten Sie vielleicht die verwenden creates Möglichkeit der unarchive Modul.

Wie Sie vielleicht bereits wissen, teilt dies Ansible mit, dass eine bestimmte Datei/ein bestimmter Ordner als Ergebnis der Aufgabe erstellt wird. Somit wird die Aufgabe beim nächsten Mal nicht erneut ausgeführt werden, wenn diese Datei/Ordner bereits vorhanden ist.

Sehen http://docs.ansible.com/ansible/unarchive_module.html#options

Question 3

Meine Lösung besteht darin, das Prüfsummenskript zu ändern und es zu einem dauerhaften Merkmal des Ansible-Prozesses zu machen. Es fühlt sich ein bisschen hackig an, meine eigene Prüfsumme zu erstellen, wenn Ansible es für mich tun sollte, aber es funktioniert.

Neue Antworten, die erklären, dass ich etwas falsch mache, oder dass eine neue Version von Ansible das Problem behebt, wären sehr willkommen.

Wenn ich einen Moment Zeit habe, werde ich dies als möglichen Fehler beim Ansible-Team melden. Allerdings wundere ich mich manchmal über das Aufwand-Ertrags-Verhältnis, wenn ich Fehler auf einem ausgelasteten Tracker melde – ich habe bereits einen ausstehenden Gegenstand, der schon eine Weile gewartet hat, und ich habe mich entschieden, auch das zu umgehen.

Update (18 Monate später)

Dieses Ansible-Build-System hat es nie ins Leben gerufen. Es fühlte sich an, als würde ich immer um etwas herum arbeiten. Als ich mich kürzlich entschied, meinen Blog auf einen anderen Server zu verschieben, habe ich ihn endlich angedockt. Das hat mehrere Wochen gedauert (da es bei einer echten WordPress-Installation überraschend viele Dinge zu beachten gibt), aber im Allgemeinen fand ich den Prozess viel schöner als die Verwendung von Orchestrierungstools.