search

FreifunkMD / FFMD-Orga

Organisation für FreifunkMD, z.B. Aufgaben
2 stars 0 forks source link

Travis prüfen #10

Closed andreasscherbaum closed 6 years ago

andreasscherbaum commented 6 years ago

Wie viel Speicherplatz stellt Travis zur Verfügung? Reicht das aus um einmal ein gluon Image Set zu bauen?

12G     gluon-v2017.1.2
LeSpocky commented 6 years ago

12G? Wir hatten zuletzt bei der alten Firmware schon über 40G, kan mir nicht vorstelle, dass das geringer geworden ist.

andreasscherbaum commented 6 years ago

Müsste mal das Log durch schauen, aber dem Ende nach sieht das sauber aus. Allerdings baue ich da wohl auch nicht alle Images.

baccenfutter commented 6 years ago

Auf allen Travis Seiten, auf denen Limits angegeben werden, ist nichts dazu zu finden. Storage scheint bei denen keine Kennzahl zu sein.

andreasscherbaum commented 6 years ago

Ein Limit das ich gefunden habe ist "4 MB Log Size": https://docs.travis-ci.com/user/common-build-problems/ Wenn der Buid mehr Output produziert, dann wird der abgebrochen.

baccenfutter commented 6 years ago

Ich bin zurück aus Köln und habe einfach mal einen Test-Case gebaut und gegen Travis gefahren.

Hier meine .travis.yml:

Hier die Testergebnisse:

$ dd if=/dev/zero of=test.iso bs=4k count=12M
dd: error writing ‘test.iso’: No space left on device
2613945+0 records in
2613944+0 records out
10706714624 bytes (11 GB) copied, 48.5835 s, 220 MB/s
The command "dd if=/dev/zero of=test.iso bs=4k count=12M" exited with 1.
0.01s

$ du -hs test.iso
10G test.iso

Es bleibt noch die Möglichkeit einfach mal ganz freundlich zu fragen. "Hey, wir sind vom Freifunk und brauchen mal so 50G für unsere Builds." Vllt klappts ja?

andreasscherbaum commented 6 years ago

Oder mal schauen welche anderen Build Möglichkeiten es gibt.

baccenfutter commented 6 years ago

Mir ist soweit keine Alternative zu Travis bekannt, die einen vergleichbaren Funktionsumfang hat und FOSS supported. Das andere Ende der Fahnenstange wäre dann wohl die Build-Umgebung auf eigener Hardware selbst zusammen zu schustern - evtl. in Form eines Docker Containers?

Alternativen zu Travis:

baccenfutter commented 6 years ago

Da fällt mir ein: Es gäbe auch noch Gitlab-CI. Das (und Gitlab insgesamt) sei wohl mittlerweile recht brauchbar und maintainable, heißt es. Erfahrungen habe ich da keine.

LeSpocky commented 6 years ago

Andere Freifunk-Communities nutzen bereits CI, vielleicht schaut man sich da nochmal um? Ich kann mich dunkel an Jenkins bei Freifunk Frankfurt/Main erinnern und Freifunk Braunschweig will da was mit Labgrid und Jenkins machen bzw. macht schon: https://stratum0.org/blog/posts/2017/08/16/freifunk-ci/

Im Freifunk Forum kann man mal nach Jenkins suchen, da werden dann auch Alternativen diskutiert: https://forum.freifunk.net/search?q=jenkins

andreasscherbaum commented 6 years ago

Der Blog Post sagt leider auch nur dass sie mal Jenkins machen wollen. Neuere Blog Posts zu dem Thema gibt es dort nicht.

Gut, müssen wir uns jetzt entscheiden, ob wir versuchen eines der Systeme aufzusetzen, oder mal bei Travis nachfragen.

penguineer commented 6 years ago

Das Nachfragen geht wahrscheinlich erstmal mit weniger Aufwand. Wenn das nicht bringt, plädiere ich auch für eine Jenkins-basierte Lösung. Dann sollten wir nochmal diskutieren, wie/wo die läuft.

baccenfutter commented 6 years ago

