Rádi byste pronikli do tajů Elasticsearch a dozvěděli se, jak s jeho pomocí naimplementovat vyhledávání na míru vaším potřebám? Chcete se dozvědět o úskalích vyhledávání v češtině a jak je řešit? Zajímá vás, jestli máte vše v Elasticsearch dobře nastavené a co všechno vám tento nástroj nabízí?

Nabízím školení Elasticsearch

Pro všechny tyto případy nabízím školení, během kterého vás seznámím se základy práce s Elasticsearch, podrobně vysvětlím jeho možnosti co se vyhledávání a analytiky týče, nebo poradím s jeho nasazením do produkčního prostředí. Během školení se také můžeme zastavit u konkrétních problémů, se kterými se ve vaší firmě při implementaci Elasticsearch potýkáte.

Přijedu školit do vaší firmy, přičemž školení může být jednodenní nebo dvoudenní. Jednodenní varianta je zaměřena na implementaci fulltextového vyhledávání. V případě dvoudenní varianty pak zbývá více prostoru pro procvičení a také pro důkladnější prozkoumání celého Elastic Stacku.

Co se osnovy týče, tak se nejprve seznámíme se samotným Elasticsearch, ukážeme si, jak do něj data ukládat, jak je číst a jak pracovat s celým clusterem. Následně se podíváme základní datové typy, jejich využití v mappingu a jakým způsobem lze psát queries a v Elasticsearch vyhledávat. Poté již můžeme jít více do hloubky a napsat si vlastní analyzer, který bude perfektně zpracovávat texty, v kterých vyhledáváne. Ukážeme si, jak v Elasticsearch vyhledávat i s překlepy, nebo jak naimplementovat našeptávač. Elasticsearch ale není jen fulltext, takže se také dostane na agregace a skriptování. V neposlední řadě se také podíváme na řazení výsledků - to totiž kromě samotné relevance může zohledňovat například popularitu produktu ve vašem e-shopu.

Kde jsem Elasticsearch používal?

S Elasticsearch jsem začal pracovat nejprve na slevovém portálu slever.cz, kde jsem řešil vyhledávání produktů, logování a základní analytiku (statistiky prodejnosti atd.). Následně jsem jej používal na projektu adboos.com pro ukládání a analýzu statistik stažených z PPC systémů. Poté jsem jej používal na atoto.cz, kde jsem s jeho pomocí implementoval vyhledávání alternativních košíků, fulltextové vyhledávání, našeptávání a základní sběr logů. Nyní s jeho pomocí vytvářím kontroly transakčích dat pro Sodexo, hojně jej také využíváme v Memsource, kde aktuálně pracuji.

Kromě toho o Elasticsearch publikuji články a věnoval jsem se mu i při psaní své diplomové práce, kdy jsem vytvářel fulltextové vyhledávání, které je poskytované jako služba.

Neváhejte se mi ozvat!

V případě zájmů o školení se mi neváhejte ozvat - veškeré kontaktní údaje jsou k dispozici na stránce s kontakty.

Luděk Veselý
E-mail: ludek.vesely@gmail.com
Tel.: 776 129 218

V tomto seriálu se budu snažit vysvětlit problematiku fulltextového vyhledávání a postupně jej implementovat pomocí nástroje Elasticsearch. Fulltextové vyhledávání je poměrně komplexní problematika, budu se ji tedy snažit rozdělit na několik samostatných částí a ty postupně projít.

Nebudu se zaměřovat na implementaci vyhledávacího nástroje pomocí konkrétního programovacího jazyka - knihovny pracující s Elasticsearch jsou obdobné napříč různými jazyky, a vesměs kopírují API, kterým disponuje Elasticsearch. Budu se snažit uvést i související teoretické znalosti - věřím, že hlubší znalost dané problematiky je užitečná k nalezení optimálního řešení problému.

V následujících dílech tohoto seriálu postupně projdu:

1. Základní pojmy
2. Instalace Elasticsearch
3. Ukládání a zobrazení dat
4. Fulltextové vyhledávání v češtině
5. Pokročilé fulltextové vyhledávání

Na konci tohoto seriálu byste měli být schopni implementovat fulltextové vyhledávání v českém jazyce s pomocí Elasticsearch. Veškeré zdrojové kódy jsou dostupné na GitHubu.

Trocha motivace úvodem

A jaké jsou hlavní důvody, proč použít pro vyhledávání právě Elasticsearch? Především má velké množství funkcí, kterými lze vyhledávání vytvořit přesně na míru danému účelu. Elasticsearch disponuje podporou češtiny a dalších jazyků, poradí si se skloňováním, časováním, synonymy nebo našeptáváním. Zároveň však disponuje základním nastavením pro řadu jazyků, s kterým vyhledávání obstojně funguje bez složitého nastavování.

Dalším důvodem pro jeho použití je rychlost, s kterou je možné vyhledávát. Omezením není ani rostoucí množství dat, Elasticsearch je možné jednoduše horizontálně škálovat, stačí přidat další servery do clusteru a Elasticsearch se o zbytek postará sám. S tím souvisí také to, že data mohou být automaticky replikována mezi servery, při výpadku některého z nich tak nedochází k výpadku celé služby ani ztrátě dat.

Fulltextovým vyhledáváním však funkce Elasticsearch nekončí. Lze jej využít pro výpočty nad nalezenými daty, která mohou být například použita pro vytvoření filtrů na webu. Dalším možným použitím je vytvoření nástroje pro ukládání logů ze všech možných zdrojů a následné vytváření vizualizací a dashboardů pomocí nástroje Kibana.

Pokud jste připraveni vrhnout se do tajů fulltextového vyhledávání a Elasticsearch poznat důkladněji, pokračujte prosím následující kapitolou.

S rostoucí popularitou Dockeru roste i popularita nástrojů pro orchestraci kontejnerů. Mezi všemi nástroji tak trochu vyčnívá Kubernetes. Zde je například vývoj zmínek o Kubernetes v otázkách na Stack Overflow:

Ke Kubernetes jsem se dostal při deploymentu nové verze portálu atoto.cz a ve srovnání s nástroji, které jsem používal předtím (Docker Cloud, Swarm, Docker Compose) mi připadal jako něco obřího a komplikovaného. S tím, jak přibývaly problémy, které bylo třeba řešit, začalo se ukazovat, jak je tato platforma promyšlená a proč je o ni stále rostoucí zájem.

V tomto článku se pokusím vypíchnout ty nejzásadnější body, které považuji za killer-features jsou to dle mého důvody, kvůli kterým stojí za to Kubernetes alespoň vyzkoušet.

Škálování, vysoká dostupnost

Klíčovou vlastností Kubernetes je to že sám řeší nasazování kontejnerů, sleduje jejich dostupnost a snaží se efektivně využít dostupné výpočetní kapacity a udržet tak aplikaci co nejdostupnější. Kubernetes vytváří abstrakci nad dostupným hradwarem, všechny připojené servery jsou dostupné jako by se jednalo o jeden stroj.

Využívá k tomu objekty, které mají různý účel. Na nejnižší úrovni se pracuje s pody, což je nejmenší samostatně nasaditelná část aplikace. V jejich rámci jsou provozovány kontejnery, které jsou vždy nasazeny společně. Pro optimální distribuci zátěže je možné definovat, kolik replik (podů) bude mít každá služba. Ty jsou pak rozloženy napříč jednotlivými servery (nody). V rámci clusteru pak může existovat více namespaců, lze tak nasazovat více nezávislých aplikací na jeden cluster.

Zero downtime deployment

Pokud nasazujete kontejnery do produkce, je třeba vymyslet mechanismus, jakým přepnout ze staré verze aplikace na novou. V případě samotného Dockeru je to poměrně obtížné - je třeba nakonfigurovat proxy, která směruje traffic na správný kontejner, poté nastartovat nový, následně přepnout proxy, pak ten starý odstranit... Nebo se prostě smířit s krátkým výpadkem.

V Kubernetes lze nasadit bez výpadku už jen pomocí správné konfigurace. Jednak je třeba nastavit readinessProbe (dokumentace). Pomocí této kontroly Kubernetes pozná, že je pod spuštěn (je nastartován web server atd.) a může na něj směřovat traffic. Druhou věcí je provedení Rolling Update. Pomocí tohoto nastavení Kubernetes ví, že má nejprve spouštět nové pody a průběžně vypínat ty staré, přičemž je definováno, kolik nejméně jich musí být v každou chvíli dostupných. Celá konfigurace deploymentu by pak vypadala následovně:

kind: Deployment  
apiVersion: extensions/v1beta1  
metadata:  
  name: rolling-update-deploy
spec:  
  replicas: 1
  template:
    metadata:
      labels:
        app: rolling-update-deploy
    spec:
      containers:
      - name: rolling-update-deploy
        image: gcr.io/google_containers/liveness
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

V tomto útržku kódu je důležité:

• Je použit image gcr.io/google_containers/liveness, pravděpodobně ale bude chtít použít svůj vlastní
• Kontrola probíhá zasláním HTTP požadavku na port 8080 a cestu /health, pro úspěch musí server vrátit kód 200
• Rolling update je pomocí maxSurge a maxUnavailable nastaven tak, že je vždy jeden funkční pod k dispozici

Samotný update aplikace pak probíhá následovně

• Je spuštěn nový pod
• Každých 5 s se posílá HTTP request na :8080/healthz
• Jakmile request vrátí kód 200, Kubernetes service směřuje komunikaci na nový pod
• Starý pod je odstraněn

Sdílení konfigurací, hesel, klíčů

V samotném Dockeru je problém s tím, jak hesla, tokeny nebo klíče. Lze je buď přímo psát do kódu aplikace, nebo ukládat do ENV prověnných, vždy je ale trochu problematické je sdílet napříč kontejnery.

Kubernetes využívá pro tento účel secrets, což jsou konfigurační soubory uložené v clusteru. Ty je pak možné připojit do kontejnerů jako volume dále s nimi pracovat.

Persistence dat, volumes

Přestože je Docker ideální pro běh bezstavových služeb, nevyhneme se nutnosti perzistence dat. Příkladem jsou databáze, u kterých je žádoucí, aby data v nich uložená přežila restart kontejneru.

V kuberntes je možné definovat volumes, které mohou být následně do kontejneru připojeny. Data tak mohou být uloženy na úložišti mimo cluster a není třeba se starat o to, na kterém serveru fyzicky existují. Takovým úložištěm může být GCE Persistent Disk, AWS EBS Volume nebo některé z dalších podporovaných úložišť.

Cron jobs, tasks

