Setup Web Hosting
Datenbanken
Datenbanken auf root Servern
Host
Als Best Practice sollten die Datenbanken auf einem dedizierten Datenbank vHost liegen auf dem per Firewall Konfiguration nur der Webhost Zugriff hat. Ein Zugriff von aussen, bsp. per SSH direkt auf den Datenbank Host sollte ausgeschlossen sein. Beispiel:
vs-db-01 Datenbank Host
vs-web-01 Webhost, MySQL greift auf vs-db-01 zu.
Namen
Der Name einer Datenbank wird immer nach folgendem Schema eingerichtet:
{Projektnummer}_{Projektname} Beispiel: penny14_int14_topps_boerse
User
(Optional) Auf die Datenbank wird mit einem dedizierten Lese- und Schreib-User zugegriffen. Der User heisst identisch zur Projekt-ID, jeweils mit dem Suffix "_r" und "_w". Beispiel:
Datenbank: penny14_int14_topps_boerse
User Read: penny14_int14_r
User Write: penny14_int14_w
Die Passwörter der User sind unterschiedlich und bestehen aus einer zufälligen Kombination aus mindestens 30 gemischten Buchstaben und Zahlen. Generiert bsp. mit diesem Tool: http://www.gaijin.at/en/olspwgen.php. Beispiel:
User: penny14_int14_r
Passwort: 407e3e5fac27f8e9179f2ba19a49b3ea9b2f619bbb056c76194dd274e1
Datenbanken HostEurope/Managed Hosting
Namen
Der Datenbankname enthält das Projektkürzel und die Version (dev|stag|live)
Beispiel
db12826593-guhl15int19sgst
User
Username und Password sind Zufallskombinationen aus Zahlen und Buchstaben mit mindestens 13 Stellen Länge, erzeugt mit einem Passwort-Generator.
Beispiel
Log: db12314593-W5mzK
Pas: 2753Ex61S3QPK
Verzeichnisse/Ordnerstruktur
Das Verzeichnis des Webprojekt strukturiert sich nach der URL "rückwärts", plus der Version und einem cconfig und einem htdocs Verzeichnis.
Beispiel
http://ampagne.guhl.de
/de/guhl/kampagne/dev/htdocs
/de/guhl/kampagne/dev/config
/de/guhl/kampagne/live/htdocs
/de/guhl/kampagne/live/config
im htdocs/ liegt das root Verzeichnis des Webservers bzw. des vHosts. Im config Ordner liegen alle sensiblen Konfigurations- und Zugangsdaten auf die nur die Anwendung selber Zugriff hat.
==
Domains ==
Dev Domains
Dev Domains für Bsp.. den Zugriff auf Staging oder Development Instanzen werden nach folgendem Muster angelegt:
{Kundendomain}.{version}.pslsrv.com
Beispiel kampagne.guhl.de.dev.preview.parasol-island.com kampagne.guhl.de.live.preview.parasol-island.com
FTP Zugänge
Sofern die Konfiguration des Zugriffs über individuelle Schlüssel nicht möglich ist, werden FTP Zugänge nach folgendem Muster angelegt:
Login: Random (mind. 13 Zeichen). Beispiel: AIg6khez93mFC
Passwort: Random (mind. 13 Zeichen). Beispiel: 8jEbExG872odq
Repository
Branches
master
develop
Trennung logischer Einheiten, bsp. Themes
Logische Einheiten, wie bsp. Themes werden durch Submodules strukturiert.
Deployment
Über dploy.io. Der develop branch wird auf den develop webspace deployt (i.d.R. auf dem Parasol Preview Webspace). Der master Branch wird auf Staging (zum testen) und Live (nach erfolgreichem Test auf Staging) deployt.
Webhook einrichten
Für das automatisierte refresh auf dploy.io bitte den "post-update" Webhook einrichten. Die Refresh URL liegt unter {Repository}/Settings/Webhooks & Badges.
../git/repositories/{repository}.git/hooks/post-update
cmod 777 ../git/repositories/{repository}.git/hooks/post-update
Beispiel
#!/bin/sh curl https://parasolisland.dploy.io/webhook/b2xc4236f17b316a17510d10b22309a81c37e52850246bdd
Exclude paths einrichten
Files oder Ordner die kritische Daten wie bsp. die Zugangsdaten zur Live-Datenbank etc. enthalten, liegen nur auf dem betreffenden Hosting Space. Damit diese nicht aus dem Repository überschrieben werden, müssen diese in den dploy.io exklude paths konfiguriert werden. Beipsiel:
tdocs/seidenglanz/wp-config.php .htpasswd
htdocs/.htaccess
ToDo
Idealerweise 1 Repository pro Webspace (bsp. fp.parasol-island.com oder app.penny.de ToDo: Projektnummer/Identifizierung
Todo: Name Webspace in dploy.io TODO: Use "config" rather than "local" TODO: Check if dploy.io supports pulling sub-modules TODO:
Dev: automatisch bei jedem Commit (Webhook) Stage: (mit Commit Tag) Live: (Manuell oder mit Key oder so? Wer?)