Meine Gedanken dazu: Ein eigenes System müssen wir nicht nur aufsetzen, sondern auch betreiben, warten und pflegen. Selbst wenn wir es vollständig mit Ansible managen, müssen dann halt langfristig Rollen und Plays maintained und irgendwo ausgeführen werden.

CI-as-a-Service Lösungen wie Travis sind aus meiner Sicht desshalb so attraktiv, weil sie "einfach laufen" (TM) und sich out-of-the-box mit Github Repositories verdrahten lassen. Eine custom-made Lösung an einen nachfolgenden Admin zu übergeben ist zudem was anderes, als wohldefinierte und standardisierte Lösungen weiter zu geben. Weniger Gefahr vor "never touch a running system" und ähnlichen Konstrukten.

Daher würde ich As-a-Service Lösungen grundsätzlich erst mal custom-made vorziehen.

Fragen kostet ja nix. Wir brauchen ja auch nur 50G Storage und nicht drölfzig CPU-Cores. Storage ist bekanntlich die kostengünstigste Hosting-Resource, sollte auch bei denen so sein. Schick doch einfach mal eine Mail von der Vorstandsadresse ab und schau was passiert...

andreasscherbaum commented 6 years ago

@baccenfutter Kannst du das übernehmen?

baccenfutter commented 6 years ago

@andreasscherbaum kann ich schon machen, aber ich denke, es hätte einen anderen Impact, wenn da was von vorstand@freifunk steht, statt von irgendwer@c-base.org. Meinst nicht?

Ansonsten bin ich grade über was Interessantes gestolpert, was ich so vorher noch nicht auf dem Tacho hatte:

Hier benutzt das ein Freifunker auch schon:

andreasscherbaum commented 6 years ago

Es gibt nur eine Mailingliste "vorstand-oberhavel", das ist keine reguläre Adresse die als Absender verwendet wird. Keine Ahnung ob Magdeburg da etwas hat ...

andreasscherbaum commented 6 years ago

Für das LambdaCD - die nutzen gar keine Container? Wie kann das sicher sein ;-)

Scherz beiseite, sieht auf jeden Fall mal interessant aus.

penguineer commented 6 years ago

Freifunk MD hat keine Hierarchie und ist organisatorisch im Netz39 untergebracht, von daher gibt es auch keinen offiziellen Vorstand und keine offizielle Vorstandsadresse. Es könnte sich höchstens der Netz39-Vorstand dort hin wenden. Dann sollte aber trotzdem jemand eine passende E-Mail formulieren und den Absender heraussuchen.

baccenfutter commented 6 years ago

Ich hab die jetzt einfach mal angeschrieben. Mal schauen was passiert.

Gibt es denn jemanden, der sich ansonsten gerne bereit erklärt einen CI-Server aufzusetzen und zu warten? Gerne direkt in Form einer Ansible-Role? Falls sich da niemand drum reißt, würde ich mich bereit erklären eine Ansible-Role für Drone zu schreiben.

andreasscherbaum commented 6 years ago

Können wir die potentiellen Kandidaten evaluieren, bevor wir uns da auf eine Software festlegen? Travis hört sich gut an weil es einfach mit GitHub integriert ist. Wenn es nicht Travis ist, ist hier eine (sicherlich unvollständige) Liste mit Fragen:

penguineer commented 6 years ago
LeSpocky commented 6 years ago

Travis hört sich gut an weil es einfach mit GitHub integriert ist.

Auch andere Dienste bzw. lassen sich mit GitHub integrieren. Für Jenkins gibt es bspw. allein zwei verschiedene Plugins. Die Anbindung an GitHub sollte da aber kein k.o. Kriterium sein, ein Umzug zu einem anderen Git Hoster (ggf. man selbst) kann schneller nötig sein als man denkt. ;-)

johannwagner commented 6 years ago

Ich stimme dem Punkt zu, dass man möglichst wenig selbst halten möchte. Wenn wir es selbst halten, braucht das ne Menge und gute Doku. Sonst stehen wir in vier Jahren wieder vor dem gleichen Problem wie jetzt..

