[python/podman] Aanpak bouwen van container images

[c-nan]

Ik ben (hobbymatig) een applicatie aan het ontwikkelen in Python. Puur om mijn kennis op peil te houden en problemen op te lossen waar ik tegen aan ga lopen.

Ik heb 2 scripts (consumer.py en producer.py). Beide maken gebruik van een Class (in data_processor.py).
Beide scripts (consumer en producer) doen een import van config.py (waar in rabbitmq, mariadb, api, en andere credentials en variabelen in staan).

producer.py: haalt data op van een API (json) en stuurt dit door naar RabbitMQ.
consumer.py: haalt data op van RabbitMQ en zet dit in MariaDB.

Ik wil zowel de producer als de consumer als een container draaien. De producer zal 1x draaien, de consumer 3 of 4 keer naast elkaar.

Volgens mij zijn er 2 manieren hoe ik dit het beste kan aanpakken, namelijk:
1. Een base image maken (de base hiervoor is een python image). In deze image de data_processor.py en config.py opnemen. Vervolgens 2 nieuwe images maken welke als base deze gecreëerde image gebruiken, 1 image voor de producer en 1 image voor de consumer.

2. Van de Class (in data_processor.py) een module maken. Twee images maken (welke als base Python hebben), in de images dmv pip install <mijn module> de module installeren.

Nadeel van optie 1 is dat je bij iedere wijziging aan data_processor.py de base image opnieuw moet bakken om vervolgens de 2 andere images die hierop gebaseerd zijn ook opnieuw bakken.

Nadeel van optie is 2 misschien dat je aan versioning moet doen, de module steeds opnieuw moet bakken en je Containerfiles moet bijwerken.

Ik ben benieuwd naar jullie meningen/ervaringen/suggesties/tips. Dank

[itons]

Dit hangt natuurlijk vooral af van hoe snel consumer en producer onafhankelijk van elkaar evolueren.

Beetje duplicatie is over het algemeen niet erg, een aparte module met eigen lifecycle compliceert in het begin en klinkt zoals je het beschrijft als overkill op dit moment.

Waarom niet 1 codebase en 1 image, waarbij je een vlag meegeeft of er als consumer of provider gedraaid moet worden?

En natuurlijk wel netjes de credentials ed uit de environment oppakken en niet uit een config file die je meepackaged

[Shivs]

Beide hebben dus een nadeel dat je ontwikkelproces beinvloedt. Misschien is het handig om te kijken of je makkelijk één van de twee nadelen kan automatiseren waardoor je er geen last van hebt. Staat je code in een bepaalde Git oplossing die ook CI achtige contructies kent? Indien ja, dan kan je dus met CI de stappen voor het bouwen van de container image automatiseren of de stappen om je Python module te maken.

[c-nan]

itons schreef op woensdag 2 augustus 2023 @ 20:07:
Dit hangt natuurlijk vooral af van hoe snel consumer en producer onafhankelijk van elkaar evolueren.

Beetje duplicatie is over het algemeen niet erg, een aparte module met eigen lifecycle compliceert in het begin en klinkt zoals je het beschrijft als overkill op dit moment.

Waarom niet 1 codebase en 1 image, waarbij je een vlag meegeeft of er als consumer of provider gedraaid moet worden?

En natuurlijk wel netjes de credentials ed uit de environment oppakken en niet uit een config file die je meepackaged

Omdat dat te simpel is het is een hobby project, ik wil niet voor de makkelijke weg kiezen. Maar als dat overduidelijk wel de beste weg is, ja dan wel uiteraard. Maar in dit geval twijfelde ik

Shivs schreef op donderdag 3 augustus 2023 @ 11:15:
Beide hebben dus een nadeel dat je ontwikkelproces beinvloedt. Misschien is het handig om te kijken of je makkelijk één van de twee nadelen kan automatiseren waardoor je er geen last van hebt. Staat je code in een bepaalde Git oplossing die ook CI achtige contructies kent? Indien ja, dan kan je dus met CI de stappen voor het bouwen van de container image automatiseren of de stappen om je Python module te maken.

Nu nog alles lokaal, maar uiteraard ga ik het bijhouden in een repository. Sowieso ga ik het e.e.a. automatiseren met GitHub Actions. Maar ik ben meer op zoek naar hoe anderen het zouden doen, en waarom dan.

[Kalentum]

Wat @itons zegt.

Ik denk dat ik zo ongeveer hetzelfde doe als jij. Ik lees lokaal een zonnepanelenomvormer uit, die data gaat naar een MQTT server, een andere server leest die data dan weer uit en slaat het op in een database. En dan heb ik nog een script die de data nabewerkt.

Ik heb een server waar 1 container opdraait (het uitlezen van de omvormer) en een server waar 4 containers opdraaien. En die gebruiken allemaal dezelfde image. Dat werkt prima. Er is 1 git repository. Geen geautomatiseerde builds ofzo, voor die paar keer per jaar dat ik iets wijzig vind ik dat de moeite niet.

[itons]

Als je deze oefening voor het fingerspitzengefühl wil doen, implanteer voor de grap eens alle twee? En hang het vooral in CI.

Optie 1 is m.i. complexer en tijdrovender. Meerdere images bouwen, downstream images updaten als het base image een nieuwe versie krijgt e.d.

Bij optie 2 kan je pip gebruiken waar het voor gemaakt is (dependencies binnen harken), simpele pipeline, etc.

In de praktijk zijn er veel meer variabelen om rekening mee te houden, zoals genoemd hoe snel veranderen de individuele componenten, welk team heeft ze in beheer, kosten aspecten van build time en opslag etc. Beide oplossingen die je aandraagt kunnen werken, maar voor welke aspecten wil je optimaliseren?

[ Voor 7% gewijzigd door itons op 03-08-2023 16:35 ]

[Tarquin]

Als je de code nog moet ontwikkelen, kun je dan niet sneller een image maken die de code draait, maar de code uit een directory buiten de container laten komen? Dus gewoon een deel van het pad binnen de container mounten op een directory die erbuiten staat.