Megosztás:

Leltárak használata az eszközök kezeléséhez és a duplikációk megelőzéséhez

A szervezet növekedésével párhuzamosan a nyomon követendő dolgok mennyisége is nő. A szervezetek gyakran duplikálják a belső erőfeszítéseket, mert a csapatok nem tudnak egymás projektjeiről. Amikor az emberek a csapatok között mozognak, új személyek csatlakoznak a vállalathoz, és mások távoznak, a projektek árvává válhatnak. A készletek segítenek megoldani ezeket a problémákat, és a platformfejlesztés kulcsfontosságú részét képezik.

A leltár olyan eszköz vagy rendszer, amelyet a szervezet technikai eszközeinek nyomon követésére, kezelésére és rendszerezésére használ. Ezek az eszközök többek között kódokat, API-kat, tárolókat, virtuális gépeket (virtuális gépeket), csapatengedélyeket és egyebeket tartalmaznak.

Ha nem követi nyomon az eszközöket, akkor technikai szórásokat és hulladékot hoz létre, mert nem tudja könnyen felderíteni a már létező elemeket. A már létezők számának elvesztése gyakori kihívás.

Rengeteg tárolót vagy [VM] példányt futtatunk. Törölhetjük a régi virtuális gépeinket? Senki sem tudja. Ki kell találnunk egy módot a régi dolgok megtisztítására és a megfelelő címkék használatára, hogy tudjuk, ki a tulajdonos vagy csapat, aki tájékoztathat minket arról, hogy mit tehetünk, és mi az életciklus.... Nem tudjuk, hogy le tudunk-e állítani egy adott virtuális gépet, mert nem tudjuk biztosan, hogy mi fog történni. - Martin, DevOps mérnök, nagy logisztikai vállalat

Eszközök nyomon követése

Szüksége van egy leltárra az ökoszisztémában létrehozott vagy beépített összes eszköz nyomon követéséhez. A belső ügyfelek érthető módon vizualizálhatják a leltárt.

A leltár javíthatja a biztonságot, előléptetheti az újrafelhasználást, és általában egyszerűbbé teheti a felderítést. Különböző eszközök érhetők el a különböző típusú eszközök nyomon követéséhez. Ezek az eszközök készletet biztosítanak a hulladék kezeléséhez, nyomon követéséhez és tisztításához.

Az elérhető nyomkövetési eszközök a következők:

  • Az Azure Deployment Environments lehetővé teszi, hogy nyomon kövesse az infrastruktúra mint kód (IaC) segítségével létrehozott összetett infrastruktúrát absztrakt környezetként.
  • Az Azure API Center lehetővé teszi a fejlesztők számára az API-k felderítését és használatát.
  • Az olyan csomagregisztrációs adatbázisok, mint a GitHub Packages vagy az Azure Artifacts (vagy a jóváhagyott csomagok és SDK-k egyéb készletei) javítják az ellátási lánc biztonságát.

A leltárak megtekintéséhez vegye figyelembe a szervezet számára legjobb módszert. Egyes szervezetek lehetővé teszik, hogy minden fejlesztő megtekintse a szoftvereszközöket, míg csak néhánynak van engedélye a módosításukra. Ez az átláthatóság első megközelítése, amelyet néha "nyitott konyha" modellnek is neveznek (ahol minden látható, például egy étterem konyhája, amelybe az ügyfelek betekintést láthatnak), elősegíti a tudatosságot és az együttműködést. Mások, különösen a szabályozott iparágakban, szigorúbban korlátozzák a hozzáférést, néha még a projektnevek láthatóságát is korlátozza a bizalmasság miatt.

A felderíthetőség, a szabályozás és az újrafelhasználás javítása

