Bereitstellungsrezepte

Wichtig

Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf AWS re:POST oder über den AWS Premium-Support.

Bereitstellungsrezepte werden dem Deploy-Lebenszyklusereignis des Layers zugewiesen. Es tritt normalerweise auf allen Instanzen des Stacks auf, wann immer Sie eine App bereitstellen. Sie können das Ereignis jedoch optional auf nur bestimmte Instanzen beschrä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 basierend auf Daten der JSON-Bereitstellung der Anwendung ein. 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. Das tomcat::deploy-Rezept legt die Variablen user, group und path basierend auf Daten aus der JSON-Bereitstellung fest. Sie werden an die directory-Ressource der Definition weitergegeben, die die Verzeichnisse verwaltet.

Anmerkung

Die Benutzer und die Gruppe Ihrer bereitgestellten Anwendung werden von den Attributen[:opsworks][:deploy_user][:user] und [:opsworks][:deploy_user][:group] bestimmt, die in der Attributdatei des integrierten Bereitstellungsrezeptbuchs deploy.rb definiert werden. Der Standardwert von [:opsworks][:deploy_user][:user] ist deploy. Der Standardwert von [:opsworks][:deploy_user][:group] hängt vom Betriebssystem der Instance ab:

• Für Ubuntu-Instances ist die Standardgruppe www-data.

• Für Amazon Linux-Instances, die Mitglieder einer Rails-App Server-Ebene sind, die Nginx und Unicorn verwendet, ist die Standardgruppe. nginx

• Für alle anderen Amazon Linux-Instances ist die Standardgruppe apache.

Sie können diese Einstellungen ändern, indem Sie mithilfe einer benutzerdefinierten JSON-Datei oder einer benutzerdefinierten Attributdatei das entsprechende Attribut überschreiben. Weitere Informationen finden Sie unter Überschreiben der Attribute.

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 Anwendungstyp verwenden. Bereitstellungsdetails wie die Verzeichnisnamen werden in der Konsole oder über die API festgelegt und in den deploy-Attributen gespeichert. Allerdings funktioniertopsworks_deploy nur für die vier unterstützten Repository-Typen: Git, Subversion, S3 und HTTP. 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. Die AWS OpsWorks Stacks-Bereitstellung ist jedoch so konzipiert, dass bis zu fünf Versionen einer App auf einer Instance beibehalten werden, sodass Sie bei Bedarf zu einer früheren Version zurückkehren können. AWS OpsWorks Stacks macht daher Folgendes:

1. Es stellt Apps in einem getrennten Verzeichnis bereit, dessen Name einen Zeitstempel enthält, wie z. B. /srv/www/my_1st_jsp/releases/20130731141527.

2. Es erstellt einen symlink mit dem Namen current, wie etwa /srv/www/my_1st_jsp/current, zu diesem eindeutigen Verzeichnis.

3. Wenn nicht bereits vorhanden, erstellt es einen symlink von dem Verzeichnis webapps zum in Schritt 2 erstellten symlink current.

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 AWS OpsWorks deploy::default Stacks-Rezept 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.

Anmerkung

Die execute-Ressource führt nichts wirklich Substantielles aus. /bin/true ist ein Dummy-Shell-Skript, das einfach einen Erfolgscode zurückgibt. Es wird hier als eine bequeme Möglichkeit verwendet, eine Neustartbenachrichtigung zu generieren. Wie bereits erwähnt wird durch die Verwendung von Benachrichtigungen sichergestellt, dass Services nicht zu häufig neu gestartet werden.

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