penguineer commented 6 years ago

Das stimmt schon, wir wollen unseren Aufwand minimieren. Da sehe ich mit Ansible und Docker aber auch gute Chancen. Sonst haben wir irgendwann ein System in der Cloud, durch das keiner mehr durchblickt, das aber ggf. trotzdem munter weiter macht.

Passenderweise hat @LeSpocky heute das aus dem Internet gefiltert: http://geek-and-poke.com/geekandpoke/2017/11/27/simply-explained

baccenfutter commented 6 years ago

@andreasscherbaum: Ich wollte es nicht so klingen lassen, als würde ich mich bereits auf eine Software festlegen. Ich wollte nur zum Audruck bringen, dass ich eher weniger Bock hab mich freiwillig für die Maintenance zu melden, aber wenn ich es machen muss, weil es nunmal irgend jemand machen muss, dann würde ich Drone bevorzugen und das auch gleich in Form einer Ansible-Role abfackeln.

Ich bin auf jeden Fall auch dafür, dass ein gemeinsamer Konsenz gefunden wird, damit dann auch alle hinter der Lösung stehen.

@LeSpocky du hast natürlich recht. Auch die self-hosted Lösungen unterstützen mittlerweile fast alle (auch Github) Webhooks. Am Ende ist das sicherlich auch zu großen Teilen ganz einfach Geschmackssache. Ich halte Jenkins für das Jira der Build-Tools - kann alles, sieht schick aus, benötigt aber eine Vollzeitstelle für Einrichtung und Betrieb. Travis, im direkten Vergleich, braucht einmal max. 5 Klicks, um das Repo zu adden, und dann ungefähr drei Zeilen YAML und der erste Build läuft an. Wenn sich jemand anderes drum kümmert, habe ich überhaupt kein Problem mit einem Jenkins.

Drone gefällt mir als self-hosted Variante von allen mir bekannten Lösungen am besten, weil es klein, kompakt und handlich ist.

Als kostenlose As-A-Service-Variante ist mir nur Travis bekannt. Die Konkurrenten machen das bisher immer nur limitiert wärend ihrer Beta-Phase. Natürlich können wir die jetzt auch alle einzeln anschreiben, aber ich könnte mir vorstellen, dass die solche Anfragen täglich zu hunderten kriegen und da einfach keinen Bock drauf haben alle einzeln zu beantworten. Von daher sagt mir mein Bauchgefühl, wenn Travis nicht klappt, sollten wir den self-hosted Weg einschlagen.

baccenfutter commented 6 years ago

Antworten für Drone:

baccenfutter commented 6 years ago

Hab die Tage ein bisschen was rum gespielt und dabei ist dann auch gleich ein fertiges Docker-Compose File raus gekommen. Von Travis hab ich bisher leider nur eine automatische Antwort des Ticket-Systems erhalten.

Hier ein fertiger FreiFunk CI Server auf Basis von Docker und Drone, der einfach so sofort die Arbeit aufnimmt, egal wo man ihn aufsetzt (inkl. fancy JS-UI auf Port 8080):

version: '2'

services:
  drone-server:
    image: drone/drone:0.8

    ports:
      - 80:8000
      - 9000
    volumes:
      - ./drone:/var/lib/drone/
      - /var/lib/drone:/var/lib/drone/
    restart: always
    environment:
      - DRONE_OPEN=true
      - DRONE_ORGS=${DRONE_ORGS}  # FreifunkMD,FreifunkOHV
      - DRONE_ADMIN=${DRONE_ADMIN} # andreasscherbaum,LeSpocky,baccenfutter,...
      - DRONE_HOST=${DRONE_HOST}  # i.e. https://ci.rocks.freifunk.de/
      - DRONE_GITHUB=true
      - DRONE_GITHUB_CLIENT=${DRONE_GITHUB_CLIENT}  # Github OAuth Token
      - DRONE_GITHUB_SECRET=${DRONE_GITHUB_SECRET}  # Github OAuth Secret
      - DRONE_SECRET=${DRONE_SECRET}  # Shared secret among drone-server and drone agents.

  drone-agent:
    image: drone/agent:0.8

    command: agent
    restart: always
    depends_on:
      - drone-server
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DRONE_SERVER=drone-server:9000
      - DRONE_SECRET=${DRONE_SECRET}

  drone-wall:
    image: drone/drone-wall

    ports:
      - 8080:80

