Před časem jsme si ukazovali, jak lze použít datové úložiště Amazon S3 pro hostování statického webu. Stejnou službu může odvést i Google App Engine – ačkoli ten je častěji spojovaný s během webových aplikací, lze jej použít i pro statický web.

Nejprve je potřeba mít účet pro službu Google App Engine. Postup je obdobný se zřizováním účtu v dalších službách od Google, nebudeme se mu tedy věnovat a budeme předpokládat, že účet už máte.

Trocha teorie

Google App Engine nabízí hostingové služby pro aplikace, napsané v Pythonu nebo v Javě. V případě potřeby lze použít např. i PHP, a to pomocí jeho interpretu, napsaného v Javě. Hlavní oblast využití spočívá ale právě ve výše jmenovaných jazycích.

Historicky starší podpora je pro Python (a pythonské verzi se budeme věnovat i v tomto článku). App Engine používá Python verze 2.5, novější verze nejsou podporovány, a budete-li pro App Engine vyvíjet, počítejte s tím. Nás se statickým webem nemusí verze Pythonu až tak dalece zajímat, přesto se jeho použití nevyhneme.

App Engine totiž nenabízí klasické „deployment“ metody, jako je FTP či „webové rozhraní“. Soubory se na server nahrávají pomocí speciálního nástroje appcfg (utilita pro příkazový řádek), nebo pomocí App Engine konzole (Launcher), která se o deploy stará za nás. Oba nástroje jsou součástí App Engine SDK, které si musíme nejprve stáhnout a nainstalovat. Pro App Engine existuje řada dalších užitečných nástrojů, které ale pro obyčejný statický web nepotřebujeme.

Krok za krokem

Vytvoříme si nejprve novou aplikaci ve webovém Dashboardu. Určíme jí možnost přihlašování uživatelů a zálohování (obojí můžeme nechat na výchozích hodnotách). Jméno aplikace musí být unikátní v rámci celého App Engine. Toto jméno je součástí adresy (xxx.appspot.com), pod níž bude web dostupný. Samozřejmostí je i možnost nastavení CNAME záznamů a přesměrování vlastní domény.

Aplikaci se stejným jménem si vytvoříme i v Launcheru na lokálním počítači. Musíme zadat adresář, v němž se budou nacházet soubory pro aplikaci.

Při prvním spuštění Launcheru bude zapotřebí nastavit cestu k interpretu Pythonu, k vlastnímu SDK a k textovému editoru.

Při vytváření aplikace jste si mohli všimnout políčka pro „port“. App Engine SDK má v sobě běhové prostředí, které funguje stejně jako samotný App Engine, takže jeho prostřednictvím je možné lokálně testovat napsané aplikace – slouží k tomu volba „Run“ v Launcheru, která spustí jednoduchý lokální webserver na zadaném čísle portu.

Konfigurace

Nejdůležitějším souborem u pythonské aplikace v App Engine je konfigurační soubor s názvem app.yaml (pro Javu je obdobou appengine-web.xml, ale javovským runtimem se v tomto článku zabývat nebudeme). Tento soubor je, jak už název naznačuje, ve formátu YAML. Obsahuje základní metainformace o projektu a pravidla pro routování URL. Ve výchozím nastavení vypadá nějak takto:

application: myapp
version: 1
runtime: python
api_version: 1

handlers:
- url: .*
  script: main.py

V souboru je jméno aplikace, její verze, použitý runtime (podle jazyka) a verze API App Engine. Poslední položkou jsou handlers, tvořené seznamem URL a odpovídajících akcí. V základní podobě, která je uvedená výše, je nastavené routování všech požadavků ( url: .*) tak, že je zpracovává skript  main.py.

V app.yaml můžete použít velké množství voleb, pomocí kterých můžeme nastavit nejrůznější vlastnosti. Kromě routování statických souborů, které využijeme i v našem příkladu, můžeme nastavit např. přihlašování uživatelů, cestu k administrátorským skriptům, statistiky, propojení s XMPP a další.

Statické routování

