|
|
|
|
|
|
|
Fest anschnallen! Kleiner Ausschnitt:
Wir haben hier zwei NGINX auf OpenBSD, dahinter zwei Linux mit Apache und dahinter viele Anwendungsserver mit Linux. Dazwischen einen einzigen Windowsserver der überall drauf darf. Unser ehemaliger RZ-Chef war NGINX-Fanboy, weil y**p***(sic!) damit läuft.
Immerhin, Standardprotokolle! Alles arbeitet damit zusammen in einer heterogenen Umgebung. Die Begründung mit y**p*** hätte ich mir jetzt nicht zu eigen gemacht, aber immerhin eine Begründung.
PS: Oli erklärt dir Welt besser 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 28.07.2018 22:46]
|
|
|
|
|
|
|
|
|
<I don't always nginx>
<But when I do it just ingresses traffic into my kubernetes clusters>
|
|
|
|
|
|
|
|
|
|
|
Ich habe Traefik. Grüsse aus der Wolke. Lol.
¤: Ja genau, ich schaue nach wie man das schreibt, und Rufus bringt den gleichen Rofl.
¤: Wir messen nebst AWS etc aber tatsächlich auch gegen die gängigen Pornolösungen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 28.07.2018 22:44]
|
|
|
|
|
|
|
|
|
Pornolösungen
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Ich habe Traefik. Grüsse aus der Wolke. Lol.
| |
Yeah, traefik nehmen wir für aktuelle Cluster auch. Aber die """legacy""" Cluster bleiben halt auf nginx-ingress. Grüße zurück, lol.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wo hostet ihr denn so? Wir wollen eigentlich inhouse auf VMware/Openstack/whatever bleiben, aber die Infrastruktur-Boys kommen da nicht hinterher. Für GCE/GKE sind wir zu geizig, also scheißen wir derzeit alles nach Digitalocean..
// 5 edits später bekomme ich am potdroid immer noch kein shrug-emoji hin. Bitte dazudenken.
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von Rufus am 28.07.2018 23:42]
|
|
|
|
|
|
|
|
|
|
"Wir" ist ziemlich breit gefächert, aber meine Berührungspunkte sind AWS, internes Openshift, und unsere "legacy" Apache/Nginx/Liberty/DB2 etc. pp. Meine Applikationen nehmen aktuell so etwa den Weg AWS (Gitlab CI), Openshift (CD) und dann auf letzteres. Und dann halt noch der NDA SACHEN Kram. Die OSS Sachen machen Travis -> Jenkins -> Legacy. Unsere neuen Applikationen sind damit wirklich richtig aufgeräumt und entkoppelt. Ich entwickle inzwischen richtig gerne mit Docker, Kubernetes und dem Kram, weil es mich als Entwickler mit einigermassen Infrastrukturverständnis wirklich entlastet. Für die alten Sachen ist Crap halt immernoch Crap. Plan ist die Legacyarchitektur "bald" auch auf AWS zu schieben. Geld spielt aber halt quasi keine Rolle, jedenfalls nicht übergeordnet.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Ich entwickle inzwischen richtig gerne mit Docker, Kubernetes und dem Kram, weil es mich als Entwickler mit einigermassen Infrastrukturverständnis wirklich entlastet.
| |
Seelenbalsam für mich, das von einem Dev zu lesen.
Ich wurde ja die Tage von einem Entwickler relativ laut angeschrien. Er deployed zwar (gezwungernermaßen) seinen Shit mittlerweile in den ihm bekannten staging-Namespace, aber der Hinweis, dass sich dieser Namespace in einem falschen Cluster befindet, war dann zuviel für seine Geduld. 
Zitat "Soll ich mir jetzt auch noch Cluster-IPs [sic] merken oder was?!".
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 29.07.2018 1:08]
|
|
|
|
|
|
|
|
|
Ich finde es irgendwie fahrlässig, nichts von den Systemen zu verstehen, von und für die man entwickelt. Wir sind weit davon entfernt (und ich bezweifle ehrlichgesagt irgendwie, dass das tatsächlich passiert), genug zu abstrahieren, dass man davon gar nichts verstehen muss. Auch ein 'Cloud' Deployment muss danach irgendwo laufen, und natürlich machen Container die konfiguration deutlich einfacher, aber ich sehe das eher als Chance für mich, überhaupt genug Einblick in die Konfiguration zu haben, um sie verstehen zu können, und nicht, sie komplett ausser Acht zu lassen. Ich bin sicher weit davon entfernt, davon wirklich genug zu verstehen, und schon sicher nicht in der nähe der Ops Leute, aber mich frustrieren auch andere Entwickler, die von 20 Zeilen docker-compose schon überfordert sind. Ich habe dann zum Beispiel auch das ganze Travis Jenkins Deploy Zeug selber aufgesetzt, einfach um das auch mal in der Hand gehabt zu haben. Klar kommt dabei bestimmt nichts wirklich perfektes raus, aber es hilft mir beim Verständnis. Und ich kann halt wirklich nicht nachvollziehen, dass man null Initiative dabei zeigt, wenigstens seine eigene Entwicklungsumgebung zu verstehen. "Ich schreibe ja nur Code, Datenbanken und Installationen sind unwichtig". Pf. Fick dich doch. Aber dann wundern wenn es andere können und mit der Antwort "selber beigebracht" nicht zufrieden sein.
TL;DR: Ich kann dich da voll verstehen.
¤: Und ja, mir ist schon klar, dass ich mit meinem Infrastruktur und Webzeug nah genug dran bin, dass sich viele Themen überschneiden, und es wahrscheinlich einfacher zu verstehen ist, als für Embeddedentwickler. Aber das musste ich mir ja trotzdem auch selber aneigenen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 29.07.2018 12:00]
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
TL;DR: Ich kann dich da voll verstehen.
| |
thx 
noch was anneres: Wo kann ich auf einem Debian/Ubuntu denn prüfen, ob (dpkg|apt(-get)?) confold per default hat, sprich geänderte conffiles bei Updates sicher nicht anfasst?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 29.07.2018 15:50]
|
|
|
|
|
|
|
|
|
ist eine dpkg-Option, also schaust du, ob in /etc/dpkg/dpkg.cfg oder /etc/dpkg/dpkg.cfg.d/* ein "force-confold" steht
leider kann apt das auch überschreiben, da müsstest du in /etc/apt/apt.conf oder /etc/apt/apt.conf.d/* nach Zeilen wie Dpkg::Options {"--force-confnew";} suchen oder apt-config dump befragen
eine einzelne Stelle zum Nachgucken gibt es soweit ich weiß nicht
|
|
|
|
|
|
|
|
|
|
|
|
Hat heute irgendein Peer mal wieder Verstopfung? Etliche US-basierte Seiten sind heute sehr, sehr langsam via DTAG.
|
|
|
|
|
|
|
|
|
|
|
oha luks2 ist raus, das ging ja völlig an mir vorbei.
bei den features werd ich ja ganz wuschig, mal schauen wie sich das alles so nutzen lässt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von red
ist eine dpkg-Option, also schaust du, ob in /etc/dpkg/dpkg.cfg oder /etc/dpkg/dpkg.cfg.d/* ein "force-confold" steht
leider kann apt das auch überschreiben, da müsstest du in /etc/apt/apt.conf oder /etc/apt/apt.conf.d/* nach Zeilen wie Dpkg::Options {"--force-confnew";} suchen oder apt-config dump befragen
eine einzelne Stelle zum Nachgucken gibt es soweit ich weiß nicht
| |
Da ist nirgends was explizit angegeben. Wie finde ich raus, was der default behaviour ist?
|
|
|
|
|
|
|
|
|
|
|
|
default behavior sollte doch eigentlich sein dich zu fragen wenn ne interaktive shell da ist.
|
|
|
|
|
|
|
|
|
|
|
Behaupte ich auch. Und was, wenn keine da ist?
Ich würde das Verhalten eben gern mal irgendwo definiert sehen. Dokumentiert ist es einfach nirgends, und gegen den Sourcecode von dpkg habe ich keine Chance.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 30.07.2018 0:45]
|
|
|
|
|
|
|
|
|
|
hmmmm, müsste man wohl ausprobieren. was ich grade so finde ist dass er die frage stellt, egal ob ne eingabemöglichkeit da ist oder nicht. erinner mich glaube ich vage dran das wir das auch mal hatten als problem.
|
|
|
|
|
|
|
|
|
|
|
|
Auch wenn man explizit DEBIAN_FRONTEND=noninteractive setzt?
|
|
|
|
|
|
|
|
|
|
|
|
=> OpenVPN ist also auch aus Admin-Sicht eher belastende Software.
|
|
|
|
|
|
|
|
|
|
|
Hm, hat jemand von euch längerfristig mal was mit go gemacht?
Vor einem Jahr mal beruflich ein go Projekt gehackt, und nu seit 3 Monaten in einer go Butze am arbeiten. Aber iwie versteh ich den Hype nicht so.
90% der Zeit verbringste mit if err != nil { return err }, control c control v und boilerplate schreiben weil du keine Macros/Templates/Generics/void* hast und Abstraktionen ja verpöhnt sind.
Aber Generics brauchste ja nicht. Wofür ne generische Liste. Kannst doch einfach eine Map nehmen und als value einfach ein leeres Struct.
Außer natürlich du willst auch nur ein Millimeter mehr. Dann gtfo. Oder schreib doch ein Code Generator. Weil wir sind gegen Complexity. Und was ist weniger Komplex als ein AST zu parsen und daraus passenden Code zu generieren?
Und Channels nutze eigentlich nur als "stopChannel" um dat eine bit zu flippen was deine for foo == true loop terminiert. Und da wäre n atomarer replace eigentlich geiler.
Meine Erfahrung mit go ist bisher echt stark ernüchternd :(
Go wäre cool für funktionales Actor Voodoo, zumindest so von der Nebenläufigkeit und Channel Magie her.
Aber defakto wird es als "Die Sprache für Microservices" verkauft.
Und iwie frag ich mich da - wtf? Für deine 10 Zeilen Business Logic brauchste 15 Zeilen um dein http request manuell zu deserialisieren, für deine fancy nosql datenbank (die ACID mit Füßen tritt, btw.) bauste dir deine drölfhundert Objekte zusammen (weil DSLs wie SQL sind out und ORMs sind nicht produktiv) jagst sie durch den json marshaller und schickst sie an ein anderen Service. Falls du retro genug bist haste auch ne SQL Datenbank die du per string Konstanten queriest.
Sorry, aber, tbh, istn Java oder C# für Microservices nicht tausend mal geiler?
Serialisierung, Persistierung, etc. wird einfach so schön abstrahiert dass du zu 90% nur noch deine Business Logik hackst.
Ich verstehs nich.
Golang, Prometheus, Cloud Native. Uh uh uh.
¯\_(ツ)_/¯
|
|
|
|
|
|
|
|
|
|
|
|
die meisten der Hype-Sprachen erfinden das Rad doch eh nicht wirklich neu. Nichts gegen neue Konzepte und gute Ideen, aber die bauen die großen halt in 3 Jahren in c# und Java ein und dann kann man den Kram auch produktiv nutzen. Zwar nur halb so schnell in der Runtime, aber who cares.
|
|
|
|
|
|
|
|
|
|
|
Langfristig? Nein. Aber ich habe ein kleines Buildtool in Go geschrieben. Es wäre wahrscheinlich Java (wollte ich nicht) oder C (kann ich nicht mehr) geworden. Also habe ich Go genommen. Warum? Crosscompile, Systemunabhängig, Abstraktion passt. Ich war nach 2 Tagen fertig. Die Sprache ist... okay. Für Web würde ich Java nehmen, weil ich das kann. C# liegt mir, weil ich das mag. Aber ich finde schon, das Go eine Niche hat. Da, wo du kein Framework willst/hast, oder da, wo du gerne einfaches C hättest, aber keinen Bock hast. Wenn du Java/C# auffährst, hast du halt die ganze Runtime, den ganzen Build, alles muss gemacht werden... oder du hast go install.
Ich will das wirklich nicht gutreden. Aber wenn du eine Umgebung hast, wo du einfach ein Executable mit buildstep reinwerfen kannst, dann ist das halt schon geil. Kein Aufwand, dein Service ist da, bäm. Aber Go ist schon eher ein Nichenprodukt als andere Sprachen, das stimmt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
die meisten der Hype-Sprachen erfinden das Rad doch eh nicht wirklich neu. Nichts gegen neue Konzepte und gute Ideen, aber die bauen die großen halt in 3 Jahren in c# und Java ein und dann kann man den Kram auch produktiv nutzen. Zwar nur halb so schnell in der Runtime, aber who cares.
| |
Eher: C# 1 Jahr, Java 15.
Das ist wirklich so mein grösster Hass, und auch warum ich C# so viel lieber mag. Die Leute hinter C# treten richtig auf's Gaspedal, wohingegen Java konservativer als meine Urgrosseltern ist. Irgendwann muss man auch mit der Rückwärtskompatibilität brechen. Ein schöner Fehler, den C++ auch macht.
¤: Die Lanze für Go möchte ich trotzdem noch brechen. Das Concurrencymodell, alt wie es sein mag, ist wirklich sauber. Nicht unbedingt allgemeingültig, aber für den high-level System/Web/Server Anwendungsbereicht wirklich grandios. Wenn auch single-purpose.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 30.07.2018 21:58]
|
|
|
|
|
|
|
|
|
Ich denke "Wenn du eigentlich C nehmen würdest, aber halt keinen Bock auf C hast" trifft es ziemlich gut, wofür Go brauchbar ist (ohne das jetzt selber mal benutzt zu haben ['fus: hier shrug emoji einfügen, A.d.A.]). Da fallen halt Binaries raus, die im Grunde überall laufen, nichtmal libc-Abhängigkeiten. Letzters dürfte primär Linux geschuldet sein, weil da halt libc-Abhängigkeit bedeutet, dass deine Binary nicht mehr zwischen Distributionen und sogar Versionen selbiger portabel ist (was so ähnlich auch für Windows gilt, keine Ahnung, wie das bei OSX aussieht). Dagegen ist das Syscall-Interface vom Linux-Kernel sehr stabil. (Ein technischer Grund liegt wiederrum im Concurrency-Modell von Go, was es relativ teuer macht FFI zu tun, weil ein Go-"Thread" normalerweise keinen fetten C-Stack unterhält.) Der Nachteil liegt natürlich auf der Hand, Linux ist ein Einzelfall was Syscall-API angeht, die meisten anderen Systeme (inkl. BSDs, OSX, Windows) haben keine stabilen Syscalls und eine .so/.dll vom System ist das stabile Interface - C-only. Klar, Syscalls ändern sich jetzt trotzdem nicht allzu häufig, aber afaik gab es da schon mehrmals Breakage auf OSX.
Für das kleine Skript oder Tool zwischendurch nehme ich halt meistens einfach Python, weil das für mich funktioniert. Irgendwelche #yolo-REST-APIs in Go zu bauen, liegt mir ungefähr so fern wie selbiges in Rust oder C++ zu tun.
(Oder mit dem BCHS-Stack: BSD, C, httpd, SQLite, der inzwischen nichtmal mehr ein "Witz" ist, sondern das wird wohl teilweise tatsächlich so praktiziert. Allerdings traue ich auch nur den Leuten einiger BSDs zu beim ersten Versuch einen String in C zu parsen, ohne Gliedmaßen zu verlieren. Für uns Normalidioten ist das, so dünkelt mir, keine gute Idee.
Ich persönlich vermisse ja so ein bisschen die Tage, als Dinge noch auf Rechnern mit 256 MB RAM laufen konnten. Heute machst du ja Python an und es nommt sich direkt 40 MB weg. Lädst nen Webframework, egal welches (klar, manche sind fetter *Django hust*, manche nicht so speckig *Pyramid Flask hust*), liegst meistens schon bei 80-100 MB. Ich hätte gern mal so ein Python-but-simpler. Früher dachte ich, dass Lua das für mich sein könnte, aber trotz interessanter Runtimes und Konzepte bin ich in vielen Versuchen nie wirklich mit der Sprache warm geworden.
Ich seh das ja gerade an dem Laptop vor dem ich sitze. 2 GB RAM, minimaler Desktop (i3+i3pystatus), Firefox mit ner handvoll Tabs offen, zack, 1.5 GB RAM voll. Früher(tm) hatte ich 512 MB RAM in meinen Laptop und habe gleichzeitig Oblivion am Laufen gehabt und im Hintergrund noch Firefox mit den Cheat-Tabellen offen, und da ist nix abgestürzt. Klar, die Sau wurde heiß wie nix gutes, der Lüfter hatte ziemlich früh nen Lagerschaden und war richtig fies laut und ich hab später ne externe Tastatur benutzt, weil die Ballenauflage zu heiß wurde, um sie zu benutzen, aber es ging. Es lief. Langsam. Mit 20 fps auf 640x480. Die Quests waren ja wichtig, nicht die Grafik. 1280x800, nativ, gingen sogar auch, aber die 3-4 fps fand ich nicht so angenehm. Und es war Sommer. Boar. Hab das die ganzen Sommerferien gespielt in meinem aufgeheizten Zimmer. War geil. Über die aktuelle Hitzewelle kann ich nichts so positives sagen, außer, dass ich die Fluffigkeit meines Skrotums bei der Wärme schätze. Aber das ist jetzt irgendwie auch nur ein schwacher Trost. Äh, ich schweife ab...)
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 30.07.2018 22:22]
|
|
|
|
|
|
|
|
|
Gute Zusammenfassung. Python wollte ich noch erwähnen, weil das wegen der Binaries nogo ist, das wäre nämlich sonst die Alternative. Ansonsten direkt aus meinem Mund.
¤: Das habe ich vor den Edits gepostet und werde mich nochmals darauf beziehen. Wobei ich trotzdem sehr einverstanden bin.
¤: Ich bin zu faul. Weitermachen.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von SwissBushIndian am 31.07.2018 9:07]
|
|
|
|
|
|
|
|
|
|
Ich denke Rückwärtskompatiblität ist kein Fehler, sondern ein Stärke. Nach ein paar Jahren etabliert sich eine Sprache mit den neuen Features (oder eben nicht) und dann ist Verlässlichkeit wichtig. Das Kunststück ist dann, mit Bedacht neue Features einzubauen. Womöglich hätte C++ deutlich früher mit nebenläufiger Programmierung nachlegen müssen und den Smart Pointern. Jedenfalls hätte ich mir das gewünscht und vielleicht auch Swiss. Ich bin ja mal gespannt, wie sich Rust entwickelt.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 31.07.2018 11:47]
|
|
|
|
|
|
|
|
|
|
C++ ist einfach zu einem royalen Clusterfuck geworden. Ich bin immer wieder froh, wenn ich es nicht nutzen muss.
|
|
|
|
|
|
|
|
|
|
|
Ich finde das Problem an C++ ist, dass man sich die Rückwärtskompatibilität im Grunde nur einredet. "Moderner" C++ Code siehr völlig anders aus, hat völlig andern Kontrollfluss und folgt völlig anderen Paradigmen. Ja, man kann ihn zusammen mit älterem Code in den selben Compiler werfen, aber bringt das wirklich irgendwas vergleichen mit sinnvollen Bindings in eine andere Sprache?
Im Gegenzug erkauft man sich das gute alte Problem, dass es für das selbe Problem zig Lösungen gibt und dass völlig unklar ist, was gut und was schlecht ist. Speziell bei C++ äußert sich das gerne in völlig kaputter (und verboser) Syntax, bei der aus Rückwärtskompatibilitätsgründen die einfachere Syntax der falsche Weg ist (Kopie, Kopie, Kopie) und die Sprachdesigner völlig verrückte Verränkungen machen müssen, die keiner mehr versteht.
|
|
|
|
|
|
|
|
|
|
|
|
Genau das. Vor allem X Wege nach Rom.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
