Ugrás a fő tartalomra

#DevNet serial - Episode I

#DevNet serial - Episode I

A világ folyamatosan változik. Új technológiai trendek jelennek meg szinte évről-évre. Ebben a folyamatosan változó inhomogén valóságban, egy mérnöknek meg kell találni azt a stabil pontot, ami meghatározza majd az elkövetkezendő évek műszaki megoldásait, hiszen csak így lehet megfelelő tervet készíteni, ami jövőtálló, jól skálázható, redundáns és automatizálható.
Ebben sokszor segítő társként vannak jelen a gyártók, hiszen biztosítják azt a erőforrás-készletet amellyel, egy műszaki-szaki fel tud készülni a technológiai változásra.
A Cisco általában élen jár a technológiai trendek evangelizációjában, De miért is képes erre? A recept nagyon egyszerű:
  • tanítsd meg az embereket az alapokra saját rendszereden
  • érd el náluk, hogy a legjobbnak érezzék magukat a szakterületükön
  • alakíts ki technológiai kötödést az emberekkel 

Hálózati technológiák terén többek között ezért tud sikeres lenni a gyártó hiszen, minden többszörösen aranyeres CCIE mérnök egy katona a hadseregben, aki kizárólag a legjobb fegyverekkel akar/képes harcolni, így sokszor élből utasít el minden mást.
Most egy új területet igyekszik meghódítani a San Francisco-i cég, még hozzá hardver mellé most már komplex szoftvereket és szoftver előfizetéseket is biztosít.
Ezeknek a szoftvereknek az automatizált/orchesztrált programozására, használatára tanít minket a #DevNet témakör, amely nem csak egy DEVOPS-hoz hasonló szemlélet és nem csak egy új minősítés, hanem egy unikális közösség.
Egyedisége a hálózati szakterületek és a szoftverfejlesztői képességek ötvözéséből fakad.
De kit akarnak megszólitani?
Téged!


Témakör

DevNet témakör alapvetően 2 mérnök típust szólít meg:
  • Hálózati rendszermérnökök, akiknek van affinitásuk a programozásra
  • Programozók, akiknek van affinitásuk hálózat automatizáció témakörére
Mondanom sem kell, hogy SDN témakörében jól látható, hogy a hálózat automatizáció, és programozhatóság egyre kiemeltebb szerephez jut. Ennek a legegyszerűbb oka pedig nem más mint a pénz.
Egy jól működő vállalatnál az üzlet egyre inkább az IT megoldásokra támaszkodik, amelynek egyik alappillére, a biztonságos, skálázható, stabil hálózat. A biztonság és a skálázhatóság érdekében viszont egyre bonyolultabb rendszereket alkotunk meg, melyek nem megfelelő kompetencia esetén instabillá válnak, így fontos, hogy egyre kevesebb emberi beavatkozást igénylő architektúrát alkossunk meg, hiszen a legkevésbé jól skálázható erőforrás a szakértelem, ami nélkül ezek a rendszerek nem üzemelhetnek.
 
A megfelelő szakértelemmel rendelkező emberek rutin feladatokkal eltöltött idejét csökkentjük, akkor a bonyolultabb, üzleti szempontból kritikus feladatok végrehajtására tudjuk koncentrálni az erőforrásainkat. Ha az IT hatékonyan tudja szolgálni az üzleti igényeket, akkor pedig a vállalat bevételeit  is képes növelni közvetve vagy akár közvetlenül is.

Szóval a #DevNet jelentőségét nem is kell nagyon túl magyarázni, hiszen az elmúlt 10-15 év technológiai változásai abba a irányba mutattak, és mutatnak most is, hogy egyedi CLI alapú hálózatüzemeltetésnek leáldozóban van.
Viszont egyre nagyobb szerepet kap, a programozás, automatizáció, analitika, amelyek mélyebb szintű megértéséhez nagyon jó segítséget kapunk a developer.cisco.com-ról. Itt találhatunk jól kialakított tananyagot és demo/lab környezeteket, amiben el tudjuk kezdeni a programozói képességünk ki vagy tovább fejlesztését.

