Új hozzászólás Aktív témák

• #25 frescho addikt bambano #15

  Új Válasz 2019-01-17 21:43:11 #25

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  frescho

  addikt

  válasz bambano #15 üzenetére

  Ha kritizálni akarod, akkor ismerd meg jobban az ellenséged:

  ha megcsináltam mondjuk a .deb-et, egy utasítás, felrakom, jónapot.
  ha konténert (pl. docker image-t) csináltam belőle, akkor kell konténer szoftver, meg annak a vezérléséhez nagy kosár más cucc is, pl. puppetet meg chef-t hallottam sokat emlegetni. azoknak a technológiáknak egy része, amit a konténerhez használsz, megvolt előtte is, pl. redundáns, storage alapú tároló volt régen is, ebből is látszik, hogy a konténer dili csak egy marketing buzzword.

  A deb csomag helyett sokkal közelebb lenne a chroot jail vagy template virtuális géphez.
  A puppet és chef jellemzően nem a konténerhez való. Nagy mennyiségű gépnél konfiguráció managelésre viszont jók. Mi is puppetet használunk a bőven 1000 fölötti géphez.
  A konténerhez a storage hogy jön? Pont az benne a buli, hogy eldobható konténerek vannak. ha elhal egy host, akkor így járt, majd indul valahol máshol konténer. Inkább pont az a bajom vele, hogy az olyan dolgoknak amiknek nagy permanens tároló kell nem az igazi. Kis webszervereknek meg hasonlónak OK, de 100G fölötti DB-hez értelmetlen.

  Irónia ON

  A többit is nézd más szemszögből szemszögből:

  Az outsource nem halott, csak átnevezték cloud-ra. Így már nincs szüksége emberre aki ért a vashoz, képes méretezni vagy érti, hogy mi az IOPs és mi a különbség a bolti HDD, SATA SSD és egy szerverbe való NVMe között. Teljesen felesleges is lenne, mert a cloudban lehet másik instance-ot indítani, ha kell. Az, hogy ez mennyibe kerül legyen a megrendelő baja, úgyis vele fizettetjük ki.

  A konténer is a devops szemléletet támogatja. Valaki már írta, hogy az ops-nak kell körbe gányolnia a leszállított kódot cron jobokkal meg log darálóval. Fölösleges, ha konténereket használ az ember. Meghal az app? Automatikusan lelövi a rendszer. Ha lassú, akkor meg indít belőle 10-et. Hogy ez mibe kerül az nem érdekes, mert legyen a megrendelő baja, úgyis vele fizettetjük ki.

  Az új módszertan, a gyors deploy is csak előnyére válik. Az új konténerek újraindítást is jelentenek. ezzel ha memory leak vagy bármi más idővel előjövő problémád van, akkor azt is megoldottad egy csapásra. A legjobb, ha mindent felépítesz a fejlesztői gépen, aztán csinálsz egy környezetet a teszteknek, egy másikat stagingnek, meg az élest. Az egészet dinamikusan fel lehet húzni, ne is nézd ez mennyi erőforrás, a cloud a korlátlan erőforrások hazája.

  A skálázhatóság is fontos, mert csak akkor jön ki a konténer előnye. Meg ugye a "scale up" úgyis utálatos dolog, mert gyorsabb CPU-ra bárki tud gyors programot írni. Az sokkal szebb, ha 8 gyors helyett 64 lassú maggal szolgáljuk ki a felhasználókat. Amúgyis ilyenkor ha elveszítünk 8 vagy 16-ot, akkor majd indítunk helyettük másikat. Na ezért végre nem kell fizetni, mert idő alapú a számlázás és így a redundanciát is megoldottuk, ha 2-3 különböző helyre telepítettük az alkalmazást, így villanthatunk a megrendelőnek, aki fizeti az egészet.

  irónia OFF

  Azért ha rendesen csinálják vannak benne jó dolgok. Csak kell hozzá egy ops csapat is aki támogatja a devopsos csapatokat más szemlélettel és tudással.

  [ Szerkesztve ]

  https://frescho.hu

• #29 frescho addikt emvy #28

  Új Válasz 2019-01-17 22:06:26 #29

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  frescho

  addikt

  válasz emvy #28 üzenetére

  Lehet. Lehet S3. Csak soha nem fogja hozni egy szerverbe becsavarozott PCIe kártya teljesytményét. Maga a swarm és k8s viszont nem építi fel helyetted replikákat és intézi a backupot. Üresen képes lehet erre, de van egy pont ami felett nem optimális. Amire igazán jó az az automatikus skálázás és nagy tömegű eldobható instance felhúzása.

  bambanonak abban igaza van, hogy a k8s infrastruktúrát is üzemeltetnie kell valakinek. A gépeket meg kell rendelni, kell hozzá áram, rack, hálózat. Fel kell húzni az alap rendszert, integrálni kell a clusterbe. De a storage sem ugrik csak úgy elő a semmiből. Szóval a devopshoz az addigi opsra ugyanúgy szükség van, csak kicsit másként.

  https://frescho.hu

• #32 frescho addikt #45997568 #31

  Új Válasz 2019-01-17 22:49:34 #32

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  frescho

  addikt

  válasz #45997568 #31 üzenetére

  Kiszerveztétek a vas beszerzést, üzemeltetést és még sok mást, ezeknek az SLA-ját is mástól várjátok el.

  Ez jó döntés is lehet. A lényegre tudtok fókuszálni és rugalmasan fejlődni. Kis forgalom, kevés bevétel mellett a kiadás is alacsony, jobb a méretgazdaságosság.

  De van amikor security vagy más szempontok miatt ez nem éri meg. Kezdődhet onnan, hogy ti magatok vagytok a cloud szolgáltató. Az is lehet, hogy szerződési kötelezettség az adatok házon belüli kezelése. Végül lehet, hogy a cloud szolgáltató csak egyedi ajánlatként tud megfelelő teljesítményű gépet biztosítani kb 3x áron 2 hónap átfutással.

  Szóval mindennek meg van a maga helye, nincs üdvözítő megoldás. Nállunk van több tucat cloudban futó mikro service ahova nem kerülhet ki csak anonimizált adat, private cloud és igazi monolitikus saját adatközpont is az érzékeny adatoknak.

  https://frescho.hu

Új hozzászólás Aktív témák