Bereitstellungsrezepte

Bereitstellungsrezepte werden dem Deploy-Lebenszyklusereignis des Layers zugewiesen. Es erfolgt in der Regel auf allen Instances des Stacks, wenn Sie eine Anwendung bereitstellen. Sie können jedoch das Ereignis optional nur auf bestimmte Instances einschränken. AWS OpsWorks Stacks führt die Deploy-Rezepte auch auf neuen Instanzen aus, nachdem die Setup-Rezepte abgeschlossen sind. Der Hauptzweck von Bereitstellungsrezepten besteht in der Bereitstellung von Code und zugehörigen Dateien aus einem Repository in den Instances des Anwendungsserver-Layers. Bereitstellungsrezepte werden jedoch auch oft auf anderen Layern ausgeführt. Auf diese Weise können Instances dieser Layer z. B. ihre Konfiguration aktualisieren, um die neu bereitgestellte Anwendung einzubinden. Wenn Sie ein Bereitstellungsrezept implementieren, beachten Sie, dass ein Deploy-Ereignis nicht notwendigerweise bedeutet, dass der Instance Anwendungen bereitgestellt werden. Es könnte auch einfach nur eine Benachrichtigung sein, dass Anwendungen in anderen Instances im Stack bereitgestellt werden, um zu ermöglichen, dass die Instance notwendige Updates durchführt. Das Rezept muss entsprechend reagieren können, was auch bedeuten kann, dass nichts durchgeführt wird.

AWS OpsWorks Stacks stellt Apps der Standard-App-Typen automatisch auf den entsprechenden integrierten Anwendungsserverschichten bereit. Zur Bereitstellung von Anwendungen in einem benutzerdefinierten Layer müssen Sie benutzerdefinierte Bereitstellungsrezepte implementieren, die die Dateien der Anwendung von einem Repository in den entsprechenden Speicherort in der Instance herunterladen. Sie können jedoch häufig die Menge des Codes begrenzen, den Sie schreiben müssen, indem Sie das integrierte Bereitstellungsrezeptbuch verwenden, um verschiedene Aspekte der Bereitstellung zu verarbeiten. Wenn Sie beispielsweise Ihre Dateien in einem der unterstützten Repositorys speichern, kann das integrierte Rezeptbuch die Details des Herunterladens von Dateien aus dem Repository in die Instances des Layers verarbeiten.

Das tomcat::deploy-Rezept ist dafür konzipiert, dem Deploy-Lebenszyklusereignis zugewiesen zu werden.

include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...

Das tomcat::deploy-Rezept verwendet das integrierte Bereitstellungsrezeptbuch für Aspekte der Bereitstellung, die nicht anwendungsspezifisch sind. Das deploy-Rezept (die Kurzbezeichnung für das integrierte deploy::default-Rezept) ist ein integriertes Rezept, das die Details der Einrichtung der Benutzer, Gruppen usw. verarbeitet, basierend auf Daten aus den deploy-Attributen.

Das Rezept verwendet zwei integrierte Chef-Definitionen, opsworks_deploy_dir und opworks_deploy, zum Installieren der Anwendung.

Die opsworks_deploy_dir Definition richtet die Verzeichnisstruktur auf der Grundlage von Daten aus der Bereitstellung der App ein. JSON Definitionen sind grundsätzlich eine bequeme Möglichkeit, Ressourcendefinitionen zu verpacken, und befinden sich im Verzeichnis definitions eines Rezeptbuchs. Rezepte können Definitionen ähnlich wie Ressourcen verwenden, aber der Definition selbst ist kein Anbieter zugeordnet, sondern nur die Ressourcen, die in der Definition enthalten sind. Sie können Variablen im Rezept definieren, die an die zugrunde liegenden Ressourcendefinitionen weitergegeben werden. Die tomcat::deploy Rezeptsätze user und path Variablen basieren auf Daten aus der BereitstellungJSON. group Sie werden an die directory-Ressource der Definition weitergegeben, die die Verzeichnisse verwaltet.

Die andere Definition, opsworks_deploy, verarbeitet die Details der Überprüfung des Codes der App und der zugehörigen Dateien aus dem Repository und der Bereitstellung in der Instance, basierend auf Daten aus den deploy-Attributen. Sie können diese Definition für jeden App-Typ verwenden. Bereitstellungsdetails wie die Verzeichnisnamen werden in der Konsole oder über die deploy Attribute angegeben API und eingegeben. opsworks_deployFunktioniert jedoch nur für die vier unterstützten Repository-Typen: Git, Subversion, S3 undHTTP. Sie müssen diesen Code selbst implementieren, wenn Sie einen anderen Repository-Typ verwenden möchten.

Sie installieren die Dateien einer App im Tomcat-Verzeichnis webapps. Eine typische Methode ist es, Dateien direkt nach webapps zu kopieren. Allerdings AWS OpsWorks Die Stacks-Bereitstellung ist so konzipiert, dass bis zu fünf Versionen einer App auf einer Instanz gespeichert werden, sodass Sie bei Bedarf zu einer früheren Version zurückkehren können. AWS OpsWorks Stacks macht daher Folgendes:

Wenn Sie eine frühere Version wiederherstellen müssen, modifizieren Sie den symlink current so, dass er auf ein bestimmtes Verzeichnis mit dem entsprechenden Zeitstempel zeigt, etwa indem Sie das Linkziel /srv/www/my_1st_jsp/current abändern.

Im mittleren Bereich von tomcat::deploy wird der symlink eingerichtet.

  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...

Das Rezept erstellt zunächst zwei Variablen, current_dir und webapp_dir, um jeweils die Verzeichnisse current und webapp darzustellen. Dann wird eine link-Ressource verwendet, um webapp_dir mit current_dir zu verknüpfen. Das Tool AWS OpsWorks deploy::defaultDas Rezept von Stacks erstellt einige Stub-Verzeichnisse, die für dieses Beispiel nicht erforderlich sind, sodass sie im mittleren Teil des Auszugs entfernt werden.

Der letzte Teil von tomcat::deploy startet den Tomcat-Service bei Bedarf neu.

  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'

Das erste Rezept führt zuerst tomcat::service aus, um sicherzustellen, dass der Service für diese Chef-Ausführung definiert ist. Dann wird eine execute-Ressource verwendet, um den Service anzuweisen, neu zu starten, aber nur, wenn ['tomcat']['auto_deploy'] festgelegt ist auf 'true'. Andernfalls überwacht Tomcat Änderungen in seinem Verzeichnis webapps, was einen expliziten Neustart des Tomcat-Services überflüssig macht.

Schließlich wird tomcat::deploy von tomcat::context ausgeführt, wodurch die Webanwendungs-Kontextkonfigurationsdatei aktualisiert wird, wenn Sie die Backend-Datenbank geändert haben.