• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    FALLENANGEL
    FALLENANGEL --- ---
    RUDOLF: GitOps je smer uvnitr DevOps, kterej pouziva git (nebo jinej verzovaci system) jako single source of truth. Pro infrastrukturu, i pro aplikace, ktery na ni bezi. Pro deployment se pouzivaji nastroje jako ArgoCD, nebo Flux, ktery hlidaji drift na obou stranach a kdyz dojde k nejake zmene, tak upravi prostredi prave podle 'source of truth'. Takze zatimco IaaC je nadefinovani infrastruktury, GitOps je cesta, jak ji implementovat (mimo jine).

    INDIAN: To zni zajimave. Takze to pouzivate jenom pro konfiguraci aplikaci, ne pro deployment?

    MUXX: A ty Salt playbooky, nebo co to pouziva, mate hostovany a verzovany nekde v repozitarich?
    RUDOLF
    RUDOLF --- ---
    RUDOLF: jo, on je to buzzword: https://www.gitops.tech/
    RUDOLF
    RUDOLF --- ---
    FALLENANGEL: to zní jako normální IaC. A plus immutable koncept. Asi nerozumím té ops části. Napadá mě jen, že ty commity pouští github actions namísto jenkins nebo co kdo používá na runtime automatizace.
    MUXX
    MUXX --- ---
    FALLENANGEL: mame skoro vsechno pres saltstack. vcera jsem to zrovna pocital - 10k+ instanci. Daji se nad tim nastavit krasne procesy a SRE vidi presne kdo kdy kam hrabnul kdyz neco nefunguje. Mame to nad klasickym datacentrem i "cloudem". co se tyka toho, ze neco neni "production ready", tak to leda produkt a lidi. produkt musi byt napsanej aspon trochu normalne ( https://12factor.net/ ), jinak se to blbe automatizuje. lidi (sysadmini) se musi naucit myslet jako dev/test jinak je to hrozny prasokod.
    INDIAN
    INDIAN --- ---
    FALLENANGEL: ja mam v duchu gitops 2 projekty:
    prvni - jde o slozity aplikacni konfigurace, cca 400 ruznejch instanci ... je nad tim umele vytvoreny workflow pomoci skriptu aby to bylo user-friendly - zmeny v konfiguracich muze delat i clovek co dela helpdesk a nasledne je validuje clovek z produkcniho oddeleni ... kazdej commit obsahuje timestamp kdy ma bejt dana konfiguraci aplikovana - z cehoz vyplyva ze se ty commity dodatecne tridi aby sly po sobe - takze je to trosku znasilneny ... pipeline v gittlab CI komunikuje s AWX (ansible frontend) a vytvari joby ktery ty konfigurace aplikujou
    druhej - konfigurace sitovejch prvku pres ansible ... pro kazdy DC mam zvlast inventory file a group_vars a soucasne mam klientsky konfigurace napric vicero DC, tam je opet zbastlena cast (tentokrat spis nad ramec ansible nez gitu)

    jinak vseobecne se snazim mit vsecko IaC, takze i zbytek infra co mam v rezii je v gitu taky samozrejme (coz se samo tyka i kontejneru abych nebyl OT;))
    SINC
    SINC --- ---
    FALLENANGEL: Primarne AWS Cloudformation. Pak Helm pro K8s.
    FALLENANGEL
    FALLENANGEL --- ---
    SINC: A jaky nastroje pouzivate?
    SINC
    SINC --- ---
    FALLENANGEL: My mame kompletni infrastrukturu vcetne konfigurace k8s clusteru, networking, DNS, node groupy, helm ... v gitu a ciste pozitiva. Bez toho se neda delat review. Jedno repo je na sdilenou infrastrukturu (clustery, networking, ...) a kazdy aplikacni repo pak obsahuje svoje vlastni resources (s3 buckety, load balancery, ...).

    K prerotovani stejne jednou za cas musi dojit i na produkci, kdyz se updatujou nody. Navic jedem na spot instancich, takze oni stejne nezijou moc dlouho :)
    FALLENANGEL
    FALLENANGEL --- ---
    INDIAN: Jde mi spis o obecnej nazor, nez ze bych mel na mysli konkretni pouziti. Jeden muj zakaznik planuje mit vsechny definice infrastruktury i kod a nastaveni aplikaci v gitu a vsechno vcetne spravy ridit pres updatovani gitu. Dalsi zakaznik premysli nad docela zajimavym konceptem Dev clusteru, kdy vsechno bude opet nadefinovany v gitu a kazdej tyden stavajici cluster odstrani a z gitu vytvori novej, cimz se vyhnou nejruznejsim problemum, ktery muze hnijici Dev cluster prinest.

    Na druhou stranu slycham, ze GitOps jeste nejsou 'production ready', chybi poradnej tooling i standardizace workflow.
    INDIAN
    INDIAN --- ---
    FALLENANGEL: pro jaky pouziti? ja neco v podobnym duchu provozuju, ale sou to mozna dost specificky zalezitosti...
    FALLENANGEL
    FALLENANGEL --- ---
    Mate nekdo zkusenosti s GitOps? Pripadne nazory? Vnimam nejake smisene signaly.
    SH_PANDA
    SH_PANDA --- ---
    MARTEN: heroku?
    KING
    KING --- ---
    MARTEN: ja bych to poskladal z ruznych sluzeb a v nekterych vecech udelal kompromis, alespon ze zacatku. Napriklad potrebujes skutecne rabbitmq, nestacil by redis nebo sqs? Zbytek bych pak resil bud klasickym VM (EC2, GCP, ...) a nebo nejakou kontejnerovou sluzbou (ECS, GKE, ...) a hlavne bych se nebal externich sluzeb jako treba Elastic Cloud na ten elk nebo Citus pokud potrebuje hodne postgresu (vetsinou budou umet lokaci ve stejnem cloudu jako zbytek takze rychlost bude v pohode)
    REFLEX
    REFLEX --- ---
    MARTEN: tyjo vlastni projekty bych dal na cloud ve chvili kdy to vydelava penize a vzal bych na to nejakyho profika a udelal to s nim, strasne moc prace a na zacatku minimalni profit
    LITTLELI
    LITTLELI --- ---
    MARTEN: Podíval bych se na Hetzner https://www.hetzner.com
    SADY
    SADY --- ---
    MARTEN: za me aws a vlastni image postavenej na nejakem zakladu co ma vetsinu veci co potrebujes uz v sobe, lepe si pak muzes managovat upgrade na vyssi verze, zvednes jen to co uz je dele stable a opravdu vyuzijes ty nove features, je to nejaka rucni prace, ale zase mas plnou kontrolu vcetne detailu instalaci, napr. TZ apod.
    MARTEN
    MARTEN --- ---
    Uplne nevim jestli to davat sem, ale kdyz uz je tu debata o cloudech a toolech.
    Pro vsechny klientske projekty jsem vzdy mel moznost pouzit nejake self hosted cloud reseni (openshift,....). S AWS, GCP mam minimalni zkusenost. Ale ted mam vlastni projekt, ktery nechci hostovat na vlastnim serveru (i kdyz docker), ale rad bych to dal do cloudu. Hlavne kvuli SLA a protoze cekam vetsi navstevnost, tak skalovani muze byt taky dulezity faktor.
    Otazka je kam to nejlepe dat. Technologicky php, nodejs, python, postgres, redis, rabbitmq, elk. Kdyz koukam ne nektere cloud reseni, tak vetsina ma postgres, ale treba ne rabbitmq a elk. Vzdy tam muzu mit vlastni image, ale urcite by bylo prijemne pouzit pripravene cele reseni a nemuset zbytecne nic nastavovat. Je neco co osobne preferujete? Koukam i na cenu, precejen to zatim budu dotovat ze sveho, nejlepe i datacentrum v CR nebo blizko. Zahranicni traffic bude minimalni.
    DWICH
    DWICH --- ---
    Nejsem expert, takže s rezervou :) Co mi přijde super, že jsem vlastně nemusel nic nastavovat, pustím aplikaci v Google Cloud Runu (nebo Cloud Function) a ... věci fungujou tak nějak samy. Aplikace logujou, když mi aplikace hodí chybu, mám ji v GCP konzoli v errorech včetně stack trace apod. Mám aplikaci napojenou i na Sentry, ale je dobrý, že GCP tohle nějak sám ví, eviduje a nabízí nad tím featury jako Cloud Debugger, Trace atd. Že prostě ta platforma pro provoz a observability je integrovaná a vlastně dost věcí se nemusí ani nastavovat.
    Debugging, distributed tracing, and profiling for web applications
    https://www.youtube.com/watch?v=CjGv1bDy9rI


    Jo a na co se chystám, je Cloud SQL Insights. Využívá to https://google.github.io/sqlcommenter/ a poskytuje to dobrý data
    Get ahead of database performance issues with Cloud SQL Insights | Google Cloud Blog
    https://cloud.google.com/blog/products/databases/get-ahead-of-database-performance-issues-with-cloud-sql-insights
    https://www.youtube.com/watch?v=qN7x3ngwz1o
    KING
    KING --- ---
    RATTKIN: jj, v djangu to jde i hezky propojit, ze je videt transakce z klienta az do databaze, klidne pres nekolik service. Bez toho bych si casto prisel jak slepy
    RATTKIN
    RATTKIN --- ---
    APM je super, hlášení chyb v jedné konzoli spolu s výkonnostními údaji.
    pro SPA je taky výborný RUM - to samý jako APM, ale na klientu
    Kliknutím sem můžete změnit nastavení reklam