ansistrano.deploy

Ansistrano

ansistrano.deploy und ansistrano.rollback sind Ansible-Rollen, die den Bereitstellungsprozess für Skriptanwendungen wie PHP, Python und Ruby einfach verwalten. Es handelt sich um einen Ansible-Port für Capistrano.

Ansistrano

Geschichte

Capistrano ist ein Automatisierungstool für Remote-Server und ist derzeit in Version 3. Die ursprüngliche Version 2.0 wurde zur Bereitstellung von RoR-Anwendungen entwickelt. Mit zusätzlichen Plugins konnte man auch andere Anwendungen wie PHP und Python bereitstellen, mit verschiedenen Bereitstellungsstrategien und -phasen. Ich habe Capistrano v2 geliebt und viel damit gearbeitet; ich habe sogar ein Plugin dafür entwickelt.

Capistrano 2 war ein großartiges Tool und funktioniert immer noch gut. Allerdings wird es nicht mehr gewartet, da das ursprüngliche Team an v3 arbeitet. Diese neue Version hat nicht die gleichen Funktionen, ist also weniger leistungsfähig und flexibel. Außerdem werden andere neue Tools wie Ansible immer einfacher zu nutzen, um Anwendungen bereitzustellen.

Deshalb habe ich beschlossen, die Nutzung von Capistrano einzustellen, weil v2 nicht mehr gewartet wird, v3 nicht genügend Funktionen hat und ich alles, was Capistrano tat, auch mit Ansible erledigen kann. Wenn Sie nach Alternativen suchen, schauen Sie sich Fabric oder Chef Solo an.

Projektname

Ansistrano setzt sich zusammen aus Ansible + Capistrano, einfach, oder?

Statistiken zur anonymen Nutzung von Ansistrano

Es gibt einen optionalen Schritt in Ansistrano, der eine HTTP-Anfrage an unsere Server sendet. Leider sind die Metriken, die wir von Ansible Galaxy erhalten können, begrenzt, sodass dies einer der wenigen Wege ist, um zu messen, wie viele aktive Benutzer wir tatsächlich haben.

Wir verwenden diese Daten nur für Nutzungsstatistiken, aber wenn Sie sich dabei unwohl fühlen, können Sie diesen zusätzlichen Schritt deaktivieren, indem Sie in Ihren Playbooks ansistrano_allow_anonymous_stats auf false setzen.

Wer verwendet Ansistrano?

Ist Ansistrano bereit für den Einsatz? Hier sind einige Unternehmen, die es derzeit verwenden:

Wenn Sie es auch benutzen, lassen Sie es uns bitte wissen, indem Sie einen PR zu diesem Dokument senden.

Anforderungen

Um Ihre Apps mit Ansistrano bereitzustellen, benötigen Sie:

Ansible auf Ihrer Bereitstellungseinheit
rsync auf der Zielmaschine, wenn Sie entweder die rsync, rsync_direct oder git Bereitstellungsstrategie verwenden oder wenn Sie ansistrano_current_via = rsync verwenden.

Installation

Ansistrano ist eine Ansible-Rolle, die global über Ansible Galaxy verteilt wird. Um die Ansistrano-Rolle zu installieren, können Sie folgenden Befehl verwenden.

$ ansible-galaxy install ansistrano.deploy ansistrano.rollback

Aktualisierung

Wenn Sie die Rolle aktualisieren möchten, müssen Sie das --force-Argument beim Installieren übergeben. Bitte überprüfen Sie den folgenden Befehl:

$ ansible-galaxy install --force ansistrano.deploy ansistrano.rollback

Funktionen

Rollback in Sekunden (mit der Rolle ansistrano.rollback)
Ihre Bereitstellung mit Hooks vor und nach kritischen Schritten anpassen
Speicherplatz sparen, indem Sie eine maximale Anzahl an Versionen auf Ihren Hosts beibehalten
Wählen Sie zwischen SCP, RSYNC, GIT, SVN, HG, HTTP Download oder S3 GET Bereitstellungsstrategien (optionaler Auspackschritt enthalten)

Hauptarbeitsablauf

Ansistrano bringt Anwendungen gemäß dem Capistrano-Ablauf zur Bereitstellung.

