Hi, Docker (basierend auf Hyper-V) wird ja immer beliebter. Wenn man nun mal auf hub.docker.com schaut, gibt es auch schon einige Images, die den AVR-Compiler zu bedienen scheinen. https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=0&q=gcc-avr&starCount=0 Leider bin ich in dem Thema noch recht neu und weiß nur, wie ich den Container starte. (Und im Beispiel von einem Server betrachte) Aber wie nutze ich den Compiler im Container nun zum produktiven arbeiten? Da ich meinen Code irgendwie rein und das fertige HEX raus bekommen muss, gehe ich mal von einem Shared/Mounted Volume aus, welches ich auf dem Hostsystem bespielen darf? Leider sind die vorhandenen Images auf Docker-Hub schlecht bis gar nicht dokumentiert. Wenn mir also Jemand sagen könnte, wie ich mit Eclipse und/oder CLion ein "Hello AVR" Projekt aufsetzen kann und dieses (sagen wir mal für einen Atmega88) über den Container compiliert bekomme, wäre das echt super! Grüße Oekel PS: Alles in einer VirtualBox (Ubuntu) zu betreiben ist für mich keine befriedigende Antwort, da dies bereits der ISTSTAND ist und sich mit einer alternativen Hypervision (Wie Docker sie benötigt) beißt. Und ich muss/soll Docker für andere Arbeiten nutzen und bin davon recht beeistert. PPS: Ja ich weiß, dass man Hyper-V aktivieren/deaktivieren (reboot notwendig) kann. Aber es geht mir hier wirklich um Docker und keine Alternativen :)
Du musst Docker benutzen und weißt nicht wie? Stell dir vor, du möchtest einen Obstteller bereiten, in dem du mit einem langen Pinsel durch ein Schlüsselloch ein Bild davon malst. Sicher gibt es den ein oder anderen dummen Vogel, der die Weintrauben auch wirklich anpickt, aber einen AVR-GCC in einem 8GByte VM-Container laufen zu lassen halte ich für eine ziemlich dicke Kneifzange um eine sehr kleine Hose anzuziehen.
Boris O. schrieb: > ...einen > AVR-GCC in einem 8GByte VM-Container laufen zu lassen halte ich für eine > ziemlich dicke Kneifzange um eine sehr kleine Hose anzuziehen. Also Gleichnisse erzählen kannst du :P Wenn es ein verpönter Weg wäre, würden die Container ja wohl nicht im Repro gelandet sein, oder? Also kannst du mir helfen oder hat sich das Vögelchen nur verflogen?
Boris O. schrieb: > aber einen > AVR-GCC in einem 8GByte VM-Container laufen zu lassen Docker benutzt Container, keine VM. Das ist ja der Witz dran.
Ok, vielleicht muss ich meine Fragen etwas genauer spezifizieren, damit ich eine Antwort erhalte. Folgende Images kommen (evtl.) in die nähere Auswahl: https://hub.docker.com/r/dea82/avr-gcc-docker/ https://github.com/dea82/avr-gcc-docker https://hub.docker.com/r/coolya/gcc-avr/ https://github.com/coolya/gcc-avr/blob/master/Dockerfile https://hub.docker.com/r/jypma/avr-gcc/ https://github.com/jypma/avr-gcc/blob/master/docker-compose.yaml https://hub.docker.com/r/kostic2000/avr-builds/ https://github.com/kostic2000/avr-builds/blob/master/Dockerfile https://hub.docker.com/r/kalledk/docker-avr-toolchain/ https://hub.docker.com/r/vyivanov/avr-docker/ https://hub.docker.com/r/mkdryden/avr-toolchain/ 'dea82' verwendet den aktuellsten GCC (aber das könnte man ja ggf. im Dokerfile beim eigenen Image anpassen), daher starte ich meine Frage nun basierend darauf. 'jypma' arbeitet mit archlinux (vielleicht ein weiterer Blick wert?) 'kostic2000' nimmt auch noch simavr mit rein (vielleicht kann man dort später auch noch ein paar Worte zu verlieren?) Also das Image ist nun 870MB und läuft im Container. In der zweiten Zeile des Dockerfiles steht
1 | ENV PATH $PATH:/usr/local/avr/bin |
Wo/Wie arbeitet der gcc-avr hier? Ist dies das Verzeichnis, welches ich beim starten des Containers als volume mounten sollte und meinen Sourcecode reinschiebe? (Auf dem Host=Windows 10) Falls nicht, welches Verzeichnis dann? Und wie bekomme ich nun den Befehl zum kompilieren in den Container gehackt? (Und wie binde ich dies später in meine IDE ein, damit ich per Knopfdruck kompilieren kann?) Ich hoffe meine Fragen sind nun etwas strukturierter und können beantwortet werden? Grüße Oekel
Ha das Hostsystem is ein Linux.Du musst in das Root-VZ vom container. Guck dir mal die Basics an. Und da liegt dann deer fertige Compiler unter /usr/local/avr..
Moin, ich würde das Host-Verzeichnis, in dem die Sourcen liegen in den Container mounten ( -v "<hostdir>:<containerdir>") und den Buildprozess über "docker exec -it <containername> <command>" starten. Das schöne an dieser Lösung ist, dass Du verschiedene Container benutzen kannst, sprich auch mit verschiedenen avr-gcc-Versionen rumspielen kannst. Als Produktiv-Umgebung würde ich das aber nicht benutzen. timpi.
Stefan L. schrieb: > Das schöne an dieser Lösung ist, dass Du verschiedene Container benutzen > kannst, sprich auch mit verschiedenen avr-gcc-Versionen rumspielen > kannst. Als Produktiv-Umgebung würde ich das aber nicht benutzen. Wieso eig. nicht? Definiere mal Produktivumgebung.Das soll doch die Stärke von Docker grad sein, dass über die Distri eine fertige Umgebung verteilt wird.
Ola schrieb: > Wieso eig. nicht? Definiere mal Produktivumgebung.Das soll doch die > Stärke von Docker grad sein, dass über die Distri eine fertige Umgebung > verteilt wird. Ja, da hast Du vollkommen recht. Ist meine Meinung, deshalb schrub ich "würde ICH nicht benutzen". Ich habe Ähnliches ein paar Jahre benutzen müssen und war nich' glücklich damit. Aber wer damit klar kommt, OK. timpi.
> kannst, sprich auch mit verschiedenen avr-gcc-Versionen rumspielen DAS ist kein Argument für einen Cont aber DAS: > ... Distri eine fertige Umgebung Wieso sollte man sich mit Containern rumschlagen, wenn man schon eine passende Plattform hat und nur das ein oder andere zusätzliche Tool braucht? Hat man das nicht, könnte ein fertiger Container schmerzloser sein.
ockerD schrieb: > Hat man das nicht, könnte ein fertiger Container schmerzloser sein. Genau das war mein Ansatz. Ich gebe Jemanden, den ich in die µC-Welt einführen will etwas komplett funktionierendes an die Hand und er macht NUR das, wofür er bezahlt wird: Coden
:
Bearbeitet durch User
D a v i d K. schrieb: > Leider bin ich in dem Thema noch recht neu und weiß nur, wie ich den > Container starte. (Und im Beispiel von einem Server betrachte) > > Aber wie nutze ich den Compiler im Container nun zum produktiven > arbeiten? > Da ich meinen Code irgendwie rein und das fertige HEX raus bekommen > muss, gehe ich mal von einem Shared/Mounted Volume aus, welches ich auf > dem Hostsystem bespielen darf? Mit "-v" bzw. "--volume" bei "docker create" oder "docker run" kannst Du ein Host-Directory in Deinen Container spiegeln, mit "docker exec" kannst Du in einem laufenden Container eine Rootshell starten.
ockerD schrieb: >> kannst, sprich auch mit verschiedenen avr-gcc-Versionen rumspielen > > DAS ist kein Argument für einen Cont Die Compilerversion wird dadurch von Typ und Version des Hostsystems komplett unabhängig, insofern ist das sogar ein ausgesprochen starkes ein Argument für Container. >> ... Distri eine fertige Umgebung > > Wieso sollte man sich mit Containern rumschlagen, wenn man schon eine > passende Plattform hat und nur das ein oder andere zusätzliche Tool > braucht? > Hat man das nicht, könnte ein fertiger Container schmerzloser sein. Ein fertiger Container ist in dieser Situation schon deswegen schmerzloser, weil mehrere Benutzer dasselbe Image benutzen können und somit alle exakt dieselbe Compilerversion und exakt dieselbe Toolchain benuzten, und zwar vollkommen gleichgültig, ob sie mit Windows, Linux, oder OS/X arbeiten.
Sheeva P. schrieb: > und zwar vollkommen gleichgültig, ob sie mit Windows, Linux, oder OS/X > arbeiten. Ich dachte, Docker setzt auf den Linux-Kernel auf. Gibt's das inzwischen auch für Windows und MacOS?
Rolf M. schrieb: > Ich dachte, Docker setzt auf den Linux-Kernel auf. Gibt's das inzwischen > auch für Windows und MacOS? Gibt es für Windows besteht dann aber aus Virtualbox mit passender VM. ist dann aber direkt aus Windows aufzurufen einschließlich Zugriff aufs Filesystem von Windows. von der VM merkt man sonst nichts und bekommt man auch nicht zu Gesicht.
ich schrieb: > Gibt es für Windows besteht dann aber aus Virtualbox mit passender VM. > ist dann aber direkt aus Windows aufzurufen einschließlich Zugriff aufs > Filesystem von Windows. von der VM merkt man sonst nichts und bekommt > man auch nicht zu Gesicht. So ein Bullshit. https://www.docker.com/microsoft https://www.windowspro.de/marcel-kueppers/container-windows-server-2016-funktionsweise-typen-anwendungen
Rolf M. schrieb: > Ich dachte, Docker setzt auf den Linux-Kernel auf. Gibt's das inzwischen > auch für Windows und MacOS? Ja, und ja. Ja, Docker nutzt Features des Linux-Kernel wie Control Groups und Namespaces, und ja, das gibt es auch für Windows und MacOS -- dort allerdings läuft der Linux-Kernel dann unter einem Hypervisor wie Virtualbox. Windows 10 hat allerdings auch eine Implementierung mit Hyper-V.
Anti-Bullshit schrieb: > So ein Bullshit. > > https://www.docker.com/microsoft > https://www.windowspro.de/marcel-kueppers/container-windows-server-2016-funktionsweise-typen-anwendungen Vielen Dank für die Links, aus denen ich aber immer noch nicht wirklich schlau werde. Laufen "Windows-Container" ohne Hypervisor, also direkt nativ auf dem Host-Kernel, hat Microsoft also Control Groups und Namespaces in den Windows-Kernel integriert? Welche Art von Gastsystem läuft in einem Windows Container, ein Linux oder ein Windows?
Sheeva P. schrieb: Welche Art von Gastsystem > läuft in einem Windows Container, ein Linux oder ein Windows? Per Default ein Linux. Kann aber in Docker umgestellt werden. ( mit Neustart, wie auch wenn du Hyper-V komplett de-/aktivierst )
Sheeva P. schrieb: > Rolf M. schrieb: >> Ich dachte, Docker setzt auf den Linux-Kernel auf. Gibt's das inzwischen >> auch für Windows und MacOS? > > Ja, und ja. Ja, Docker nutzt Features des Linux-Kernel wie Control > Groups und Namespaces, und ja, das gibt es auch für Windows und MacOS -- > dort allerdings läuft der Linux-Kernel dann unter einem Hypervisor wie > Virtualbox. Gut, aber dass man Linux in VirtualBox laufen lassen kann, ist ja nun nichts neues und hat erstmal mit Docker nichts zu tun.
Rolf M. schrieb: > Gut, aber dass man Linux in VirtualBox laufen lassen kann, ist ja nun > nichts neues und hat erstmal mit Docker nichts zu tun. Natürlich, und das wäre ja auch nicht erwähnenswert gewesen. Aber mit Docker kann ich ein einmal erstelltes Image besonders einfach auf ganz verschiedene Zielplattformen verteilen, und auf allen exakt dasselbe Image benutzen. Das sorgt für Konsistenz, minimiert Versions- und andere Konflikte, und bietet einen einfachen, sauberen Workflow -- bei minimalem Aufwand.
D a v i d K. schrieb: > Sheeva P. schrieb: > Welche Art von Gastsystem >> läuft in einem Windows Container, ein Linux oder ein Windows? > > Per Default ein Linux. Kann aber in Docker umgestellt werden. ( mit > Neustart, wie auch wenn du Hyper-V komplett de-/aktivierst ) Vielen Dank! Laufen diese Windows-Container dann direkt auf dem Windows-Kernel des Hostsystems (hat Microsoft dem Windows-Kernel also APIs für cgroups und namespaces spendiert), oder mit Hypervisor auf einem Linux-Kernel? Und: hast Du dazu möglicherweise einen oder mehrere Links?
Beitrag #5222954 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Rolf M. schrieb: >> Gut, aber dass man Linux in VirtualBox laufen lassen kann, ist ja nun >> nichts neues und hat erstmal mit Docker nichts zu tun. > > Natürlich, und das wäre ja auch nicht erwähnenswert gewesen. Aber mit > Docker kann ich ein einmal erstelltes Image besonders einfach auf ganz > verschiedene Zielplattformen verteilen, und auf allen exakt dasselbe > Image benutzen. Das sorgt für Konsistenz, minimiert Versions- und andere > Konflikte, und bietet einen einfachen, sauberen Workflow -- bei > minimalem Aufwand. Erwähnenswert ist aber das Docker auf Windows sich wegen Hyper-V nicht mit Virtualbox verträgt, auf das ich nicht verzichten wollte. Also kein Docker. Oder kennt jemand eine Lösung?
Carl D. schrieb: > Erwähnenswert ist aber das Docker auf Windows sich wegen Hyper-V nicht > mit Virtualbox verträgt, auf das ich nicht verzichten wollte. Also kein > Docker. Oder kennt jemand eine Lösung? Entweder auf Virtualbox verzichten und alles mit Hyper-V machen, oder unter Virtualbox ein Linux aufsetzen und darin dockern.
Einen "Umschalter" was cc aka gcc macht, kann man auch ohne den ganzen Docker/VM-Quatsch auf einem Linux/UNIX haben. Also verschiedene Versionen, Targets, Libs etc. Das ist allerdings nuex fuer Doofe.
--- schrieb: > Einen "Umschalter" was cc aka gcc macht, kann man auch ohne > den ganzen Docker/VM-Quatsch auf einem Linux/UNIX haben. > > Also verschiedene Versionen, Targets, Libs etc. Das ist halt drölfmal mehr Arbeit und viel fehleranfälliger... erst Recht, und wenn Du es mit heterogenen Systemumgebungen zu tun hast. > Das ist allerdings nuex fuer Doofe. Das ist ja das Schöne an Docker: automatisch eine vollkommen einheitliche Umgebung, überall und ohne unsere Tester, Anwender, Berater und Marketing-Leute mit irgendwelchen Details zu belasten. Find' ich super!
Sheeva P. schrieb: > Carl D. schrieb: >> Erwähnenswert ist aber das Docker auf Windows sich wegen Hyper-V nicht >> mit Virtualbox verträgt, auf das ich nicht verzichten wollte. Also kein >> Docker. Oder kennt jemand eine Lösung? > > Entweder auf Virtualbox verzichten und alles mit Hyper-V machen, oder > unter Virtualbox ein Linux aufsetzen und darin dockern. Nicht zwangsläufig. Die Docker-GUI liefert ein Häkchen, das man es in einer VirtualBox ausführt statt mit Hyper-V. Hab es zwar noch nicht getestet, aber ich denke das Linux in der Box muss man dann nixht wie gewohnt weiter anfassen.
Sheeva P. schrieb: > Carl D. schrieb: >> Erwähnenswert ist aber das Docker auf Windows sich wegen Hyper-V nicht >> mit Virtualbox verträgt, auf das ich nicht verzichten wollte. Also kein >> Docker. Oder kennt jemand eine Lösung? > > Entweder auf Virtualbox verzichten und alles mit Hyper-V machen, oder > unter Virtualbox ein Linux aufsetzen und darin dockern. Nicht zwangsläufig. Die Docker-GUI liefert ein Häkchen, das man es in einer VirtualBox ausführt statt mit Hyper-V. Hab es zwar noch nicht getestet, aber ich denke das Linux in der Box muss man dann nicht wie gewohnt weiter anfassen.
Was mich aber derzeit vielmehr verwirrt sind die Volumes, deren Mountings und Windows-Shares. Ein ./foo:/etc bekomme ich in der compose hin. In dem Docker File jedoch nur mit $(pwd). Und das Share NUR, wenn ich es im Nachgang mit Kinematics auf das Volumen setze. Ich hasse es aber, wenn Dinge nicht zu 100% über die Console bzw. Das ConfigFile funktionieren. Einige fertige Images meckern sogar, dass sie nicht auf das Verzeichnis schreiben dürfen, welches ich gemountet habe. Wer bestimmt denn wann und wo die chmod Rechte eines Volumes/Dir? Passiert da schon einiges beim Bauen des Images? Oder erst beim starten des Containers?
:
Bearbeitet durch User
D a v i d K. schrieb: > Was mich aber derzeit vielmehr verwirrt sind die Volumes, deren > Mountings und Windows-Shares. > > Ein ./foo:/etc bekomme ich in der compose hin. In dem Docker File jedoch > nur mit $(pwd). Da gehört es ja auch nicht hin. Im Dockerfile steht nur ein absoluter Pfad innerhalb des Containers als Hinweis, daß bei der Erzeugung von Containern auf den Container-Pfad XY etwas gemountet wird. Welches Host-Verzeichnis dorthin gemountet werden soll, weiß das Image nicht -- das gehört zur Container-Konfiguration und kann je nach Container und Host auch völlig verschieden sein. Hinweis: das Host-Verzeichnis muß beim --volume/-v als absoluter Pfad angegeben werden. > Und das Share NUR, wenn ich es im Nachgang mit Kinematics auf das > Volumen setze. Sicherlich wäre es sinnvoller, wenn Du Dich erst einmal grundsätzlich in die Konzepte und Bedienung von Docker einarbeiten würdest, bevor Du zu High-Level-Konzepten und -Tools wie Compose & Co. greifst. > Ich hasse es aber, wenn Dinge nicht zu 100% über die Console bzw. Das > ConfigFile funktionieren. Wenn man es richtig macht (und die Konzepte verstanden hat), funktioniert es meiner Erfahrung nach tadellos. ;-) > Einige fertige Images meckern sogar, dass sie nicht auf das Verzeichnis > schreiben dürfen, welches ich gemountet habe. Wer bestimmt denn wann und > wo die chmod Rechte eines Volumes/Dir? > Passiert da schon einiges beim Bauen des Images? Oder erst beim starten > des Containers? Images können nicht meckern, das können nur Container. ;-) Das Image wird beim Starten des Containers gemountet. Welche Rechte der Container auf dem Host und den gemounteten Images hat, wird vom Mountparameter --volume, von der Direktive USER im Dockerfile und dem Startparameter --user für "docker start" bzw. "docker run" bestimmt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.