Bez dockeru ani ránu

Docker_(container_engine)_logo

V článu Docker server snadno a rychle, kde jsem shrnul jednoduchý způsob, jak rozchodit hlídané docker kontejnery za pár vteřin, jsem nezmínil, jak moc důležitou roli v mém vývoji samotný Docker hraje, proč by si měl získat i vás a taky proč by měl být Dockerfile či Docker Compoer (možná kromě node.js) nedílnou součástí všech repozitářů vašich projektů.

Nebudu tu rozebírat milionkrát omílané tutoriály s hello wordy. Spíš se zaměřím na pár jednoduchých poznámek a rad, které mě nakonec motivovali natolik, že jsem na dockeru začal stavět téměř všechno nové a připravil na něm také vývojové zázemí pro všechny aktivní stávající projekty u svých klientů.

Bylo nebylo…

Když jsem začal dělat pro první větší firmy a pracovat v prvních menších vývojových týmech, tak to vypadalo tak, že všichni měli vývojové prostření nainstalované na svém počítačích, tak jak to nějak vytušili z kódu. Reálně to nakonec vypadalo tak, že přišel nový člověk, který věděl, že děláme na PHP a MySQL a tak si to nějak rozchodil.

Když byl klient štědrý, tak zaplatil ještě nemovitému juniorovi licenci MAMP PRO a vše bylo téměř superrůžové. Téměř…

Výsledkem bylo, že jeden dělal na PHP verzi 5.6. Ti co tam byli dřív, tak ještě 5.4 a ty úplně nejčerstvější kousky by tam už měli třeba PHP 7… Ano. Velkým tajemstvím je mi to, proč se s tímto přístupem stále setkávám a ještě větším, proč to každý z nich je schopný obhajovat do úmoru, než aby šel s dobou a moderními ověřenými nástroji. Trochu mi to připomíná přístup důchodců „Za našich časů tyto věci nebyly a tak je nebudu používat ani já.“

Bohužel škody, které je schopný tento přístup napáchat, můžou být opravdu velké. Vzpomínám na situaci, kdy všichni vývojáři včetně mě vyvíjeli na PHP 5.6, zatímco na produkčním serveru bylo 5.4 (informace, kterou mi tak nějak zapomněli říct). Jelikož to byl eshop, který měl nějakých 2000 objednávek denně a denní obrat kolem 1.5 milionu, tak důsledky večerního uspěchaného RUČNÍHO OUTSOURSOVANÉHO buildu mohly a také občas byly fatální.

Takže první a nejzásadnější přidaná hodnota Dockeru je, že všichni vyvíjí na stejném prostředí.

Virtualizace vs. Kontejnerizace

Lepším přístupem se kterým se setkávám je, že projekt už u developerů běží na nějaké virtualizované mašině … Nejčasteji je její build zajištěn Vagrantem a aspoň už všichni vyvíjí za stejných podmínek a dokonce se už ani nestává, že by to na produkci bylo jinak.

Nevím přesně proč to tak je, když v zásadě by to mělo fungovat na dost podobné myšlence, že celé prostředí nahodíte jedním příkazem, ale vždy jsem musel trávit minimálně den tím, že jsem u nováčků rozchozoval a instaloval všechny potřebné nástroje (Vagrant, VirtualBox apod.), protože to potřebovalo milion pluginů a když už jsme je měli, tak to zahlásilo nekompatibilní verze a celý postup šel nanovo.

Tohle to s dockerem odpadá. Stačí nainstalovat jeden vyladěný instalátor (na OSX a Linux) a vše, dle mých zkušeností, běží jako nic.

To, že je docker znatelně výkonově nenáročnější. Je jen malé přidané plus.

Není všechno jenom růžové

Ten kdo je obeznámen fungování kontejnerů, tak ví, že o data, která si nenamountujeme jinam, příjeme při vypnutí kontejneru. Takže nahrávání obrázků a souborů do administrace na localhostu většinou problém není, ale když na produkci běží cloud balancovaných kontejnerů, tak aby měl každý z nich přístup ke stejným datům, je už docela oříšek, nicméně je řešitelný.

Největší problém, co jsem přes docker řešil, byl práce s DB. Ze stejného důvodu jaký jsem zmiňoval, tak o data přijít nechceme. … Kvůli různým zabezpečením databází mi příjde skoro neřešitelné takový kontejner zmigrovat, i když data máme uložena někde bokem. Po migraci nemají správná práva, mají špatné ownery a nejspíš nejsou pokřtěna krví jednorožce originálního kontejneru.

Proto doporučuji databáze přes docker neřešit nebo pouze na vlastní nebezpečí.

