[Codeforde-cert] Server-Infrastruktur für die Labs

[Julia Kloiber]

Liebe Leute,

ich kümmere mich gerne um einen weiteren Server - ich bräuchte dazu nur die Infos: Größe.. etc.
bzw. auch ganz kurz für was er verwendet werden soll.

Sobald ich die Infos habe, spreche ich Sponsoren an.

Lg Julia


> Am 11.10.2015 um 17:31 schrieb Jochen Klar <mail at jochenklar.de>:
> 
> Hallo Morris, hallo Liste,
> 
> cool das Ihr die euch zum Thema Infrastruktur zusammen gesetzt habt.
> Hier ein Paar Gedanken vom mir dazu.
> 
> Das mit den VMs finde ich sehr gut. Im Prinzip war das ja auch schon der
> Plan mit brandt, nur das sich damals herausgestellt hat das die Maschine
> dafür einfach zu schwach (insb. RAM) ist. Ich hatte libvirtd schon
> installiert ...
> 
> Ich bin auch stark dafür die Leute auf github-pages zu verweisen. Im
> Nachhinein denke ich, unserer gitolite/git-hook deploy Kiste hat da eher
> unnötige Komplexität rein gebracht.
> 
> Nach ein-einhalb Jahren brandt denke ich das der Bedarf für die
> mittleren Projekte (php/python/scala + datenbank + login um logs zu
> lesen) am größten ist. Es ist aber insbesondere eine Stärkere Kapselung
> was den Ressourcenverbrauch angeht nötig. VM würden das deutlich
> vereinfachen.
> 
> Für größere Sachen, gerade wenn es nicht unmittelbar aus den Labs kommt,
> sollte man irgendwo anders Platz finden. offenesparlarment.de, ich
> schaue in deine Richtung.
> 
> Ich weiß nicht ob Lab-Infrastrukturen wie das Münster-Discourse nicht
> besser auf einer der anderen OKFN Kisten aufgehoben wären.
> 
> Zum Thema Proxy: Ich glaube gerade laufen auch nur Port 80/443 Dienste
> daher sollte das mit nem Revese-Proxy auch gehen.
> 
> cheers,
> Jochen
> 
> On 11/10/15 15:03, Morris Jobke wrote:
>> Hallo liebes Server-Team,
>> 
>> wir hatten ja gestern Lab-Lead-Workshop in Hamburg und da ist das Thema
>> Infrastruktur aufgekommen. Aktuell haben wir ja brandt, was aber mehr
>> Wildwuchs als organisierte Infrastruktur ist. Ebenfalls läuft dieser
>> stark an seiner Belastungsgrenze (Load von 3-4 bei einem Quadcore).
>> 
>> Deshalb haben wir uns einmal spontan zusammen gesetzt und nachgefragt,
>> was denn so gebraucht wird und was für Lösungen es geben könnte. Dabei
>> sind wir dann zu dem Schluss gekommen, dass eine grobe Dreiteilung den
>> Labs an die Hand gegeben werden soll:
>> 
>> - ausschließlich (serverseitig) statische Projekte sollen nach
>> Möglichkeit über GitHub-Pages gehostet werden
>> - kleinere Projekten soll shared Webspace mit PHP/Python/...
>> Interpretern zur Verfügung gestellt werden
>> - größere Projekte sollen VMs zugeteilt bekommen, die dann unter der
>> Verantwortung der Labs administriert werden
>> 
>> Als Lösungsvorschlag war dann folgendes als Idee aufgekommen: Julia
>> kümmert sich um einen zweiten Root-Server (Sponsoring, etc), auf dem
>> dann etwas striktere Regeln zur Administration gelten sollen, damit es
>> nicht wieder in der ähnlichen Situation wie aktuell endet. Auf diesem
>> zweiten Server sollen dann ausschließlich Zugang zu VMs für die
>> einzelnen Projekte der Labs erstellt werden. Die Administration der VMs
>> obliegt dann den einzelnen Labs.
>> 
>> Das einzigste Problem, was wir gesehen haben, dass wir ausschließlich
>> eine IPv4-Adresse haben und deshalb nur über Ports an die VMs
>> herankommen. Eventuell müssten wir dann noch einen HTTP(S)-Proxy auf dem
>> Host aufsetzen und im Einzelfall über SNI und Virtual Hosts auf die
>> jeweiligens VMs weiterleiten. Aber aktuell dürfte das ja auch nicht
>> anders funktionieren. Oder haben wir mehrere IPs?
>> 
>> Bezüglich des Shared Webspace: Eine Möglichkeit wäre es, auf Dienste wie
>> Uberspace zu verweisen. Andere meinten, dass man auch eine eigene VM
>> dediziert dafür administriert und dort den Leuten einfache Zugänge zu
>> ihren eigenen Webspace geben kann und eben einen Apache mit PHP und
>> Python bereitstellt.
>> 
>> Ich würde mich auch bereit erklären das in entsprechende Ansible-Skripte
>> zu giesen, da wir das ja bereits einsetzen und auch entsprechend
>> dokumentieren, damit wir als Admin-Team, da möglichst einfach die
>> Infrastruktur den Labs zur Verfügung stellen.
>> 
>> Falls es noch Anregungen, Ideen, Verbesserungsvorschläge, Kritik oder
>> Fragen dazu gibt: Immer her damit. Ansonsten würde ich das dann weiter
>> angehen, sofern es keine Einwände bis in zwei Wochen (2015-10-25) gibt.
>> 
>> Ich habe Vater und Tobias noch mit in CC genommen, da wir über dieses
>> Thema ausfürhlich geredet haben.
>> 
>> Viele Grüße
>> Morris
>> für die Infrastruktur Session :)
>> 
>> 
>> _______________________________________________
>> Codeforde-cert mailing list
>> Codeforde-cert at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/codeforde-cert
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.okfn.org/pipermail/codeforde-cert/attachments/20151012/544b8fc3/attachment.sig>