Einrichtungsphase: Erstellt die Ordnerstruktur für Ihre Versionen
Codeaktualisierungsphase: Stellt die neue Version auf Ihre Hosts
Symlink-Phase: Nach der Bereitstellung der neuen Version auf Ihren Hosts ändert dieser Schritt den softlink current auf die neue Version
Bereinigungsphase: Entfernt alte Versionen gemäß dem Parameter ansistrano_keep_releases (siehe "Rollenvariablen")

Ansistrano Flow

Rollenvariablen

vars:
  ansistrano_deploy_from: "{{ playbook_dir }}/" # Wo sich mein lokales Projekt befindet (relativer oder absoluter Pfad)
  ansistrano_deploy_to: "/var/www/my-app" # Basispfad zur Bereitstellung.
  ansistrano_version_dir: "releases" # Name des Versionsordners
  ansistrano_shared_dir: "shared" # Name des gemeinsamen Ordners
  ansistrano_current_dir: "current" # Name des Softlinks. Sollten selten geändert werden.
  ansistrano_current_via: "symlink" # Bereitstellungsstrategie, bei der der Code in den aktuellen Pfad bereitgestellt wird. Optionen sind symlink oder rsync
  ansistrano_keep_releases: 0 # Anzahl der Versionen, die nach einer neuen Bereitstellung beibehalten werden sollen. Siehe "Alte Versionen entfernen".

  # Arrays von Verzeichnissen und Dateien, die gemeinsam genutzt werden sollen.
  # Die folgenden Arrays von Verzeichnissen und Dateien werden nach dem Schritt 'update-code' und dessen Rückrufen mit dem aktuellen Veröffentlichungsverzeichnis verlinkt
  # Hinweise:
  # * Pfade sind relativ zum gemeinsamen Verzeichnis (keine führenden /)
  # * Wenn Ihre Elemente sich in einem Unterverzeichnis befinden, schreiben Sie den gesamten Pfad zu jedem gemeinsam genutzten Verzeichnis
  #
  # Beispiel:
  # ansistrano_shared_paths:
  #   - path/to/first-dir
  #   - path/next-dir
  # ansistrano_shared_files:
  #   - my-file.txt
  #   - path/to/file.txt
  ansistrano_shared_paths: []
  ansistrano_shared_files: []

  # Erstellung der gemeinsamen Pfade und gemeinsamen Dateien.
  # Standardmäßig werden die Verzeichnisse für gemeinsame Pfade und Basisverzeichnisse für gemeinsame Dateien automatisch erstellt, wenn sie nicht vorhanden sind. In einigen Szenarien könnten diese Pfade jedoch Symlinks zu anderen Verzeichnissen im Dateisystem sein, und der Bereitstellungsprozess würde fehlschlagen. Mit diesen Variablen können Sie die betroffenen Aufgaben deaktivieren. Wenn Sie zwei oder drei gemeinsame Pfade haben und nur für einige von ihnen keine Erstellung benötigen, können Sie immer die automatische Erstellung deaktivieren und eine benutzerdefinierte Aufgabe in einem Hook hinzufügen.
  ansistrano_ensure_shared_paths_exist: yes
  ansistrano_ensure_basedirs_shared_files_exist: yes
  
  # Bereitstellungsstrategie - Methode, die zur Auslieferung des Codes verwendet wird. Optionen sind copy, download, git, rsync, rsync_direct, svn oder s3. 
  ansistrano_deploy_via: rsync 
  # Copy, download und s3 haben einen optionalen Schritt zum Auspacken der heruntergeladenen Datei, den Sie durch Hinzufügen von _unarchive verwenden können. 
  # Bei der rsync_direct-Strategie entfällt eine Dateiübertragung auf das Ziel, was zu einem leichten Geschwindigkeitsvorteil führt, wenn Sie an gemeinsame Hosts bereitstellen.
  # Sie können alle Optionen im Verzeichnis tasks/update-code einsehen!
  
  ansistrano_allow_anonymous_stats: yes

  # Variablen für die rsync/rsync_direct Bereitstellungsstrategie
  ansistrano_rsync_extra_params: "" # Zusätzliche Parameter zur Verwendung bei der Bereitstellung mit rsync als einzelner String. Obwohl Ansible ein Array erlaubt, kann dies Probleme verursachen, wenn wir versuchen, mehrere --include-Argumente hinzuzufügen.
  ansistrano_rsync_set_remote_user: yes # Siehe [Ansible Synchronize-Modul](http://docs.ansible.com/ansible/synchronize_module.html). Optionen sind ja, nein.
  ansistrano_rsync_path: "" # Siehe [Ansible Synchronize-Modul](http://docs.ansible.com/ansible/synchronize_module.html). Standardmäßig ist es "sudo rsync", kann jedoch überschrieben werden (Beispiel): "sudo -u user rsync".
  ansistrano_rsync_use_ssh_args: no # Siehe [Ansible Synchronize-Modul](http://docs.ansible.com/ansible/synchronize_module.html). Wenn auf ja gesetzt, verwenden Sie die in ansible.cfg angegebenen ssh_args.

  # Variablen für die Git-Bereitstellungsstrategie
  ansistrano_git_repo: [email protected]:USERNAME/REPO.git # Standort des Git-Repository
  ansistrano_git_branch: master # Welche Version des Repository ausgecheckt werden soll. Dies kann der vollständige 40-Zeichen SHA-1-Hash, der literale String HEAD, ein Branch-Name oder ein Tag-Name sein.
  ansistrano_git_repo_tree: "" # Wenn angegeben, der Teilbaum des Repository, der bereitgestellt werden soll.
  ansistrano_git_identity_key_path: "" # Wenn angegeben, wird diese Datei kopiert und als Identitätsschlüssel für die Git-Befehle verwendet, der Pfad ist relativ zum Playbook, in dem es verwendet wird.
  ansistrano_git_identity_key_remote_path: "" # Wenn angegeben, wird diese Datei auf dem Remote-Server als Identitätsschlüssel für die Git-Befehle verwendet, der Pfad ist absolut.
  ansistrano_git_identity_key_shred: true # Identitätsschlüssel wird standardmäßig geschreddert, kann aber auf falsch gesetzt werden, wenn Sie auf das folgende Problem stoßen (https://github.com/ansistrano/deploy/issues/357).
  # Optionale Variablen, standardmäßig weggelassen
  ansistrano_git_refspec: ADDITIONAL_GIT_REFSPEC # Zusätzliches refspec, das vom 'git'-Modul verwendet wird. Verwendet dieselbe Syntax wie der Befehl 'git fetch'.
  ansistrano_git_ssh_opts: "-o StrictHostKeyChecking=no" # Zusätzliche ssh-Optionen, die in Git verwendet werden
  ansistrano_git_depth: 1 # Zusätzliche Historie, die auf die angegebene Anzahl von Revisionen gekürzt wird.
  ansistrano_git_executable: /opt/local/bin/git # Pfad zur verwendenden git ausführbaren Datei. Wenn nicht angegeben, wird der normale Mechanismus zur Auflösung von Binärpfaden verwendet.

  # Variablen für die SVN-Bereitstellungsstrategie
  # Bitte beachten Sie, dass es einen Fehler im Subversionsmodul in der Ansible 1.8.x-Serie gab (https://github.com/ansible/ansible-modules-core/issues/370), sodass es nur ab Ansible 1.9 unterstützt wird.
  ansistrano_svn_repo: https://svn.company.com/project # Standort des SVN-Repository
  ansistrano_svn_branch: trunk # Welcher Branch des Repository ausgecheckt werden soll.
  ansistrano_svn_revision: HEAD # Welche Revision des Repository ausgecheckt werden soll.
  ansistrano_svn_username: user # SVN-Authentifizierungsbenutzername
  ansistrano_svn_password: Pa$$word # SVN-Authentifizierungs-Passwort
  ansistrano_svn_environment: {} # Dict mit Umgebungsvariablen für SVN-Aufgaben (https://docs.ansible.com/ansible/playbooks_environment.html)

  # Variablen für die HG-Bereitstellungsstrategie
  ansistrano_hg_repo: https://[email protected]/USERNAME/REPO # Standort des HG-Repository
  ansistrano_hg_branch: default # Jede Branch-ID, die mit hg -r funktioniert, also benannter Branch, Lesezeichen, Kommithaft usw.

  # Variablen für die Download-Bereitstellungsstrategie
  ansistrano_get_url: https://github.com/someproject/somearchive.tar.gz
  ansistrano_download_force_basic_auth: false # keine Standardeinstellung, da dies erst ab Ansible 2.0 unterstützt wird
  ansistrano_download_headers: "" # keine Standardeinstellung, da dies erst ab Ansible 2.0 unterstützt wird

  # Variablen für die S3-Bereitstellungsstrategie
  ansistrano_s3_bucket: s3bucket
  ansistrano_s3_object: s3object.tgz # Fügen Sie dem ansistrano_deploy_via den _unarchive-Suffix hinzu, wenn Ihr Objekt ein Paket ist (z.B.: s3_unarchive)
  ansistrano_s3_region: eu-west-1
  ansistrano_s3_rgw: false # muss Ansible >= 2.2 sein; verwenden Sie Ceph RGW für S3-kompatible Cloud-Anbieter
  ansistrano_s3_url: http://rgw.example.com # Wenn Ceph RGW verwendet wird, setzen Sie die URL.
  # Optionale Variablen, standardmäßig weggelassen
  ansistrano_s3_aws_access_key: IHRE_AWS_ZUGRIFFSSCHLÜSSEL
  ansistrano_s3_aws_secret_key: IHRE_AWS_SECRET_KEY
  ansistrano_s3_ignore_nonexistent_bucket: false
  
  # Variablen für die GCS-Bereitstellungsstrategie
  ansistrano_gcs_bucket: gcsbucket
  ansistrano_gcs_object: gcsobject.tgz # Fügen Sie dem ansistrano_deploy_via den _unarchive-Suffix hinzu, wenn Ihr Objekt ein Paket ist (z.B.: s3_unarchive)
  ansistrano_gcs_region: eu-west-1 # https://cloud.google.com/storage/docs/bucket-locations
  # Optionale Variablen, standardmäßig weggelassen
  ansistrano_gcs_access_key: IHRE_GCS_ZUGRIFFSSCHLÜSSEL # gehen Sie zu Cloud Console > Storage > Einstellungen > Interoperabilität
  ansistrano_gcs_secret_key: IHRE_GCS_SECRET_KEY

  # Hooks: Benutzerdefinierte Aufgaben, wenn Sie sie benötigen
  ansistrano_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-setup-tasks.yml"
  ansistrano_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-setup-tasks.yml"
  ansistrano_before_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-update-code-tasks.yml"
  ansistrano_after_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-update-code-tasks.yml"
  ansistrano_before_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-shared-tasks.yml"
  ansistrano_after_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-shared-tasks.yml"
  ansistrano_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-tasks.yml"
  ansistrano_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-tasks.yml"
  ansistrano_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-cleanup-tasks.yml"
  ansistrano_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-cleanup-tasks.yml"