V praxi je kromě stále běžících služeb (databáze nebo webový server) nutné nasazovat skripty, které jsou pouštěny jednou, nebo v pravidelných intervalech. Na fyzickém serveru je pro tento účel typicky využit Cron, ve světě kontejnerů je však situace složitější. Možností je instalovat Cron přímo do kontejnerů, Kubernetes však tuto funkcionalitu nabízí sám o sobě.

V případě jednou spouštěných příkazů lze využít Jobs. V nich je definován kontejner, který běží do svého ukončení. Jejich speciální variantou jsou Cron Jobs, které navíc obsahují definici časů, kdy se mají spouštět.

Komunita, dokumentace

Kubernetes disponuje obsáhlou dokumentací, která popisuje veškerou dostupnou funkčnost. Ta je doplněna řadou tutoriálů, které usnadňují první kroky při seznamování s Kubernetes.

Díky stále rostoucí populárnosti Kubernetes existuje řada návodů, které oficiální materiály doplňují a popisují řešení konkrétních problémů. Na GitHubu je pak možné sledovat rapidní vývoj této platformy a řešit případné problémy.

Nevýhody

Samozřejmě, že Kubernetes neřeší všechny problémy jen tak a je třeba počítat s jistými nevýhodami, nebo spíše vlastnostmi tohoto nástroje. Každý už si musí zvážit, jestli pro jeho situaci bude vhodné použít Kubernetes, nebo se poohlédnout po jiném řešení.

Komplexnost

Kubernetes je rozsáhlý systém a jaho pochopení zabere nějaký čas. S tím je třeba počítat. Dokumentace je sice přesná a lze v ní nalézt vše potřebné, nicméně i její načtení nějaký čas zabere.

Může se také zdát, že triviální spuštění jednoho kontejneru je složité oproti spouštění přes Docker Compose. To, co v docker-compose.yml zabere pár řádků znamená v konfiguraci Kubernetes vytvoření deploymentu s šablonou podu, vytvoření service, případně dalších pomocných objektů.

Problém s komplexností se snaží řešit projekt Rancher, který tvoří jakousi obálku nad API Kubernetes a umožňuje s ním komunikovat skrz pěkné uživatelské rozhraní, které je navíc kompatibilní s konfiguračními soubory pro Docker Compose.

Nekompatibilita s Docker CLI a Compose

S komplexností systému souvisí i to, že je Kubernetes nekompatibilní se soubory docker-compose.yml a příkazy jako docker run .... To nebylo možné použít vzhledem k množství funkcí a konfigurací, které má Kubernetes navíc. Příkaz kubectl se prostě chová jinak a musíte se jej naučit používat. To může být problém, pokud používáte Docker na lokále i na produkci - najednou je třeba mít vše dvakrát.

Řešení jsou vzásadě tři - buď se naučit pracovat s kubectl a jiným formátem konfiguračních soborů, což je dle mého nejlepší řešení. Další možností je spustit si Kubernetes lokálně pomocí Minikube, v tu chvíli používám jeden nástroj u sebe i na produkci. Třetí možností je opět komunikovat s Kubernetes skrz Rancher. a použít tak stávající soubory docker-compose.yml.

Cena

Posledním aspektem, který je třeba zvážit, je cena provozu clusteru. Pokud si Kubernetes spouštíte na svém železe, nic se nemění, samotný Kubernetes je zdarma. Ve chvíli, kdy se člověk rozhodne přejít do cloudu, je cena za provoz serverů prostě vyšší - je třeba zvážit, zda je cena za přechod adekvátní.

Konkrétně přechod do Google Cloudu má řadu pozitiv - cluster je spuštěn během chvíle, není třeba se starat o provoz master nodu, aktualizace. Vše je snadno napojitelné na zbytek cloudu (úložiště, load balancery), snadno lze nastavit automatické škálování. Cena oproti stejně výkonnému serveru hostovanému u levnějšího providera je ale vyšší.

Zdroje

• Dokumentace Kubernetes - tutoriály, návody, popis API
• Google Container Engine (GKE) - Kubernetes spravovaný Googlem
• Rancher - orchestrace kontejnerů podporující Kubernetes
• E-book o nasazování Kubernetes pomocí Rancher

V rámci své diplomové práce jsem se rozhodl vytvořit nástroj, který bude poskytovat fulltextové vyhledávání jako služba, přičemž hlavní sílovou skupinou jsou e-shopy.

Typický případ použití vypadá následovně:

• Provozovatel e-shopu chce implementovat fulltextové výhledávání, má k dispozici data v XML formátu
• Zaregistruje se v službě a zadá URL souboru s produkty
• Následně obdrží přístup k API, vyhledávání na e-shop implementuje jako volání tohoto API

A proč by měl někdo takovou službu používat?

• Zpracování českého jazyka není triviální
• Implementace vyhledávání svépomocí zabere nějaký čas
• Rychlost vyhledávání je klíčová (s rostoucí zítěží a množstvím dat)

Video: Ukázka aplikace z pohledu uživatele

Detaily implementace

Pro samotné vyhledávání a ukládání dat jsem použil Elasticsearch z důvodu podpory velkého množství funkcí pro fulltextové vyhledávání, výkonnost a snadnou škálovatelnost. Veškerá funkčnost služby je dostupná přes API, přičemž aplikace je psaná v jazyce Go. Hlavním důvodem je rychlost - ať už jde o samotnou aplikaci, rychlost vývoje nebo deploymentu. Aplikace je nasazována automaticky pomocí CircleCI a její distribuce je řešena pomocí nástroje Docker. Zdrojové kódy jsou uloženy na GitHubu a dokumentace API je dostupná v nástroji Apiary.

Zdroje a odkazy

• Text diplomové práce v PDF
• Zdrojové kódy textu práce (LaTex)
• Zdrojové kódy aplikace na github.com
• Dokumentace API na apiary.com
• Nasazená aplikace (aktuálně pozastavena)
• Screencast, ukázka aplikace na youtube.com

Dokud vám na serveru běží pár kontejnerů, dají se jejich logy procházet ručně pomocí příkazu docker logs. S rostoucím počtem kontejnerů je ale obtížnější v logách něco najít. V tu chvíli může situaci usnadnit agregace logů. Jakmile máte logy na jednom místě, můžete v nich vyhledávat a filtrovat, je práce s nimi snažší. Jedním z nástrojů, který toto umožňuje se jmenuje Elastic Stack, dříve známý jako ELK Stack.

Pro absolvování tohoto tutoriálu předpokládám nainstalovaný Docker a docker-compose. Pokud jej ještě nemáte, postupujte podle oficiálního návodu. Tento článek předpokládá, že Docker běží nativně a kontejnery jsou dostupné přes localhost. Protože je ale tato funkčnost zatím oficiálně jen na Linuxu (pro OS X je ve verzi beta), je možné, že máte docker ve virtuálním stroji vytvořeným pomocí docker-machine. V tom případě nahraďte localhost ip adresou, kterou získáte pomocí docker-machine ip.

Elastic Stack

Elastic Stack sám o sobě není jediná aplikace, jde o sadu tří nástrojů, konkrétně se jedná o Elasticsearch, Logstash a Kibana. Ty bývají často použity společně (a například u Kibany by to ani jinak nešlo, protože se umí připojit jen na Elasticsearch).

Elastic stack oproti ELK stacku nenabízí prakticky nic nového, jde především o sjednocení verzí, nemusíte si tedy hlídat, které verze Elasticsearche, Kibany a Logstashe jsou vzájemně kompatibilní. Více na webu elastic.co. Pojďme se nyní podívat na jednotlivé části stacku.

Logstash

Logstash je nástroj, který umí vzít nějaký vstup, transformovat jej a následně jej někam uložit. Do konfiguračního souboru můžete zapsat všemožné kombinace vstupů, výstupů a filtrů. Vstupem může být soubor, data v Redisu nebo nějakém message brokeru. Můžete je také pouze nechat naslouchat na určeném portu a data mu dodávat z vaší aplikace, nebo použít nějaký jiný nástroj. Výstupem může být například Elasticsearch, soubor, standardní výstup... Popis všech možností by byl hodně dlouhý, odkážu radši na oficiální dokumentaci, kde můžete najít jak možné vstupy tak výstupy. Filtrem se rozumí různé transformace a parsování vstupních dat, například rozpadnutí záznamu v Apache access logu, CSV, JSONu...

Elasticsearch

Elasticsearch je škálovatelné úložiště, do kterého můžete uložit lobovolný dokument ve formátu JSON. Je bezschémový, nemusíte tedy předem definovat sloupce jako v relační databázi. Je také škálovatelný, stačí spustit více instancí, data se automaticky rozloží mezi nody a dotaz můžete poslat na kterýkoliv z nich. Disponuje velmi dobrým fulltextovým vyhledáváním, pro které bývá často primárně použit, to však v tomto případě nevyužijeme.

Kibana

Kibana je poslední částí, se kterou budete nakonec pracovat nejčastěji. Je to webové rozhraní, které umí číst data z Elasticsearche a z nich vytvářet grafy, tabulky, metriky. Nad vytvořenými dashboardy můžete fulltextově vyhledávat, filtrovat data. Vytvořený dashboard v Kibaně může vypadat například takto:

Spuštění Elastic Stacku

Protože budeme agregovat logy Dockeru, předpokládám, že máte Docker nainstalovaný. Spustit samotný Elastic Stack je otázkou vytvoření souboru docker-compose.yml a následným spouštěním pomocí nástroje docker-compose.

V soboru docker-compose.yml definuji tři sekce, z káždé následně vznikne jeden kontejner. Pro každou sekci využiji oficiální Docker image. Důležité je zpřístupnění portu 5601, abychom mohli otevřít Kibanu v browseru. V commandu logstashe je definováno jak bude spuštěn. Parametr -e znamená, že bude následovat konfigurace (která je jinak v souboru). V ní je definován jako vstup podt 5000 a jako výstup Elasticsearch. Vstupní port 5000 je také zveřejněn.

kibana:  
  image: kibana
  links:
    - 'elastic:elasticsearch'
  ports:
    - '5601:5601'
logstash:  
  image: logstash
  command: 'logstash -e "input { tcp { port => 5000 } } output { elasticsearch { hosts => elastic } }"'
  ports:
    - '5000/tcp:5000/tcp'
  links:
    - elastic
elastic:  
  image: elasticsearch

Uložte tento soubor a následně spusťte příkaz docker-compose up. Mělo by být vidět, jak jednotlivé služby startují:

Nyní zapíšeme do Logstashe jednu zprávu. Otevřete další terminál a zadejte:

nc localhost 5000 <<< "This is my log message"  

