Jó napot kívánok mindenkinek.
Jelenleg a Python az egyik legelterjedtebb nyelv, amelyet nemcsak szoftvertermékek fejlesztésére, hanem azok infrastruktúrájának biztosítására is használnak. Ennek következtében sok DevOps mérnöknek, akaratán kívül vagy sem, meg kellett tanulnia egy új nyelvet, hogy aztán kiegészíthesse a régi, jól bevált Bash-scripteket. Ugyanakkor a Bash és a Python különböző megközelítéseket alkalmaz a kód írásában, és bizonyos sajátosságokkal rendelkeznek, ami miatt a Bash-scriptek "kígyónyelvre" való áttérítése néha egy összetett és nem triviális feladatnak bizonyulhat.
A DevOps mérnökök életének megkönnyítése érdekében sok hasznos Python könyvtárat és segédprogramot hoztak létre és továbbra is létrehoznak. Ez a cikk két új könyvtárat ír le, amelyeket a bejegyzés szerzője készített — és — és céljuk, hogy megszabadítsák a DevOps-okat attól, hogy sok figyelmet fordítsanak a Python működésének finomságaira, lehetőséget adva ehelyett érdekesebb feladatokra. A könyvtárak tevékenységi köre a környezeti változók és külső segédprogramok indítása.
Aki érdeklődik, kérem, kattintson ide.
Új „kerékpárok”?
Úgy tűnhet, miért lenne szükség új csomagok létrehozására a meglehetősen banális műveletekhez? Mi akadályoz meg abban, hogy közvetlenül az os.environ-t és a subprocess-t használjuk.?
Külön bizonyítékokat fogok hozni mindkét könyvtárra.
A smart-env könyvtár
Mielőtt megírnánk saját kreálmányunkat, érdemes az internetre nézni és kész megoldások után kutatni. Természetesen van kockázat, hogy nem találjuk meg a szükségeset, de ez inkább egy "biztosítási eset". Általában ez a megközelítés működik, és rengeteg időt és energiát takarít meg.
A Gartner 2016-os jelentése szerint sok cég virtualizáltsági szintje meghaladja a 75%-ot, a piac pedig 5,6 milliárd dollárra becsülhető. Azonban vannak bizonyos tényezők, amelyek gátolják a virtualizáció elterjedését. Az egyik legfontosabb ok a adatközpontok új munkamódszerre való "átszervezésének" nehézsége, mivel az erre fordított költségek gyakran meghaladják a potenciális hasznot. kiderült a következő:
- vannak csomagok, amelyek valóban burkolják az os.environ hívásait, de ezzel együtt sok zavaró lépést is igényelnek (osztálypéldány létrehozása, speciális paraméterek a hívásokban stb.);
- vannak jó csomagok, amelyek azonban szorosan egy adott ökoszisztémához kapcsolódnak (főként webes keretrendszerekhez, mint például a Django), és ezért nem univerzálisak;
- vannak ritka próbálkozások új dolgok létrehozására. Például: és egyértelműen elemzi a változók értékeit az alábbi metódushívásokkal:
get_(változó_neve)Vagy itt van , amely azonban nem támogatja a már elavult Python 2-t (aminél, annak ellenére, hogy , még mindig rengeteg írt kód és egész ökoszisztémák maradtak;
- vannak iskolai diákprojektek, amelyek a legkevésbé sem érthető okból a PyPI felsőbb szintjein szerepelnek, és csak problémákat okoznak az új csomagok elnevezésében (különösen a 'smart-env' név — szükségszerű megoldás).
Ezt a listát sokáig folytathatnánk. Azonban a fent említett pontok elegendőek voltak ahhoz, hogy izgalmat érezzünk egy kényelmes és univerzális dolog létrehozása iránt.
Azok az elvárások, amelyek a smart-env írásával szemben támasztva voltak:
- Maximálisan egyszerű használati séma
- Könnyen konfigurálható adat típustámogatás
- Kompatibilitás Python 2.7-tel
- Jó tesztelési lefedettség
Végül is mindez megvalósult. Íme egy példa a használatra:
from smart_env import ENV
print(ENV.HOME) # Egyenlő print(os.environ['HOME'])
# feltételezve, hogy beállította az env változót MYVAR "True"-ra
ENV.enable_automatic_type_cast()
my_var = ENV.MY_VAR # Egyenlő logikai True-val
ENV.NEW_VAR = 100 # Új környezeti változó beállítása
Ahogy a példa is mutatja, elegendő a új osztályt importálni (példányt létrehozni nem szükséges — ez felesleges lépés). Bármely környezeti változóhoz való hozzáférés osztályváltozóként való hivatkozással érhető el az ENV segítségével, ami gyakorlatilag intuitív módon burkolja az alapértelmezett rendszerkörnyezetet, miközben szinte bármely rendszer konfigurációs objektuma lehet (hasonló megközelítést, például, a Django éri el, ahol a konfigurációs objektum a settings modul van).
Az automatikus típuscasting támogatás bekapcsolása/kikapcsolása a enable_automatic_type_cast() és disable_automatic_type_cast() két metódus használatával történik. Ez kényelmes lehet, ha a környezeti változó egy sorosított JSON-szerű objektumot vagy éppen egy logikai konstansot tartalmaz (a DEBUG változó egyértelmű beállítása a Django-ban a környezeti változóval "megfelelő" sztringek összehasonlításával — az egyik gyakran előforduló eset). De most nincs szükség a sztringek egyértelmű konvertálására — a szükséges lépések nagy része már a könyvtár mélyén van, és csak arra vár, hogy jelet kapjon a cselekvésre. 🙂 Összességében a típusszabályozás átláthatóan működik, és szinte minden beépített adattípust támogat (a frozenset, complex és bytes nem volt tesztelve).
A Python 2 támogatás követelményei gyakorlatilag áldozatok nélkül valósultak meg (a typing elhagyása és a Python 3 legújabb verzióinak néhány "cukorkájának" elhagyása), különösen a mindenütt jelenlévő six-nek köszönhetően (metaklassz problémák megoldására).
De vannak némi korlátozások is:
- A Python 3 támogatása a 3.5-ös verziót és az annál frissebbeket jelenti (ha ezek nincsenek a projektedben, az vagy lustaság, vagy a fejlesztések iránti szükséglet hiánya, mivel nehéz lenne objektív indokot találni arra, hogy miért maradtál még mindig a 3.4-en);
- A Python 2.7 könyvtár nem támogatja a készletek literáljainak deszerializálását. Leírás . De ha valaki meg szeretné valósítani — szeretettel várjuk:);
A könyvtár egy kivételkezelési mechanizmust is alkalmaz a parsolási hibák esetére. Ha a sort egyik meglévő elemző sem tudja értelmezni, az érték szöveges marad (inkább a kényelmi és a hagyományos változók Bash-beli működésének visszafelé kompatibilitása miatt).
A python-shell könyvtár
Most a második könyvtárról mesélek (a meglévő analógok hátrányait nem részletezem — ez hasonló az smart-env leírásához. Analógok — és ).
Összességében az implementáció ötlete és a hozzá szükséges követelmények hasonlók a smart-env-ban leírtakhoz, amit a példa is mutat:
from python_shell import Shell
Shell.ls('-l', '$HOME') # Egyenlő: "ls -l $HOME"
command = Shell.whoami() # Egyenlő: "whoami"
print(command.output) # kiírja a jelenlegi felhasználó nevét
print(command.command) # kiírja: "whoami"
print(command.return_code) # kiírja: "0"
print(command.arguments) # kiírja: ""
Shell.mkdir('-p', '\/tmp\/new_folder') # új mappa létrehozása
Az ötlet a következő:
- Egy egységes osztály, amely a Bash-t képviseli a Python világában;
- Minden Bash-parancsot a Shell osztály metodusaként hívnak meg;
- A hívási paraméterek tovább kerülnek a megfelelő Bash-parancs meghívásába;
- Minden parancs "itt és most" végrehajtásra kerül a hívás pillanatában, azaz szinkron megközelítést alkalmaz;
- Hozzáférés van a parancs stdout kimenetéhez, valamint a visszatérési kódhoz;
- Ha a parancs hiányzik a rendszerből — kivétel keletkezik.
A smart-env esetéhez hasonlóan biztosított a Python 2 támogatása (bár kicsit több áldozatra volt szükség), és a Python 3.0-3.4 támogatása hiányzik.
A könyvtárak fejlesztési tervei
A könyvtárakat már most is használhatod: mindkettő elérhető az hivatalos PyPI-n. A forráskódok elérhetők a Github-on (lásd lent).
Mindkét könyvtár fejlődni fog a beérkező visszajelzések figyelembevételével. És ha a smart-env esetében talán nehéz új funkciók sokaságát kitalálni, akkor a python-shellben biztosan van még mit hozzáadni:
- nem blokkoló hívások támogatása;
- interaktív kommunikációs lehetőség a csapattal (stdin használatával);
- új tulajdonságok hozzáadása (például property a stderr-ből jövő kimenet megszerzésére);
- elérhető parancsok könyvtárának megvalósítása (a dir() funkció használatához);
- stb.
Hivatkozások
- A smart-env könyvtár: és
- A python-shell könyvtár: és
- a könyvtárak frissítései
UPD 2020.02.23:
* A repók áthelyezésre kerültek, a megfelelő linkek frissítve lettek
* A python-shell==1.0.1 verzió a 2020.02.29-i megjelenésre készül. A változások között szerepel a parancsok automatikus kiegészítése és a dir(Shell) parancs, Python-nal nem kompatibilis azonosítók indítása, hibák javítása.
Forrás: habr.com