{{ playbook_dir }} ist eine Ansible-Variable, die den Pfad zum aktuellen Playbook enthält.

Bereitstellung

Um mit Ansistrano bereitzustellen, müssen Sie einige Schritte ausführen:

Erstellen Sie eine neue hosts-Datei. Überprüfen Sie die Ansible-Inventardokumentation, wenn Sie Hilfe benötigen. Diese Datei identifiziert alle Hosts, auf die bereitgestellt werden soll. Für mehrstufige Umgebungen siehe Mehrstufige Umgebungen.
Erstellen Sie ein neues Playbook zur Bereitstellung Ihrer App, z. B. deploy.yml.
Richten Sie die Rollenvariablen ein (siehe Rollenvariablen).
Fügen Sie die Rolle ansistrano.deploy als Teil eines Plays hinzu.
Führen Sie das Bereitstellungs-Playbook aus.

ansible-playbook -i hosts deploy.yml

Wenn alles korrekt eingerichtet ist, erstellt dieser Befehl die folgende ungefähre Verzeichnisstruktur auf Ihrem Server. Überprüfen Sie, wie die Ordnerstruktur der Hosts nach einer, zwei und drei Bereitstellungen aussehen würde.

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100509145325
|-- releases
|   |-- 20100509145325
|-- shared

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100509150741
|-- releases
|   |-- 20100509150741
|   |-- 20100509145325
|-- shared

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100512131539
|-- releases
|   |-- 20100512131539
|   |-- 20100509150741
|   |-- 20100509145325
|-- shared

