Archívum
január 30
Docker-el hogy megy a build & deploy?
Érdekelne, hogy mi a best practice, ha docker container-ben szeretném futtatni az alkalmazásom. Több kérdésem is van.
- Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
■ - Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
január 29
PHP változó elfelejti tartalmát
Üdvözletem!
Van egy kódom:Tegyük fel, hogy az összes tagfüggvény megvan, továbbá egy belső változó, ais.
Amikor végrehajtom ezeket, a $this->query tagváltozóba írják a maguk dolgait (pl. "column" => ["sor", "másodsor"]), így végül aznevű tagfüggvény az alapján végre tudja hajtani a lekérdezést.
A kérdésem az lenne a fenti koncepcióval kapcsolatban (amely a hiba keletkezése előtt (kb. 6x) jól működik) az lenne, hogy az említett $this->query tagváltozó az egyik metódus meghívásakor (Value()) hogyan lehet üres, mikor már fel lett töltve?
Van egy kódom:
$this->database
->Add()
->Col("which", "ident", "date", "time", "client")
->Value($which, $id, Sanitizer("toSTDdate")->Sanitize(getTime()), Sanitizer("toSTDtime")->Sanitize(getTime()), getClientID())
->Table("form");
$res = $this->database->Execute();
$this->query
Amikor végrehajtom ezeket, a $this->query tagváltozóba írják a maguk dolgait (pl. "column" => ["sor", "másodsor"]), így végül az
Execute()
A kérdésem az lenne a fenti koncepcióval kapcsolatban (amely a hiba keletkezése előtt (kb. 6x) jól működik) az lenne, hogy az említett $this->query tagváltozó az egyik metódus meghívásakor (Value()) hogyan lehet üres, mikor már fel lett töltve?
V8 Release 4.9
A Google Chrome 49-es verziója 91%-os ES2015 támogatással érkezik
■ január 29
NixOS – The Purely Functional Linux Distribution
Deklaratív, tranzakcionális csomagkezelésre és konfigurációra épülő Linux disztribúció
■ Google Will Soon Shame All Websites That Are Unencrypted
A nem biztonságos weboldalak vizuális megjelenítése hamarosan megváltozik a Google Chrome-ban
■ január 28
Knightmare: A DevOps Cautionary Tale
Hogyan vitte az automatizálás hiánya negyvenöt perc alatt csődbe az Egyesült Államok legnagyobb tőzsdei kereskedőjét
■ január 26
How to Manage the Risk of Losing API Access
Hogyan kezeljük a külső API-k használatából adódó kockázatokat
■ 9 things every React.js beginner should know
Néhány hasznos best practice React fejlesztőknek
■ január 25
Meteor, Angular2 and React: once the dust settles…
Összefoglalás a 2015-ös évről frontend keretrendszerek szemszögéből
■ 