In Github Account Settings -> Developer Settings -> OAuthApps -> New OAuth App

Alle Felder ausfüllen, die Authorization Callback URL ist https://your.ci.server.name.or.ip/authorize

Github OAuth Form

Anschließend geht man im Browser auf https://your.ci.server.name.or.ip/authorize und klickt den Github Knopf, bestätigt den OAuth Handshake und wartet bis Drone den Account synchronisiert hat. Hier kann man jetzt die Repos aktivieren, für die Drone sich zuständig fühlen soll.

In die jeweiligen Repos legt man dann eine .drone.yml. Mein Test-File sieht so aus:

pipeline:
  my_test:
    image: drone/drone
    commands:
      - dd if=/dev/zero of=test.iso bs=1G count=1
      - du -hs test.iso

Commit -> Push == Drone legt los.

baccenfutter commented 6 years ago

Der Travis-Support hat sich mit einer guten und mit einer schlechten Nachricht gemeldet.

LeSpocky commented 6 years ago

Wenn man jedes GLUON_TARGET einzeln baut, reicht der Platz. Dann müsste man beim Build aber anders vorgehen, jeweils:

Wenn man das ungeschickt anstellt, baut man jedesmal alles neu inklusive Toolchain, aber grundsätzlich könnte das gehen.

baccenfutter commented 6 years ago

Ständig am oberen Limit zu kratzen und einzeln Builds weg zu kopieren dürfte den gesamten Build-Prozess spürbar verlangsamen. Weiß nicht, ob das optimale Voraussetzungen für eine zukunftsweisende Infrastruktur sind. Das führt doch sicherlich nur dazu, dass wir den ganzen CI Kram in max. 1-2 Jahren wieder komplett umwerfen müssen, oder nicht? Ich meine... ich kenn den Gluon Build-Prozess nicht. Ich gehe einfach davon aus, dass der in Zukunft tendentiell eher wächst, oder?

LeSpocky commented 6 years ago

Pro target, man könnte auch sagen pro Architektur oder pro Platform (wobei das technisch nicht ganz korrekt wäre), wird eine neue Cross-Toolchain gebaut und das ganze System einmal kompiliert inklusive Bootloader, Kernel und Userland, ggf. mit unterschiedlichen targetspezifischen Patches, da bin ich nicht ganz sicher. Für ein target braucht man IIRC ca. 7 GB, ± ein bisschen. Es ist zumindest für FFMD auch jetzt schon so, dass man immer nur ein target zur Zeit baut, unser Skript built.sh baut die halt alle nacheinander. Stark wachsen tut das ganze nur wenn neue targets dazu kommen. Ich gehe davon aus, dass man für ein Target auch in Zukunft bei max. 10 bis 12 GB bleibt.

andreasscherbaum commented 6 years ago

Wie lange braucht das derzeit für eine Architektur/Target? Die Travis CI hat wohl pro Build ein Limit von 2 Stunden, wenn ich das richtig in Erinnerung habe.

@baccenfutter Kriegt man das "drone" in einen LXC/D Container gepackt?

baccenfutter commented 6 years ago

@andreasscherbaum: Den Drone-Server kriegen wir sicherlich in einen LXC/D Container, aber die Drone-Agents (die können ja ansonsten auch sonstwo laufen und beliebig hoch und runter fahren, solange sie das Shared-Secret des Drone-Servers kennen und den auf Port 9000 erreichen können) brauchen zwingend Zugriff auf den Docker-Socket ihres jeweiligen Hosts und müssen (zumindest im Docker-Context) im priviligierten Modus gestartet werden, damit sie im Docker die Build-Jobs ausführen können. Da also eh ein Teil im Docker laufen muss, ist es sinnvoll gleich den ganzen Stack im Docker laufen zu lassen, weil er sich dann so schön kompakt in ein docker-compose.yml pressen lässt. Evtl. kombiniert sich das ggf. brauchbar mit einem LXC/D Container, in den man dann Docker betreibt oder den Docker Socket vom Host rein reicht und betreibt dann Drone im Docker im LXC/D?

