Ich verwende GlassFish, um eine Java EE-Webanwendung zu erstellen. Die Dinge funktionieren gut auf meiner lokalen Dev-Maschine. Ich habe
Ich versuche, dieselbe App auf der von AWS Elastic Beanstalk gehosteten Glassfish-Instanz bereitzustellen. AWS-EB verwendet Docker zum Bereitstellen der Glassfish-Instanz. Ich kann nur den dritten Schritt oben (Bereitstellen einer Web-App) tun, und bin völlig ratlos, wie man die ersten beiden macht.
Was ich gerne tun würde, ist über die Web-Zugriffe auf die Glassfish Admin-Konsole, aber das scheint auf keiner Ebene zu funktionieren. Eine Alternative wäre, den Glasfisch "asadmin" auf meiner lokalen Maschine zu verwenden, um die entfernten Glasfische zu konfigurieren, aber das kann ich auch nicht machen.
Wie konfiguriert man eine Glassfish-Instanz, die auf AWS EB gehostet wird? Ist es überhaupt möglich?
Ich habe einige Beobachtungen gemacht, aber ich würde mich über eine Bestätigung oder auf andere Weise freuen:
Vielleicht muss ich der EC2-Instanz mitteilen, dass sie von localhost zu 1.2.3.4 weiterleitet, aber wie kann ich das erreichen, wenn der EB Load Balancer es skaliert?
Jeder Rat würde sehr geschätzt werden.
Was folgt, ist etwas, das für mich funktioniert - aber ich habe das Gefühl, dass mir etwas fehlt. Alle Bearbeitungen / Kommentare wären sehr willkommen.
Es gibt verschiedene Hooks in der EB / Docker-Implementierung, mit denen die Ausführung von Post-Deployment-Hooks in einer Glassfish-Instanz innerhalb eines Docker-Containers innerhalb einer EB-Instanz ausgeführt werden kann. Ich habe Post-Deployment-Hooks verwendet, um einen Verbindungspool einzurichten. So sieht die endgültige Installation aus, nur als Referenz:
%Vor%Das insgesamt gewünschte Ergebnis besteht darin, dass nach der Bereitstellung der App in der Docker-Instanz die Befehle asadmin ausgeführt werden, um einen JDBC-Verbindungspool zu erstellen und diesen Verbindungspool zu einer jdbc-Ressource zu machen . Auf meinem lokalen Rechner wären die Befehle
%Vor%Dabei ist "jdbc / dev" der Name, den der Java-Code wissen muss, um eine Verbindung in der üblichen Weise zu erhalten, d. h.
%Vor%Wir möchten, dass die Befehle in der Docker-Instanz ausgeführt werden, da die Docker-Instanz Zugriff auf die Umgebungsvariablen hat, die Sie in der AWS-Verwaltungskonsole deklarieren, sodass ich Konfigurationsinformationen ohne sie in meinen Build-Skripten übergeben kann.
>Um dieses Ergebnis zu erreichen, benötigen wir während der Installation eine Datei in der EC2-Instanz, in meinem Fall /opt/elasticbeanstalk/hooks/appdeploy/post/99_configure_jdbc.sh . Diese Datei wird nach der Bereitstellung als Root in der EC2-Instanz ausgeführt. Ich werde es als ec2-post-deploy-hook bezeichnen.
Wir werden diese Datei mit einer .exextensions / .config-Datei erstellen, wie hier dokumentiert
Meine .config Datei hat folgenden Inhalt:
%Vor%Alles nach dem Inhalt: | endet im ec2-post-deploy-hook .
Ich habe diese Idee von Ссылка gelernt.
Nur die letzte Zeile und die viertletzte Zeile werden benötigt, aber die anderen Zeilen sind für das Debuggen nützlich. Die Ausgabe endet in / tmp / post auf der EC2-Instanz.
Der einzige Trick in dieser Datei ist, dass wir die ID des Andock-Containers immer mit
erhalten können %Vor%, da nach der Bereitstellung nur ein Docker-Container ausgeführt wird und der Name "neustes" hat.
Die letzte Zeile des ec2-post-deploy-Hooks verwendet das Andockfenster, um in der Docker-Instanz diejenigen Befehle auszuführen, die ich ursprünglich ausführen wollte - das sind die asadmin-Befehle. Ich stelle eine Datei namens setup_pool.sh in meiner WAR-Datei bereit, sodass sie während der Bereitstellung an einem bekannten Speicherort landet. Mein setup_pool.sh sieht so aus (und ich nenne es einen docker-post-deploy-hook ):
%Vor%Diese Datei wird in der Docker-Instanz ausgeführt. Die beiden asadmin -Befehle sind das Fleisch, aber auch hier gibt es Debugging in / tmp / setup_connections innerhalb der Docker-Instanz
Passwörter usw. werden von der AWS-Umgebung erhalten.
Das einzige, was ich zu diesem Zeitpunkt nicht tun kann, ist, dass die AWS-Umgebungsvariablen bei der ersten Bereitstellung verfügbar sind. Ich habe keine Ahnung warum, aber ich kann sie nur einstellen, nachdem die Instanz läuft. Das bedeutet, dass ich zweimal bereitstellen muss, eine Dummy-Bereitstellung, gefolgt von einer Bearbeitung der Umgebung, gefolgt von einer tatsächlichen Bereitstellung.
Also, zusammenfassend,
Und alles funktioniert. Es ist irgendwie hässlich zu sehen, aber, weißt du, ich auch.
Nachdem ich mich einige Zeit mit diesem Problem herumgeschlagen habe, denke ich, dass ich endlich eine akzeptable Problemumgehung (zumindest für mich) gefunden habe: -
Erstellen Sie DockerFile und packen Sie es direkt in den WAR (auf der höchsten Ebene, nicht in einem Ordner). DockerFile -
%Vor%Jetzt, wenn diese WAR bereitgestellt wird (ich verwende 'eb deploy'). Diese DockerFile wird ausgeführt.
Im obigen einfachen Beispiel wird zuerst der mysql jdbc-Treiber heruntergeladen und in das lib-Verzeichnis von glassfish gesetzt. Als nächstes habe ich domain.xml verpackt (alle Ressourcen, usw. bereits eingerichtet) innerhalb der WAR selbst, wird in den Domain-Konfigurationsordner von Glassfish verschoben, um geladen zu werden, wenn Glassfish gestartet wird.
Tags und Links amazon-web-services docker glassfish