Zpráva This is my log message by měla být uložená v Elasticsearch. Nyní otevřete prohlížeč na adrese http://localhost:5601 a potvrďte výchozí nastavení. Dále přejděte do sekce Discover, měla by tam být vidět zalogovaná zpráva.

Pokud jste došli až sem, gratuluji, právě jste úspěšně spustili ELK Stack, zapsali zprávu do Logstashe, který ji uložil do Elasticsearche a následně zobrazili v Kibaně.

Propojení Dockeru a Elastic Stacku

Nyní stojíme před otázkou jak dostat logy kontejnerů do Logstashe. To je vzásadě možné několika způsoby:

1. Loguje samotná aplikace

Pokud máte v kontejneru vlastní aplikaci, můžete do ní doprogramovat zápis logů do Logstashe. Například v PHP pomocí Monologu - nastavíte adresu a port a vesele logujete. Zde je problém, jak získat ostatní logy, například webserveru nebo databáze. Lepší je dle mého všechny logy směřovat na standardní výstup a o sběr logů se postarat na úrovni Dockeru.

2. Aplikace loguje do souboru, Logstash jej čte jako vstup

Pokud už nyní logujete do souboru, nabízí se možnost jej zpřístupnit jako volume a Logstash nakonfigurovat, aby jej použil jsko vstup. Zde jsou problémy stejné jako výše, navíc je problém se sdílením souborů, pokud Docker běží na víc serverech.

3. Aplikace loguje na standardní výstup, logy sbírá další služba

Toto je lepší varianta - ke všem logům, které kontejnery produkují přistupuji jednotným způsobem. Ve výchozím stavu Docker zapisuje tyto logy jako JSON do filesystemu, zbývá tedy zajistit čtení těchto souborů.

4. Aplikace loguje na standardní výstup, kontejner má nastaveny logging-drivers

Obdoba předchozí varianty s tím rozdílem, že kontejneru při spuštění řeknete kam má logovat. Kontejner tak aktivně zapisuje logy na dané umístění, v předchozím případě je kontejner pasivní a logy jsou sbírány. Nahradíte tak výchozí logování do souboru ve formátu JSON. Tato funkčnost byla do Dockeru přidána ve verzi 1.6, aktuálně je k dispozici několik driverů, mezi issues na GitHubu jsem nalezl zmínku o driveru pro logstash, aktuálně je asi nejlepší variantou syslog.

Dále budu popisovat třetí variantu, protože umožní zapnutí logování nezávisle na běžících kontejnerech. Není teda nic měnit, jen se spustí další služba, která logy sbírá a přeposílá do Logstashe.

Sběr logů kontejnerů: logspout

Pro tento účel byl vytvořen nástroj logspout (GitHub, Docker Hub). Jde o připravený image, který se spustí, zpřístupní se mu socket docker démona skrz který čte logy všech běžících kontejnerů a přeposílá je dál. Automaticky zjišťuje nové kontejnery, takže existující stacky lze používat beze změny.

Propojení docker démona a logspoutu je pouze zpřístupněním souboru /var/run/docker.sock. Zbývá propojit logspout a Logstash. Logspout má několik adaptérů pro směřování výstupu: tcp, udp, syslog... Upravíme tedy soubor docker-compose.yml - doplníme sekci logspout:

logspout:  
  image: gliderlabs/logspout:v3
  command: 'udp://logstash:5000'
  links:
    - logstash
  volumes:
    - '/var/run/docker.sock:/tmp/docker.sock'
kibana:  
  image: kibana
  links:
    - 'elastic:elasticsearch'
  ports:
    - '5601:5601'
logstash:  
  image: logstash
  command: 'logstash -e "input { udp { port => 5000 } } output { elasticsearch { hosts => elastic } }"'
  links:
    - elastic
elastic:  
  image: elasticsearch

Dále jsem provedl změny v sekci logstash. Smazal jsem část s nastavením portů - k Logstashi přistupuje pouze logspout, což je automaticky zajištěno (kontenery v stacku na sebe vidí jako by byly na lokální síti), není tedy nutné ho zveřejňovat. Dále jsem upravil vstup Logstashe z tcp na udp. Nějakou dobu totiž trvá, než se Logstash spustí a pokud použiji spojení tcp, logspout ihned po spuštění skončí, protože se nemůže připojit na spouštějící se Logstash. UDP je nespojované spojení, logspout tak stále skouší zprávy poslat a je mu jedno, jestli na daném portu něco běží nebo ne, nevyžaduje žádné potvrzení.

Pokud vám ještě běžý starý stack, zabijte jej pomocí ctrl + c, případně i smažte kontejnery pomocí docker-compose rm -f. Nový stack spusťte opět příkazem docker-compose up.

Nyní jsou logy všech kontejnerů routovány přes logspout a Logstash do Elasticsearche. Můžeme zkusit spustit kontejner, který pouze zaloguje jednu zprávu a skončí:

docker run --rm alpine echo Hello world  

Pokud se podíváte do Kibany na http://localhost:5601, na záložce Discover by měla být vidět jako poslední zalogovaná zpráva Hello world:

Jistě jste si všimli spousty zpráv zalogovaných níže. Logspout automaticky přijímá logy všech kontejnerů, tedy i běžící Kibany, Logstashe a Elasticsearche. Pokud nechcete logy některého kontejneru zpracovávat, je třeba mu přidat proměnnou prostředí LOGSPOUT shodnotou ignore. To je možné doplněním do souboru docker-compose.yml. Funkční konfigurace, kdy jsou agregovány logy všech kontejnerů kromě spuštěného Elastic Stacku by tedy vypadala následovně:

logspout:  
  image: gliderlabs/logspout:v3
  command: 'udp://logstash:5000'
  links:
    - logstash
  volumes:
    - '/var/run/docker.sock:/tmp/docker.sock'
kibana:  
  image: kibana
  links:
    - 'elastic:elasticsearch'
  ports:
    - '5601:5601'
  environment:
    - LOGSPOUT=ignore
logstash:  
  image: logstash
  command: 'logstash -e "input { udp { port => 5000 } } output { elasticsearch { hosts => elastic } }"'
  links:
    - elastic
  environment:
    - LOGSPOUT=ignore
elastic:  
  image: elasticsearch
  environment:
    - LOGSPOUT=ignore

Přidání názvu kontejneru do logů

Pokud použijeme spojení logspoutu a Logstashe přes UDP, nezjistíme z jakého kontejneru logy pochází. Abychom to zjistili, je nutné použít jako adaptér syslog. Pro to je třeba upravit nastavení logspoutu i Logstashe. V případě logspoutu stačí upravit v docker-compose.yml část command: 'udp://logstash:5000' na command: 'syslog://logstash:5000'. Obdobnou úpravu je třeba provést na vstupu Logstashe - namísto input { udp { port => 5000 } } použít input { syslog { port => 5000 } }. Do message uložené v Elasticsearch se tak dostane několik dalších informací, mimo jiné název kontejneru a název stacku. Taková zpráva vypadá následovně:

2016-05-03T22:32:26.510Z 172.17.0.5 <14>1 2016-05-03T22:32:26Z 79445d78c31a hopeful_goldstine 1936 - - Hello world  

To však není úplně přehledné, je tedy ještě přidat sekci filter, která tuto zprávu zparsuje:

filter {  
  grok {
    match => { "message" => "%{SYSLOG5424PRI}%{NONNEGINT:ver} +(?:%{TIMESTAMP_ISO8601:ts}|-) +(?:%{HOSTNAME:service}|-) +(?:%{NOTSPACE:containerName}|-) +(?:%{NOTSPACE:proc}|-) +(?:%{WORD:msgid}|-) +(?:%{SYSLOG5424SD:sd}|-|) +%{GREEDYDATA:msg}" }
  }
  syslog_pri { }
  date {
    match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
  }
  mutate {
    remove_field => [ "message", "priority", "ts", "severity", "facility", "facility_label", "severity_label", "syslog5424_pri", "proc", "syslog_severity_code", "syslog_facility_code", "syslog_facility", "syslog_severity", "syslog_hostname", "syslog_message", "syslog_timestamp", "ver" ]
  }
  mutate {
    remove_tag => [ "_grokparsefailure_sysloginput" ]
  }
  mutate {
    gsub => [
      "service", "[0123456789-]", ""
    ]
  }
  if ("" in [msg]) {
    mutate {
      rename => { "msg" => "message" }
    }
  }
  mutate {
    remove_field => [ "tags" ]
  }
}

Tím se ale stane zápis v docker-compose.yml dost nepřehledný, lepší je si vytvořit vlastní image - napsat Dockerfile. Jeden takový jsem vytvořil, je dostupný na Docker Hubu. Kromě zpracování zprávy ve formátu syslogu umí i zpracovat JSON, je tedy možné upravit vaši aplikaci tak, aby logovala ve formátu JSON a Logstash to automaticky zpracuje. Konečný docker-compose.yml bude vypadat následovně:

logspout:  
  image: gliderlabs/logspout:v3
  command: 'syslog://logstash:5000'
  links:
    - logstash
  volumes:
    - '/var/run/docker.sock:/tmp/docker.sock'

logstash:  
  image: ludekvesely/logstash-json
  environment:
    - DROP_NON_JSON=false
    - STDOUT=false
  links:
    - elasticsearch

kibana:  
  image: kibana
  environment:
    - LOGSPOUT=ignore
  links:
    - elasticsearch
  ports:
    - '5601:5601'

elasticsearch:  
  image: elasticsearch
  environment:
    - LOGSPOUT=ignore

Nyní bude v Kibaně k dispozipi zalogovaná zpráva včetně názvu kontejneru a stacku. V případě, že byla zpráva ve formátu JSON, bude i ten zpracován. Ted už zbývá vytvořit par přehledných tabulek a grafů v Kibaně a uložit si je jako dashboard.

Poslední úpravou před spuštěním na produkci bude pravděpodobně nastavení volume pro Elasticsearch, aby data přežila restart kontejneru. Nezapomeňte zabezpečit Kibanu, aby nebylo přístupná celému světu (například pluginem do ES Shield/SearchGuard). Pokud nechcete Kibanu kontrolovat každý den, nastavte si notifikace (plugin do ES Watcher nebo ElastAlert).

Zdroje:

• http://nathanleclaire.com/blog/2015/04/27/automating-docker-logging-elasticsearch-logstash-kibana-and-logspout/
• https://blog.tutum.co/2015/05/26/log-searching-and-analysis-with-tutum-and-an-elk-2/
• https://www.zdrojak.cz/clanky/sber-logu-z-kontejneru
• http://www.slideshare.net/raychaser/6-million-ways-to-log-in-docker-nyc-docker-meetup-12172014
• http://pt.slideshare.net/sematext/docker-logging-webinar
• https://www.loggly.com/blog/top-5-docker-logging-methods-to-fit-your-container-deployment-strategy/