penguineer commented 6 years ago

An der Stelle könnten wir noch einmal überlegen, ob wir die Zahl der von uns regelmäßig geprüften Architekturen beschränken wollen. Ich hatte dazu früher schon vorgeschlagen, nur eine Auswahl von Geräten zuverlässig zu unterstützen und den Rest mehr oder weniger den jeweiligen Nutzern zu überlassen, um unseren Support-Aufwand zu verringern.

Für CI würde das bedeuten, dass wir die Zahl der ständig gebauten Architekturen einschränken. Nur vor einem Release würde man dann noch einen kompletten Build machen, um zu sehen, ob es doch irgendwo kracht.

Auf diese Art können wir die Build-Zeiten schlanker halten.

andreasscherbaum commented 6 years ago

@baccenfutter Dann sollten alle Container unter Docker laufen, nicht unter LXC/D. Zwei Systeme zum Managen von Containern auf einem Host kann nicht gutgehen.

Kriegt man den ganzen Router ect. dort auch drauf zum Laufen, wie sieht das mit Management in den Containern dann aus?

baccenfutter commented 6 years ago

Bin mir nicht sicher, ob ich deine Fragen richtig verstehe...

Den fertigen Build kriegen wir theoretisch auch im Docker zum Laufen, sofern wir das in einem Docker starten, der auf der jeweils richtigen Architektur läuft.

Management in den Build-Container selbst existitiert nicht. Die sind volatil und machen nach jedem Build puff. Wenn man was debuggen muss, dann muss man den/die Container bei sich lokal hoch ziehen und dort debuggen. Wenn das Problem beseitigt ist committen, pushen und dem Production-Build zuschauen bis er durch gelaufen ist.

Natürlich kann root des Hosts immer docker ps, docker exec -it DOCKERID /bin/bash und los... Build-Umgebungen betrachtet man normalerweise als immutable und das will man eigentlich auch so. Schließlich sind sie die Instanz, die garrantiert, dass ein Build wirklich reproducible ist.

Wenn was mit dem dem Drone-Setup selbst verheddert ist, machen wir:

Dadurch werden einmal alle Drone Container abgesägt, gelöscht neu gebaut und deployed. Etwaig laufende Builds werden anschließend automatisch neu gestartet, weil wir die SQLite3 DB container-übergreifend persistieren. Der neue Drone kriegt einfach wieder die DB seines Vorgängers. Hab ich getestet, funktioniert.

andreasscherbaum commented 6 years ago

Na ja, ich hatte jetzt angefangen einiges in LXD aufzusetzen. Aber zwei Container Umgebungen parallel machen keinen Sinn ...

baccenfutter commented 6 years ago

Ja tut mir leid, wenn ich da jetzt ewas voreilig war. Ich hab mich eines Abends einfach durch deren Doku geklickt, weil ich das auch für die Firma interessant find, und da fällt am Ende halt einfach ein docker-compose.yml raus.

andreasscherbaum commented 6 years ago

