[Codeforde-cert] Server-Infrastruktur für die Labs
Jochen Klar
mail at jochenklar.de
Thu Nov 5 19:57:32 UTC 2015
Hallo,
sehe ich auch so, würde aber noch mehr RAM drauflegen:
Also 8 Cores, 32 Gig RAM, 1TB Raid (kann auch Software sein so wie jetzt).
Wenn ich mal hier
https://www.hosteurope.de/Server/Root-Server/
https://www.manitu.de/root-server/vergleich/
schaue, scheint das aktuell so die L bis XL Fraktion zu sein, je nach
Anbieter.
cheers,
Jochen
On 11/05/2015 08:24 PM, Morris Jobke wrote:
> 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
> <mailto: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
> <mailto: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>
> > <mailto: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>
> > <mailto: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>
> > <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>
> <mailto: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>
> <mailto: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
>
>
>
More information about the Codeforde-cert
mailing list