Webserver-How-To Teil 1: Überlegungen und Umsetzung der Infrastruktur
22. März 2008Ein Webserver möchte gut überlegt sein. Zu allererst sollte man sich deshalb überlegen, was denn genau der Zweck sein soll. Soll er etwa einfach nur zum lokalen Austesten von Scripten dienen - oder soll er gar als Webserver genutzt werden, der z.B. als dedizierte Maschine in ein Rechenzentrum gestellt werden soll? Natürlich gibt es auch noch viele Zwischenstufen. So kann ein Webserver natürlich auch dazu dienen, das komplette Intranet-Netzwerk zu realisieren und z.B. eine Intranet-Seite für Firmen oder für ein größeres Netzwerk bereitstellen. Darüberhinaus kann er natürlich auch dafür nützlich sein, innerhalb einer Community gegenseitig Webspace zur Verfügung zu stellen, um im Team effizienter arbeiten zu können. Er sollte demnach nicht nur im eigenen Netzwerk verfügbar sein, aber auch nicht im kompletten Internet - sondern eben nur für festgelegte Mitglieder. Auch so etwas lässt sich natürlich realisieren.
Wenn ich euch nun zu jedem der Szenarien erklären würde, wie man das jetzt genau realisiert, dann würde das den Umfang doch ziemlich sprengen. Auf alles nur ein bisschen eingehen, halte ich auch nicht wirklich für klug, da alles nur grob angerissen wird. Aus diesem Grund lege ich mich einfach auf ein Szenario fest: Einen Webserver einrichten, der im Internet genutzt werden soll - wahrscheinlich obendrauf noch das umfangreichste von allem. Aber ich mache es euch einfach: Zuerst werden wir den Webserver ganz lokal einrichten, sodass dieser nur auf dem eigentlichen Computer läuft, danach werden wir das ganze im kompletten Netzwerk einrichten (an dieser Stelle werde ich noch auf die VPN-Möglichkeit eingehen, die es ermöglicht, nur bestimmten Nutzern aus dem Internet Zugriff zu gewähren) und letztendlich den kompletten Webserver noch webtauglich zu machen.
Sollte ich euch vorher etwas verwirrt haben mit den ganzen Begriffen, so möchte ich mich dafür herzlich entschuldigen und nun mehr Klarheit reinbringen. Schauen wir uns die erste Möglichkeit an, nämlich dass der Webserver nur lokal läuft:

Die Struktur hierbei ist denkbar einfach. Ein einzelner Rechner regelt den kompletten Ablauf. Diese Möglichkeit ist die einfachste und zu empfehlen für Leute, die einfach mal schnell und unkompliziert ihre Scripte ausprobieren möchten.
Eine weitere Möglichkeit wäre, den Webserver in einer virtuellen Maschine laufen zu lassen. Das hat den Vorteil, dass man im Prinzip eine "eigene" (dedizierte) Maschine für alleine für den Webserver hat. So können u.a. viel weniger Konflikte mit anderen Programmen, die noch zusätzlich auf dem Arbeitscomputer installiert sind, auftreten. Ein Aufbau würde folgendermaßen aussehen:

Hier erkennt man den Unterschied: Die virtuelle Maschine läuft auf dem eigentlichen Computer, nur eben abgeschottet von anderen Anwendungen. Dies ist die elegantere und sicherere Lösung, auch wenn man seine Scripts eigentlich nur lokal testen möchte. Jedoch sei hier auch wieder der (finanzielle) Aufwand zu erwähnen: In der virtuellen Maschine muss natürlich auch ein komplett neues Betriebsystem eingerichtet werden. Zudem braucht man dafür (zumindest bei Windows XP) eine zusätzliche Lizenz. Und gute Virtualisierungssoftware kostet auch eine ganze Menge. Falls die finanziellen Mittel zur Verfügung stehen, so empfehle ich euch VMWare Workstation (Version 6 Einzellizenz zur Zeit 189$) oder - für die ganz Professionellen - VMWare Infrastructure (günstigste Variante zur Zeit 1540$).
So viel also zum Lokalen. Soll der Webserver in einem Netzwerk laufen, sieht das ganze schon anders aus:

In diesem Fall läuft der Webserver auf einer eigenen Maschine - also ein dedizierter Webserver. Dieser ist über einen Router oder über einen Switch mit den restlichen Computern im Netzwerk verbunden. Diese können über die interne IP auf diesen dann zugreifen. Natürlich gibt es auch hier die Möglichkeit mit einer virtuellen Maschine. Je nachdem, wie viele Computer auf den Webserver im Netzwerk jedoch zugreifen sollen, empfiehlt es sich teilweise, einen eigenen Computer für den Webserver zur Verfügung zu stellen, denn virtuelle Maschinen haben i.d.R. nicht wahnsinnig viel Leistung (wobei das natürlich auch wieder auf den physischen Computer ankommt, auf dem diese läuft). Ich gehe in meinem How-To von der Konfiguration aus, dass der Webserver eine dedizierte Maschine ist.
Was jedoch, wenn nun nicht nur Leute aus dem Intranet auf den Webserver zugreifen dürfen sollen, sondern auch andere, aber nicht das komplette Internet? Hier kommt die VPN-Lösung ins Spiel. VPN funktioniert im Prinzip nicht viel anders als ein richtiges Netzwerk. Sind sogenannte VPN-Clients (also diejenigen, die Zugriff erhalten sollen) über den VPN-Server authenzifiziert, werden diese wie reale Computer im eigentlichen Intranet behandelt. Sie können demnach natürlich auch bestehenden Arbeitsgruppen oder Domänen beitreten, die im Intranet schon vorhanden sind. Der Beitritt in einen VPN-Server (der z.B. auf eurem Webserver laufen kann) erfolgt über das Internet. Mit entsprechendem Benutzernamen und Passwort können also Leute aus der ganzen Welt in euer Netzwerk über die VPN-Bridge eurem Netzwerk beitreten. Und genau das wollen wir in diesem Fall ja. So könnte das aussehen:

Die VPN-Clients sind demnach auf den Remote-Computern (also den Internet-Rechnern) installiert. Diese Clients stellen über das Internet eine Verbindung zum VPN-Server her, der (in diesem Beispiel ebenfalls ein dedizierter ist) mit dem dedizierten Webserver verbunden ist. Der VPN-Server kommuniziert also über das Internet mit den Clients und stellt somit die Verbindung her. Wie man ein solches VPN einrichtet, erkläre ich an dieser Stelle nicht. Einer der bekanntesten VPN-Clients ist jedoch Hamachi, der größtenteils selbsterklärend ist. Bei Hamachi verhält sich das jedoch wieder etwas anders: Die Hamachi-Clients stellen eine Verbindung mit einem Hamachi-VPN-Server her - die Installation eines VPN-Servers im eigenen Netzwerk entfällt also. Lediglich der Client muss auf jedem Rechner installiert sein.
Nun zur wahrscheinlich komplexesten Konfiguration: Der Webserver im Internet - er soll also von jedem Standort der Welt aus errreichbar sein:

Dies ist eine stark vereinfachte Version des kompletten Geschehens. Hierbei ist der dedizierte Webserver mit sämtlichen anderen Computern im eigenen Netzwerk standardmäßig über einen Router mit dem Internet verbunden. Auf dem Router werden dabei die benötigten Ports freigeschaltet, die wiederum auf Computer im Netzwerk weitergeleitet werden. Kommt zum Beispiel eine Anfrage von außen auf Port 80 und ist der Router so konfiguiert, dass dieser diese Anfrage auf den dedizierten Webserver weiterleitet, so erhält derjenige, der angefragt hat, die Antwort direkt vom Webserver. Der Router hat somit eigentlich keine andere Rolle als verschiedene Anfragen weiterzuleiten. Der Router wiederum ist durch eine Leitung mit dem Provider (z.B. Telekom) verbunden, der ja bekanntlicherweise den Internetzugang zur Verfügung stellt. Die Provider wiederum haben sogenannte DNS-Server, über die von außen (also dem Internet) jeder Internetzugang eine eindeutige Adresse zugewiesen bekommt. In der Regel sind das dynamische IP-Adressen, die jedoch wiederum mit Diensten wie z.B dyndns.org weitergeleitet werden können und der Router somit eine Adresse hat, unter der er ständig erreichbar ist. Computer aus dem Internet greifen also auf DNS-Server zu, die die Anfrage wieder weiterleiten. Und genau so verhält es sich, wenn euer Webserver im kompletten Internet zur Verfügung stehen soll. Dies geschieht über solch eine Konfiguration.
Solltet ihr jetzt nicht ganz mitgekommen sein, so ist das auch nicht schlimm. Das war alles mehr oder weniger Theorie, die euch helfen soll, zu verstehen, wie alles geregelt ist. Jedoch halte ich so Know-How für sehr wichtig - denn wenn ihr das jetzt im Groben einigermaßen verstanden habt, könnt ihr nun selbst entscheiden, wie euer Webserver am Netz hängen soll.
So viel also zur Infrastruktur. Lasst euch genug Zeit für eure Überlegung! Bloß keine voreiligen Entscheidungen. Geht außerdem nochmal alles Schritt für Schritt durch, ob das so auch klappt mit eurem Netzwerk.
Das war auch schon Teil 1 meines Webserver-Workshops. Ich hoffe, ihr habt einigermaßen etwas gelernt und seid bei Teil 2 auch wieder dabei!
Fragen etc. werden nur in den Kommentaren hier beantwortet. Nur so profitieren alle davon.

Save to Browser Favorites
Ask
backflip
blinklist
BlogBookmark
Bloglines
BlogMarks
Blogsvine
BUMPzee!
CiteULike
co.mments
Connotea
del.icio.us
DotNetKicks
Digg
diigo
dropjack.com
dzone
Facebook
Fark
Faves
Feed Me Links
Friendsite
folkd.com
Furl
Google
Hugg
Jeqq
Kaboodle
linkaGoGo
LinksMarker
Ma.gnolia
Mister Wong
Mixx
MySpace
MyWeb
Netvouz
Newsvine
PlugIM
popcurrent
Propeller
Reddit
Rojo
Segnalo
Shoutwire
Simpy
sk*rt
Slashdot
Sphere
Sphinn
Spurl.net
Squidoo
StumbleUpon
Technorati
ThisNext
Webride
Windows Live
Yahoo!
Email This to a Friend
If you like this then please subscribe to the 




[...] Webserver-How-To Teil 1: Überlegungen und Umsetzung der Infrastruktur [...]
Chronicles of Seb » How-To: Einen Webserver auf Windows aufsetzen | 22. März 2008 | 22:51[...] Webserver-How-To Teil 1: Überlegungen und Umsetzung der Infrastruktur [...]
[...] man sich für eine Konfiguration der Infrastruktur entschieden, steht
Chronicles of Seb » Webserver-How-To Teil 2: Das Sicherheitskonzept | 23. März 2008 | 17:55[...] man sich für eine Konfiguration der Infrastruktur entschieden, steht der nächste wichtige Schritt an: Die Absicherung, um Hackern und anderen [...]
[...] geht es richtig los! Nachdem man sich ausführlich Gedanken
Chronicles of Seb » Webserver-How-To Teil 3: Apache installieren & konfiguieren | 24. März 2008 | 22:59[...] geht es richtig los! Nachdem man sich ausführlich Gedanken zur Infrastruktur und zur Sicherheit gemacht hat, geht es los mit ersten Schritt zur Installation des eigenen [...]