Serielle Bereitstellungen

Um unterschiedliche Zeitstempel zu verhindern, wenn die Bereitstellung auf mehreren Servern unter Verwendung der serial Option erfolgt, sollten Sie die Variable ansistrano_release_version festlegen.

ansible-playbook -i hosts -e "ansistrano_release_version=`date -u +%Y%m%d%H%M%SZ`" deploy.yml

Rückgängigmachen

Um mit Ansistrano zurückzugehen, müssen Sie die Bereitstellung einrichten und das Rollback-Playbook ausführen.

ansible-playbook -i hosts rollback.yml

Wenn Sie versuchen, mit null oder einer bereitgestellten Version zurückzugehen, wird ein Fehler ausgegeben und keine Aktionen werden durchgeführt.

Die Variablen, die Sie in der Rollback-Rolle anpassen können, sind weniger als in der Bereitstellungsrolle:

vars:
  ansistrano_deploy_to: "/var/www/my-app" # Basispfad zur Bereitstellung.
  ansistrano_version_dir: "releases" # Name des Versionsordners
  ansistrano_current_dir: "current" # Name des Softlinks. Sollten selten geändert werden.
  ansistrano_rollback_to_release: "" # Wenn angegeben, wird die Anwendung auf diese Version zurückgesetzt; vorherige Version sonst.
  ansistrano_remove_rolled_back: yes # Sie können diese Einstellung ändern, um die zurückgesetzte Version auf dem Server für spätere Inspektionen zu behalten.
  ansistrano_allow_anonymous_stats: yes

  # Hooks: Benutzerdefinierte Aufgaben, wenn Sie sie benötigen
  ansistrano_rollback_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-setup-tasks.yml"
  ansistrano_rollback_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-setup-tasks.yml"
  ansistrano_rollback_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-symlink-tasks.yml"
  ansistrano_rollback_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-symlink-tasks.yml"
  ansistrano_rollback_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-cleanup-tasks.yml"
  ansistrano_rollback_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-cleanup-tasks.yml"

