vyresit jak deploynout config.local.neon

[Mikulas]

Jde o to, že deploy vezme repo (a pustí ně něm build a migrace atp.) ale nemá config.local.neon. Jak ho tam dostat?

[tsusanka]

To je to na čem to padlo? Nebo co tam je za problém?

[Mikulas]

jj ten deploy spadnul protože v local nebyl ten novej org password

Teď se to řeší tak že se config kopíruje z předchozí verze, takže to funguje jenom když se local nemění.

Nevim teď jak to vyřešit dobře, nechám to chvíli uležet.

[Mikulas]

Resp takhle, podle mě je hodně dobrý mít v local.sample.neon nějaký klíč version, který musí být stejný v local.neon. Pokud změna v local.sample.neon (verzovaný) není zpětně kompatibilní, tak se musí version zvětšit. Tohle by jednak při vývoji po pullu uporoznilo programátora že se config změnil a i by to pomohlo deploy. Max by to ale řeklo „bacha změna, nemůžu deploy udělat“.

A

V tom deploy repu by mohla být branch, do které by se pushoval do tagu podle čísla verze v local.sample.neon. Deploy by si stáhnul správnou verzi local.neon a odmítnul by deploy pokud tam ten config není. Navíc by to umožnilo rollback na zpětně nekompatibilní verze local.neon.

Takhle to zní složitě a v praxi by to bylo jednoduchý (a zdokumentovaný rovnou v odpovědi toho deploy).

Ale jak řikám nechám to chvíli uležet, třeba nás napadne něco elegantnějšího.

[Mikulas]

Je to docela fajn řešení, ale docela se to tim zkomplikuje (hlavně na serveru, u klienta je to ještě docela v poho).

B

Další řešení je mít local v repu. To není dobré řešení z hlediska bezpečnosti a praktičnosti, protože vývojáři chtějí vlastní local. Zmiňuju jenom pro pořádek.

[Mikulas]

C

Produkční konfigy můžou být v repu (v nějaké custom složce) a zašifrované aesem, deploy si to rozklíčuje a umístní na správné míst. To je docela fajn řešení, ale je podobně náročné ná implementaci jako A a je míň bezpečné a ne tak elegantní.

D

Další možnost je že deploy dojde do post-receive a zahlásí „čekám na config“ a bude čekat na nějakém socketu nebo na uploaded file nebo tak něco. Až detekuje že to tam někdo nahrál, tak deploy dokončí. Tohle je podle mě dost voser pro klienta a není to bezpečný, protože v ten moment co je to otevřený to tam teoreticky může nahrát kdokoliv.

[Mikulas]

Prosím o radu / diskuzi @tsusanka, @Clevis/hrach, @JanTvrdik . Nejlepší varianta je podle mě suveréně A. Jak by se to zdálo nejlepší řešit vám?

[tsusanka]

A tohle mi přijde asi nejlepší z těch možností
B ne z důvodu bezpečnosti jak říkáš
C to sice problém řeší ale přináší to dost práce navíc. pokaždé když přídáme nový klíč to budeme muset šifrovat. a to vše "jen" kvůli deployi
D to si neumím moc živě představit, taky mi to přijde jako overkill

Podle mě a-d nemá dostatečný "cena/výkon" abychom to dělali :). A hlavně to všecko trpí klasickým clevis syndromem, kdy se snažíme udělat mega super řešení, ale po krátkým čase začne být neudržované a zahodíme ho. Podle mě je lepší jít tou KISS cestou.

E

Co by podle mě bohatě stačilo, kdyby se udělal diff na config.local oproti samplu*, zjistilo se, jestli tam nastala nějaká změna (kontrolovat jen klíče) a pokud ano, tak na to během deploye upozornit. Developer si všimne hlášky, logne se na server a ten config upraví. Ano hrozí dočasná nedostupnost ale imho momentálně nědeláme takový velký weby aby to vadilo.

F

Ještě trochu upravený E). Deploy se mrkne, jestli neexistuje config.local.new. Pokud ano, smaže/zazálohuje config.local a nový config.local.new přejmenuje na config.local. Developer, který tedy dělá deploy si předem musí připravit config.local.new a nahrát ho na server. Ideálně by deploy by udělal check toho config.local vs config.local.sample* a pokud tam je rozdíl tak ten config.local.new vyžadovat. Bez něj prostě failne.

* Možná lépe projet commity a kouknout, jestli někdo udělal změnu v config.local.sample