O Elasticsearch právě píši seriál, který určitě stojí za přečtení!

Elasticsearch je snadno škálovatelné úložiště umožňující pokročilé fulltextové vyhledávání, komunikace s ním probíhá skrz REST API. Komunikovat s ním pouze skrz terminál není úplně nejpřívětivější, existuje však několik nástrojů, které používání Elasticsearch zjednoduší. Toto je ucelený seznam všech nástrojů se kterými jsem se setkal.

Níže popisované nástroje jsou kompatibilní s Elasticsearch verze 2.x.x. U verze 5 a vyšší se některé věci změnily - Sense (a také Marvel) je součástí nástroje Kibana, Kopf není plugin, ale samostatná aplikace nazvaná Cerebro.

Management s grafickým rozhraním

Kopf

Kopf je webové rozhraní umožňující vizualizaci a správu Elasticsearch clusteru. Instalace je možná dvěma způsoby, buď jako plugin do Elasticsearch, nebo jako samostatná aplikace. Pokud máte Elasticsearch nainstalovaný lokálně, nejjednodušší je se přepnout do jeho složky a Kopf nainstalovat příkazem:

./bin/plugin install lmenezes/elasticsearch-kopf/2.1.1

Nyní by měl být Kopf přístupný zadáním adresy http://localhost:9200/_plugin/kopf do webového prohlížeče. Vidět je stav clusteru - zda je v pořádku (zelená/oranžová/červená lišta v záhlaví), jaké má nody (řádky tabulky), indexy (sloupce) a jak jsou rozmístěny shardy.

Kromě vizalizace lze Elasticsearch spravovat - vytvářet indexy, měnit nastavení, spravovat percolatory, aliasy, snapshoty, templaty... K dispozici je i stránka pro posílání requestů, která napovídá názvy indexů a umožňuje procházet historii proběhlých requestů. Více informací včetně detailního návodu k instalaci je na githubu.

ElasticHQ

Webové rozhraní umožňující správu Elasticsearch clusteru, funkčně je dost podobný Kopfu. Jsou celkem tři způsoby jak jej spustit - může běžet jako samostatná aplikace, plugin v Elasticsearch nebo lze spustit rovnou bez instalace v prohlížeči po zadání adresy http://www.elastichq.org/app/index.php?url=http://localhost:9200. Je však nutné mít povolené CORS v elasticsearch.yml.

Marvel

Pokud chcete vidět přesně co se v clusteru děje, sledovat detailně jednotlivé metriky, umí to právě Marvel. Aktuálně je bohužel instalace trochu složitější než dřív, což je způsobeno tím, že Marvel není zdarma. Nyní je součástí x-packu, který je nabízen jako balíček několika nástrojů, mezi něž Marvel patří. Ke stažení je na webu Elasticu, kde naleznete i dokumentaci.

Vizualizace

Kibana

Kibana je nástroj umožňující vizualizaci dat uložených v Elasticsearch ve webovém prohlížeči. Je to samostatná aplikace, kterou lze stáhnout z webu Elasticu. Po stažení a rozbalení archivu stačí v konzoli spustit příkazem ./bin/kibana ve složce s rozbaleným archivem. Dostupná pak bude v prohlížeči na adrese http://localhost:5601.

V záhlaví jsou čtyři položky:

• Discover: Vyhledávání a výběr sloupců v tabulce
• Visualize: Vytvoření vizualizace (grafu/tabulky/mapy/...) z uloženého nebo nového vyhledávání
• Dashboard: Několik uložených vizualizací nebo vyhledávání na jedné stránce
• Settings: Nastavení (pattern pro výběr indexu, nastavení polí, import/export)

Sama o sobě je Kibana silný nástroj umožňující vytvořit vizualizace z dat několika kliknutími, ty je pak možné vložit jako iframe do jiné aplikace, nebo jen použít dotaz, který kibana vygenerovala. Rozšiřitelná je pomocí řady pluginů. Veškeré informace i Kibaně jsou pak dostupné v dokumentaci

Grafana

Grafana je primárně určena pro vizualizaci dat z InfluxDB, nicméně se umí napojit i na Elasticsearch. Vizuálně je dost podobná starší Kibaně. Pokud máte data uložená ve více databázích, může pro vás být Grafana tou pravou volbou. Více na grafana.org.

Dotazování

Sense

Sense byl dříve samostatnou aplikací, nyní je dostupný jako plugin do Kibany. Je to konzole umožňující komunikovat s Elasticsearchem - vytvářet requesty, číst odpovědi. Přestože už je obdobná funkčnost v Kopfu, Sense má jednu důležitou výhodu - našeptávání.

Je to asi nejpohodlnější způsob, jak psát dotazy na elasticsearch. Všechny jeho možnosti jsou pak popsané v dokumentaci.

Postman

Postman není určen primárně pro použití s Elasticsearch, je to nástroj umožňující komunikovat obecně s jakýmkoli API. Dostupný je jako rozšíření pro Google Chrome nebo jako samostatná aplikace pro OS X. Výhodou je možnost si requesty ukládat pro budoucí použití, případně automatizovat jejich spouštění.

Adminer

Nesmím zapomenout zmínit také český nástroj Adminer Jakuba Vrány. Ten od verze 4 podporuje také NoSQL databáze, mezi něž Elasticsearch spadá. Adminer jsem zkoušel, ale měl problém s zobrazením složitějších dat v tabulce. Od té doby jsem jej nezkoušel, takže je možné, že v současné verzi už budou tyto problémy odladěny. Stažení je možné na webu adminer.org.

Management - konzolové nástroje

ElasticDump

Elasticdump je konzolový nástroj umožňující import a export dat z/do Elasticsearch. Je to vpodstatě taková obdoba Mysqldumpu. Nevýhodou je, že vyžaduje npm. Pokud ale chcete rychle zálohovat menší množství dat, nebo dostat data z produkce na lokál, může elasticdump dobře posloužit. Více na npmjs.com.

# instalace
npm install elasticdump -g

# dump indexu do souboru (vytvoreni zalohy)
elasticdump \  
  --input=http://production.es.com:9200/my_index \
  --output=/data/my_index_mapping.json \
  --type=mapping
elasticdump \  
  --input=http://production.es.com:9200/my_index \
  --output=/data/my_index.json \
  --type=data

# stazeni dat z produkce na lokal
elasticdump \  
  --input=http://production.es.com:9200/my_index \
  --output=http://localhost:9200/my_index \
  --type=mapping
elasticdump \  
  --input=http://production.es.com:9200/my_index \
  --output=http://localhost:9200/my_index \
  --type=data

Alternativou by mohl být elasticsearch-tools. Nabízí podobnou funkčnost jako elasticdump, nemám s ním ale zkušenosti.

Curator

Pokud vytváříte denní indexy (logstash-2016-05-01, logstash-2016-05-02, ...), pravděpodobně budete chtít ty staré uzavírat nebo rovnou mazat. Nástroj který to umí automaticky se jmenuje Curator a je přímo od Elasticu. Více informací o tom jak ho použít naleznete v oficiální dokumentaci, případně na GitHubu.

Notifikace

Předposlední kategorií jsou nástroje umožňující zasílat notifikace na základě událostí uložených v Elasticsearch. Příkladem může být například zaslání e-mailu, pokud počet chyb aplikace (které si ukládáte do ES) vzroste nad určitou hodnotu. Nástroje, které toto umožňují jsou dva a liší se tím, že jeden je přímo od Elasticu a je placený (Watcher), zatímco druhý je opensource (ElastAlert).

Elastic Watcher

• Web
• Dokumentace

ElastAlert

• Repozitář na GitHubu
• Dokumentace

Zabezpečení

Pokud chcete data v Elasticsearch někomu zpřístupnit, ale nechcete mu dát plný přístup k clusteru, je třeba použít některý z nástrojů, který jej zabezpečí. Například lze po zadání hesla umožnit přístup pouze k určitému indexu a to pouze pro čtení. Situace je podobná jako v případě nástrojů pro notifikace - jsou dva, z toho jeden oficiální ale placení a druhý opensource.

Elastic Shield

• Web
• Dokumentace

SearchGuard

• Web
• GitHub

To jsou nástroje, které vám mohou zpříjemnit soužití s Elasticsearch. Víte o nějakém zajímavém nástroji, který zde chybí? Podělte se o něj v diskuzi!

Málokdo používá Docker tak že si spustí nějaký základní image, provede změny a zavolá docker commit. Většinou napíšete Dockerfile, ve kterém je definované, jak se má požadaný image vytvořit. Díky tomu je možné build automatizovat, provádět na integračním serveru a opakovaně. Usnadní to třeba aktualizaci nástrojů na požadovanou verzi (nedávno jsem aktualizoval Elasticsearch a nebylo to tak hrozné). Díky kešování výsledků mezikroků to ani není moc pomalé. Přesto je třeba si uvědomit pár základních věcí a využít tak možnosti Dockeru naplno.

Vhodně zvolený base image

Na začátku každého Dockerfile stojí FROM .... Dost lidí nad tím očividně nepřemýšlí a zvolí nějakou linuxovou distribuci, nejčastěji Ubuntu. Schválně se podívejte na GitHub, kolikrát soubor Dockerfile obsahuje FROM ubuntu. Pokud vyhledáte všechny soubory Dockerfile, zjistíte, že z přibližně 170 000 nalezených souborů jich asi 50 000 obsahuje frázi FROM ubuntu. Výsledky nelze brát uplně přesně, nelze totiž vyhledávat pomocí přesné shody, jako ukazatel ale postačí. Navíc zde nejsou započitány image které jako základ použijí image který používá Ubuntu.

Co je na tom špatného? Proč nepoužít operační systém který dobře znám, na serveru už jej dávno mám a vidím jej často i u oficiálních obrazů? Je třeba si uvědomit, že v době vzniku Ubuntu a podobných distibucí (CentOS, Debian, ...) byl Docker vzdálenou budoucností a distribuce mezitím dost nabobtnaly. Nesou si tak s sebou spoustu nástrojů, které se na serveru můžou hodit, ale v běžícím kontejneru je vůbec nevyužijete. Poslat celý image Ubuntu po internetu tak chvíli zabere, instalace jediného nástroje trvá věčnost, s využitím RAM to také není úplně růžové. Jak z toho ven?

FROM alpine  

