Citat:
bogdan.kecman: kako nisu, nesto ti tu nisi dobro svatio
devops == madjionicar, kad nesto zase1234es njega okrivis i magicno
nemas vise problem
Al si ti vickast.... :) Mada, da ne pocinjem ko to radi i kako... :)
@Coyote:
- Izmene koda idu prilicno fino. CD u praksi, sa PHP aplikacijama ide skroz live :
1) Napravis DocRoot koji je /neki/path/current/public
2) Napravis /neki/path/releases/1 (pri release)
3) Napravis current kao symlink na releases/1
Sledeci put, dignes releases/2, promenis symlink, reloadujes php-fpm/nginx/apache, obavezno reloadujes opcache - i to je to.
Ako napravis dovoljno testova u pipeline-u, nema nikakvog razloga zasto ne bi radio i CD. Ako ima neki monitoring, koji moze da okine rollback, ako aplikacija pocne da vraca greske, sve moze i sme da ide automatski. Mozes sve ovo da resis sa malo vise truda krozcist gitlab-ci.yml (OK, mnogo vise truda), mozes da koristis gotova resenja kao npr. Envoyer. :)
- Izmene baze razni "DevOps Engineers" ovog "modernog tipa" misle da se rade iz koda kroz migracije. Kad imas bazu od preko 100GB i tabele preko 1GB, pa ti pametni pusti migraciju.... pa imas na drugoj temi Bogijev savet za kristalnu kuglu :D
Realno, schema-less strukture su popularne zbog ovoga... moz' da radis sta 'oces. Naravno, puno srece kad nesto ne radi. :D U praksi, sve ima svoj merrit, ako zelis DevOps kao kulturu, nista te ne sprecava da imas sve elemente te kulture i da radis planirane izmene nad bazom. Ako hoces da imas "devops guy" koji je realno release engineer koji misli da sve zna, onda puno srece :). Again, vidi onu kuglu. :)
Izmene na bazi koje su velike su malo obimna prica za forum. Svode se na to da imas asinhronu replikaciju, pa da se potrudis da izmene budu ili :
1) Dodavanje index-a
2) Dodavanje kolone na kraj (OBAVEZNO NA KRAJ)
3) Kreiranje novih tablea (ovo moze kad god hoces ;) )
Onda 1) i 2) mozes da uradis prvo na slave-ovima, pa proglasis neki slave za master, a onda uradis izmene na masteru i vratis ga u upotrebu. Pri tom ti treba alat kojim menjas kako se klijenti kace na bazu... Mislim da je zvanicno MySQL resenje MySQL Router, onda imas MySQL orchestrator, verovatno ima jos nesto. Moze da se, recimo resi tako sto imas ProxySQL na svakom klijentu, plus Orchestrator, pa onda kad prebacis da neki drugi host bude master, proxysql prebaci klijente da se kace na njega... Ima malo posla :)
Pri tom, celo ovo resenje JESTE infrastructure as code, jeste skroz u skladu sa DevOps principima, ima gotove module za puppet recimo... i sto je najvaznije odlicno radi. :) Samo sto nije za ove .... "znam ja sve, to cu ja kroz kod" tipove. Baze podataka obicno drze bitne stvari (citaj novac / finansijske podatke) i nisu za taj nacin rada.
Da se vratimo na Galera replikaciju: Ovo sve NE MOZE sa Galera replikacijom. Galera je sinhrona, ne mozes da pustis upit prvo na slave, jer je u pitanju multi-master sistem. Kad imas Galera-u, onda alter lockuje sve tri baze i dok ne zavrsi ceo sistem ti je lockovan (moras da imas 3 da bi imao pouzdan quorum ako jedna masina ispadne). Zato kazem da Galera nije resenje za sve, stavise nije za dosta toga. Odlicna je za neke use-cases, ali samo za neke. :)
Note: Ako ti je baza do 2-3GB, za neki WordPress, lepo sve to ignorisi, digni RDS i pucaj ALTER TABLE na produkciju. :) Prodje to dovoljno brzo. :)
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'