Mehrstufige Umgebung (devel, preprod, prod usw.)

Wenn Sie in verschiedene Umgebungen wie devel, preprod und prod bereitstellen möchten, wird empfohlen, verschiedene Hosts-Dateien zu erstellen. Wenn dies erledigt ist, können Sie beim Ausführen des Bereitstellungs-Playbooks eine andere Host-Datei mit dem -i-Parameter angeben. In jeder Host-Datei können Sie verschiedene Benutzer, Passwörter, Verbindungsparameter usw. angeben.

ansible-playbook -i hosts_devel deploy.yml

ansible-playbook -i hosts_preprod deploy.yml

ansible-playbook -i hosts_prod deploy.yml

Hooks: Benutzerdefinierte Aufgaben

Sie müssen normalerweise Ihren Webserver nach dem Schritt Symlink neu laden oder Ihre Abhängigkeiten vor Code update herunterladen oder sogar dies in der Produktion vor dem Symlink tun. Um Ihre benutzerdefinierten Aufgaben auszuführen, haben Sie einige Hooks, die Ansistrano vor und nach jedem der drei Hauptschritte ausführt. Dies ist der Hauptvorteil gegenüber anderen ähnlichen Bereitstellungsrollen.

-- /meine-lokale-maschine/meine-app.com
|-- hosts
|-- deploy.yml
|-- meine-b Benutzerdefinierte-Aufgaben
|   |-- before-code-update.yml
|   |-- after-code-update.yml
|   |-- before-symlink.yml
|   |-- after-symlink.yml
|   |-- before-cleanup.yml
|   |-- after-cleanup.yml

Zum Beispiel, um Apache nach dem Schritt Symlink neu zu starten, fügen wir in die after-symlink.yml folgendes hinzu:

- name: Apache neu starten
  service: name=httpd state=reloaded

Q: Wo würden Sie eine E-Mail-Benachrichtigung nach einer Bereitstellung hinzufügen?
Q: (für PHP und Symfony-Entwickler) Wo würden Sie den Cache leeren?

Sie können für vor und nach jedem Schritt eine benutzerdefinierte Aufgaben-Datei mit ansistrano_before_*_tasks_file und ansistrano_after_*_tasks_file Rollenvariablen angeben. Weitere Informationen finden Sie unter "Rollenvariablen".

Variablen in benutzerdefinierten Aufgaben

Wenn Sie Ihre benutzerdefinierten Aufgabedateien schreiben, benötigen Sie möglicherweise einige Variablen, die Ansistrano Ihnen zur Verfügung stellt:

{{ ansistrano_release_path.stdout }}: Pfad zur aktuellen Bereitstellungsversion (vermutlich die, die Sie am häufigsten verwenden werden).
{{ ansistrano_releases_path }}: Pfad zum Releases-Ordner.
{{ ansistrano_shared_path }}: Pfad zum gemeinsamen Ordner (wo gemeinsam genutzte Assets gespeichert werden können).
{{ ansistrano_release_version }}: Relativer Verzeichnisname für die Version (standardmäßig entspricht dies dem aktuellen Zeitstempel in UTC).