Řešením je jako základ použít Alpine Linux. Jedná se o minimální verzi linuxu (5MB!) s připraveným balíčkovacím nástrojem. V dokumentaci mají příklad, který dokonale popisuje jak problém řeší. Chci vytvožit image s nainstalovaným MySQL klientem, abych se mohl přihlásit k MySQL databázi. Nic víc, nic míň, jen jeden balíček. V případě použití Ubuntu by Dockerfile vypadal následovně:

FROM ubuntu-debootstrap:14.04  
RUN apt-get update -q \  
  && DEBIAN_FRONTEND=noninteractive apt-get install -qy mysql-client \
  && apt-get clean \
  && rm -rf /var/lib/apt
ENTRYPOINT ["mysql"]  

Sestavit image trvalo 19 vteřin a jeho výsledná velikost je 164 MB. S použitím Alpine by to vypadalo následovně:

FROM gliderlabs/alpine:3.3  
RUN apk add --no-cache mysql-client  
ENTRYPOINT ["mysql"]  

Build za 3 vteřiny a velikost image je 36 MB (Zdroj). Představte si že chcete mít v kontejneru každý konzolový příkaz, který vám na serveru běží na pozadí - najednou použití Dockeru dává větší smysl. Použití Alpine s sebou nese určité změny oproti Ubuntu - místo shellu BASH je použit ASH a balíčky se instalují pomocí apk místo apt-get.

Minimalizace počtu příkazů v Dockerfile

Zejména se to týká příkazu RUN použitého opakovaně za sebou. Podívejme se na tento Dockerfile:

FROM alpine  
RUN apk update  
RUN apk add php-cli  
RUN apk add wget  
RUN wget http://domain.com/run.php  
ENTRYPOINT ["php" "run.php"]  

Co je zde špatně? Nejprve je třeba si uvědomit, jak Docker image vytváří. Po provedení každého image vzniká jeho nová vrstva, která se jakoby nabalí na tu předchozí. Vlastně taková sněhová koule valící se z kopce. Problém je, že každá vrstva se uloží. K čemu ale potřebuji výsledek apt-get install wget, který mi sloužil jen ke stažení souboru v následujícím kroku? Lepší by bylo příkaz nainstalovat, stáhnout soubor a opět odinstalovat (pominu fakt, že by šel nahradit příkazem ADD), přičemž po odinstalaci by bylo dobré dostranit i všechny dočasné soubory. Nelze také opominout režiji spojenou s zpraováním jednotlivých vrstev. Lepší by tedy bylo všechny příkazy provést v jednom kroku:

FROM alpine  
RUN apk update && \  
    apk add php-cli && \
    apk add wget && \
    wget http://domain.com/run.php && \
    apk del wget && \
    rm -rf /tmp/* && \
    rm -rf /var/cache/apk/*
ENTRYPOINT ["php" "run.php"]  

Pokud by to působilo Dockerfile nepřehledným, lze vytvořit shellový skript (například install.sh) a v Dockerfile ho přidat a spustit:

FROM alpine  
COPY install.sh /install.sh  
RUN bash /build.sh  
ENTRYPOINT ["php" "run.php"]  

Vhodné pořadí příkazů

Docker při buildu ve výchozím nastavení používá cache pro každou vrstvu image. Jakmile dostane příkaz (například COPY install.sh /install.sh), nejprve zjistí, zda již nemá výsledek a pokud ano tak jej použije. Při COPY souboru sjistí jeho hash, porovná s keší a případně použije již existující výsledek. Pokud u jednoho příkazu nepoužije keš, platí to i pro všechny následující příkazy. Toho je třeba maximálně využít a to co se často mění přesunout na konec Dockerfile. Takto například vypadá nevhodný image:

FROM alpine  
COPY run.php /run.php  
RUN apk update && \  
    apk add php-cli && \
    rm -rf /tmp/* && \
    rm -rf /var/cache/apk/*
ENTRYPOINT ["php" "/run.php"]  

V čem je problém? Při změně zdrojového kódu v souboru run.php, což Docker zjistí hned na druhém řádku, musí provést i všechny další kroky, tedy nainstalovat PHP. Předpokládám ale, že zdrojové kódy se mění vždy, kdežto nový balíček s PHP nevychází příliš často. Lepší tedy bude instalaci PHP přesunout na začátek a při dalších buildech jej vůbec neinstalovat, ale využít cache:

FROM alpine  
RUN apk update && \  
    apk add php-cli && \
    rm -rf /tmp/* && \
    rm -rf /var/cache/apk/*
COPY run.php /run.php  
ENTRYPOINT ["php" "/run.php"]  

To že se používá cache je vidět v logu Dockeru. Pokud spustíte docker build, u každého kroku uvidíte buď running in... (není použita cache) nebo using cache (je použita).

Co nejjednodušší kontejnery

Filozofii Dockeru nejlépe odpovídá situace, kdy je v něm spuštěn jeden proces, ten produkuje log na standardní výstup a končí odpovídajícím návratovým kódem. Chápu, že ne vždy je to možné, ale je dobré takto přemýšlet a pokud se rozhodnu mít v kontejneru více procesů, měl bych pro to mít dobrý důvod. Já takhle používám NGINX a PHP-FPM, protože mi jeden bez druhého nedávají smysl a nechci řešit restart a deploy každého kontejneru zvlášť. Podobné je to s logováním - nepřijde mi dobrý nápad řešit uvnitř kontejneru kam bude logovat, prostě vypisuji na standardní výstup a o sběr logů ať se postará někdo jiný. Pro tento účel používám Logspout a pokud vypadne, neovlivní to nijak chod ostatních kontejnerů.

Další postřehy

COPY vs ADD

Moc jsem nechápal rozdíl mezi ADD a COPY, z dokumentace jsem byl trochu zmatený:

ADD:

The ADD instruction copies new files, directories or remote file URLs from <src> and adds them to the filesystem of the container at the path <dest>.

COPY:

The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>.

V praxi jde o to, že ADD umí to samé co COPY, navíc ale ještě umí:

• načíst soubor z URL (není tedy třeba instalovat wget/curl)
• rozbalit některé archivy (není tedy třeba volat tar xvf ...)

V některých starších verzích Dockeru bylo COPY označené jako deprecated, to ale neplatí a pokud nevíte který zvolit, stačí se držet jedním pravidlem:

• pokud to jde použít COPY

ENTRYPOINT vs CMD

Definici příkazu který se má provést při spuštění kontejneru jsem viděl více způsoby - pomocí ENTRYPOINT, CMD, v hranatých závorkách i bez nich. Jak to tedy je? Uvedu příklad:

ENTRYPOINT ["/bin/bash"]  
CMD ["ls"]  

Zde se při spuštění kontejneru provede /bin/bash ls. Oba příkazy se tedy spojí a provedou jako jeden příkaz. CMD lze definovat při spuštění kontejneru, měl by tedy obsahovat něco, co se může měnit.

Lze také vynechat hranaté závorky, co se stane? Pokud bychom zapsali ENTRYPOINT ["/run.sh"], provedlo by se /run.sh. Pokud ale zapíšeme ENTRYPOINT run.sh, provede se /bin/sh -c /run.sh. Více k tématu naleznete v dokumentaci.

Závěrem

Také jste se setkali s nějakými záludnostmi při psaní Dockerfile? Podělte se o ně! Protože je dobré si informace načíst z více zdrojů, přihodím pár odkazů.

• Best practises for writing Dockerfiles přímo od Dockeru
• Další seznam best practises
• Dockerfile reference - naprostý základ
• Image postavený na Alpine řešící některé známé problémy
• Další užitečné image postavené na Alpine Linux: Java, Redis, PHP, Elasticsearch s českým slovníkem

Update: tento článek je mírně zastaralý, Tutum je přejmenován na Docker Cloud a má nové grafické rozhraní.

Pokud máte aplikaci psanou v PHP, je možné její deployment řešit několika způsoby. Například můžete rozběhnout prostředí ručně připojením na server přes SSH, použít automatizovaný nástroj typu Puppet nebo Chef, použít některý z dostupných PAAS. Pokud ale chcete mít vše ve svých rukách a zároveň si chcete práci maximálně zjednodušit (například u nás je pro běh aplikace vyžadován NGINX, PHP, RabbitMQ, Elasticsearch, Redis, Nodejs, Phantomjs a databáze Percona), nabízí se použití Dockeru. To s sebou nese řadu výhod:

• Spuštění celého prostředí je možné "jedním příkazem"
• Služby jsou izolované, paralelně mi tedy může běžet například databáze v různých verzích
• Konfiguraci lze snadno přenést na testovací nebo produkční server, vždy mám jistotu že je vše stejné
• Proces je možné automatizovat

Je však třeba počítat i s nevýhodami tohoto řešení. Některé Docker image nejsou úplně optimálně vytvořené a jsou tak zbytečně velké, což v kombinaci s pomalým připojením k internetu může trochu zdržovat. Je také třeba počítat, že použití Dockeru o něco zvýší využití procesoru a paměti.

Předpoklady

Tento článek je rozdělený na několik částí - nejprve spustíme webserver s PHP aplikací lokálně, následně totéž spustíme na serveru a nastavíme automatický deployment při každé změně kódu. Nakonec nastíním možnosti další využití a škálování nasazené aplikace.

Pokud si budete chtít spustit kontejnery lokálně, uude třeba nainstalovat Docker a Docker Compose a git. K sdílení kódu bude použit GitHub, bude tedy třeba mít účet na GitHubu (pokud chcete deployovat vlastní kód). Dále předpokládám server s operačním systémem Linux (Ubuntu, Debian, CentOS nebo Fedora).

Spuštění prostředí lokálně

Pokud vás zajímá samotný deployment na produkci a nachcete si hrát s Dockerem lokálně, tuto kapitolu klidně přeskočte.

Prvním krokem je spustit Nette Quickstart lokálně. Tato aplikace pro svůj běh vyžaduje webserver s PHP a databázi MySQL. Předpokládám že máte nainstalovaný Docker, pokud ne, postupujte podle oficiálního návodu. Dalším nástrojem, který budeme potřebovat je Docker Compose, který umožňuje spuštění a propojení několika kontejnerů pomocí jediného konfiguračního souboru. Ověříme, že oba nástroje máme v pořádku nainstalované:

bash-3.2$ docker -v  
Docker version 1.7.1, build 786b29d  
bash-3.2$ docker-compose -v  
docker-compose version: 1.3.0  
CPython version: 2.7.9  
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014  

Stažení zdrojových kódů aplikace

Prvním krokem je stažení zdrojových kódů aplikace. Já jsem si vytvořil fork quickstartu, do kterého následně přidám nové soubory. Můžete ale zkusit libovolnou PHP aplikaci.

V terminálu se přepneme do požadované složky a pomocí gitu zdrojové soubory naší aplikace stáhneme z GitHubu (můžete stáhnout můj fork).

bash-3.2$ git clone git@github.com:ludekvesely/tutorial-quickstart.git  
Cloning into 'tutorial-quickstart'...  
remote: Counting objects: 236, done.  
remote: Total 236 (delta 0), reused 0 (delta 0), pack-reused 236  
Receiving objects: 100% (236/236), 349.68 KiB | 0 bytes/s, done.  
Resolving deltas: 100% (82/82), done.  
Checking connectivity... done.  
bash-3.2$ cd tutorial-quickstart/  
bash-3.2$ ls -l  
total 104  
drwxr-xr-x   8 ludekvesely  staff    272 Dec 29 02:16 app  
-rw-r--r--   1 ludekvesely  staff    829 Dec 29 02:16 composer.json
-rw-r--r--   1 ludekvesely  staff  39125 Dec 29 02:16 composer.lock
-rw-r--r--   1 ludekvesely  staff   7233 Dec 29 02:16 database.sql
drwxr-xr-x   3 ludekvesely  staff    102 Dec 29 02:16 log  
drwxr-xr-x   3 ludekvesely  staff    102 Dec 29 02:16 temp  
drwxr-xr-x   4 ludekvesely  staff    136 Dec 29 02:16 tests  
drwxr-xr-x  11 ludekvesely  staff    374 Dec 29 02:16 www  

Zdrojové kódy máme stažené a nyní bude třeba vytvořit kontejner, ve kterém aplikace poběží.

Vytvořejí kontejneru s Apache a PHP

Kontejner je spuštěná image, my tedy nejprve musíme vytvořit image, kterou budeme moci spustit. Při vytváření Docker image je dobré se nejprve podívat, zda už nějaký vhodný neexistuje. Začít vyhledávat je možné na adrese hub.docker.com. My použijeme image s připraveným Apache a PHP, který spravuje společnost tutum.co (využijeme ji pak pro deploy), můžete jej najít na docker hubu a jeho zdrojové kódy na githubu.

V rootu aplikace vytvoříme soubor Dockerfile. Jeho obsah bude vypadat následovně:

FROM tutum/apache-php

RUN apt-get update && apt-get install -yq git php5-sqlite && \  
    rm -rf /var/lib/apt/lists/* && rm -fr /app

COPY . /app

RUN chmod 777 log temp && \  
    composer install && \
    rm -rf composer* Dockerfile .git && \
    sed -i "s/DocumentRoot \/var\/www\/html/DocumentRoot \/var\/www\/html\/www/g" /etc/apache2/sites-available/000-default.conf

ENV ALLOW_OVERRIDE true  

Co to ten Dockerfile je, k čemu a jak se použije? Je to vpodstatě seznam příkazů, který se provede před spuštěním webserveru. Můžete si to představit jako když máte server s čistou instalací a toto je posloupnost kroků, které se musí provést před spuštěním aplikace. Určitě vás napadne, jestli není zbytečné a pomalé pokaždé provádět apt-get install. Každý příkaz v Dockerfile se provede a uloži jako další vrstva vytvářeného obrazu. Před vykonáním každého kroku Docker zkontroluje, zda je opravdu nutné ho provést - například před kopírováním souboru si porovná jeho hash s cachovaným hashem z minulosti a krok provede až pokud se liší, v opačném případě pouze použije vrstvu, kterou již v minulosti vytvořil.

Projděme si jednotlivé části Dockerfile. Zápis FROM tutum/apache-php značí, z kterého image je Dockerfile odvozený. Vpodstatě to znamená, že tento Dockerfile končí tam, kde předchozí skončil - podívat se na něj můžete na GitHubu.

Následující řádky začínající RUN apt-get update && apt-get install -yq git php5... nainstalují nástroje potřebné k rozběhnutí aplikace. Nette vyžaduje php5-sqlite, nakonec smažeme nepotřebné soubory. Za RUN může přijít jakýkoliv příkaz, který bude spuštěn v bashi.

Příkaz COPY . /app nakopíruje kód aplikace do image, . značí aktuální adresář (tedy složky app, temp, log, www...), je možné uvést adresář nebo konkrétní soubor, /app značí kam se soubory nakopírují.

Následně řádky začínající RUN chmod 777 log temp... nastaví potřebná práva nakopírovaným adresářům, odstraní nepotřebné soubory (adresář .git nemá na produkci co dělat) a pomocí sedu provede změny konfigurace Apache.

Posledním krokem ENV ALLOW_OVERRIDE true je nastavení proměnné ALLOW_OVERRIDE na true. Ta je pak v kontejneru vždy dostupná - můžeme k ní přistupovat jako k jakékoliv jiné proměnné, například ji vypsat příkazem echo $ALLOW_OVERRIDE. Po spuštění kontejneru je ale spuštěn tento soubor, kde se na základě této proměnné povolí mod rewrite.

Dockerfile a zdrojové kódy apikace máme připraveny, můžeme tedy provést build. Ve rootu aplikace spustíme docker build -t nette-quickstart .. Parametr -t značí, jak si výsledný image pojmenujeme (jaký bude mít tag). Důležitá je tečka na konci, kdy se build provede v aktuálním adresáři, kde je také očekáván Dockerfile.

bash-3.2$ docker build -t nette-quickstart .  
Sending build context to Docker daemon 523.3 kB  
Sending build context to Docker daemon  
Step 0 : FROM tutum/apache-php  
 ---> cdced04212b6
Step 1 : RUN apt-get update && apt-get install -yq php5-sqlite &&     rm -rf /var/lib/apt/lists/* && rm -fr /app  
 ---> Running in dfce886a3ceb
Ign http://archive.ubuntu.com trusty InRelease  
Get:1 http://archive.ubuntu.com trusty-updates InRelease [64.4 kB]  
Get:2 http://archive.ubuntu.com trusty-security InRelease [64.4 kB]

...

Processing triggers for libapache2-mod-php5 (5.5.9+dfsg-1ubuntu4.14) ...  
 ---> 0af4e3fa2efe
Removing intermediate container dfce886a3ceb  
Step 2 : COPY . /app  
 ---> 3f09c2f8c42c
Removing intermediate container fc3e65c222c1  
Step 3 : RUN chmod 777 log temp &&     composer install &&     rm -rf composer* Dockerfile .git &&     sed -i "s/DocumentRoot \/var\/www\/html/DocumentRoot \/var\/www\/html\/www/g" /etc/apache2/sites-available/000-default.conf  
 ---> Running in 22809fbf0bb1
Warning: This development build of composer is over 60 days old. It is recommended to update it by running "/usr/local/bin/composer self-update" to get the latest version.  
Loading composer repositories with package information  
Installing dependencies (including require-dev) from lock file  
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.  
  - Installing dg/adminer-custom (v1.6.1)
    Downloading: 100%

...

  - Installing nette/tester (v1.4.0)
    Downloading: 100%

nette/utils suggests installing ext-intl (for script transliteration in Strings::webalize() and toAscii())  
Generating autoload files  
 ---> e026f4842c1c
Removing intermediate container 22809fbf0bb1  
Step 4 : ENV ALLOW_OVERRIDE true  
 ---> Running in f59173c8afee
 ---> 8e15d5de7d02
Removing intermediate container f59173c8afee  
Successfully built 8e15d5de7d02  

Ve výstupu můžete vidět, že pro každý příkaz v Dockerfile je následně proveden jeden krok, odtud například Step 4 : ENV ALLOW_OVERRIDE true v logu. Pokud build spustíme znovu, pod každým krokem uvidíme ---> Using cache, což znamená, že Docker nezjistil změnu a pokračuje dalším krokem. Jakmile ale upravíme jediný soubor, v kroku COPY . /app zjistí pomocí kontrolního součtu změnu a tento a následující kroky už jsou provedeny. Z toho vyplývá, že věci, které se často nemění (instalace nástrojů, nastavení proměnných) je dobré mít před věcmi, které se mění často (např. nakopírování zdrojových kódů aplikace).

Image máme připravený, zbývá ho jen spustit. To provedeme příkazem docker run --rm -p 8012:80 nette-quickstart. Po zadání příkazu se spustí kontejner a uvolní svůj port 80, ukončit jej můžeme zkratkou ctrl + c. Parametr --rm značí, že bude po ukončení kontejner automaticky odebrán a můžeme jej tak spustit znovu. Parametr -p definuje které porty kontejneru mají být zveřejněny (zde port 80, na kterém běží Apache) a pod jakým portem mají být zveřejněny (zde 8012, pod kterým bude webová stránka dostupná v prohlížeči). Pokud bysme jej nezadali, zvolí se náhodný volný port.

Spuštěný kontejner lze dobře prohlédnout pomocí nástroje Kitematic, pokud jej nemáte nainstalovaný, zkuste můj návod.

Zde lze prohlížet log (který je i v terminálu), náhled webové stránky a nastavení kontejneru. A co zde není zajímavého - server error v náhledu webové stránky! Jak ale zjistit v čem je problém, jak se dostat do kontejneru? Ideální by bylo, kdyby byly chyby vidět přímo v logu, samotné logování by ale vydalo na samostatný článek, nyní si ukážeme, jak ladit běžící kontejner. V horní liště má Kitematic možnost EXEC, klikneme na ni a otevře se terminál v běžícím kontejneru. Nyní můžu prohlížet a editovat soubory, spouštět příkazy... Podíváme se co Tracy zalogovala:

# cat log/exception.log
[2015-12-31 01-08-09] Nette\Database\ConnectionException: SQLSTATE[HY000] [2003] Can't connect to MySQL server on '127.0.0.1' (111) in /app/vendor/nette/database/src/Database/DriverException.php:25 caused by PDOException: SQLSTATE[HY000] [2003] Can't connect to MySQL server on '127.0.0.1' (111) in /app/vendor/nette/database/src/Database/Connection.php:70  @  http://192.168.99.100:8012/  @@  exception-2015-12-31-01-08-09-377469fd79b0ea3f7414b9d5d0198f74.html

Z logu je patrné, že se aplikace nemůže připojit k databázi, protože žádná neběží.

Spuštění MySQL databáze a propojení s webserverem

Spustit databázi můžeme dvěma způsoby - buď ji nainstalovat do existujícího kontejneru a oba procesy držet při životě nějakým správcem procesů (například supervisord), jak to tutum dělá ve svém image LAMP. Druhou variantou je spustit nový kontejner s databází a oba pak propojit. Filozofii dockeru lépe odpovídá druhá varianta. Obecně je lepší držet kontejnery co nejmenší a nejjednodušší. V jednom kontejneru by měl ideálně běžet jeden proces, lépe se pak kontejnery udržují, pokud vše dáme do jednoho kontejneru, vytrácí se pak výhody, které Docker přináší. To, jaké všechny kontejnery budeme spouštět a jak je mezi sebou propojíme nám usnadní Docker Compose, kde celou sadu kontejnerů definujeme v souboru docker-compose.yml, který bude vypadat následovně:

web:  
  build: .
  links:
    - db
  ports:
    - "80"
db:  
  image: tutum/mysql
  environment:
    STARTUP_SQL: "/tmp/database.sql"
    ON_CREATE_DB: test
    MYSQL_PASS: testpass
  volumes:
    - ./database.sql:/tmp/database.sql:ro

Tento yml soubor má dvě sekce - web a db. Dle sekce web by se měl provést build v aktuálním adresáři (tak jak jsme provedli příkazem docker build...). Zveřejní se port 80 a připojena bude k službě db. Ta je definována v další sekci a vychází z image tutum/mysql. V proměnných jsou definovány přihlašovací údaje a název databáze. Důležitá je část volumes, kde je definováno že soubor database.sql bude připojen do kontejneru jako /tmp/database.sql v režimu read-only. V proměnné STARTUP_SQL je pak definována cesta právě k tomuto souboru a použije se při inicializaci databáze.

Ještě musíme nastavit připojení k databázi v aplikaci úpravou souboru app/config/config.local.neon.

database:  
  dsn: 'mysql:host=db;port=3306;dbname=test'
  user: admin
  password: testpass
  options:
    lazy: yes

Nyní můžeme zavolat příkaz docker-compose up a oba kontejnery se spustí a propojí. V Kitematic by měly být oba kontejnery vidět a web by měl jít otevřít v prohlížeči.

Tímto jsme schopni spustit PHP aplikaci v Dockeru, připravit databázi a kontejnery propojit, vše jediným příkazem docker-compose up. Pokud vám něco uniklo, podívejte se na tento commit. Kód můžeme pushnout na github a zavřít terminál, pro deployment na server už nám bude stačit jen webový prohlížeč.

Deployment aplikace na produkci

Pro spuštění aplikace na serveru by bylo možné se na něj přes SSH připojit, nainstalovat Docker, stáhnout kód a spustit kontejnery. Existuje však služba Tutum, která toto všechno umí skrze webový prohlížeč a celý proces nasazení aplikace automatizovat a monitorovat.

Přihlaste se na adrese https://dashboard.tutum.co/accounts/login/ - můžete pomocí účtu na Docker Hubu, GitHubu nebo pomocí vlastní e-mailové adresy.

Po vytvoření účtu ho musíme propojit s GitHubem a serverem.

Propojení Tutum a serveru

Nejprve musíme propojit server s Tutum, aby bylo kam deployovat - to je možné na záložce Nodes. Můžete si přidat účet například z Amazonu a servery tak vytvářet rovnou z rozhraní Tutum. Pokud ale už máte server vlastní, zvolte možnost Bring your own node.

Přihlaste se na server přes SSH a spusťte zkopírovaný příkaz. Nainstaluje se docker a všechny nástroje nutné pro chod Tutum.

Propojení Tutum a GitHubu

Pro propojení s GitHubem klikněte na záložku Repositories, propojte s GitHubem (pokud jste se přes něj přihlásili, pravděpodobně už to nebude třeba) a pokračujte možností Create new repository. Zvolte libovolný název a popis a potvrďte.

Vytvoří se repository, do které bychom mohli pushnout image vytvořený lokálně v první kapitole. Zde je repository obdobou repozitáře na githubu - také můžu provést docker push, docker pull, mít různé tagy... My chceme ale mít vše automatizované, proto v divu Automated build from GitHub klikneme na tlačítko Edit repository.

Potvrdíme kliknutím na Save and build. Tutum vybere volný server z těch, které jsme k účtu připojili, tam provede build a v případě úspěchu pushne vytvořený image do repozitáře.

Vytvoření kontejnerů na serveru

Jakmile je build hotový, v detailu repository zvolíme Launch service. Spustí se průvodce, který umožňí službu nakonfigurovat a spustit. V kroku service configuration můžeme novou službu pojmenovat a provedeme zde jedinou změnu - zveřejníme port 80. Pokud chceme, aby se aplikace nasadila automaticky po každém úspěšném buildu, zaškrtneme ještě možnost Autoredeploy.

Krok Environment variables můžeme přeskočit a posledním nastavením před spuštěním je nastavení Volumes. Volumes slouží k persistenci dat - ukládají se mimo kontejner a přežijí tak jeho restart, což se hodí například u databází. Zde pomocí volumes zpřístupníme složku aplikace, ve které je dump databáze. Na řádek Add volume do pole Container path zadejte /app a klikněte na Add. Výsledek by měl vypadat následovně:

Potvrdíme kliknutím na Create and deploy. Nyní se na server stahuje vytvořený image a následně se spouští. Průběh můžeme sledovat pod záložkou Timeline. Po spuštění je veškerý výstup vidět na záložce Logs.

Dalším krokem je spuštění databáze - v hlavním menu zvolíme Services a následně Create service. Image MySQL je možné vyhledat na záložce Public repositories -> Search Docker hub zadáním tutum/mysql.

Zvolíme vyhledaný image a v dalším kroku je důležité službu pojmenovat db. V konfikuraci Nette aplikace totiž máme definovanou databázi právě pod db.

V dalším kroku nastavíme proměnné prostředí. Je třeba nastavit MYSQL_PASS na testpass a ON_CREATE_DB na test. Dále je třeba vložit novou proměnnou na řádku Add environment variable STARTUP_SQL s hodnotou /app/database.sql, což je cesta k souboru s dumpem databáze. Ten by aktuálně v kontejneru dostupný nebyl, zpřístupníme ho nastavením volumes v dalším kroku.

Posledním krokem před spuštěním databáze je načtení volumes definovaných v předchozí službě. V kroku Volumes tedy na řádku Add volumes from zvolíme službu nette-quickstart a potvrdíme.

Potvrdíme kliknutím na Create and deploy a počkáme až se databáze spustí. Přes menu Services se vrátíme do služby nette-quickstart. Zde nás zajímá záložka Endpoints, na které vidíme seznam všech zveřejněných portů. Zde by měl být právě jeden, který můžeme otevřít.

Po otevření bycho měli vidět spuštěnou a funkční aplikaci Nette Quickstart.

Co dál?

Prošli jsme celý proces, od kódu editovaného lokálně přes jeho zveřejnění na GitHubu až po spuštění aplikcace pomocí Docker a Tutum na serveru. Nyní můžeme provést změny v kódu, pushnout na GitHub a aplikace se automaticky aktualizuje. Pro skutečné použití na produkci by ale bylo dobré provést následující kroky:

• Persistence dat v databázi pomocí nastavení volumes. Nyní se při restartu databáze data přemažou.
• Aktualizace struktury databáze pomocí migrací. Jakmile totiž máme v databázi data, bylo by dobré provádět jen přírůstkové změny (aktuálně používám nextras/migrations a fungují výborně).
• Zálohování databáze. Přístupů je více - například použít další kontejner s nainstalovaným mysqldump a nastavenými volumes from.
• Testy. Pokud do rootu zdrojových kódů přidáte soubor pro docker compose docker-compose.test.yml, který má definovanou sekci sut - test se provede při každém buildu. Více zde.
• Škálování. Výhodou použití kontejnerů je snadné škálování - před web stačí předřadit proxy, s jejíž pomocí můžete simulovat virtualhosty, rozdělovat zátěž.. Kontejnery pak můžou běžet na více serverech a lze tak snadno rozdělit jejich výkon.
• HTTPS - pokud už budete používat haproxy, je nastavení https otázkou přidání dvou proměnných v konfiguraci.
• Monitoring a logování - o tom snad v některém z dalších článků.

Alternativy orchestrace kontejnerů

Tutum je zatím zdarma, jednou ale přejde na placený model. Je možné že cenu nasadí tak vysoko, že se provoz služby velmi prodraží a tak je třeba počítat s dostupnými alternativami.

• ClusterHQ Flocker: Super věc, při migraci kontejneru na jiný server migruje i data a lze tak v klidu například přemigrovat databázi na silnější server. Nemá webové rozhraní jako Tutum.
• Rancher: Mají vlastní operační systém pro provoz kontejnerů a nástroj pro jejich správu. Vypadá slibně, není to ale služba, vše si člověk musí rozběhat sám.
• Další nástroje pro orchestraci: Docker Swarm, Google Kubernetes, Apache Mesos, CoreOS Fleet. Nemám zkušenosti, mělo by ale jít o prověřené nástroje nabízející orchestraci kontejnerů.

O Elasticsearch právě píši seriál, který určitě stojí za prozkoumání!

Elasticsearch je škálovatelné úložiště umožňující nejen fultextové vyhledávání v reálném čase. Využít se dá několika způsoby, primárně byl ale vytvořen právě pro vyhledávání. Pokud máte data v MySQL nebo jiné relační databázi a zjišťujete, že vyhledávání pomocí LIKE už vám nestačí, nasazení Elasticsearch může být další logický krok.

Trocha motivace úvodem

Co vám tedy Elasticsearch nabízí a na co jej můžete použít? Pokusím se to shrnout ve třech bodech:

1. Elasticsearch jako fulltextové vyhledávání

S pomocí volně dostupných slovníků můžete například vyhledávat klíčové slovo nehledě na skloňování, nebo naimplementovat našeptávač, "měli jste na mysli" a další pokročilé nástroje. Elasticsearch je postaven nad Apache Lucene a plně jej využívá.

2. Elasticsearch jako rychlé distribuované úložiště

Do Elasticsearch můžete uložit jakýkoli dokument ve formátu JSON. Pokud vám pak běží na více strojích, jsou vytvářeny kopie dokumentů a o data tak v případě výpadku nebo poruchy některého z serverů nepříjdete. Navíc je pro většinu výsledků používána cache, takže jsou odpovědi opravdu rychlé (za cenu pomalejšího ukládání).

3. Elasticsearch jako analytický nástroj

V kombinaci s nástrojem Kibana je možné Elasticsearch využít jako pokročilý analytický nástroj poskytující reporty v reálném čase. Můžete tak do Elasticsearch ukládat například access log webového serveru a v Kibaně pak vytvořit grafy s počty přístupů, mapy a další statistiky.

Instalace Elasticsearch

1. Stažení

Pro použití v Nette projektu je spuštění otázkou několika minut. Nejprve navštivte stránky společnosti Elastic a v sekci downloads stáhněte aktuální verzi v zip archivu:

Pokud budete chtít rozběhnout Elasticsearch na serveru s OS Linux, doporučuji využít repozitářů - dojde také k instalaci init skriptů. ZIP archiv rozbalte do vaší oblíbené složky (v mém případě Downloads) a vznikne adresářová struktura podobná této:

2. Konfigurace

Před samotným spuštěním doporučuji upravit konfiguraci v souboru elasticsearch.yml (druhá šipka). Otevřete jej v libovolném editoru - jde o prostý textový soubor. Vzorová konfigurace pro lokální vývoj by mohla vypadat takto:

cluster.name: mylocalcluster  
node.name: "My Node"  
node.local: true  
index.number_of_shards: 1  
index.number_of_replicas: 0  

Pokusím se vysvětlit jednotlivé řádky konfigurace.

cluster.name je název clusteru, ve kterém se daný uzel (node) nachází. Elasticsearch sám prozkoumává síť a snaží se připojit ostatní uzly se stejným jménem cluster.name do jednoho clusteru. Změnou tak předejdete tomu, že se vám Elasticsearch chová podivně, pokud jej používá více vývojářů na lokální síti.

node.name je název uzlu který spouštíte, slouží pro jeho jednoznačnou identifikaci například v pluginu kopf. Pokud necháte parametr prázdný, vygeneruje se náhodné jméno.

node.local umožní pouze lokální přístup k Elasticsearch. Pozor na bezpečnost, pokud necháte na produkci zvenčí dostupný port 9200 - i tam se může hodit "lokální" přístup k nodu.

index.number_of_shards a index.number_of_replicas nemá smysl pro lokální vývoj nastavovat jinak. Pokud vám vypadne jediný počítač, na kterém máte data, je jedno v kolika kopiích byla uložena :). Při nasazení na produkci doporučuji rozmyslet nastavení index.number_of_shards, protože po vytvoření indexu jej již nezměníte.

3. Spuštění

Před spuštěním se ujistěte, že máte nainstalovanou javu, pokud ne, bude třeba ji stáhnout. Nyní spusťte soubor elasticsearch ve složce bin (první šipka v obrázku s rozbaleným archivem). Můžete tak provést z konzole:

$ pwd
/Users/ludekvesely/Downloads/elasticsearch-1.7.1
$ ./bin/elasticsearch

To že se povedlo Elasticsearch spustit ověříte na adrese http://localhost:9200. Nové verze vznikají velmi rychle, nelekejte se tedy mé starší verze 1.5.2. ;-)

Vytvoření Nette projektu

Předpokládám že s Nette již máte zkušenosti a pravděpodobně jen chcete využít možností Elasticsearch v existujícím projektu. Pokud přesto nemáte žádný projekt vytvořený, nainstalujte si composer a následně pomocí příkazu

composer create-project nette/web-project  
cd web-project  
chmod -R a+rw temp log  

Vytvořte prázdný projekt. Tato varianta je od verze Nette 2.3 preferovaná před nette/sandbox, více na fóru Nette. Projekt přesuňte do veřejně přístupného adresáře vašeho webového serveru a po přístupu na soubor index.php ve složce web-project/www byste měli vidět úvodní obrazovku:

Instalace Kdyby/ElasticSearch

Otevřte terminál ve složce s projektem a zadejte příkaz

composer require kdyby/elastic-search  

Nyní se nainstalovaly knihovny ruflin/elastica (samotná knihovna pracující s Elasticsearch) a kdyby/elastic-search (napojení na Nette). Zaktualizovaly se také soubory composer.json a composer.lock.

Dále je třeba rozšíření zaregistrovat v Nette a nakonfigurovat. To je maximálně jednoduché - do souboru app/config/config.neon přidejte následující řádky:

extensions:  
    search: Kdyby\ElasticSearch\DI\SearchExtension

search:  
    host: 127.0.0.1
    port: 9200

No a to je vlastně všechno! Nyní si stačí kdekoli vyžádat Kdyby\ElasticSearch\Client, která dědí od Elastica\Client a s připojením dále pracovat podle dokumentace knihovny Elastica.

Použití knihovny Elastica v Nette aplikaci

Ve vzorové aplikaci pro zachování jednoduchosti ukáži použití v již vytvořeném presenteru HomepagePresenter.php, ve vaší aplikaci ale tuto logiku doporučuji přenést do modelu. Otevřte tedy zmíněný soubor HomepagePresenter.php a do třídy HomepagePresenter přidejte:

private $client;

public function __construct(\Kdyby\ElasticSearch\Client $client)  
{
    $this->client = $client;
}

Nyní můžete využívat připojení k Elasticsearch pomocí proměnné $client. Například můžu nejprve vytvořit index s názvem my-index, nastavím mu počet shardů roven jedné a budu pracovat s type nazvaným data.

$index = $this->client->getIndex('my-index');
$index->create(['number_of_shards' => 1]);
$type = $index->getType('data');

Následně mohu definovat mapování. Například chci, aby se pro koaždé pole nazvané @timestamp použil datový typ datum:

$mapping = new \Elastica\Type\Mapping();
$mapping->setType($type);
$mapping->setParam('dynamic_templates', [
    ['template_timestamp' => [
        'match' => '@timestamp',
        'mapping' => [
            'type' => 'date', 
            'format' => 'date_time_no_millis'
        ]
    ]]
]);
$mapping->send();
$type->setMapping($mapping);

Nyní lze zaindexovat dokument, v tomto příkladu pole $raw:

$raw = [
    'name' => 'Nette',
    'year' => 2000
];
$document = new \Elastica\Document(1, $raw);
$type->addDocument($document);
$index->refresh();

Tím jsme dokument zaindexovali do Elasticsearch a měl by být vyhledatelný. Ověřit to můžeme jednoduchým vyhledáním všech dokumentů:

foreach ($type->search([])->getResults() as $result) {  
    dump($result->getSource());
}

Výstupem (http://localhost/web-project/www/) by pak měl být námi zaindexovaný dokument:

array (2)  
   name => "Nette" (5)
   year => 2000

Výsledný soubor HomepagePresenter.php by pak měl vypadat takto:

<?php

namespace App\Presenters;

use Nette;


class HomepagePresenter extends Nette\Application\UI\Presenter  
{
    /**
     * @var \Kdyby\ElasticSearch\Client
     */
    private $client;

    public function __construct(\Kdyby\ElasticSearch\Client $client)
    {
        $this->client = $client;
    }

    public function actionDefault()
    {
        // name of index is 'my-index'
        $index = $this->client->getIndex('my-index');

        // create index with single shard
        $index->delete();
        $index->create(['number_of_shards' => 1]);

        // name of type is 'data'
        $type = $index->getType('data');

        // put mappings (every field called @timestamp will be stored as a date)
        $mapping = new \Elastica\Type\Mapping();
        $mapping->setType($type);
        $mapping->setParam('dynamic_templates', [
            ['template_timestamp' => [
                'match' => '@timestamp',
                'mapping' => ['type' => 'date', 'format' => 'date_time_no_millis']
            ]]
        ]);
        $mapping->send();
        $type->setMapping($mapping);

        // index an array into es
        $raw = [
            'name' => 'Nette',
            'year' => 2000
        ];
        $document = new \Elastica\Document(1, $raw);
        $type->addDocument($document);

        // refresh es index
        $index->refresh();

        // now we can search indexed document
        foreach ($type->search([])->getResults() as $result) {
            dump($result->getSource());
        }

        $this->terminate();
    }
}