Egy vagy több leltárrendszer használata, amelyek segítenek nyomon követni a készleteidet, kritikus fontosságú a platformmérnöki gyakorlatokhoz és a technikai szétaprózódás elkerüléséhez. Eleinte elég lehet, ha egy egyszerű készletlistával rendelkezik. A felderíthetőséget azonban tovább javíthatja, ha több leltárban lévő különböző eszközök közötti kapcsolatokat ad hozzá. A szükséges láthatósági szinttől függetlenül a központosított összesítési ponttal a csapatok gyorsan kereshetnek és felderíthetik a számukra elérhető összes eszközt. Ez a megközelítés elősegíti az újrafelhasználást, csökkenti a redundanciát, és konzisztens szabályozási megközelítést hoz létre.

Fontolja meg az API-definíció és az interfészt implementáló üzembe helyezett alkalmazáskód közötti kapcsolatot. Ezt a kódot egy adattárban tárolja a rendszer, és egy csapat felügyeli. Dokumentációt nyújt a használatáról. Fejlesztési, tesztelési, éles környezetek és akár ideiglenes sandbox környezetek is létrejönnek. Natív felhőbeli forgatókönyvekben előfordulhat, hogy a környezetek egy megosztott Kubernetes-fürtön lesznek üzembe helyezve. Az API-t fejlesztő fejlesztői csapatnak és annak belső felhasználóinak képesnek kell lenniük arra, hogy információkat szerezzenek ezekről a dolgokról, de az erőforrások kapcsolatának nem egyértelmű.

Először is használhat egy olyan egyszerű wikilapot, amellyel nyomon követheti, hogyan viszonyulnak egymáshoz az egyes dolgok. De a dokumentáció gyorsan öregszik, és nehéz lehet megtalálni és elemezni is. Ideális esetben egy kapcsolati gráffal rendelkező rendszerrel rendelkezne, amely lehetővé teszi a felhasználói felületek számára, hogy a leltárban lévő kapcsolatokon keresztül navigáljanak. A felderíthetőség javítása érdekében képesnek kell lennie arra, hogy több típusú leltárban vagy gráfban tárolt dolgokat társítson egymáshoz. Előfordulhat, hogy nem kell közvetlenül leltárkészleteket használnia, de feltehetően egy API-katalógusrendszer információival szeretné összekapcsolni.

A digitális tár hasonlatának használatához hasznos lehet a katalógus elemeit (sablonjait) az eredményként kapott készlettartalommal társítani. Ha például rájön, hogy az egyik sablon nem biztonságos konfigurációt hoz létre, gyorsan meg kell találnia a sablonnal létrehozott összes erőforrást a javításukhoz. A megfelelő alkalmazássablonok kezdőcsomagok ebben a katalógusban, amelyek más típusú katalóguselemekhez (például IaC-sablonokhoz) kapcsolódnak. Ezeknek a társításoknak a nyomon követésével proaktívan megkeresheti azokat az alkalmazásokat, amelyek rossz IaC-sablonra hivatkoznak, még akkor is, ha még nincs kiépítve infrastruktúra.

Ennek a fogalmi, magas szintű fejlesztői platformdiagramnak egy egyszerűsített változata ma is megtalálható néhány eszközkészletben és termékben, bár különböző neveken ismert. A nyílt forráskódú portál eszközkészlete például Backstage.io szoftverkatalógusnak hívja, míg más termékek más kifejezéseket használnak. A legtöbb ilyen termék és eszközkészlet azonban feltételezi, hogy a szélesebb körű funkciókészletet használja, és megköveteli, hogy a készletek tartalma duplikálva legyen bennük. Ez a duplikáció azt jelenti, hogy a katalógusadatbázis tartalma nem felhasználóspecifikus, elavulttá válhat, és nem a tényleges forrásrendszer felhasználói engedélyezési mechanizmusai vezérlik. Ez azonban a szervezet számára is jól működik, ha egy átláthatósági megközelítést követ, amelyben minden fejlesztő megtekintheti az objektumokat.

Kapcsolódó tartalom

  • Last updated on