Setup Web Hosting: Difference between revisions
| Line 1: | Line 1: | ||
=Datenbanken= | == Datenbanken == | ||
==Datenbanken auf root Servern== | |||
===Host=== | === 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:<br /> | 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:<br /> | ||
<br /> | <br /> | ||
| Line 7: | Line 9: | ||
''vs-web-01'' Webhost, MySQL greift auf vs-db-01 zu.<br /> | ''vs-web-01'' Webhost, MySQL greift auf vs-db-01 zu.<br /> | ||
===Namen=== | ==== Namen ==== | ||
Der Name einer Datenbank wird immer nach folgendem Schema eingerichtet:<br /> | Der Name einer Datenbank wird immer nach folgendem Schema eingerichtet:<br /> | ||
''{Projektnummer}_{Projektname}'' Beispiel: ''penny14_int14_topps_boerse'' | ''{Projektnummer}_{Projektname}'' Beispiel: ''penny14_int14_topps_boerse'' | ||
===User=== | ==== 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:<br /> | (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:<br /> | ||
<br /> | <br /> | ||
| Line 24: | Line 26: | ||
<br /> | <br /> | ||
==Datenbanken HostEurope/Managed Hosting== | === Datenbanken HostEurope/Managed Hosting === | ||
===Namen=== | |||
==== Namen ==== | |||
Der Datenbankname enthält das Projektkürzel und die Version (dev|stag|live)<br /> | Der Datenbankname enthält das Projektkürzel und die Version (dev|stag|live)<br /> | ||
<br /> | <br /> | ||
| Line 31: | Line 34: | ||
db12826593-guhl15int19sgst<br /> | db12826593-guhl15int19sgst<br /> | ||
===User=== | ==== User ==== | ||
Username und Password sind Zufallskombinationen aus Zahlen und Buchstaben mit mindestens 13 Stellen Länge, erzeugt mit einem Passwort-Generator.<br /> | Username und Password sind Zufallskombinationen aus Zahlen und Buchstaben mit mindestens 13 Stellen Länge, erzeugt mit einem Passwort-Generator.<br /> | ||
<br /> | <br /> | ||
| Line 40: | Line 43: | ||
<br /> | <br /> | ||
=Verzeichnisse/Ordnerstruktur= | == Verzeichnisse/Ordnerstruktur == | ||
Das Verzeichnis des Webprojekt strukturiert sich nach der URL "rückwärts", plus der Version und einem cconfig und einem htdocs Verzeichnis. <br /> | Das Verzeichnis des Webprojekt strukturiert sich nach der URL "rückwärts", plus der Version und einem cconfig und einem htdocs Verzeichnis. <br /> | ||
| Line 55: | Line 58: | ||
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. | 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. | ||
== <br> | |||
Domains == | |||
== | === Dev Domains === | ||
Dev Domains für Bsp.. den Zugriff auf Staging oder Development Instanzen werden nach folgendem Muster angelegt: | |||
{Kundendomain}.{version}.pslsrv.com | {Kundendomain}.{version}.pslsrv.com | ||
Beispiel | '''Beispiel''' | ||
kampagne.guhl.de.dev.preview.parasol-island.com | kampagne.guhl.de.dev.preview.parasol-island.com | ||
kampagne.guhl.de.live.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. | |||
== ToDo == | |||
Idealerweise 1 Repository pro Webspace (bsp. fp.parasol-island.com oder app.penny.de | Idealerweise 1 Repository pro Webspace (bsp. fp.parasol-island.com oder app.penny.de | ||
ToDo: Projektnummer/Identifizierung | ToDo: Projektnummer/Identifizierung | ||
Todo: Name Webspace in dploy.io | Todo: Name Webspace in dploy.io | ||
| Line 91: | Line 100: | ||
TODO: Check if dploy.io supports pulling sub-modules | TODO: Check if dploy.io supports pulling sub-modules | ||
TODO: | TODO: | ||
Dev: automatisch bei jedem Commit (Webhook) Stage: (mit Commit Tag) Live: (Manuell oder mit Key oder so? Wer?) | |||
Revision as of 08:09, 8 May 2015
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.
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?)