U webových aplikací není zpracovávání skriptovacím jazykem žádoucí vždy a za všech okolností. Mnohé soubory (obrázky, kaskádové styly, JavaScriptové knihovny, soubory ke stažení, statické HTML stránky, …) mohou být posílány uživatelům tak, jak jsou; jejich zpracování pomocí skriptovacího jazyka je nejen zbytečné, ale také zpomaluje a přidělává práci. V takové situaci můžeme použít statické routování – tedy místo parametru script říct, že daný handler bude fungovat buď pro konkrétní soubor(y) nebo celý adresář.

Příklad:

application: myapp
version: 1
runtime: python
api_version: 1
default_expiration: "7d"
handlers:
- url: /img
  static_dir: img
- url: /css
  static_dir: css
- url: /js
  static_dir: js

Všechny požadavky, jejichž cesta v URL bude začínat /img (resp. /css či /js) budou brány jako požadavky na statické soubory, umístěné v patřičných adresářích. V handlerech, používajících static_dir, lze uvést i vlastnost mime_type, která nastaví souborům, jež budou daným handlerem odesílány, konkrétní MIME typ. Pokud mime_type neuvedeme, bude typ určován podle přípony.

Pomocí výše uvedeného zápisu jsme si nastavili routování statických souborů z adresářů img, css a js. Nemáme ale nastavené routování pro hlavní HTML soubor (či soubory). Hned to napravíme:

application: myapp
version: 1
runtime: python
api_version: 1
default_expiration: "7d"
handlers:
- url: /img
  static_dir: img
- url: /css
  static_dir: css
- url: /js
  static_dir: js
- url:  /(.*.html)
  static_files: 1
  mime_type: text/html
  upload: (.*.html)

Handler se static_files umožňuje určit mapování jednotlivých souborů, dokonce pomocí regulárních výrazů. Poslední handler tedy ovládá požadavky na všechny soubory s příponou .html, říká, že server má poslat ty se stejným názvem ( static_files: /1) a má je poslat s typem text/html. Poslední direktiva (upload) říká appcfg/Launcheru, které soubory z lokálního disku má na server nahrát – on totiž nedokáže sám určit statické soubory, které je potřeba uploadovat na server.

Touto úpravou jsme si zajistili, že se na server nahrají všechny soubory z kořenového adresáře aplikace, které mají příponu .html, plus kompletní obsah adresářů /img, /css a /js. Statický web už máme téměř připravený, zbývá jen poslední věc: zajistit správné poslání indexového souboru v případě, že uživatel zadá jen adresu domény bez cesty.

Na konec app.yaml přidáme poslední handler:

- url: /
  static_files: index.html
  upload: index.html

… a je to! Máme nastaveno.

Deploy

V tuto chvíli zbývá jen nahrát do pracovního adresáře patřičné soubory, soubor main.py můžeme smazat (vygeneroval ho Launcher) a zadáme Deploy. Launcher se nás zeptá na uživatelské jméno a heslo. Pak vše potřebné nahraje na server a otestuje, zda byla aplikace nahrána správně.

Pokud budeme se soubory experimentovat, brzy nás začne nutnost zadávat jméno a heslo obtěžovat. Můžeme se jí vyhnout tím, že použijeme řádkovou utilitu appcfg.py, která si dokáže přihlašovací údaje zapamatovat.

Pro snazší „deploy“ si můžete vytvořit např. podadresář scripts a do něj umístit dávkový soubor (.bat / .sh), který bude obsahovat jen:

appcfg.py update ../ -e vase.uzivatelske.jmeno@gmail.com

Při prvním spuštění se zeptá na heslo, při dalších se už neptá. Tento skript můžeme např. navázat jako obsluhu commitu ve verzovacím systému.

Statický web sice může vypadat jako degradace schopností App Engine, ale přesto nalezne, obzvlášť v kombinaci s HTML5, mnoho možností využití. Příkladem budiž web HTML5 Rocks, který je hostován právě v App Engine.

V článku jsme si ukázali, jak vytvořit projekt v systému Google App Engine, jak nastavit jednoduchá routovací pravidla pro statický web a jak nahrát soubory na server. V pokračování si ukážeme, jak statický web oživit a využít serverových možností pro obsluhu AJAXových požadavků.