[Mikulas]

Díky Tome:

Určitě by bylo fajn aby to bylo co nejjednodušší. Ale nejenom na serveru, ale hlavně pro vývojáře.

E: nejde kontrolovat jenom klíče, protože na produkci třeba může být zaplý redis nebo něco takového, takže se ty klíče neshodují. Kontrolovat commity je podobně složité jako dělat ten aes a udělá to false positives, když se třeba jenom změní pořadí klíčů. Nedostupnost ale nehrozí, protože ten deploy si už teď nejdřív zkouší appku pustit (dělá migrace) a až potom swapuje symlink. Tohle řešení podle mě ale nefunguje dobře, protože každý kdo by dělal deploy musí mít i přístup na server. Teď stačí mít přístup do toho repa.

F: pokud by byl ten new v repu, tak je to zase problém protože by se pushoval i na github. Pokud by v repu nebyl, nemáme ho tam jak dobře dostat (upload přes sftp bych se rád vyhnul)

---

Zatím mi z toho vychází, že nejlepší by bylo mít a app/config/deploy git repo, které by obsahovalo config.local.neon. To by se pushovalo do tagů production-%N (případně test-%N atp) kde %N by bylo číslo verze poznačené někde. Může být poznačené třeba v config.local.sample.neon, ale na tom mi trochu něco vadí. Deploy by si pak jenom stáhnul z toho tagu tenhle soubor a umístil ho do appky. Pokud by správný tag neexistovat, tak by se deploy neprovedl.

Když vymyslíme jak dobře určit (kde) verzi toho config.local.sample.neon, tak je to docela dobrý a jednoduchý, jak na serveru tak u klienta/dev.

[hrach]

Chlapci chlapci... myslim si, ze je treba se na to divat uplne z jineho pohledu.

---

Obrovskou chybou nette bylo dropnuti sekci, diky kterym bylo verzovano i produkcni prostredi. Ano, chapu security issue s verzovanim hesla, ale hesel a klicu je minimum. Mnohem casteji nastavuji redisy, cesty, produkcni konfigurace jako profilovani, etc. Jen se podivejte na konfigurak vetsiho projektu jako jsou signaly. Ano, toto je config.local.neon na serveru a nemam ho zalohovany. (Ted uz jo :P) https://gist.github.com/hrach/f84fd621a3bb76b0d183

---

Imo je spravne reseni takove, ze budeme verzovat local konfig s tim, ze se budeme snazit minimalizovat zmenu konfigu, a to tak, ze budeme verzovat konfiguraci pro produkci / development.

Treba https://github.com/Clevis/Skeleton/blob/v2.2/app/config/config.local.sample.neon - vetsina parametru muze byt verzovana.... Tim se zasadne minimalizuje problem s deployem.

Ty sileny napady s verzovanim pushovanim tagu etc. naprosto nechapu a jsou imo overkill.

[Mikulas]

Díky za připomínku, to co říkáš určitě dává smysl, ale pořád to neřeší jak na server dostat nový konfig kde jsou hesla. Navíc local je to pro to, že ho verzovat nechceš, a pokud ano, tak v místě kde se sám nenačte. Typicky nastavení produkčního smtp: není nebezpečné, ale na localu na devu to mít nechceš.

[hrach]

Stejne jako config.local.neon.sample bych pridal config.environment.neon.sample kde by bylo nadefinovano vyvojarske prostredi (file mailer, etc.) Repo by melo zaroven comminute config.signaly.cz.neon, respektive config.beta.signaly.cz.neon, ktere by deploy prejmenovaval na config.environment.neon. (jmena souboru berte jako tip)

[hrach]

@Mikulas cetls to poradne? Proste deploy to neprovede, pokud je zmenena verze v local configu. A musis ho na serveru rucne upravit.

SMTP: krome hesla a usera chces naopak vsechny ostatni volby verzovat - jako port, adresu, sifrovani...

[Mikulas]

Jasně, četl jsem to, jenom z části nesouhlasim :). Já jsem zase říkal, že bych nerad aby někdo musel něco měnit na serveru přes sftp nebo nedejbože ssh. Oproti tomu pushnout jeden tag se mi zdá fakt dobrá varianta (a řešít to všechny problémy co jsi vyjmenoval, především verzování produkčního konfigu).

Líbí se mi že bychom měli local co nejmenší, jsem docela fanda těch environment. Když rozlouskneme ještě jak ty hesla, tak máme vážně dobrý řešení 🍭