So, hin und her gelesen und probiert: "drone" wird kein LXC/LXD unterstützen (https://github.com/drone/drone/issues/1240), außerdem gibt es keine Debian Packages - nur fertige Docker Container (https://github.com/drone/drone/issues/1126). Update Strategie unklar.

Auch müsste ich dann den Rest alles auf Docker statt auf LXC/D umstellen - und dann ist die Update Strategie dort auch ungewiss. Beides zusammen geht wohl nicht.

Das Drone Docker Image sieht erst mal gut aus, aber wie das mit dem Rest zusammen spielt weiß ich nicht.

baccenfutter commented 6 years ago

Update Strategie unklar.

Update Strategie:

docker-compose down
docker-compose up -d

Beim Starten holt sich Docker automatisch das :latest Image, wenn es ein neueres gibt. Da die Config und SQLite3 DB durch ein Volume in den Container gereicht wird, hängt sich der neue Container an die alte DB, findet Config und alles funktioniert einfach weiter.

Nicht, dass ich mich für Drone als Lösung einsetzen will, ich kenn das auch noch nicht aus dem produktiven Betrieb!

Wie genau würde denn eine LXC/D Lösung mit Jenkins oder Gitlab-CI aussehen?

johannwagner commented 6 years ago

Ich denke, dass die Drone-Docker-Lösung schon funktionieren wird. Wenn man das richtig hält. dann nimmt das einem viel Arbeit ab, gerade, wenn die Tags vernünftig gesetzt werden und sowas.

Ich finde die Entscheidung für CI einen sehr wichtigen Schritt.

baccenfutter commented 6 years ago

Jenkins und Gitlab-CI (o. Ä.) sind halt die Platzhirsche. Bei Drone finde ich den Gedanken nach wie vor ziemlich sexy, dass es im Disasterfall mit einem Zweizeiler wieder am Start ist. Ggf. muss in Github noch die Webhook-URL angepasst oder einen DNS-Change gemacht werden. Im Worst-Case verliert man die Build-History. Meiner Ansicht nach, ist die in unserem Fall nicht sooo wichtig. Wenn doch, dann müssen wir Backups vom Docker-Volume erstellen.

Evtl. sieht eine LXC/D Lösung mit Jenkins/Gitlab-CI aber ähnlich simpel aus. Das weiß ich nicht.

andreasscherbaum commented 6 years ago

Das Problem ist nicht Drone, sondern Docker. Wenn du ein Ding mit Docker machst, dann musst du alles auf dem Host mit Docker machen. Das verträgt sich nicht mit anderen Container-Lösungen.

Würde es Drone nicht nur als Docker Container geben, sondern auch so zum Installieren, hätte das wahrscheinlich viel mehr Charme.

baccenfutter commented 6 years ago

Warum? Auf meinem Gentoo Server beim Hoster habe ich sowohl LXC Container, als auch Docker Container am laufen? Warum sollte das in unserem Fall nicht auch gehen?

andreasscherbaum commented 6 years ago

Das funktionierte bei mir nicht sauber. Die streiten sich um Resourcen ect. Und Drone in LXC/D wird zum Beispiel explizit nicht unterstützt.

Die entscheidende Frage: Docker nur wegen Drone? Oder hat jemand Docker für den Rest der notwendigen Software auch fertig?

baccenfutter commented 6 years ago

Docker und LXC/D benutzen beide cgroups. cgroups in cgroups unterstuetzt der Kernel AFAIK nicht, daher gehen weder Docker in LXC/D noch anders herum. Aber nebeneinander sollten die sich nicht mehr um die Resourcen streiten, wie zwei Prozesse auf der selben CPU sich um die Resourcen streiten. Nach einem apt-repository ...: apt install docker ist die Einrichtung von Docker auch schon durch.

Aber ich bin jetzt erst mal ruhig und warte ab wie denn eine LXC/D Loesung genau aussehen wuerde.

penguineer commented 6 years ago

Soweit ich das verstehe, ist es für das CI-System relativ egal, ob wir Container mit Docker oder LXC/D verwenden. Ich schlage vor, diesen Teil der Diskussion auf später zu verschieben, wenn wir mehr über das eigentlich zu verwendende System wissen. Dann haben wir noch ein wenig mehr Input.

Mag jemand (auch für das nächste Treffen) mal den Zwischenstand kurz zusammenfassen? Gern auch im Pad: https://pad.n39.eu/p/FreifunkReboot5

andreasscherbaum commented 6 years ago

http://jenkins.freifunk-oberhavel.de/

Da fällt ein blankes Jenkins raus, fertig in einem LXC Container. Admin Passwort kommt aus Ansible.

johannwagner commented 6 years ago

Wir machen das hier zu, Topic is abgeschlossen. Ob es bei Jenkins bleibt, ist abzuwarten.