Kam dál?

Jsme u konce návodu jak rozběhnout knihovnu Kdyby/Elasticsearch v Nette projektu. Pro další informace o Elasticsearch doporučuji přímo web společnosti Elastic a jejich oficiální dokumentaci, pokud máte radši tištěnou literaturu, tak by měla být dobrá kniha The Definitive Guide. Pro práci s knihovnou Elastica je veškeré podrobné info na jejich webu elastica.io. Zdrojové kódy knihovny Kdyby/ElasticSearch pak naleznete na githubu.

Update: tento článek je mírně zastaralý, aktuálně je nejsnažší cesta využít Docker for Mac případně Docker for Windows.

Slyšeli jste už o Dockeru? Pokud ne, tak v rychlosti shrnu k čemu vám může být nápomocný. S jeho pomocí je možné vytvářet kontejnery, ve kterých můžete spouštět svou aplikaci. Pokud píšete v PHP, tak podobně jako do souboru composer.json zapisujete všechny závislosti, vytvoříte soubor Dockerfile, který popisuje jak aplikaci zprovoznit. Zvolíte základní image (těch je nepřeberná řada volně k dispozici), například Ubuntu. Dalšími příkazy v tomto souboru nainstalujete například požadovanou verzi PHP a nakopírujete zdrojové soubory. Máte tak jistotu že aplikace vždy poběží ve stejném prostředí.

