|
|
|
|
|
|
|
| | Zitat von Renga
Gibt's für Docker irgendwelche Tools die mich beim Version Pinning der verwendeten Tools im Container unterstützen?
Problem ist ja, dass wenn man seine Tools im Dockerfile nicht genau auf eine Version spezifiziert, beim Rebuild des Containers sich so einiges ändern kann. Das ist eher ungünstig wenn ich auf einem Releasebranch nach x Monaten nen kleinen Fix plus Anpassung im Container nachschieben will und da auf einmal ne neue Compilerversion drin ist.
Wie geht ihr damit um?
| |
wie werden denn diese "tools" installiert?
wenn du z.b. auf nem "latest" upstream image dependest dann ist das klar dass das rolling ist -> wir dependen immer auf expliziten version.
für z.b. apt-packages intern haben wir nen eigenen aptly der intern mit snapshots arbeitet und die base versionen verweisen nur auf nen snapshot von so nem aptly.
für python muss halt ne requirements.txt sein (pder sowas wie poetry benutzen)
für npm dependences ne packages-lock.json
und und und
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von Renga
Gibt's für Docker irgendwelche Tools die mich beim Version Pinning der verwendeten Tools im Container unterstützen?
Problem ist ja, dass wenn man seine Tools im Dockerfile nicht genau auf eine Version spezifiziert, beim Rebuild des Containers sich so einiges ändern kann. Das ist eher ungünstig wenn ich auf einem Releasebranch nach x Monaten nen kleinen Fix plus Anpassung im Container nachschieben will und da auf einmal ne neue Compilerversion drin ist.
Wie geht ihr damit um?
| |
wie werden denn diese "tools" installiert?
wenn du z.b. auf nem "latest" upstream image dependest dann ist das klar dass das rolling ist -> wir dependen immer auf expliziten version.
für z.b. apt-packages intern haben wir nen eigenen aptly der intern mit snapshots arbeitet und die base versionen verweisen nur auf nen snapshot von so nem aptly.
für python muss halt ne requirements.txt sein (pder sowas wie poetry benutzen)
für npm dependences ne packages-lock.json
und und und
| |
Geht erstmal nur um Installationen per apt-get.
Die Baseimage Version ist zumindest mal fix (Ubuntu oder Debian). Gibt's da ne klare Regel für Pakete, z.B das da keine Major changes drin sein dürfen wenn ich mich auf z.B Ubuntu:20.xx als Basis festlege? Oder kann man sich da nicht drauf verlassen?
|
|
|
|
|
|
|
|
|
|
|
Apt-get hat ja erstmal nix mit docker zu tun...
Version pinning vielleicht? Als Beispiel
| | create a file called /etc/apt/preferences.d with the contents:
Package: gitlab
Pin: version 14.4.*
Pin-Priority: 1001 | |
Dann updated er nicht die major Version
|
|
|
|
|
|
|
|
|
|
|
|
Es geht um apt Installationen im Dockerfile.
|
|
|
|
|
|
|
|
|
|
|
Die laufen auch im Kontext Deines Docker Containers.
Also vorher ein ADD, um das config Dir in den Container zu kopieren (oder halt mounten).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KDO2412]Mr.Jones
Apt-get hat ja erstmal nix mit docker zu tun...
Version pinning vielleicht? Als Beispiel
| | create a file called /etc/apt/preferences.d with the contents:
Package: gitlab
Pin: version 14.4.*
Pin-Priority: 1001 | |
Dann updated er nicht die major Version
| |
bringt dir halt nichts wenn die version nichtmehr upstream verfügbar ist? aber ja, das scheint nen gangbarer weg zu sein. sprich wenn man packages updaten will generiert mehr ne neue pinfile und ansonsten hofft man dass nen install mit der pinfile noch klappt(=die versionen noch im repo sind)
also debian hat innerhalb eines stable releases eigentlich keine versionsupgrades drin (ausnahmen wie chromium&co bestätigen die regel, das sind programme bei denen können sie nicht die patches backporten)
ansonsten bekommst du z.b. in einem bullseye dockercontainer genau das gleiche geliefert wie mit ner bullseye installation.
bei ubuntu bin ich mir da nicht so sicher was die alles innerhalb ner LTS updaten.
was ich auch grade seh, debian bietet wohl selber snapshots an:
https://snapshot.debian.org/
wenn du nur die in deinen sources.list drinhast dann solltest du safe sein.
|
|
|
|
|
|
|
|
|
|
|
Mach doch dein eigenes Base image mit allem (von apt) was du brauchst. Das kannst du dann nach ein paar Monaten einfach wider verwenden. Allerdings wird dir wahrscheinlich vulnerability management dir einen Strich durch die Rechnung machen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Renga
Gibt's für Docker irgendwelche Tools die mich beim Version Pinning der verwendeten Tools im Container unterstützen?
Problem ist ja, dass wenn man seine Tools im Dockerfile nicht genau auf eine Version spezifiziert, beim Rebuild des Containers sich so einiges ändern kann. Das ist eher ungünstig wenn ich auf einem Releasebranch nach x Monaten nen kleinen Fix plus Anpassung im Container nachschieben will und da auf einmal ne neue Compilerversion drin ist.
Wie geht ihr damit um?
| |
Du kannst als base Image einen fixen sha256 digest nehmen, dann ist definitiv immer das identische image drunter. Der pullt den afaik auch aus der registry.
|
|
|
|
|
|
|
|
|
|
Hat hier jemand einen Tipp, wie man folgendes am besten lösen kann:
Usecase: Infos befinden sich in Jira (Feldern) -> Diese sollen in ein Word Dokument (Vorlage). Word Dokument wird dann als PDF gedruckt. 
Die Daten händisch Feld für Feld rauszukopieren ist.. müßig.
Ich dachte zuerst an etwas wie: Jira -> XML Export -> dann via XSLT in HTML. HTML imitiert die Word Vorlage oder man kopiert evtl. daraus zusammenhängend weiter nach Word. Aber aktuelle Browser scheinen das aus Security Gründen nicht mehr zu erlauben (Einbindung local XSL file in einer XML).
Die Lösung muss DAU-tauglich und darf keine Adminrechte auf dem (Windows)-PC erfordern. Am besten mit Boardmitteln 
/e: mist, sollte eigentlich in den Informatiker helfen PC Neulinge /o\
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Swot am 19.07.2022 17:36]
|
|
|
|
|
|
|
|
|
https://pypi.org/project/jira/ vielleicht?
e: also dau tauglich ist die library sicher nicht, aber damit kann man was dautaugliches basteln. dann noch mittels py2exe oder vergleichbarem bundeln und ab geht die luzi.
nicht vergessen den sourcecode danach wegzuschmeissen, das macht man mit solchen custom tailored tools!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 19.07.2022 17:48]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Danke euch, schaue ich mir beides genauer an.
|
|
|
|
|
|
|
|
|
|
|
Ich fange zum 1.9. in einer neuen Firma an und darf mir aussuchen, ob ich einen Mac oder Windows Laptop will...
Einerseits bin ich seit 13 Jahren auf dem Mac am Coden, andererseits nervt mich die Entwicklung von Mac OS ein wenig. Ständig was neues und nix, was ich brauche (kein iPhone oder Apple Watch vorhanden).
Hach. Was gibt es denn an vergleichbar "wertigen" Windows Laptops?
Allein aus Gewohnheit werde ich wohl zu einem Macbook greifen...
E: Außerdem kann ich wohl ein iPhone als Arbeitshandy bekommen. Dann kann ich zumindest die geteilte Zwischenablage nutzen...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KDO2412]Mr.Jones am 22.07.2022 20:15]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Für mich waren die Firmen-MBPs bisher auch eher so 'meh'. Seit kurzem habe ich aber ein 14" 2021er M1 MBP und das macht mir wirklich sehr viel mehr Spaß.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von xfxian am 22.07.2022 20:55]
|
|
|
|
|
|
|
|
|
|
Niemand sollte auf Windows entwickeln müssen. Wenn Linux zur Auswahl steht, dann ist die Diskussion wieder offen, aber fuck off mit Windows.
|
|
|
|
|
|
|
|
|
|
|
Ich bin ja zuletzt (fürs Homeoffice) von einem iMac mit i9 8-Kerner auf einem Mac Mini mit M1 umgestiegen... Was soll ich sagen. Der Mini ist so viel schneller.
Gut, der iMac hätte vielleicht zwischendurch auch mal neu installiert werden dürfen, aber trotzdem.
|
|
|
|
|
|
|
|
|
|
|
Aktuell ist M unschlagbar. Selbst mein altes M1 Pro haut jeden anderen Rechner weg den ich zur Auswahl hätte. Mit Abstand.
Deswegen: Mac.
|
|
|
|
|
|
|
|
|
|
|
|
Mir hat man zum Monatsanfang bei meiner neuen stelle nen Win10 laptop hingestellt und es ist tatsächlich okay(ish). Ich mein, inzwischen kann das ding wenigstens virtuelle Desktops, hat ein brauchbares terminal+ssh on board, mit winget sogar sowas wie nen Paketmanager und vor allem: WSL. Hab den Vergleich zu Macs aber auch nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 22.07.2022 22:20]
|
|
|
|
|
|
|
|
|
Entwickelst du in der WSL? Nutzt du die WSL mit grafischem Desktop?
Wir mussten betteln, dass im BIOS die Virtualisierungsfunktionen aktiviert wurden, die Voraussetzung für die WSL sind.
|
|
|
|
|
|
|
|
|
|
|
|
Ich benutze das vor allem zusammen mit Visual Studio Code. Wenn ich Code starte, habe ich direkt bash im Arbeitsverzeichnis als Terminal in Code geöffnet.
|
|
|
|
|
|
|
|
|
|
|
Ja, das ist schon ziemlich n1 geworden.
Ich hab neulich mal for fun in WSL2 das DALL-E Mini in einem WSL2 Docker Container ausgeführt, mit kompletter Durchreiche der Grafikkarte in WSL2 und dann Docker. Gerade so Python-Kram wo die libs haufenweise binary dependencies haben sind sonst so abartig schmerzhaft, schon abgefahren.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Armag3ddon
Ich benutze das vor allem zusammen mit Visual Studio Code. Wenn ich Code starte, habe ich direkt bash im Arbeitsverzeichnis als Terminal in Code geöffnet.
| |
Ja, das. Inzwischen hab ich noch ne dicke linux-buildmaschine unterm Schreibtisch, ob ich per remoteextension dort oder im wsl arbeite macht (bis auf die Geschwindigkeit) quasi keinen unterschied. Und aufm laptop hat man damit auch ne ordentliche shell.
Wenn ichs mir aussuchen könnte, hätt ich auch ein Linux aufm laptop, aber ich kann so auch gut genug arbeiten, dass ich mir den hassle die ganze firmen-it selber anzubinden eigentlich nicht geben will. Vor allem weil der ganze MS-shit wie office/outlook/Teams da tendenziell scheiße ist.
|
|
|
|
|
|
|
|
|
|
|
Mir wurde beim neuen Job ungefragt ein Mac hingestellt. Der Job erfordert gefühlt 95% Golang und 5% Webdev für interne Admininterfaces.
War bei meinem letzten Job (ein selbst gegründetes Startup) ähnlich und da hatte ich Windows. Der Frontend npm Kram lief in WSL und alle Builds wurden in Docker Containern gebaut und gepusht.
Aus dieser Sicht wäre es mir egal ob Windows oder Mac aber die IT der neuen Firma läuft unter Windows. Für Mails muss ich mich in ein hässliches Lotus Notes Webinterface einloggen. Ich kann im Büro nicht Drucken was angeblich an Active Directory liegen soll. Jeder Mitarbeiter hat eine Interne Durchwahl die mit ner VoIP Software läuft die es nur unter Windows gibt. Es gibt Erweiterungen für Lotus Notes wo ich das Kennzeichen meines Autos hinterlegen kann damit das Parkhaus automatisch auf geht wenn ich vorfahre... Kann ich nicht nutzen weil Mac. Genauso ein Excel Plugin für Analytics welches natürlich nicht für Excel unter Mac gemacht ist.
Daher bin ich wohl einer der wenigen Developer der lieber doch einen Windows Rechner hätte 
|
|
|
|
|
|
|
|
|
|
|
Und ich Naivling dachte, dass in einer Welt in der 90% der PCs mit Windows laufen und das proprietäre MS Office sich immer tiefer in den Workflow vieler Unternehmen einnistet, man kaum auf die Idee kommen würde, einen Mac für was anderes als Programmierung von Apple-Apps o.ä. zu verwenden.
Ich werde aus euern Kürzeln nicht schlau. Wieso scheint MS nicht in der Lage zu sein, von euch so dringend benötigte Features abzudecken? Nicht deren Fokus, sollen die Nerds doch Linux nutzen?
|
|
|
|
|
|
|
|
|
|
|
Rein praktische eigene Erfahrung:
auch wenn man mittlerweile vielleicht einen Windows-PC mit WSL usw. entwicklungstauglich bekommen könnte, meistens kommt dann die firmeneigene IT um die Ecke und möchte ihn gerne "administrieren".
Bei Macs und Linux erschien da bisher die Hürde deutlich höher.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Izmir
Ich werde aus euern Kürzeln nicht schlau. Wieso scheint MS nicht in der Lage zu sein, von euch so dringend benötigte Features abzudecken? Nicht deren Fokus, sollen die Nerds doch Linux nutzen?
| |
Naja, Windows hat halt ne andere Architektur (nicht Unix). MacOS und Linux sind Unix. Die meisten Anwendungen (Web oder Backend) laufen mal auf Linux (Unix), da isses halt oft hilfreich, auch auf Unix zu entwickeln (weil dann halt doch mal irgendwas anders compiled wird oder whatever).
Bei meinem letzten Projekt gab's ein test-windows und ein test-linux command, wegen Zeitzonengedöns.
|
|
|
|
|
|
|
|
|
|
|
|
Ich brauch ein aosp-buildsystem, das läuft nur unter Linux.
|
|
|
|
|
|
|
|
|
|
|
ich bin _so_ froh einfach linux (selbstadministriert) auf meinem arbeitslaptop zu haben und fertig.
natürlich fixt man doch die probleme der kolleg:innen auf den windows rechnern, WSL2, ja toll, das funktioniert halt auf dem papier und auch nur so lange bis es mal nicht funktioniert.
der mount (geil gelöst über 9p protokoll!) stürtz ab wenn man nur docker desktop&debian standard hat? direkt beim starten? "liegt am bug in der linux implementierung" (tut es anscheinend wirklich, aber wieso muss ich mich dazu erstmal durch zig github issues/kommentare quälen und kann es dann, oh wunder, doch durch nen setting "fixen".)
das direkt zu anfang, beim totalen entwicklungsedgecase wsl2+docker (läuft jetzt wegen lizenz eh komplett im wsl2 auf cli only)
zugriff aufs windows homeverzeichnis? `npm install` dauert mal 1,2 stunden und bricht dann fucking ab. (anstatt 2 minuten). danke virenscanner.
dann halt im linux home arbeiten und von windows aus per \\wsl$ drauf zugreifen, läuft perfekt, sIcHeRhEiT ist auch genüge getan.
autostart im wsl2 (noch so ein randfeature, besonders wenn man das andere randfeature aka docker hochfahren will)? lool, gibts natürlich erst mit windows 11, davor einfach krampf in die .bashrc einfügen und dich schlecht fühlen.
not even once diese MVP scheisse.
e: um mal noch nen knacks reinzumachen, das "linux selbstadministriert" ist eiiiigentlich auch nicht so das gelbe vom ei.
ja, ich krieg das hin, ja ich mach das seit 20 jahren.
aber bei uns haben noch wesentlich mehr leute linux auf dem entwicklungspc und dann musste erstmal gesagt werden "ja, beim installieren wäre es schon wichtig gewesen dass du auf 'festplatte verschlüsseln' geklickt hättest" und so.
aber anstatt da einfach mal ne liste von kriterien aufzustellen auf die man sich einigt
- platte verschlüsselt
- alle updates werden zeitnah eingespielt
- keine services von aussen erreichbar, erst recht nicht mit standardpw
- backup kümmerst dich selber, nech?
wird einfach nichts gemacht.
auch nicht grandios aber nunja.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [KdM]MrDeath am 24.07.2022 20:42]
|
|
|
|
|
|
|
|
|
Docker Desktop für Mac ist aber auch... Nicht optimal.
Fast jedes minor Update (auf x.y.0) macht irgendwas kaputt. Ich warte schon immer auf die .1, bevor ich update.
Trotzdem ist das soviel besser, als jeden Scheiß direkt per Homebrew zu installieren und die Versionen abzugleichen.
Wir haben eine "Developer Setup" Anleitung, danach ist ein neuer Rechner bereit zum Entwickeln. Hauptsächlich besteht die Anleitung aus ein paar Kommandozeilen, die Quellen und Sjripte auschecken und diese dann ausführen...
|
|
|
|
|
|
|
|
| Thema: Software-Entwicklung 1 ( Nach log4j ist nichts mehr wie es war ) |
![[KDO2412]Mr.Jones](./avatare/mrjones2.gif)
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