Asi další mínus o kterém jsem slyšel je, že na windows nefunguje docker nativně a je docela sranda ho rozchodit tak, aby vše fungovalo a stejně to nefunguje úplně jak má. Nevím jak aktuální je takto informace, protože když jsem začínal s dockerem já, tak stejný problém byl i na OS X a nyní už vše běží jak má. Navíc jediný obhajitelný důvod proč vyvýjet na windows je to, že pracujete v Microsoftu.

Motivace na závěr

Docker je tedy skvělý nástroj, díky kterému nejen že mají všichni stejné vývojové prostředí pouhým lusknutím prstu, ale také na menších VPS při správně nastavené architektuře je vše krásné izolované, nic se vzájemně neovlivňuje a migrace je otázka přesunu jedné složky a puštění jednoho příkazu.

 

AMQP – Potenciál fronty bez bolesti hlavy

rabbitmq_logo

Žádná microservis architektura se dřívě či později neobejde bez přidání frontovacího systému. S tím ale souvisí velké utrpení, protože než člověk vstřebá veškeré know-how a poté si osvojí best practice, uplyne dlouhá doba a stejně nakonec neví, zda to napsal tak jak se má a sluší.

Jak jsem již psal v článku s mým balíčkem na loadování configů, tak z velké částí je prvotní motivací, pro vytvoření nového package, sjednocení a až pak méně časté inovování a shana vytvořit něco, co se bude používat, protože je to lepší, nové a cool. Z prvního důvodu vyznikl také můj balíček amqp-model.

V desítkách projektů, ke kterým jsem se dostal, byla stále omýlaná téměř stejná funkcionalita práce s frontami a exchangemi, ale pokaždé jinak pojatá a ve výsledku těžce uchytitelná.

Proto jsem se pokusil sjednotit všechny požadavky našich servis a výstupem je snadno použitelný NPM balíček, který má vše potřebné pro práci s AMQP protokolem.

Docker server snadno a rychle

Docker_(container_engine)_logo

Každý developer si při vývoji projektu musí položit dříve či později otázku, jak budou aplikace, které jsou jeho součástí, běžet. Při větších projektech je vhodné si postavit architekturu na Rancherovi a při těch úplně největších klidně celou automatizovanou flow na Mesosu s Maratonem.

Někdy je ale jasné, že toto by byl zbytečný overengeneering a uchýlí se k jednodušší, byť méně škálovatelné či ošetřené variantě. Mě osobně 90% projektů běží v docker containerech na několika desítkách VPS s tím, že jejich běh hlídá jediný supervisor s webovou adminsitrací a nic víc. Spousta projektů totiž nic víc ani nepotřebuje.

Proto se pro mě stalo docela rutinou, že jsem potřeboval na čistý VPS server nainstalovat docker, pak supervisor a taky vše ostatní, co je k tomu potřeba. Instalace probíhala většinou tak, že jsem do googlu dal vyhledávat jednotlivé tutorialy a pak jsem nakopíroval defaultní configy z jiných svých serverů. Všeho všudy práce na hodinu i s kafem.

Nicméně mě jednoho dne přešla trpělivost a práci, která se dala zautomatizovat jsem si našel nějaký čas navíc a zautomatizoval jsem ji. Vznikl script, který tuto rutinní práci udělá během pár minut bez nutnosti vyhledávat a copy/pastovat příkazy z tutorialů.

Celý repozitář i s použitím můžete najít zde: https://github.com/bouchal/docker-master-install

Nutno podotknout, že jak tomu zákon schválnosti chce, tak od doby co jsem ho napsal, jsem měl potřebu ho použít mnohem méně, než tomu bylo dřív.

NPM environmentconfig

DtHsMG5

Když jsem před několika lety začal pracovat pro větší společnosti, které už neměly problém vybudovat si docela obstojné zázemí pro správu, buildování, deploy a samotný běh několika stovek, až tisíců servis, začal jsem vnímat nesourodost mezi tím, jak každá jednotlivá servisa načítala svůj config na základě prostředí ve kterém běžela.

Jak už to tak bývá, tak většina servis běží v pár základních prostředích … produkce, development, test a localhost. Někdy je navíc stage nebo nesou zkratku místo celého názvu ( development => dev ).

Propracovanější nástroje potom také při deployi k projektu připojí „.env“ soubor, kde jsou například connection stringy, které by se neměly ukládat do repozitáře a nebo jsou součástí většího poolu, kdy je každý z nich přiřazený k několika servisám dle potřeby.

Z toho důvody jsem pro své potřeby vytvořil NPM package envitonmentconfig.

Hlavní goaly tohoto balíčku jsou:

  • Načítání .env
  • Parsování více formátů s přípravou pro jednoduché rozšíření na další pro další contributory
    • Prozatím CSON, JSON
  • Watherfall loadování configu
    • Všechno z konfigu produkce se promítne do developmentu, ale může být přepsáno
  • Vlastní definice prostředí
    • Jednoduché rozšíření o další prostředí než jsou jenom defaultní, případně jejich vlastní pojmenování