Der einfachste Weg einen Shopware Shop zuinstallieren war immer, die ZIP-Datei mit dem Webinstaller downzuloaden und diese in das gewünschte Verzeichnis zu entpacken. Dann die URL aufrufen und dem Installer folgen. Das ist für automatische Deployments nicht so toll und oft wurde dort einfach die Git-Version verwendet. Die hat den extremen Nachteil, dass diese unglaublich viele Dinge mitbringt, die in einer produktiven Umgebung nichts zu suchen haben. Buildscripte, Tests, etc bringen einen wirklich nur in der Dev-Umgebung was und sollten in der produktiven Umgebung nicht mit rumliegen, weil je mehr rumliegt, desto mehr Sicherheitslücken oder ungewollte Probleme könnten mitkommen.
Seit einiger Zeit kann man Shopware aber auch sehr einfach über den Composer installieren. Dabei wird eine eher moderne Verzeichnisstruktur angelegt und auch die Basis-Konfiguration kann einfach über Env-Variablen gesetzt werden, so dass ein automatisches Deployment für einen Server damit sehr einfach wird. Im Idealfall hat man die Datenbank schon sauber und fertig vorliegen. Dann erspart man sich fast den gesamten Installationsprozess und kann direkt loslegen.
Wenn man den Composer noch nicht installiert hat, muss man diesen kurz installieren:
<Directory /var/www/your_webshop>
AllowOverride All
Require all granted
</Directory>
RewriteEngine On
</Virtualhost>
Reload des Apache und schon kann es an sich losgehen. Wenn man sehen möchte wie die DATABASE_URL verarbeitet wird, kann man einen Blick in die etwas komplexer gewordene config.php werfen die man nun unter your_webshop/app/config/config.php findet.
Sollte man noch keine fertige Datenbank auf dem Server liegen haben, muss man die ./app/bin/install.sh ausführen. Gerade für mehrere automatische Deployments, würde ich aber die Datenbank einmal local auf meiner Workstation anlegen und mit Default-Werten befüllen. Diese kommt dann auf den Datebankserver und wird beim deployment, mit den spezifischen Daten wie den Shopdaten und Admin-Zugängen versehen.
Natürlich würden Updates auch über den Composer laufen, wobei sw:migration:migrate automatisch mit aufgerufen wird, um die Datenbank mit aktuell zu halten. Das Verhalten kann man über die Deaktivierung des entsprechenden Hooks in der composer.json verhindern (aber das macht an sich nur in Cluster-Umgebungen Sinn). Ein Update über das Webinstaller-Plugin würde Probleme bereiten und sollte, wenn man es dann ,z.B. weil man eine alte Installation umgezogen hat, installiert und aktiv hat mit ./bin/console sw:plugin:uninstall SwagUpdate entfernen.
Der wirkliche Vorteil liegt jetzt darin, dass man in die composer.json seine Git-Repositories von den Plugins mit eintragen kann und die Plugins direkt über den Composer installieren und updaten kann. Man muss also nicht diese erst vom Server downloaden + entpacken oder per Git clonen (wo dann wieder viel Overhead mit rüber kommen würde).
Ich musste mich damit beschäftigen wie man eine kleine REST-API mit Python erstellt. Django macht dabei an sich bei jeden Pups bei mir Probleme und war doch sehr umständlich, weil man sich noch mit dem gesamten MVC-Pattern darin beschäftigen musste. Nachdem es auch mit dem ORM schwieriger wurde (im Vergleich zu Spring Boot mit JPA/Hibernate) dachte ich mir, es müsse doch auch für Python was modernes geben. So kam ich zu Turbo Gears 2 und das macht schon mal genau was ich wollte. Einfach, schnell und übersichtlich.
from tg import expose, TGController, AppConfig
import jsonpickle
# --
class TestEntity(object):
def __init__(self, id ,name, sub):
self.id = id
self.name = name
self.sub = sub
class TestSubEntity(object):
def __init__(self, value):
self.value = value
# --
class RootController(TGController):
@expose("json")
def index(self):
test = TestEntity(42, 'blubb', TestSubEntity('sub-blubb'))
return jsonpickle.encode(test, unpicklable=False)
print("Serving on port 8090...")
httpd = make_server('', 8090, application)
httpd.serve_forever()
Mit Turbo Gears 2, Spring Boot und Meecrowave kann wirklich schnell und einfach Microservices erstellen und vieles des Overheads alter Zeiten ist einfach nicht mehr da bzw wurde so gut versteckt, dass man sich rein auf den Code und die Logik konzentrieren kann. Welche Lösung man da nimmt ist Geschmackssache. Von der Codestruktur her sieht alles an sich fast 100% gleich aus.
Bei Python sehen Flask, Bottle und Hug auch interessant aus
<Directory "/var/www/shopware">
Options Indexes FollowSymlinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Weil es ja Probleme mit TLS-SNI-01 gibt, kann man auch einfach eine Domain neu installieren. Dann wird ein neuer Eintrag mit dem Postfix 0001 angelegt.
Um unseren Shopware-Server aufzusetzen brauchen wir
- Apache (mit php7.0-mod)
- PHP7 (common,mysql,gd,xml,json,xsl,intl,gettext,mbstring,zip)
- MySQL Server
- OpenSSH Server
- PHPMyAdmin (wichtig hier Apache2 auszuwählen.. also mit Sternchen sichtbar nicht nur makiert)
Dann folgt die conf für den Apache und der Eintrag in die Host-Datei.
Jetzt können wir Shopware downloaden und installieren
Nun folgt die Netzwerk Konfiguration mit VirtualBox und die Anpassungen der hosts-Datei unter Windows.
Am Ende können wir mit dem Browser auf Shopware und mit WinSCP auf das System und das Shopware-Verzeichnis zugreifen.
So können wir unser lokalen Plugin-Verzeichnis mit dem auf dem Server synchron halten und Änderungen werden automatisch auf den Server gepusht.
Wenn man HTPS hat möchte man auch, dass es immer verwendet wird, auch wenn die Leute über HTTP auf die Seite kommen. Mit RewriteCond ist das ganz einfach.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
Ich bin jetzt auch mit MP4toGIF.com auf meinen Server bei netcup umgezogen. Einer der Hauptgründe von dem Hostingpacket von 1&1 auf einen eigenen Server umzuziehen war neben den günstigeren Betriebskosten für Server und Domains auch die Möglichkeit SSL-Zertifikate von Let's Encrypt verwenden zu können. Also keine 2,99 mehr pro Domain, um https nutzen zu können.
Let's Encrypt ist auch sehr einfach zu verwenden. Hier ist eine Anleitung für Ubuntu 16.04 LTS.
Zu erst, um nicht erst in kryptische Fehler zu laufen, aktivieren wir SSL für den Apache.
Dann startet der Client und man muss den Anweisungen folgen. Bei mir brach er mitten drin ab weil 'sudo apache2ctl configtest'
einen Fehler meldete, der wohl auf das bei mir noch nicht aktive SSL-Module zurück zu führen war.
ABER es ist sehr einfach den Rest per Hand einzurichten.
Zuerst die conf-Datei in sites-available mit dem Zusatz "-ssl" doppeln. Also zum Beispiel mp4togif.conf in mp4togif-ssl.conf doppel.
Dann in der neuen Datei den Port von 80 auf 443 ändern und dies hier einfügen.
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/mp4togif.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mp4togif.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mp4togif.com/fullchain.pem
Nun nur die site aktivieren mit
sudo a2ensite mp4togif-ssl
und den Apache neuladen
sudo service apache2 reload
und schon sind wir fertig und https sollte funktionieren.
Wenn man lokal entwickelt muss man sich oft eine Subdomain für "localhost" einrichten. Das ZF und ZF2 sind am liebsten so installiert und Folders in einer Domain funktionieren nicht immer ganz so gut. Außerdem kann man dann so einfach alles auf die produktive Domain kopiren ohne die htaccess anpassen zu müssen.
So etwas einzurichten ist auch ganz einfach. Es geht in der httpd.conf oder man richtet sich die extra/httpd-vhost.conf ein.
<VirtualHost *:80>
DocumentRoot "C:/workspaces/php/projectXYZ"
ServerName xyz.localhost
ServerAlias www.xyz.localhost
<Directory "C:/workspaces/php/projectXYZ">
DirectoryIndex index.php
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Mit AllowOverride erlaubt man das Verwenden von Rewrites
Beim Zend Framework 2 muss man sich ja wieder mit ReWrite-Rules und sowas auseinander setzen. Beim der REST-Implementierung in meinem Framework habe ich die ja auch benutzt und mußte mich erstmal wieder mit dem Syntax auseinander setzen um auch die Request und Get-Parameter mit zu übergeben. Ich fragte mich dann warum ich nicht von anfang an darauf gesetzt hatte, weil man so ja auch Domain mit Text und Namen drin einfach realiseren kann.
Nachdem ich dann beim Zendframewprk wieder damit kämpfen durfte, war es mir wieder klar. Get-Parameter sehen nicht toll aus, aber funktionieren immer! Wirklich immer egal auf welchen Server und mit welcher Konfiguration auch immer!
Das Zend Framework macht ja nichts anderes als mein Framework und biegt die URLs auf die index.php um und liefert dann die ursprüngliche URL zum Parsen mit. Vielleicht sollte ich doch noch mal die Rules meiner htaccess weiter verbessern, dass man doch Pages mit Namen und weiterer Beschreinung wie einer Überschrift aufrufen kann (die Beschreibung dann dynamisch auslesen oder so.. was auch bei URLs im Blog-Module toll wäre).
Wenn ich auch das Servlet-Mapping aus dem Tomcat mit dem ReWrite-Rules im Apache vergleiche.. der Servlet-Container macht es einem doch sehr viel einfacher. Da geht mal ein Punkt an die Java-Welt.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?