[Codeforde-cert] Server-Infrastruktur für die Labs
Morris Jobke
hey at morrisjobke.de
Thu Nov 5 19:24:25 UTC 2015
Hallo,
so die Zeit ist um und ich habe mal wieder etwas Zeit gefunden.
Aktuell haben wir auf dem Brandt folgendes:
8 GB RAM (~6GB in use)
4*3,2 GHz (Load: 3.3)
1 TB HDD (310GB in use)
Für VMs braucht man ja prinzipiell etwas mehr. Ich würde sagen, dass wir
mindestens 16 GB RAM bräuchten - mehr ist natürlich immer besser. Da die
CPUs jetzt schon gut zu tun haben, wäre da natürlich auch mehr besser (so 6
oder 8 Kerne, da wir ja Parallelität wirklich nutzen können) ;)
Die HDD reicht über unsere Zwecke glaub ich immer. Wir haben jetzt nicht
wirklich die datenintensiven Sachen und RAID wird in dieser Kategorie von
Server immer verbaut sein.
Wie sehen das die Anderen hier?
Ansonsten kann sich Julia damit ja dann mal auf die Suche machen.
Viele Grüße
Morris
Am 13. Oktober 2015 um 08:58 schrieb Morris Jobke <hey at morrisjobke.de>:
>
>
>> Das mit AWS etc. kann ich auch verstehen. Ich frage mich aber schon ob es
>> eine Lücke zwischen GitHub pages und "Ich brauche einen Server" gibt. Ich
>> habe zum Beispiel eine kleine alte PHP+mysql App bei Red Hat Openshift am
>> laufen, das kostet nichts. Aber wenn jede Lab sowieso eine VM haben will,
>> ist es wahrscheinlich nicht relevant.
>>
>
> Diese Lücke hatte ich auch angesprochen. Die Idee war es auf entweder
> uberspace, etc zu verweisen oder eine gemeinsam (vom cert-Team)
> administrierte shared Webspace VM zu haben. Da muss dann halt ein MySQL,
> PHP und Python in einem Webserver laufen können und die Daten werden aus
> den userdirs gezogen. Halte ich jetzt für nicht allzu viel Arbeit.
>
> Viele Grüße
> Morris
>
>
>>
>> Viele Grüße,
>> Matt
>>
>> 2015-10-12 14:07 GMT+02:00 Jochen Klar <mail at jochenklar.de>:
>>
>>> Hallo Matt,
>>>
>>> Ich sehe da das Problem das docker, im Vergleich zu ich-habe-ein-ssh
>>> login doch einiges mehr an Einarbeitung erfordert. Man muss aus der
>>> existierenden Webapplikation ja erst mal etwas machen was in einem
>>> docker Container läuft.
>>>
>>> Virtuelle Maschinen sind da deutlich Einsteiger-freundlicher. In den VM
>>> kann man ja immer noch per docker deployen.
>>>
>>> Btw: bei 'nur' docker müsste man organisatorisch einiges klären. So eine
>>> VM für jedes Lab verteilt auch die Verantwortlichkeiten gleich mit.
>>>
>>> cheers,
>>> Jochen
>>>
>>> On 10/12/2015 01:53 PM, Matthew Fullerton wrote:
>>> > Ich finde den Plan gut. Ich würde nur raten Docker für VMs
>>> auszutauschen.
>>> >
>>> > In den letzten 1.5 Jahren haben die Hypethemen Docker und Cloud
>>> Services
>>> > sich weniger als Hype herausgestellt und mehr als die Zukunft. Ist über
>>> > Docker nachgedacht worden? Da bleiben die einzelne größere Projekte
>>> > abgetrennt von einander ohne VM overhead.
>>> >
>>> > Mit Cloud bin ich mich nicht so sicher, aber kleinere Projekte (z.B.
>>> > nodejs, Django basiert) lassen sich gut über Heroku oder Amazon Elastic
>>> > Beanstalk deployen und skalieren. Und Amazon hat inzwischen das EC2
>>> > Container Service - da kann man kompletten Docker containers pushen und
>>> > die werden ebenso deployed. Das Gute ist dass man da einen Cluster von
>>> > Instanzen haben kann (bei Bedarf), falls es zu viel Containers wird
>>> oder
>>> > zu viele Instanzen von den Containers. Der Nachteil ist natürlich dass
>>> > die Kosten weniger vorhersehbar sind als bei einem fixierten Server.
>>> >
>>> > Zum Thema sponsoring kann ich mich gut vorstellen, dass Amazon da was
>>> in
>>> > die Hand nehmen wird.
>>> >
>>> > Viele Grüße,
>>> > Matt
>>> >
>>> > 2015-10-12 12:34 GMT+02:00 Julia Kloiber <julia.kloiber at okfn.org
>>> > <mailto:julia.kloiber at okfn.org>>:
>>> >
>>> > 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
>>> > <mailto: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
>>> > <http://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 <mailto:
>>> Codeforde-cert at lists.okfn.org>
>>> > >> https://lists.okfn.org/mailman/listinfo/codeforde-cert
>>> > >>
>>> > >
>>> >
>>> >
>>> > _______________________________________________
>>> > Codeforde-cert mailing list
>>> > Codeforde-cert at lists.okfn.org <mailto:
>>> Codeforde-cert at lists.okfn.org>
>>> > https://lists.okfn.org/mailman/listinfo/codeforde-cert
>>> >
>>> >
>>>
>>>
>>
>> _______________________________________________
>> Codeforde-cert mailing list
>> Codeforde-cert at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/codeforde-cert
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/codeforde-cert/attachments/20151105/2f65e106/attachment.html>
More information about the Codeforde-cert
mailing list