Citizenfour (Server): Unterschied zwischen den Versionen

Aus RaumZeitLabor Wiki
K (→‎laufende Dienste: verweis auf Diskussion auf github hinzugefügt)
(archiviert)
 
(14 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Archäologie}}
{{ProjektInfoBox
{{ProjektInfoBox
|name        = Citizenfour (Server)
|name        = Citizenfour (Server)
Zeile 4: Zeile 6:
|image      = RaumZeitLabor - Logo - Schwarz.svg
|image      = RaumZeitLabor - Logo - Schwarz.svg
|description = Rootserver bei Hetzner
|description = Rootserver bei Hetzner
|category    = Infrastruktur
|subcategory = Netz
|author      = [[NOC Team|NOC-Team]]
|author      = [[NOC Team|NOC-Team]]
|username    =  
|username    =  
Zeile 53: Zeile 57:
=== Reverse Proxy ===
=== Reverse Proxy ===


Es läuft ein Reverse-Proxy der für alle HTTP/HTTPS Requests genutzt wird und diese an die Container weiterreicht. Der Reverse-Proxy spricht auch SPDY/3.1 (HTTP2 yet to come).
Es läuft ein HA-Proxy als IPv4-NAT für HTTP(S). Dieser kann für Backends, die kein SSL oder kein IPv6 können das auch passend Terminieren damit alle Backends via IPv6 und SSL erreichbar sind. Außerdem kann er auf Wunsch selbstständig HTTP-Redirects von einer Domain auf eine andere machen und HTTP -> HTTPS-Redirects.
 
== Netzwerk ==
=== IPv6 ===
IP-Addressbereich: '''2a01:4f8:161:9025::/64'''
{| class="wikitable"  valign = "top"
!Netzbereich
!Verwendung
|-
|2a01:4f8:161:9025:1337::/80
|docker
|-
|2a01:4f8:161:9025::/65
|KVM-VMs
|-
|}
 
IP-Konfiguration für VMs:
{| class="wikitable"  valign = "top"
|IP-Address
|2a01:4f8:161:9025:<vm-number>::<arbitrary number>
|-
|Gateway
|2a01:4f8:161:9025::2
|-
|Netmask
|65
|-
|}
 
=== IPv4 ===
IP-Addresse: '''5.9.77.39'''
{| class="wikitable"  valign = "top"
!Netzbereich
!Verwendung
|-
|172.17.0.0/16
|docker
|-
|192.168.123.0/24
|KVM-VMs
|-
|}
 
Port-Mappings:
 
TCP:
{| class="wikitable"  valign = "top"
!externer Port
!interner Port
!interne IP
!VM
! Dienst
|-
|443
|443
|192.168.123.10
|proxy
|HTTPS
|-
|80
|80
|192.168.123.10
|proxy
|HTTP
|-
|36268
|22
|192.168.123.11
|git
|SSH
|-
|36269
|22
|192.168.123.12
|chat
|SSH
|-
|25
|25
|192.168.123.13
|[[Premium (Server)]]
|SMTP Server2Server
|-
|587
|587
|192.168.123.13
|[[Premium (Server)]]
|SMTP Submission
|-
|465
|465
|192.168.123.13
|[[Premium (Server)]]
|SMTPS
|-
|143
|143
|192.168.123.13
|[[Premium (Server)]]
|IMAP
|-
|4190
|4190
|192.168.123.13
|[[Premium (Server)]]
|Sieve Mailfilter Configuration
|-
|5222
|5222
|192.168.123.13
|[[Premium (Server)]]
|XMPP Client2Server
|-
|5269
|5269
|192.168.123.13
|[[Premium (Server)]]
|XMPP Server2Server
|-
|9102
|9102
|192.168.123.13
|[[Premium (Server)]]
|Bareos
|-
|53
|53
|192.168.123.13
|[[Premium (Server)]]
|Autoritative DNS-Server
|-
|}
 
UDP:
{| class="wikitable"  valign = "top"
!externer Port
!interner Port
!interne IP
!VM
!Dienst
|-
|53
|53
|192.168.123.13
|[[Premium (Server)]]
|Autoritative DNS-Server
|-
|2303
|2303
|192.168.123.13
|[[Premium (Server)]]
|OpenVPN
|-
|}
 
=== interne IP-Vergabe ===
{| class="wikitable"  valign = "top"
!IPv4
!IPv6
!VM
|-
|192.168.123.10
|2a01:4f8:161:9025:1::1
|proxy
|-
|192.168.123.11
|2a01:4f8:161:9025:2::1
|git
|-
|192.168.123.12
|2a01:4f8:161:9025:3::1
|chat
|-
|192.168.123.13
|2a01:4f8:161:9025:4::1
|[[Premium (Server)]] (geplant)
|-
|172.17.0.2
|
|raumzeitlabor/nginx-proxy
|-
|172.17.0.3
|
|raumzeitlabor/rzl-homepage-docker
|-
|172.17.0.4
|
|raumzeitlabor/mysql-docker
|-
|172.17.0.5
|
|raumzeitlabor/mediawiki-docker
|-
|}
 
== Oh shit, Oh shit, Oh shit ==
Falls du den Server rebootet hast und bemerkst, dass der Docker nicht rebootfest ist: Folgendes magische Kommando bootet den Docker ordnungsgemäß.
 
<code>
docker start a7f35a54a870 && sleep 10 && docker start 4b5254424853 && sleep 10 && docker start 5f7c99507988 && sleep 10 && docker start 9255e89bf9ed && sleep 10 && docker stop a7f35a54a870 4b5254424853
</code>
 
Die Startreihenfolge der Docker-Container ist wichtig, da Docker die IPv4-Addressen beim Start der Container fortlaufend vergibt und verschiedene Configurationsdateien genau diese IP-Addressen fest eingetragen haben.


<graphviz format='png'>
Sollte ein Docker-Container nicht mehr benötigt werden, rate ich dazu diesen trotzdem zu starten und erst wenn alle anderen Docker-Container laufen zu beenden, damit die korrekte Zuweisung der IPv4-Addressen gewährleistet ist.
digraph {
reverse-proxy -> rzl-homepage;
reverse-proxy -> mediawiki-web;
}
</graphviz>


[[Kategorie:Hardware]]
[[Kategorie:Hardware]]
[[Kategorie:Infrastruktur]]

Aktuelle Version vom 22. März 2022, 15:50 Uhr

Dieser Artikel ist Tot Dieser Artikel wurde archiviert.

Das Gerät/Projekt hinter diesem Artikel existiert nicht mehr oder verrichtet andere Dienste. Bitte bedenke, dass dieser Text nicht mehr unbedingt der Wahrheit entspricht. Wenn du Fragen zu dem Thema hast, nimm am besten Kontakt mit dem Autor auf, sofern dieser noch unter uns weilt.


       
Citizenfour (Server)

Release status: stable [box doku]

Beschreibung Rootserver bei Hetzner
Kategorie  Infrastruktur / Netz
Autor(en)  NOC-Team
Hostname  citizenfour.raumzeitlabor.de

Citizenfour ist unser Rootserver, der Premium, den OVH Rootserver und die Trollcon VM ersetzt. Er wurde Anfang März 2015 bei Hetzner angeschafft und besitzt eine IPv4 sowie ein /64. Citizenfour hat volle IPv6 Konnektivität, d.h. alle Dienste, die auf ihm laufen, sind i.d.R. per IPv6 erreichbar (z.B. dieses Wiki).

Technische Daten

Produkt Hetzner SB29
Rechenzentrum RZ16
CPU Intel i7-3770 CPU @ 3.40GHz (Quadcore mit HT)
RAM 16GB RAM
HDDs 2x 3TB (RAID1, LVM, ext4)
Kosten 29€ mtl.

laufende Dienste

aktuell

  • Homepage
  • Wiki

TODO

Reverse Proxy

Es läuft ein HA-Proxy als IPv4-NAT für HTTP(S). Dieser kann für Backends, die kein SSL oder kein IPv6 können das auch passend Terminieren damit alle Backends via IPv6 und SSL erreichbar sind. Außerdem kann er auf Wunsch selbstständig HTTP-Redirects von einer Domain auf eine andere machen und HTTP -> HTTPS-Redirects.

Netzwerk

IPv6

IP-Addressbereich: 2a01:4f8:161:9025::/64

Netzbereich Verwendung
2a01:4f8:161:9025:1337::/80 docker
2a01:4f8:161:9025::/65 KVM-VMs

IP-Konfiguration für VMs:

IP-Address 2a01:4f8:161:9025:<vm-number>::<arbitrary number>
Gateway 2a01:4f8:161:9025::2
Netmask 65

IPv4

IP-Addresse: 5.9.77.39

Netzbereich Verwendung
172.17.0.0/16 docker
192.168.123.0/24 KVM-VMs

Port-Mappings:

TCP:

externer Port interner Port interne IP VM Dienst
443 443 192.168.123.10 proxy HTTPS
80 80 192.168.123.10 proxy HTTP
36268 22 192.168.123.11 git SSH
36269 22 192.168.123.12 chat SSH
25 25 192.168.123.13 Premium (Server) SMTP Server2Server
587 587 192.168.123.13 Premium (Server) SMTP Submission
465 465 192.168.123.13 Premium (Server) SMTPS
143 143 192.168.123.13 Premium (Server) IMAP
4190 4190 192.168.123.13 Premium (Server) Sieve Mailfilter Configuration
5222 5222 192.168.123.13 Premium (Server) XMPP Client2Server
5269 5269 192.168.123.13 Premium (Server) XMPP Server2Server
9102 9102 192.168.123.13 Premium (Server) Bareos
53 53 192.168.123.13 Premium (Server) Autoritative DNS-Server

UDP:

externer Port interner Port interne IP VM Dienst
53 53 192.168.123.13 Premium (Server) Autoritative DNS-Server
2303 2303 192.168.123.13 Premium (Server) OpenVPN

interne IP-Vergabe

IPv4 IPv6 VM
192.168.123.10 2a01:4f8:161:9025:1::1 proxy
192.168.123.11 2a01:4f8:161:9025:2::1 git
192.168.123.12 2a01:4f8:161:9025:3::1 chat
192.168.123.13 2a01:4f8:161:9025:4::1 Premium (Server) (geplant)
172.17.0.2 raumzeitlabor/nginx-proxy
172.17.0.3 raumzeitlabor/rzl-homepage-docker
172.17.0.4 raumzeitlabor/mysql-docker
172.17.0.5 raumzeitlabor/mediawiki-docker

Oh shit, Oh shit, Oh shit

Falls du den Server rebootet hast und bemerkst, dass der Docker nicht rebootfest ist: Folgendes magische Kommando bootet den Docker ordnungsgemäß.

docker start a7f35a54a870 && sleep 10 && docker start 4b5254424853 && sleep 10 && docker start 5f7c99507988 && sleep 10 && docker start 9255e89bf9ed && sleep 10 && docker stop a7f35a54a870 4b5254424853

Die Startreihenfolge der Docker-Container ist wichtig, da Docker die IPv4-Addressen beim Start der Container fortlaufend vergibt und verschiedene Configurationsdateien genau diese IP-Addressen fest eingetragen haben.

Sollte ein Docker-Container nicht mehr benötigt werden, rate ich dazu diesen trotzdem zu starten und erst wenn alle anderen Docker-Container laufen zu beenden, damit die korrekte Zuweisung der IPv4-Addressen gewährleistet ist.