Fejlesztői környezetek

A szoftver fejlesztés egy külön iparág, a saját kis ajánlásaival és az iparágban bevált és használt sztenderdjeivel, melynek mélyebb szintű megértéséhez éveket kell eltölteni ezen területen. Persze a programozó szempontjából az egyik legfontosabb részlet, az a környezet amelyre fejleszt és a környezet, amelyben fejleszti az alkalmazását. DevNet-en fellelhető tananyagok nem tesznek különbséget Windows, Mac, vagy Linux fejlesztői környezetek között, mert a python, REST-API, git, docker, bash scripting, Ruby, C egyes formái mind-mind elérhetőek mindegyik operációs rendszerre, szóval megmarad a választás illúziója...
Személy szerint én az összes lehetőséget kipróbáltam, és tudom, hogy ezért bizonyos vallási nézettekkel rendelkező programozók vagy mérnökök megköveznek, de a legegyszerűbben kialakítható és legjobban működő fejlesztői környezetet linux alapokon tudjuk megvalósítani.
Miért?
Legyen annyi elég, hogy csak.
(A legtöbb tool amit telepítünk opensource, vagy linux alapú megoldás, így itt by desing egy optimalizált megoldást kaphatunk.)

De nekem windowz van a gépemen, vagy Mac-et használok!

Semmi gond a megoldás a ..... doppergés .... nah? ........

virtualizáció, pontosabban desktop virtualizáció!

Ubuntu-t már 15 éve  tudunk, vmware workstation-be, virtualbox-ra telepíteni....

Ubuntu telepítési lépéseket remélem ezen a szintem már nem kell magyarázni, főleg, hogy desktop kialakítása gyakorlatilag next-next-finish....

Ajánlott a 18.04.02-est LTS verzióval kezdeni, hiszen a devnet oldalon is ezen példán visznek végig, így jó eséllyel a LAB környezetet is gond nélkül érjük el. (20.04-el sem volt gond...)

Amire szükségünk van a fejlesztői környezet kialakításához, azt apt csomagkezelővel fel tudjuk telepíteni, a szükséges függőségekkel együtt szóval nem egy rakéta tudomány ennek a feladatnak a meglépése sem.

Az igazán utána járós google engineer feladat, a python library-k rendbetétele, illetve a python verzióhoz megfelelő python install packeges verzió alkalmazása, hogy mindig az áltatlunk használt python verzióhoz megfelelő library készletet használjunk.

Jah miért pont pythonban tanít meg a cisco a programozásra?

Mert szinte minden feladatra találtak ki python script-et.

Ami még szintén az oktatási anyag szerves része, az a szoftverfejlesztés lépéseinek elsajátítása. Verzió követés git alkalmazás segítségével és javasolt repository-ként a github-ot ajánlják.
Nekem is van már telecommer néven.
https://github.com/telecommer/telecommer
 
....
 

DevNet Expert?

 
Mindenesetre én fontosnak tartom ezt a témát, legalább olyan fontos mint a CCIE SP, úgyhogy, ha nem is helyette, de mellette megcsinálom a professzional szintet.
Nem mellesleg a CCIE is tartalmaz evolving témaköröket, amelyek pont a hálózat-virutalizáció és a programozhatóság kapcsán kerültek bele az anyagba.
 
A DevNet Associate-n már túl vagyok - talán Magyarországon az elsők között - most jön az Enterprise és Service Provider automation speacializációs vizsga, és végül a CORE amellyel egésszé válik a DevNet Proffessional minősítés...
(SP automation-nal CCNP SP is bebillen, mert időközben megcsináltam CCS-SPCORE-t, ami a CCIE written is egyben szóval CCIE #xxxxx1 kész :-) )

 A továbbiakban szeretnék még néhány post-ot összerakni ebben a témában, esetleg segítve más felkészülését.










Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy közbe

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs