Python in LTS-omgevingen

[TheMak]

Is Python wel geschikt voor stabiele omgevingen? Ik werk samen met collega's in een server-omgeving met linux en java. Nu wil ik me verdiepen in Python. De vraag is nu of Python wel geschikt is in kritische omgevingen om daarmee tooling te ontwikkelen.

Ik zie dat de packages continue van versie veranderen. Het risico wat ik zie dat als twee developers tooling ontwikkelen, dat je dan krijgt, dat elk met zijn eigen versies gaat werken. Ik zie zelfs dat je met anaconda per project je eigen set van packages kan definiëren.

Het lijkt mij dat de package-management complex zal worden, dat daarmee python niet echt geschikt is voor omgevingen die blijven draaien als ik al weg ben. Klopt dat?

[Ramon]

Voor Python heb je pip, hiermee installeer je pakketjes en je legt de versies daarvan vast in een requirements.txt bestand waarmee je er dus voor zorgt dat je collega's dezelfde versies gebruiken, zie: https://pip.pypa.io/en/stable/user_guide/

[CH4OS]

Het package-/dependancies management maakt het juist gemakkelijker om dit te kunnen doen? Daarmee geef je juist aan welke versies van de packages en dependancies gebruikt wordt. Je habt dan dus juist altijd dezelfde versies onderling.

[sanderdw]

Containers/Docker/Kubernetes is the way to go. Van OS tot je uit te voeren programma definieer je in code en kan dus ook altijd opnieuw deployed worden.

[The Eagle]

sanderdw schreef op woensdag 7 juli 2021 @ 12:53:
Containers/Docker/Kubernetes is the way to go. Van OS tot je uit te voeren programma definieer je in code en kan dus ook altijd opnieuw deployed worden.

^^^ dat idd.

[Lethalis]

Specifiek voor Python:

https://pythonbasics.org/virtualenv/

Python by default installs modules system wide. That can become an issue if programs need different versions of the same module.

This is unlike other programming languages that don’t install modules system wide. Imagine two Python apps of which one needs libBar 1.0 and another libBar 2.0.

A virtualenv solves this problem cleverly by creating an isolated environment. Modules will only be installed inside the virtual environment. Inside your environment you can install any module without affecting the systemwide configuration

sanderdw schreef op woensdag 7 juli 2021 @ 12:53:
Containers/Docker/Kubernetes is the way to go. Van OS tot je uit te voeren programma definieer je in code en kan dus ook altijd opnieuw deployed worden.

En Docker kan inderdaad ook helpen.

[ Voor 42% gewijzigd door Lethalis op 07-07-2021 14:59 ]

[Lethalis]

TheMak schreef op woensdag 7 juli 2021 @ 11:39:
Is Python wel geschikt voor stabiele omgevingen?

Waarom wil je eigenlijk Python gebruiken?

Ik gebruik het zelf vooral voor scripting en voor het serieuzere werk blijf ik bij .NET. Java is natuurlijk ook prima.

Bij Java kun je ook kiezen uit een heleboel verschillende programmeertalen die op de JVM draaien. Bijvoorbeeld Kotlin voor als je iets moderners wil dan plain old Java.

[TheMak]

Waarom python: De reden is dat heel POC's (AI en andere moderne experimenten met data) in python geschreven worden. Dus ik wil er vertrouwd mee worden, maar ik ben ook op zoek naar een simpele use-case.

Ik wil kijken of Python gebruikt kan worden als alternatief voor bash-scripts.
Tot de machines hebben we eigenlijk alleen een terminal connectie beschikbaar. Maar de omgeving is nogal specifiek. Je kan er niet vanuit gaan dat ik system-wide access heb.

Ik weet niet of virtualisatie een oplossing is. of dat docker een oplossing is. Dan moet je de host up-to-date houden (security-patches), en alle dockers
(ik moet wel zeggen dat ik nog niet helemaal snap welk gedeelte van het OS binnen de docker valt, en welk gedeelte op de host).

[Kalentum]

Als het alleen maar gaat om het kunnen scheiden van dependencies dan is virtualenv the way to go. Docker op geen enkele manier nodig en verhoogt je complexiteit.

Wat virtualenv doet is geen virtualisatie maar veel simpeler: alle specifieke dependencies van je python project worden samen in 1 directory geplaatst en je python project zal als eerste in die specifieke directory gaan kijken.

Python heeft een omgevingsvariabele (PYTHONPATH) die bepaalt waar je libraries te vinden zijn en wat virtualenv doet is zorgen dat je project precies die specifieke libraries gebruikt.

Als je ermee wilt spelen kun je bv https://pypi.org/project/pipenv/ gebruiken, wat het werken met verschillende python environments wat makkelijker maakt.

[Morrar]

Als het om data science / ML aankomt denk ik niet dat er veel alternatieven zijn die kunnen tippen aan Python.

Veel is al gezegd; werk inderdaad met een virtuele omgeving per project zodat packages / dependencies netjes gescheiden blijven. Hiervoor is virtualenv een optie, maar bijvoorbeeld ook Anaconda. Binnen zo'n omgeving zet je alle versienummers vast zodat de stabiliteit gegarandeerd is.

Verder kan een tool als dependabot je helpen om verouderde dependencies te managen: https://dependabot.com/. Deze bot maakt een pull request aan als een oude versie wordt aangetroffen; dit kan dan je CI/CD pipeline triggeren inclusief tests, zodat je meteen weet of er compatibiliteitsproblemen optreden.

Je eigen code / packages kun je op soortgelijke manier managen. Gebruik ook tools als pre-commit / pylint / black / mypy om de kwaliteit van je code. Ook poetry is interessant als je vooral packages gaat ontwikkelen.

Tot slot zou ik nog goed kjiken naar de veiligheidsaspecten; de vraag is of je bijvoorbeeld met PyPI wilt werken of niet. PyPI is niet curated en zou dus malware kunnen bevatten - al grijpen ze wel in bij meldingen daarvan. Met Anaconda heb je een gecontroleerd ecosysteem, maar dat is wel beperkter qua omvang. Tot slot is er ook nog de mogelijkheid om zelf een PyPI of DevPI mirror op te zetten inclusief white- of blacklist, maar dat is meer werk.

Lang verhaal kort; life cycle management van Python is nog niet perfect, maar zeker wel redelijk volwassen en bruikbaar in productie omgevingen.

[Lethalis]

TheMak schreef op woensdag 7 juli 2021 @ 15:33:
Ik wil kijken of Python gebruikt kan worden als alternatief voor bash-scripts.

Ik weet niet of virtualisatie een oplossing is. of dat docker een oplossing is. Dan moet je de host up-to-date houden (security-patches), en alle dockers
(ik moet wel zeggen dat ik nog niet helemaal snap welk gedeelte van het OS binnen de docker valt, en welk gedeelte op de host).

Ik gebruik Python als alternatief voor BASH scripts Dus ja, het kan. Is het altijd even handig? Dat niet per se. BASH kan een stuk korter zijn, maar in Python is het makkelijker om een complexere logica toe te passen (mijn mening, maar ik ben dan ook niet geweldig met BASH).

Tip: er zijn ook andere shells die je misschien prettiger vindt om mee te werken!

Voor de rest: een host moet je - altijd - uptodate houden

Een "Docker container" is een fancy begrip voor een proces dat simpelweg met beperkte rechten in een chroot draait. Dus op dezelfde kernel als de host, maar een andere bestandsstructuur (het Docker image, gecombineerd met eventuele volumes die gemount zijn).

De beperkte rechten worden o.a. gerealiseerd door namespaces in de Linux kernel. Zo kun je in een beperkte PID namespace zitten, waardoor het proces niet of nauwelijks met andere processen kan communiceren. Enzovoorts.

Docker is simpelweg wat tooling die er omheen gebouwd is om die isolatie eenvoudig en vooral ook reproduceerbaar te maken. Je kunt heel eenvoudig zelf images maken op een eenduidige manier die overal op dezelfde manier werken. En met docker-compose kun je ze ook nog eens combineren met elkaar en zo een "stack" maken van containers die in hun eigen netwerk draaien etc.

Qua security is een eventuele pitfall dat mensen vergeten / verzuimen hun containers bij te werken. Of ze als root draaien

Het grote voordeel is dus dat je een standaard Debian image kunt pakken, Python (of wat dan ook) en de juiste dependencies kunt toevoegen, jouw programma kunt toevoegen en als main entrypoint markeren.

Vervolgens kan letterlijk elke willekeurige Docker host jouw image uitvoeren. Want het voert gewoon jouw programma uit met de omgeving die jij in het image hebt gemaakt, maar wel direct op de kernel van de host (= dus praktisch net zo snel, geen "virtualisatie", en net zo efficiënt want het verbruikt ook niet meer geheugen).

Door de chroot denkt het proces dat dit image alles is. Het ziet alleen de bestandsstructuur van het image, niet van de host.

En dit is dan dus ook overal hetzelfde (op eventuele volume mounts na voor data persistence). LXC containers werken op een soortgelijke manier, BSD jails ook (in FreeBSD kon je 20 jaar geleden al een jail maken als ik het mij goed herinner... maar "containers" klinken nou eenmaal hipper en de kracht zit hem vooral in de tooling er omheen).

Maar ook Snaps werken bijvoorbeeld volgens hetzelfde principe. Zodat je de nieuwste software inclusief dependencies op jouw kernel kunt draaien.

[ Voor 11% gewijzigd door Lethalis op 08-07-2021 00:06 ]

[boxlessness]

Bij mijn oude werkgever, en ook mijn nieuwe, word Python gebruikt voor inzet in POCs maar ook in productie omgevingen.
Python kent zeker nadelen wat betreft performance, maar de laagdrempeligheid ervan maakt dat ook niet hardcore software ontwikkelaars een bijdrage kunnen leveren aan het product in de vorm van code. Bijvoorbeeld data analisten en ML/algoritme ontwikkelaars.
De way of working is wel dat hun Python code geisoleerd wordt zodat deze niet zo maar overal aan kan en kritische onderdelen stuk kan maken. En vaak gaat er nog een slag overheen om te kijken of er edge cases zijn wat betreft input waardoor zaken in de soep kunnen lopen. Kwa code-quality zijn de eisen niet zo hoog als bij andere software ontwikkeling, en daarom zit dit soort code niet in het kritische pad en wordt het geisoleerd.

In de algemenere zin, is Python geschikt voor productie omgevingen? Jazeker! De taal en runtime zijn erg stabiel.
Er zijn regelmatig package updates, maar er is geen reden om ten allen tijden mee te blijven bewegen met de latest-and-greatest package versions afhankelijk hoe je code/runtime geisoleerd is.