Citizenfour (Server): Unterschied zwischen den Versionen
(→Oh shit, Oh shit, Oh shit: +stop nginx-Docker) |
|||
Zeile 147: | Zeile 147: | ||
<code> | <code> | ||
docker start a7f35a54a870; docker start 4b5254424853; docker start 5f7c99507988; docker start 9255e89bf9ed | docker start a7f35a54a870; docker start 4b5254424853; docker start 5f7c99507988; docker start 9255e89bf9ed; docker stop a7f35a54a870 | ||
</code> | </code> | ||
Version vom 1. Mai 2017, 00:06 Uhr
Citizenfour (Server) Release status: stable [box doku] | |
---|---|
Beschreibung | Rootserver bei Hetzner |
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
- RZL Videos
- Mailserver
- Mailingliste https://github.com/raumzeitlabor/rzl-tuwat/issues/29
- Jabber (hax404 kümmert sich drum)
- DNS (hax404 kümmert sich drum)
- OpenVPN
- Munin
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:
externer Port | interner Port | interne IP | VM |
---|---|---|---|
443 | 443 | 192.168.123.10 | proxy |
80 | 80 | 192.168.123.10 | proxy |
interne IP-Vergabe
IPv4 | IPv6 | VM |
---|---|---|
192.168.123.10 | 2a01:4f8:161:9025:1::1 | proxy |
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; docker start 4b5254424853; docker start 5f7c99507988; docker start 9255e89bf9ed; docker stop a7f35a54a870
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.