To je velmi výhodné při lokálním vývoji. Prostě spustíte odpovídající kontejnery a aplikace běží. Není třeba trávit čas instalací software v odpovídajících verzích nebo jejich přepínáním. Obdobně lze pak aplikaci přenést na server - stačí na serveru stáhnout image a spustit.

Princip Dockeru je podobný jako práce s virtualizovanými stroji. Hlavní rozdíl je ten, že kontejnery mají daleko menší režii. Přestože Docker nyní prochází bouřlivým vývojem, je zatím nativně podporován pouze v OS Linux. Co ale dělat pokud jej chcete používat i na Windows nebo OS X?

Řešení zatím není úplně triviální - je třeba rozběhnout virtualizovaný Linux a v něm teprve Docker, vyřešit synchronizaci mezi hostitelským a virtualizovaným OS...

Kitematic

Naštěstí existuje aplikace, která tento problém elegantně řeší. Jmenuje se Kitematic a pro stažení vás odkáži na oficiální web: https://kitematic.com.

Nejprve tedy stáhněte Kitematic a spusťte jej. Úvodní obrazovka by měla vypadat takto:

Přemýšleli jste jak nainstalovat VirtualBox a správně jej nastavit? Kitematic to zvládne za vás. Můžou se objevit problémy pokud jste již v minulosti Docker instalovali, v mém případě vše proběhlo v pořádku a nyní je k dispozici hlavní obrazovka:

Zde můžete spustit terminál, ve kterém lze spouštět příkazy Dockeru jako docker run a další. Nejrychlejší způsob spuštění kontejneru je ale kliknutím na Create u příslušného image. Po spuštění můžete vidět jak aplikace vypadá v prohlížeči a procházet připojené složky. Poslední možností je nastavení kontejneru - jaké porty jsou zveřejněny, jaké složky jsou připojeny a nastavení proměnných.

Další informace a návody:

• https://kitematic.com/docs/
• https://docs.docker.com/kitematic/userguide/