Alte Versionen entfernen

In kontinuierlichen Bereitstellungsumgebungen haben Sie möglicherweise viele Versionen in der Produktion. Vielleicht haben Sie viel Speicherplatz und stört es Sie nicht, aber es ist gängige Praxis, nur eine benutzerdefinierte Anzahl an Versionen beizubehalten.

Nach der Bereitstellung, wenn Sie alte Versionen entfernen möchten, setzen Sie einfach die variable ansistrano_keep_releases auf die Gesamtanzahl der Versionen, die Sie beibehalten möchten.

Lassen Sie uns drei Bereitstellungen mit einer Konfiguration ansistrano_keep_releases: 2 ansehen:

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100509145325
|-- releases
|   |-- 20100509145325
|-- shared

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100509150741
|-- releases
|   |-- 20100509150741
|   |-- 20100509145325
|-- shared

-- /var/www/my-app.com
|-- current -> /var/www/my-app.com/releases/20100512131539
|-- releases
|   |-- 20100512131539
|   |-- 20100509150741
|-- shared

Sie können sehen, wie die Version 20100509145325 entfernt wurde.

Beispiel-Playbook

Im Ordner example finden Sie ein Beispielprojekt, das zeigt, wie man eine kleine Anwendung mit Ansistrano bereitstellt.

Um es auszuführen, benötigen Sie Vagrant und die installierten ansistrano-Rollen. Weitere Informationen zu Vagrant finden Sie auf https://www.vagrantup.com.

$ cd example/my-playbook
$ vagrant up
$ ansible-playbook -i hosts deploy.yml

Und nachdem Sie diese Befehle ausgeführt haben, wird die index.html im my-app-Ordner auf beiden Vagrant-Boxen bereitgestellt.

Um das Rollback-Playbook zu testen, müssen Sie deploy.yml mindestens zweimal ausführen (damit es etwas gibt, auf das zurückgegriffen werden kann). Und wenn das erledigt ist, müssen Sie nur noch ausführen:

$ ansible-playbook -i hosts rollback.yml

Sie können fortgeschrittenere Beispiele im Testordner einsehen, die gegen Travis-CI ausgeführt werden.

Beispiellösungen

Wir haben Ansistrano für andere Projekte, an denen wir arbeiten, unterstützt.

LastWishes: Domain-Driven Design PHP Beispiel-App: https://github.com/dddinphp/last-wishes

Hier ist zum Beispiel das Ausführungsprotokoll der LastWishes-Bereitstellung:

PLAY [Bereitstellung der letzten Wünsche-App auf meinem Server] ************************************

FAKTEN SAMMELN ***************************************************************
ok: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Sicherstellen, dass der Basis-Bereitstellungsordner existiert] ***
ok: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Sicherstellen, dass der Releases-Ordner existiert] ***
ok: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Sicherstellen, dass der gemeinsame Elementeordner existiert] ***
ok: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Freigabe-Zeitstempel abrufen] ***********
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Freigabe-Pfad abrufen] ****************
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Freigabe-Pfad abrufen] ***************
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Anwendung dateien zur Remote shared Copy (im rsync-Fall) kopieren] ***
changed: [quepimquepam.com -> 127.0.0.1]

AUFGABE: [ansistrano.deploy | Bereitstellung des vorhandenen Codes auf Servern] ***
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Bereitstellung des vorhandenen Codes auf Remote-Servern] ***
skipping: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Remote-Repository aktualisieren] ********
skipping: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Erstellen Sie eine Kopie des Repository] *******
skipping: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Bereitstellung des Codes auf Servern] *****
skipping: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Kopieren Sie die Versionsnummer in die REVISION-Datei] ***
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Berührt den Release-Code] *****
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Wechselt den Softlink zur neuen Version] ***
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Apache neu laden] *******************
changed: [quepimquepam.com]

AUFGABE: [ansistrano.deploy | Bereinigen von Versionen] ***************
skipping: [quepimquepam.com]

PLAY-ZUSAMMENFASSUNG ********************************************************************
quepimquepam.com           : ok=14   changed=10   unreachable=0    failed=0