Tento stack není žádná novinka, ale dlouho chybělo dobré pojmenování. Nejlepší příklad většího použití podle mne je přechod Smashing Magazine, který pěkně poslali v článku.

Nejdůležitější věci co definují JAMstack:

• používá CDN
• používá místo databáze Git
• markup se převádí pomocí automatického buildu

Javascript

Pokud máte JAMstack nemusíte rezignovat na CMS, je tu několik CMS napsaných jako Javascriptové SPA aplikace – A List of Content Management Systems for JAMstack Sites. Nejznámější řešení je Netlify CMS – An open-source CMS for your Git workflow, které je open source, ale i nabízená jako SaaS.

Zajímavé řešení nění jen na Javascriptu, ale například na WordPressu, kde Wordpress funguje jako CMS, ale stránky jsou staticky vygenerované. Další podobné řešení je Forestry a určitě najdete další.

API

Samozřejmě nevystačíte jen statickými stránkami a potřebujete přidat funkce na zpracování formulářů nebo napojit na eshop. Například Javascript Shopping Cart řeší eshop a můžete využít Serverless a implementovat co potřebujete pokud využijete GraphQL a například Graphcool kombinuje GraphQL a AWS Lambdu i jiné FaaS.

Další API které se používají například v Smashing magazine a jsou open source.

Markup

Statické generátory (jekyll, hugo) jsou oblíbené a najdete jich velký seznam na Top Open-Source Static Site Generators. Například Hugo je napsaný v Go langu a je velmi rychlý a stále se hodně rozvíjí. Jekyll se součást Github Pages a proto je hodně oblíbený mezi vývojáři na Githubu.

Závěr

Pokud vás to zajímá tak doporučuji podcast JAMstack Radio, kde je spousta zajímavých hostů a zdrojů k inspiraci.

Pokud si chcete popovídat o GraphQL zastavte se na Hive talks 11.7. v Karlíně.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ docker version
Client:
 Version:      17.05.0-ce-rc1
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   2878a85
 Built:        Tue Apr 11 20:55:05 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.05.0-ce-rc1
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   2878a85
 Built:        Tue Apr 11 20:55:05 2017
 OS/Arch:      linux/amd64
 Experimental: true

Multi stage

O co vlastně jde v tom multi stage. Pokud potřebujete vyrobit image pro aplikaci, která má artefakty (C/C++, Go, Java, etc.) tak potřebujete jen malou část těch závislostí pro běh v produkci, ale při výrobě těchto artefaktů musíte nainstalovat hodně a většinou ne malých závislostí. Řešilo se to patternem builder za pomocí dvou Dockerfile souborů, ale teď existuje jednodušší řešení.

Řešení v jednom souboru kde máte dvě sekce, každá začíná deklarací FROM. Tady je ukázka pro Go lang.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

FROM golang:1.8 as builder

ENV GLIDE_VERSION 0.10.2
ENV APP_VERSION 1.0.2

ADD https://github.com/Masterminds/glide/releases/download/${GLIDE_VERSION}/glide-${GLIDE_VERSION}-linux-amd64.tar.gz /tmp/glide-${GLIDE_VERSION}-linux-amd64.tar.gz

RUN cd /tmp && \
    tar -zxvf /tmp/glide-${GLIDE_VERSION}-linux-amd64.tar.gz && \
    cp /tmp/linux-amd64/glide /usr/local/bin/glide && \
    chmod 755 /usr/local/bin/glide && \
    rm /tmp/glide-${GLIDE_VERSION}-linux-amd64.tar.gz && rm -rf /tmp/linux-amd64/

COPY . /go/src/github.com/apiaryio/heroku-datadog-drain-go

RUN cd /go/src/github.com/apiaryio/heroku-datadog-drain-go && \
    glide install && \
    go install

FROM scratch
COPY --from=builder /go/bin/heroku-datadog-drain-go .
CMD ["./heroku-datadog-drain-go"]

V první části se použije image golang a nainstaluje se glide (package manager) a vyrobí se binární soubor, který potom v druhé část (FROM scratch) se použije a pomocí COPY --from=builder se překopíruje artefakt z jednoho image do druhého. Pokud si image v první sekci nepojmenujete tak použijte číselné označení COPY --from=0.

Výsledné image potom vypadají takto:

1
2
3
4

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
drain               latest              7a7abced7a9d        6 seconds ago       10MB
<none>              <none>              edabce509d75        7 seconds ago       752MB
golang              1.8                 c0ccf5f2c036        13 days ago         703MB

Máte dva image jeden pro produkci a druhý můžete klidne smazat.

Závěr

Tato inovace zjednodušší život mnoha lidem a je to super. Pokud si to chcete vyzkoušet můžete na webu v bez nutnosti instalovat si poslední Docker.

Pipeline se serie kroků, které vám dovolí orchestovat práci, kterou potřebujete k buildu, testovaní a nasazení aplikace. Pipelines jsou definovány v souboru Jenkinsfile a je uložen v kořenovém adresáři repozitáře projektu.

Stávájící formát pipelines je psaný v Groovy DSL a vypadá takto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

node {
   stage('Preparation') {
      git 'https://github.com/abtris/bee.git'
      poll: true

   }
   stage('Deps') {
       env.PACKAGE="github.com/abtris/bee"
       env.GOPATH="/Users/abtris/go"
       env.GOROOT="/usr/local/opt/go/libexec"
       sh 'glide --no-color install'
       sh 'mkdir -p release'
   }
   stage('Test') {
       sh 'make xunit'
   }
   stage('Build') {
         parallel (
            linux64: { sh "GOOS=linux GOARCH=amd64 go build -o release/bee-linux-amd64 ${PACKAGE}" },
            linux32: { sh "GOOS=linux GOARCH=386 go build -o release/bee-linux-386 ${PACKAGE}" },
            mac64: { sh "GOOS=darwin GOARCH=amd64 go build -o release/bee-darwin-amd64 ${PACKAGE}" },
            win64: { sh "GOOS=windows GOARCH=amd64 go build -o release/bee-windows-amd64 ${PACKAGE}" }
          )
   }
   stage('Results') {
      archive 'release/*'
      junit 'tests.xml'
   }
}

a nový formát zjednodušuje tento zápis i pro ty kteří Groovy nevládnou a je více deklarativní s podporou pro editor, který Jenkins Blue Ocean tým vyvíjí.

Tady je přepsaný příklad ze shora do nového formátu.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

pipeline {
  agent any
  environment {
    PACKAGE="github.com/abtris/bee"
    GOPATH="/Users/abtris/go"
    GOROOT="/usr/local/opt/go/libexec"
  }
  stages {
     stage('Preparation') {
        steps {
          git 'https://github.com/abtris/bee.git'
        }
     }
     stage('Deps') {
        steps {
           sh 'glide --no-color install'
           sh 'mkdir -p release'
       }
     }
     stage('Test') {
        steps {
         sh 'make xunit'
        }
     }
     stage('Build') {
        steps {
           parallel (
              linux64: { sh "GOOS=linux GOARCH=amd64 go build -o release/bee-linux-amd64 ${PACKAGE}" },
              linux32: { sh "GOOS=linux GOARCH=386 go build -o release/bee-linux-386 ${PACKAGE}" },
              mac64: { sh "GOOS=darwin GOARCH=amd64 go build -o release/bee-darwin-amd64 ${PACKAGE}" },
              win64: { sh "GOOS=windows GOARCH=amd64 go build -o release/bee-windows-amd64 ${PACKAGE}" }
            )
        }
     }
     stage('Results') {
        steps {
          archive 'release/*'
          junit 'tests.xml'
        }
     }
  }
}

Celou syntaxi si můžete prohlédnout v dokumentaci.

Hlavní rozdíl je v tom, že přidali další bloky jako je hlavní pipelines a je potřeba deklarovat vždy agenta, který může být v různém formátu. Vyměnilo nazvosloví a z node je agent.

Build můžete pustit jednoduše například v Dockeru pomocí: agent docker:'node:6.3' nebo pokud nechcete to řešit tak můžete dát agent any jako v příkladu, to se hodí například pro lokální testování a není to rozhodně vhodné pro nějaké větší nasazení, kdy potřebujete orchestrovat jednotlivé agenty.

Deklarace environment na začátku zpřehledňuje celý zápis a každá stage má teď steps, které jsou nové. Přidali sekci post, která má kroky always, success a failure pro ošetření konce buildu a poslání notifikací. Nechybí ani options, parameters a triggers, kde nastavíte co potřebujete.

I když celý tento projekt v beta fázi, přijde mi to jako krok správným směrem a spolu s čím dál lepším Blue Ocean to bude příští rok hlavní novinka v Jenkinsu.

V tomto příspěvku se budu věnovat dalším bodům:

• distributed job across multiple nodes
• autoscaling on traffic with lowest possible price
• solution for caching for installations
• docker support
• matrix builds

V Jenkinsu je podpora pro distribuované agenty, dnes můžete mít jednotlivé stroje v AWS (pomocí ec2, ec2-fleet pluginů), OpenStack, Docker, Kubernetes apod.

Aby jste byli schopni dosáhnou kvalitního autoscalingu za velmi dobrou cenu dají se velmi dobře využít spot instance od AWS. Můžete ušetřit až 90% nákladů oproti normálním instancím.

Pokud provozujete vlastní Jenkins je potřeba vyřešit cache, ideální řešení je JFrog Artifactory, které podporuje caching pro velké množství vývojových nástrojů. Bohužel toto řešení poměrně drahé. Ale existuje Nexus repository, které má komunitní verzi. Ale bohužel v Nexus OSS chybí například podpora pro PHP Composer.

Matrix buildy jsou potřeba v Jenkinsu se jim říká Multi-configuration project. Můžete tu vytvořit vlatní matice podle čeho chcete a Jenkins vygeneruje potřebné projekty s parametry které potřebujete, podobně jako když by jste použili Job DSL plugin. To se hodí od testovaní různých verzí operačního systému, verzí programovacího jazyka apod.

Poslední věc je podpora Dockeru. V Jenkinsu je několik pluginů pro Docker. Využití může být také různé. Buď to použijete na vytvoření agentů nebo přímo můžete pouštět projekt v docker containeru. Bohužel toto funguje spolehlivě jen na linuxu.

Takto se docker popíše v Jenkins pipelines.

1
2
3
4
5
6
7
8
9

node('docker') {
 // My project sources include both build.xml and a Dockerfile to run it in.
 git 'https://git.mycorp.com/myproject.git'
 // Ready?
 docker.build('mycorp/ant-qwerty:latest').inside {
   sh 'ant dist-package'
 }
 archive 'app.zip'
}

Hostované řešení jako je TravisCI nebo CircleCI mají výhodu pokud potřebujete začít. Ale postupem, když máte více lidí nebo potřebujete větší flexibilitu tak se můžete dostat do potíží. Jenkins je náročnější na údržbu, ale umožňuje velkou flexibilitu.

Shrnutí

Jenkins 2 přinesl deklarativní popis, lepší bezpečnost a stále zachoval zpětnou kompatibilitu. Vylepšené UI a tady se stále pracuje na dalších vylepšeních (Blue Ocean). S Blue Ocean potom přijde deklarativní popis continues delivery pipelines a také by měl tam být online visual editor pro pipelines. Na další rok mají plány také na přidání Configuration API a myslím, že by mohl Blue Ocean v budoucnu uplně nahradit dnešní UI a zároveň otevřít cestu pro to například kompletně používat Jenkins bez UI. Uvidíme jak to bude dlouho trvat, každopádně se už teď těším na další novinky.

Jenkins používám řadu let a také ho školím ve firmách co chtějí toto řešení nasadit. Před 2 lety jsem si řekl, že není Jenkins moc dobrá cesta. Žádné použitelné novinky se dlouho neobjevovali a vůbec se nezlepšovalo použití pro větší nasazení Jenkinusů ve firmách.

Já mám na každé CI tento seznam požadavků:

• job definitions in repository
• autoscaling on traffic with lowest possible price
• pipelines / workflow
• solution for caching for installations
• docker support
• matrix builds
• distributed job across multiple nodes

a hned ten nejzásadnější právě dlouho Jenkins nesplňoval. Od verze 2.0 je mezi základními rozšířeními podpora pro Continues Delivery Pipelines (dále jen pipelines), které jdou psát do souboru jako Jenkinsfile, který můžete mít s projektem v repozitáři a Jenkins umí spolupracovat s SCM například s Github, kde mu stačí dát jméno organizace nebo uživatele a on proskenuje vaše repositáře a tam kde najde Jenkinsfile pro ty repositáře vytvoří úlohy ke zpracování.

Ukázka jak takový soubor s pipelines vypadá pro malý projekt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

node {
   stage('Preparation') {
      git 'https://github.com/abtris/bee.git'
   }
   stage('Deps') {
       env.PACKAGE="github.com/abtris/bee"
       env.GOPATH="~/go"
       env.GOROOT="/usr/local/opt/go/libexec"
       sh 'glide --no-color install'
       sh 'mkdir -p release'
   }
   stage('Test') {
       sh 'make xunit'
   }
   stage('Build') {
         parallel (
            linux64: { sh "goos=linux goarch=amd64 make build" },
            linux32: { sh "goos=linux goarch=386 make build" },
            mac64: { sh "goos=darwin goarch=amd64 make build" },
            win64: { sh "goos=windows goarch=amd64 make build" }
          )
   }
   stage('Results') {
      archive 'release/*'
      junit 'tests.xml'
   }
}

Jenkinsfile je DSL v programovacím jazyku Groovy obsahuje blok s názvem node kde si definujete, kde a co se má co spouštět. V ukázce tam není žádná podmínka a tak Jenkins rozhodně sám kde to spustí. Pokud by jste to chtěli upřesnit tak se dá se specifikovat zda to má být master nebo naopak, že to nemá být master (doporučeno) a také jde přímo označit agenta (slave), kterého máte připojeného k Jenkins masteru. Může to být instance na Amazon Web Services (AWS) nebo v jiném cloudu, tak jakýkoliv jiný počítač, který si k tomu určíte a pustíte na něm potřebného klienta.

Další klíčovým slovem je stage, kde si názvem rozdělíme pipeline do nějakých logických celků. Tyto části, pokud to má smysl, můžeme zpracovávat paralelně jako je to v ukázce v části Build. Využití paralelního zpracování je tam, kde chcete zkrátit čas celého build a pokud na to máte volné prostředky (agenty).

Vše spouštím pomocí linuxového shellu pomocí klíčového slova sh. Mohl bych testovat pomocí isUnix() zda jsme na stroji, který toho je vůbec schopen, to vám pomůže pokud používáte různé stroje, některé s Windows a jiné s Linuxem.

V poslední části Results archivujeme artefakty (tady binárné soubory) vytvořené při buildu a výsledky testů z kroku Test.

To je vše a v Jenkinsu to potom vypadá takto:

Takto se pipelines zobrazují v novém UI BlueOcean.

Pipelines mají před sebou velkou budoucnost, připravují se vylepšení v podobě online editoru a více deklarativního zápisu než dnes.

Dalším požadavkům, které mám na CIE se budu věnovat zase v dalším příspěvku.

Pokud vás zajímá rozdíl mezi SRE a DevOps a o tom jak se liší SRE v Google, Facebooku, LinkendIn nebo Microsoftu a ve startatup jako je Apiary, přijděte si o tom popovídat.

Co to SRE je?

Pokud nevíte co to je SRE, tak kromě mého článku existuje skvělá kniha Site Reliability Engineering od lidí z Googlu, kde se všechno detailně vysvětluje a skoro každý přenášející něco z knihy citoval. Je to taková bible SRE a vůbec první kniha zastřešujíc tento obor.

Nejzajímavější přednášky

K přednáškám chci jen dodat, jsou to mé postřehy, pokud vás to zaujme měli by být videa za pár týdnů veřejně dostupné na youtube.

Splicing SRE DNA Sequences in the Biggest Software Company on the Planet – Greg Veith, Microsoft

Greg mluvil o transformaci v Microsoftu a jeho práci na zavádění SRE do práce týmů kolem MS Azure. Začali budovat SRE kolem roku 2009 a doteď transformace probíhá nejen v MS Azure, ale v celé firmě. Pro zavedení byli klíčové tři věci. Za prvé vlastní start SRE týmu, zavedení principů. Za druhé aplikaci principů, aby jste model otestovali. Za třetí musíte akcelerovat a vylepšovat ho tak, aby zahrnul celou firmu. Gregova přednáška byla také hodně o tom jak je MS velký firma a tak je to práce pro hodně lidí, přesto hlavní SRE tým je asi jen 5-7 lidí.

Diskuze o tom kolik SRE lidí má být ve firmě byla celkem častá. Osobně se mi libí názor z LinkedIN, kde uvádějí 1:10 poměr SRE a Engineeringu. U velkých firem jako je Google je to asi 5%. Tomu 1:10 odpovídáme i v Apiary a myslím, že je dobré se toho držet.

Doorman: Global Distributed Client-Side Rate Limiting – Jos Visser, Google

Jos mluvil o projektu Doorman, který používají v Youtube limitaci zdrojů v distribuovaném systému pro omezení zátěže MySQL. Doorman je napsaný v Go langu, používá pro komunikaci gRPC. Zajímavé je hlavně to, že nemá žádný diskový prostor pro ukládání stavu a drží informace jen v paměti. Pokud dojde k výpadku tak se pustí learning mode a od klientů se dozví všechno co potřebuje a potom pokračuje ve funkci.

### Building and Running SRE Teams – Kurt Andersen, LinkedIn Kurt mluvil o knize Team of Teams a jak aplikovat vojenské postupy do SRE a systému rozhodování. Jako klíčové viděl hlavně posun důležitých rozhodnutí na lidi co jsou nejblíže tomu tu akci potom vykonat.

The Production Engineering Lifecycle: How We Build, Run, and Disband Great Reliability-focused Teams – Andrew Ryan, Facebook

Andrew mluvil o Production Engineeringu (PE) ve Facebooku. Je to obdoba SRE. Mají asi 700 lidí v šesti kancelářích po celém světe. Drží poměr 1:10 podobně jako LinkedIn. Hodně řeší nakolik je v každém týmu potřeba PE a zda je produkt opravdu tak důležitý pro firmu, aby bylo nutné mít oncall (min. 12+ PE). Pokud ne tak se oncall přesune na vývojáře a PE může působit jako poradce jak věci zlepšit. Naopak na core produktech mají například pro cache pět paralelních rotací na oncallu.

How to Improve Your Service by Roasting It – Jake Welch, Microsoft

Jake mluvil o tom jak přenést znalosti o komplexních systémech od autorů k dalším lidem do firmy. Doporučil vytvořit skupinku a věnovat 45min týdně po dobu 10 týdnů na předávání znalostí. Je důležité, aby to někdo řídil. Role Roast Master je pro úspěch klíčová. Musí hlídat jak tón řeči a vůbec vyjadřování, aby to nesklouzlo k osobním antipatijím a drželo se to v racionální rovině. Agendu je potřeba správně rozdělit po komponentách nebo subsystémech a držet se toho, na konci potom stanovit co se bude probírat příště a nepřekračovat čas 45min.

What SRE Means in a Start-up – Brian Scanlon, Intercom

Brian mluvil o SRE ve startupu, kde je situace jednoduší pokud se prostě nastaví politika od začátku, často se používá hostovaná infrastruktura, která celou věc usnadňuje. Celkem to kopírovalo to jak to děláme mi v Apiary.

Hodně je vidět jaký velký rozdíl a kolik práce to dá pokud chcete firmu předělat na SRE (brownfielding) nebo začnete hned.

The Many Ways Your Monitoring Is Lying to You – Sebastian Kirsch, Google, skirsch@google.com

Skvělá přednáška o tom jak nemůžete věřit každému grafu v monitoringu. Doporučuji schlédnout až bude video, bylo tam hodně příkladů. Jde o to, že věci, které uváděl nejsou pro mě například vůbec nové díky lekcím z numerické matematiky a statistiky na ČVUT, ale ne každý má statistický background a nebývá to až tak běžná součást Computer Science.

Next-generation Alerting and Fault Detection – Dieter Plaetinck, raintank

Dieter hodně zdůrazňoval použití machine learning na detekci anomálií a to jak to prakticky moc nefunguje a proto se uchylujeme k streamovanému zpracování dat pomocí nástrojů jako je Spark nebo Riemann.io. Ale nejzajímavější věc zmíněná v přednášce je Bosun, také IDE pro alerting, kde se dá dělat historický testing, ladění alertů, vyhodnocování na základě dalších dat. Pro podrobosti doporučuji projít články na blogu.

DNS @ Shopify – Emil Stolarsky, Shopify

Krátký lighting talk o mangementu DNS používající Git a CI. Čerstvé open source přímo před konferencí.

• https://github.com/Shopify/record_store
• https://github.com/Shopify/ejson

Availability Objectives of SoundCloud’s Microservices – Bora Tunca, SoundCloud

SoudCloud je autorem Prometheus.io monitoringu a měli dvě přednášky co jsem viděl. Mají dnes microservice architekturu rozdělenou do několika vrstev a podle toho je daná požadovaný dostupnost a také pracují s graceful degradation pokud to jde. Jako příklad jsou třeba statistky k jednotlivým trackům. Modul stats má SLO 95% a tracks mají 99.995% a tak je to zohledněné i na UI.

The Knowledge: Towards a Culture of Engineering Documentation – Riona MacNamara, Staff technical writer, Google

Riona mluvila o hrozném stavu dokumentace v Google. Přirovnala ji k testování v roce 2005. Jak to celkově zhoršuje produktivitu, spolehlivost a rychost. Zkoušeli to několikrát vyřešit pomocí vytvoření komplexního dokumentačního systému, který vytvoří někdo pro celou firmu a zeshora se to prosadí.

Tento přístup nefungoval a proto v roce 2014 úplně změnili přístup, začali ze zdola nahoru od jednotlivých engineerů a vytvořili systém g3doc, který dnes používá 10k projektů v google a mají přes 17k autorů, kteří do dokumentace přispívají.

Klíčové bylo dát dokumentaci přímo do repositářů projektu, mít to v jednoduchém formátů čitelném přímo v IDE. Zvolili markdown, který si potom silně vylepšili. Mají potom na serverové straně systém, který vygeneruje HTML a publikuje dokumentaci na url, které se dá lehce podle jména projektu odhadnout.

Projekt bohužel není open source, ale snad jednou bude. Díky spoustě googlerů, kteří do projektu v rámci svých 20% přispěli je tam hodně funkcí, které mi máme díky Sphinx.

Odkazy na zdroje

• http://www.franklinangulo.com/blog/2016/7/11/srecon-2016-dublin-day-1
• http://www.slideshare.net/goldshtn/the-next-linux-superpower-ebpf-primer
• https://github.com/dastergon/awesome-sre

Budu se snažit průběžně doplňovat zdroje a přidám odkazy na videa až budou.

Shrnutí

Pokud se zajímáte o transformaci engineeringu a říká vám něco DevOps nebo SRE je to konference pro vás. Pokud vás to zajímá a chtěli by jste si o tom promluvit, klidně mě kontaktujte. Bohužel jsem nenašel vhodnou konferenci v Česku, kde o tom mluvit, aby se to dostalo více do povědomí firmem.

Další SREcon bude příští rok zase v USA (March 13–14, 2017, SF), Evropě (Dublin) a také poprvé v Asii (May 22–24, 2017, Singapur).

Zkusím popsat co je to serverless trochu lidsky. Samotné bez serveru je asi moc široký pojem. Pokud se podíváte na Awesome Serverless najdete zde všechno možné od databází jako Firebase, Hoodie, které poskytují frontendovým aplikacím vše co potřebují k běhu, až k systémům, které vám umožňují více než stávající řešení na principu virtuálních serverů. O těch se hodně mluví a nejstarší z nich je Amazon Web Service Lambda.

AWS příšlo se základním systémem v roce 2014 a postupně to rozšiřovali, přidali v roce 2015 AWS Gateway a dnes je systém celkem dobře použitelný a vzniklo i několik frameworků (Serverless, Apex a Flourish).

Amazon, ale není jediný kdo má podobný systém. Dnes je k dispozici těch systémů několik.

• IBM Bluemix OpenWhisk (únor 2016, early access)
• Google Cloud Functions (únor 2016, alfa)
• Microsoft Azure Functions (březen 2016, in preview)

Jak vidíte kromě AWS, ale jsou ostatní spíše na začátku, ale za pár let v tom bude dobrá konkurence. Zvláště je důležité dořešit věci o které se snaží frameworky a to zjednodušit vývojáři nastavení samotné infrastruktury, verzování aplikace a prostředí do kterých nasazujete.

Proč by mě to mělo zajímat?

Dnes se můžete na Lambdu koukat jako na něco co umí pustit kód v NodeJS, Pythonu nebo Javě. Ale hlavní síla je v kombinaci s dalšími AWS službami, ze kterých můžete vytvořit obří velmi dobře škálující aplikaci za velmi nízkých nákladů pro provoz resp. závislé na tom co opravdu aplikace dělá. Skoro zdarma dostanete neprodukční prostředí, které můžete mít stejné jako to produkční. Je potřeba samozřejmě aplikace navrhovat trochu jinak a ne pro každé použití je to správná cesta, ale na spoustu věcí to je zajímé.

Například si můžete udělat vlastní GraphQL server nebo Slack bot.

Před nedávnem se konala i specializovaná konference na toto téma.

PragueJS o Serverless

Pokud vás to zaujalo, přijďte si poslechnout nejen moji přednášku o Serverless na meetup 30.6.2016 do kanceláří STRV. Registrace je na eventbrite.

Můžete to slyšet přímo od Bena Treynora. Poslechněte jeho skvělou přednášku Keys to SRE z SRECon14.

Díky, že jste přímo neutekli na přednášku Bena Treynora, podívejte se na ní aspoň někdy později, protože to opravdu stojí za to.

Jestli jste se snažili někdy ve firmě zavést DevOps tak jste možná narazili, případně říkáte, že máte DevOps, ale často to úplně ve všem nepomohlo.

Přišel jsem před 7 lety do LMC. Měli jsme všecho rozdělené na týmy podle toho co kdo dělal a přišlo nám to tehdy logické. Produkt měl svůj tým, QA měl svůj tým, Support, Ops, Sales, Marketing a Development také. Development byl ještě rozdělný na tři týmy podle specializace (interní systémy, B2C). A ještě jsme měli externí partnery. Také jsme měli release 3-4 krát do roka a celkem to fungovalo.

Potom, ale přišla revoluce. Měli jsme skvělé školení od produktového vývoje a ve firmě se všechno začalo měnit. Vytvořili se produktové týmy. Každý tým měl scrummastera, produkťáka, ux a programátory, kterří dělali i QA. Jediné co zůstalo bylo Operations. Potom jsem z firmy odešel a nevím zda se v tom posunuly dál, ale to je dost těžký krok zvláště pro větší firmu.

V Apiary přišel náš CTO Lukáš Linhart s tím, že vytvoříme SRE tým, který bude horizontálně podporovat ostatní týmy na produktech. Protože tyto věci mě baví, tak jsem do toho týmu šel a dnes ten malý tým vedu. Nejdříve jsem si myslel, že to je prostě takové agilní, startupové OPS. Ale až později mi došlo, že za tím je mnohem víc a že se to musí přenést do kultury celé firmy.

Podle mě nejdůležitější věc je, aby se byl společný pool lidí. Prostě přijmete jen programátory, žadné lidi co chtějí dělat jen OPS. Důležité, aby to byli hodně líní programátoři a nechtěli nic dělat ručně a když to dělají podruhé už si na to píší nějaký kód, zautomatizují to a příště už mohou řešit něco jiného. Snaha o automatizaci je klíčová. Každá firma chce růst a nechcete to dohánět neustálým nabíráním nových lidí, kteří pokrývají jen provoz.

Začněte SRE dělat hned ono se vám to v budoucnu vrátí. V Googlu začali v 6 lidech (2003) a těď mají v SRE asi 2500 lidí (odněkud zaslechnuto).

Musíte zapojit do OPS práce programátory. V Apiary každý programátor má službu a stará se i produkční systémy, je to potřeba, aby to každý z nich uměl. Využíváme hodně SaaS řešení což celou práci programátorům ulehčuje, když máte technický problém, je tu support od poskytovale co vám rád pomůže. Tohle funguje velmi dobře.

Klíčový rozdíl mezi SRE a DevOPS jsou error buggety. Aby jste neměli válku mezi DEV a OPS týmy, dá se to nastavit jednoduše. Stanovíte SLA mezi systémy. SLA může být interní nebo externí se zákazníky a tuto metriku nestanoví obvykle ani SRE nebo DEV tým. Je to spíš nástroj managementu. Důležité je jen, aby tým se svým SLA souhlasil, nepřišlo mu to nesmyslé. Potom se dá vypočítat error budget pomocí: 1 - SLA a máte v hodnotu budgetu.

Budget musíte měřit a mít to v monitoringu, kde na to vidí jak DEV tak SRE tým. Když je DEV tým pod limitem svého error budgetu, může provádět deploy. Po překročení limitu nesmí nasazovat. To má tu výhodu, že je to čirá matematika, nikde tam není boj o moc apod. DEV se naučí hlídat si svůj error budget a PR, které mají málo testů nebo mají jiná rizika nebudou mít tak jednoduchý život.

Samozřejmě to není všechno kolem SRE, je toho mnohem více. Pro ty, které SRE problematika zajímá tak doporučuji sledovat SRE Weekly nebo se zůčastnit SRECon 2016.

Pokud budete upgradovat, buďte opatrní, nový formát image není zpětně kompatibilní.

V originálu si novinky můžete prostudovat na blogu Dockeru:

• Docker 1.10: New Compose file, improved security, networking and much more!
• Docker Engine 1.10 Security Improvements
• Compose 1.6: New Compose file for defining networks and volumes

pokud si chcete přečíst novinky v češtině pokračujte v mém článku.

Novinek je spousta, ale budu se věnovat jen těm zásadním.

Docker Engine 1.10

Docker 1.10 používá nový systém pro ukládání image a layers. Není to zpětně kompatibilní, pokud uděláte upgrade, nemůžete použít staršího clienta. Migrace, která se spustí může trvat poměrně dlouho, pozor pokud máte docker v produkci. Při migraci se počítají SHA256 checksumy pro každý soubor.

Tyto změny s podporou paralelního pushovaní by měli urychlit docker push a docker pull, zvláště při pushi by to mělo být znát.

Další změny se týkají bezpečnosti. Podpora seccomp profiles, User namespaces, Authorization plugins. V dalších verzích budou PID Control Group.

• nový příkaz docker update umožňuje měnit resources za běhu například pro navýšení paměti apod.
• příkaz docker images podporuje flag --format
• nový status=dead pro filtrování v docker ps
• deprecated -f pro docker tag
• přidaný support pro ** v .dockerignore pro více úrovní adresářů
• nový logging ovladač pro Splunk
• podpora více tagů v buildu

Docker Compose 1.6

Nový formát version 2 pro docker-compose.yml.

1
2
3
4
5
6
7
8
9
10

version: '2'
services:
  web:
    build: .
    ports:
     - "5000:5000"
    volumes:
     - .:/code
  redis:
    image: redis

Migrace většinou nebude složitá, stačí přidat version: 2 a services: na začátek a odsadit.

Nové vlastnosti

• nový příkaz events stejný jako docker events
• nový příkaz config pro validaci docker-compose.yml včetně interpolací a použítí extendu
• nový příkaz create pro vytvoření kontejnerů bez spuštění
• nový příkaz down pro stopnutí a odstranění všeho co pouští příkaz up
• přídané nové konfigurační vlastnosti cpu_quota, stop_signal
• flag --abort-on-container-exit stopne všechny kontainery pokud jeden vyhodí exit

Docker Machine 0.6

Zásadní vylepšení developer experience v příkazech docker-machine start, docker-machine stop a ostatních nemusíte používat argument default pokud ho přímo nespecifikujete.

Driver pro EC2 umí používat default VPC and automaticky číst přístupové údaje z ~/.aws/credentials.

Spousta drobných změn, které mi nepřišli už důležité.

Závěr

Každý release přinese spoustu změn. Celý ekosystém dockeru je poměrně mladý, ale o to více dynamický.

V Praze se každý měsíc konají docker meetupy, pokud vás tato problematika zajímá. Přijďte nebo nabídněte svoji přednášku pořadatelům.

Sublime Text jako vývojové prostředí

Sublime používá dost lidí, u nás v Apiary je to rozdělné mezi Emacs, Vim, Sublime, Atom a Webstorm. Řekl bych, že Sublime je asi nejvíc používaný, ale to se také mění. Já ho preferuju hlavně pro jeho rychlost startu.

Používám tyto balíčky:

• Package Control – balíčkovací systém
• API Blueprint – podpora pro práci s jazykem [API Blueprint
• Alignment – zarovnávání na různé znaky, obvykle např. require na začátku js souborů
• All Autocomplete
• Better CoffeeScript – podpora pro CoffeeScript
• Color Highlighter – zobrazí barvu v CSS
• FileDiffs – porovnávání souborů přímo v Sublime, podpora clipboard, velmi užitečné
• Focus File on Sidebar
• GhostText – s pluginem v Chrome je to combo pro editaci textarea na webu přímo v Sublime
• Git
• Hayaku – jednoduší psaní CSS
• JSCS Formatter – lepší formátování pro Javascript
• Pretty JSON – formátovaní JSON
• Markdown Preview – podpora pro Markdown
• SidebarEnhancements
• Stylus – podpora pro jazyk
• Terraform – podpora pro jazyk
• TrailingSpaces – příkazy pro mazání, zobrazení whitespace z dokumentů
• GoSublime – podpora pro jazyk Go
• GoImports – podpora pro zakomentování importů v Go
• Pretty YAML – formátovaní YML
• AutoSpell – kontrola překlepů v angličtině
• Docker Based Build Systems – pouštění kódu v dockeru pro různé jazyky
• Dockerfile Syntax Highlighting – zvýrazňování syntaxe pro Dockerfile
• Seti UI – vzhled který používám

Terminal

Možná se divíte, že terminál uvádím, ale i tady lze nastavit tisíce věcí.

• iTerm2
• oh-my-zsh
• ack
• dotfiles

Pokud používáte pro programování bash doporučuji na Macu, hlavně upgradovat přes homebrew na verzi 4, která bohužel stále není v základu Mac OS X.

Mých top 10 příkazů v terminalu. Dostal se tam jen 1 alias a to gco - git checkout.

1
2
3
4
5
6
7
8
9
10

 1  2015  20.152%    git
 2  834   8.34083%   heroku
 3  734   7.34073%   gco
 4  499   4.9905%    cd
 5  465   4.65047%   cat
 6  451   4.51045%   docker
 7  317   3.17032%   npm
 8  264   2.64026%   ack
 9  252   2.52025%   curl
10  157   1.57016%   brew

Pokud nemáte vlastní dotfiles, doporučuji si je vytvořit a uchovávat si konfiguraci pro svůj terminál.

Pro používání Datadog na Heroku je potřeba několik věcí. Za prvé, pro datadog agenta potřebujete custom buildpack, který v kombinaci s vaším buildpackem vám umožní mít vše pohromadě. Pokud to nechcete můžete udělat samostatnou service přes kterou se dají parsovat logy pomocí této knihovny v NodeJS. Pokud chcete do Datadogu zapisovat deploy na Heroku použijte emailový post deploy hook. Aplikaci a její metriky můžete posílat přes Datadog API.

Začátek

Jako první jsem použil výchozí aplikaci od tvůrců a pustil tam jednu malou aplikaci, kde počet req/min dosahoval několika desítek a vše bylo bez problémů.

Tak jsem zapojil produkční aplikace. Počet requestů stoupl na 3000 req/min a aplikace začala mít značné problémy i když běžela na Performace-M dynu.

Řešení

Po diagnostikování těchto problémů jsme se dali do hledání memory leaks v NodeJS aplikaci a současně jsme zkusili tuto malou service přepsat do Go.

Obě řešení zafungovala a za pár hodin práce jsme měli už přijatelné výsledky v NodeJS. Mohli jsme snížit používaná dyna na běžné 1X a tam provádět další srovnání.

Verze v go langu je na tom ještě trochu lépe hlavně s ohledem na stabilitu a pamět. Tuto verzi jsme nechali potom trvale v běhu na nejmenším dynu k dispozici s monitoringem.

Závěr

Pokud vás toto zaujalo pojďte si popovídat o Go langu na první Go lang meetup v Praze. Budeme mít lighting talk o tomto příkladu s dalšími detaily a zúčastní se i další firmy, které řeknou o svých zkušenostech. Pokud vás zajímají nějaké detaily o používaní Datadogu na Heroku tak se ozvěte v komentářích.

Amazon web services operují v několika regionech. Dnes je jich 10 a z toho máte dva i v evropě. Pokud chcete zkoušet novinky, které AWS poskytuje doporučuji použít region us-east-1.

Amazon kromě regionů, které vám umožňují poskytovat služby z geograficky nejbližšího místa vašim zákazníkům, také podporuje Availability Zones (AZ), které vám umožňují zvýšit spolehlivost v jednom regionu. V každém regionu je k dispozici několik zón. Pokud máte skupinu serverů ve škálovacím režimu je dobré je rozprostřít přes několik AZ a tím máte jistotu pokud dojde k výpadku jedné zóny, že vaše služba poběží.

Elastic Beanstalk podporuje PHP, NodeJS, Python, Ruby, Java, Go a Docker.

Teď k Elastic Beanstalku (EB). Služba využívá zdroje AWS. Na vstupu je Elastic Load Balancer, který vám směřuje provoz na vaši aplikaci.

Docker

Pro funkci dockeru potřebujete buď Dockerrun.aws.json nebo Dockerfile. Já pro svůj příklad používám json file.

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "AWSEBDockerrunVersion": "1",
    "Image": {
        "Name": "registry:0.9.1"
    },
    "Volumes": [
    ],
    "Ports": [
        {
            "ContainerPort": "5000"
        }
    ]
}

tady je příslušný dockerfile, ale ten nemusíte použít. Buď json file nebo dockerfile.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

FROM registry:0.9.1

ENV DEPS loose
RUN pip uninstall -y docker-registry-core && pip uninstall -y boto && pip install boto==2.34.0 && pip install docker-registry-core

RUN env

ENV SETTINGS_FLAVOR s3
ENV AWS_BUCKET $AWS_S3_BUCKET
ENV STORAGE_PATH /registry
ENV AWS_KEY $AWS_S3_ACCESS_KEY
ENV AWS_SECRET $AWS_S3_SECRET_KEY
ENV AWS_REGION $AWS_S3_REGION
ENV AWS_HOST s3.amazonaws.com
ENV AWS_PORT 443
ENV AWS_CALLING_FORMAT REGULAR
ENV DEBUG True
ENV LOGLEVEL debug

EXPOSE 5000

CMD ["docker-registry"]

Možná vás překvapí, že kontainer nemá definovaný port na který má být směřovám. EB ve verzi 1 směřuje všechno na port 80, kde nginx proxy. Pokud definujete více portů použije se jen ten poslední.

Není to moc užitečné a pokud potřebujete použít více portů nenašel jsem vhodné řešení. Konfigurční předpis, ale již existuje ve verzi 2, kde jsou možnosti mnohem širší a tyto problémy se dají dobře řešit. Ale zatím to není v oficiální dokumentaci a našel jsem to jen AWS labs.

Nginx Proxy

Jak jsem říkal v předchozím odstavci, máte defaultní nginx proxy a veškeré nastavení se dá změnit, ale musíte to udělat pomocí adresáře .ebextensions.

Například konfigurace nginxu:

1
2
3
4
5
6
7
8
9
10
11
12
13

files:
  "/etc/nginx/docker-registry.conf":
    mode: "000644"
    owner: root
    owner: root
    content: |
      proxy_pass                        http://docker;
      proxy_http_version                1.1;
      proxy_set_header  Host            $http_host;
      proxy_set_header  X-Real-IP       $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header  Authorization  "";
      proxy_read_timeout               900;

a tady konfigurace vlastní website, kde jsem přidal autorizaci.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

files:
  "/etc/nginx/sites-available/elasticbeanstalk-nginx-docker-proxy.conf":
    mode: "000644"
    owner: root
    owner: root
    content: |
      server {
        listen 80;

        client_max_body_size 0;
        chunked_transfer_encoding on;

        location / {
          auth_basic            "Restricted";
          auth_basic_user_file  docker-registry.htpasswd;
          include               docker-registry.conf;
        }

        location /_ping {
          auth_basic off;
          include               docker-registry.conf;
        }

        location /v1/_ping {
          auth_basic off;
          include               docker-registry.conf;
        }
      }

Závěr

Je potřeba definovat několik proměnných prostředí, které jsou vidět na skriptu pro spuštění.

1
2
3
4
5
6
7
8
9
10
11
12

docker run \
         -e SETTINGS_FLAVOR=s3 \
         -e AWS_BUCKET=$AWS_S3_BUCKET \
         -e STORAGE_PATH=/registry \
         -e AWS_KEY=$AWS_S3_ACCESS_KEY \
         -e AWS_SECRET=$AWS_S3_SECRET_KEY \
         -e SEARCH_BACKEND=sqlalchemy \
         -e DEBUG=True \
         -e LOGLEVEL=debug \
         -e AWS_REGION="us-east-1" \
         -p 5000:5000 \
         registry

PaaS jako Elastic Beanstalk je celkem použitelný, má CLI clienta, funguje s gitem. Má to některé věci, které mi chybí například na Heroku (VPC, auto scaling). Ale přesto mi například práce s heroku přijde příjemnější i když to teď zabili změnou plánů.

V poslední době se zabývám technologiemi pro řízení clusterů s docker konteinery.

Pokud by to někoho zajímalo, zkusím jsem shrnout s čím jsem se potkal a kde vidím možné využití.

Nástroje, které můžete použít cluster management:

• Apache Mesos (cpp, api for java, python, c++)
• Docker Swarm (golang)
• CoreOS Fleet (golang)
• Google Kubernetes (golang)
• Spotify Helios (java)
• New Relic Centurion (ruby)

potom k tomu ješte patří některé frameworky pro Mesos a to Marathon a Chronos. A Kubernetes Framework for Apache Mesos.

Ještě potřebujete nástroj pro service discovery:

• CoreOS Etcd (golang)
• Hashicorp Consul (golang)
• Apache Zookeeper (java)

Etcd používá Kubernetes a další projekty. Service discovery je potřeba pro management clusteru. Můžete použít stejně jednoduše i ostatní projekty.

Apache Mesos umí pracovat s různorodým prostředím včetně Amazon ECS service. Framework Marathon vám potom slouží k pouštění dlouho běžících konteinerů pro aplikace a Chronos typicky pro batch processing například pro zpracování velkých dat. S Mesosem musíte provozovat ZooKeeeper pro discovery service.

Protože se snažím Javě vyhnout a raději volím nástroje v jiných jazycích, kde mám větší znalosti. Pro discovery service clusteru bych raději použil Consul nebo Etcd.

Google Kubernetes je poměrně vyspělý nástroj používaný pro Google Cloud a adaptovaný například RedHatem pro OpenShift V3. Tam mám trochu výhradu, že to nemá podporu pro více uživatelů a neumí pracovat s externím filesystémy co vím. Ale dá se používat na tvorbu dokonce hybridních clusterů mezi více poskytovateli (AWS, Google Cloud, OpenShift, fyzické stroje).

Docker Swarm je nástroj pro řízení clusterů konteinerů přímo od Dockeru, ale kromě základních příkladů není k dispozici nic většího, poporuje několik discovery service (etcs, consul, zookeeper). Nevím o nikom, kdo by to používal ve větším měřítku.

CoreOS Fleet je systemd a etcd a nemám s ním zkušenosti vůbec žádné. Projekty kolem CoreOS jsou zajímavé. Mají vlastní technologii konteinerů Rocket.

Stejně jako CoreOS snaží se o podobnou věc i Project Atomic od RedHatu. Vytvořit základní systém pro práci s konteinery.

Závěr je asi takový, že pokud budete chtít řídít vlastní cluster asi zvolíte buď Mesos nebo Kubernetes. Osobně asi budu volit Kubernetes, co vy?

Banky posílají změnu zůstatku emailem a SMS. Za SMS začínájí účtovat třeba i 2Kč což mi přijde fakt hrůza. Tak jsem si řekl jak dostat ten email do telefonu pomocí push notifikace, aby mě to nestálo moc peněz a dalo se případně používat univerzálně.

Pushover

Služba Pushover není zcela zdarma, ale zaplatíte jen jednorázově při nákupu aplikace nebo při aktivaci desktop notifkací. A získáte tím možnost zasílat notifikace skoro z čehokoliv a kam potřebujete. Můžete konfigurovat kdy nechcete být rušeni (noc, víkendy apod.).

Parse emails by Zapier

Služba Zapier má zajímavou službu na parsování dat z emailu, která se zatím zdarma a nenašel jsem jinou, který by byla dobrá pro tento můj problém. Existují sice služby na parsování emailů, ale ty jsou spíše děláný na zpracování velkého množství emailů a nejsou zdarma.

Na službě si zřídíte emailovou schránku na kterou si přepošlete email z banky, označíte si v něm část co chcete posílat na mobil. Služba potom toto políčko poskytne jako placeholder pro zpracování a poslání dále.

Zapier

V Zapieru potom nakonfigurujete zpracování emailů z vaší schránky na parseru a poslání na mobil pomocí pushover. Zkoušel jsem třeba i hangouts, ale nedošlo mi to všechna zařízení a není to tak komfortní jako pushover.

Závěr

I bez programování můžete vyzrát na chytráky co si snaží za služby s minimálními nároky účtovat hromady peněz a Zapier nebo IFTTT jsou na to super pomocníci.

Ochtra

Naštěstí jsem to dělat nemusel, protože vznikl malý projekt ochtra (One Commit Hook To Rule All).

Tento projekt teď umí kontrolovat Ruby, JavaScript, Python, Bash, Dash, Go, PHP, XML, JSON, YAML. A co se mi zvláště líbí je, že autor pěkně popsal instalaci, která je potřeba, aby vám hook fungoval automaticky, když použijete git clone.

Instalace

Potřebujete git 1.7, kde je podpora pro git templates.

mkdir -p ~/.gittemplate/hooks
curl https://raw.github.com/kvz/ochtra/master/pre-commit -o ~/.gittemplate/hooks/pre-commit \
 && chmod u+x $_
git config --global init.templatedir '~/.gittemplate'

Instalace vytvoří adresář s template pro git, která se použije pokud dáte git clone, případne git init.

Git init potřebujete pokud už máte projekty někde vyclonované.

cd my-project
rm .git/hooks/pre-commit
git init

Celý projekt má i testy a podpora je pro všechno co mě napadlo. Pokud něco někomu chybí tak se ozvěte nebude to problém přidat.

Co to je docker?

Pěkně podrobně to najdete na samotném webu docker.io a také jsem to snažil postihnout ve své přednášce na letošním Devfestu.

Co se do přednášky nevešlo

Všechny příklady, které jsem nestihl předvést naživo jsou v repository a jsou pro verzi 0.6.7 a mezi Devfestem a tímto článkem už stačila vyjít verze 0.7, která je revoluční v podpoře více distribucí (Fedora, RHEL, Ubuntu, Debian, Suse, Gentoo, Arch). Přidáný storage drivers o kterých jsem mluvil kromě AuFS je to VFS a DEVICEMAPPER a brzo budou další ZFS, Gluster, Ceph.

Závěr

Autoři slibují v další verzi se zaměřit hlavně na kvalitu, doplnění dokumentace a api. Je před nimi mnoho práce, ale čím dál více lidí docker používá i v produkci. O dockeru budu mluvit 13.12. také v rámci Web Inkognito a 3-4.12.2013 se koná celosvětový Docker HackDay, pokud by jste se chtěli zůčastnit nebo pomocí s organizací místa kde se to bude konat dejte vědět mě nebo organizátorům.

Tady je příklad hooku pro gitolite, který používáme na některých repository.

Občas je potřeba notifikovat jen větev, která se změní, aby to nepustilo zbytečně joby, kde změny neproběhli.

Nejdůležitější části, jsou detekce větve, escape lomítka ve jménech větve.

branch=$(git rev-parse --symbolic --abbrev-ref $1)
escaped_branch=$(echo $branch | sed s:/:%2F:g)

potom vlastní git-notify volání curlem.

REPOSITORY_BASENAME=$(basename "$PWD")
curl "http://jenkins.firma.cz/git/notifyCommit?url=ssh://git@git.firma.cz/$REPOSITORY_BASENAME&branch=$escaped_branch"

Snad to bude někomu užitečné také, pokud si chcete o Jenkinsu popovídat více, dejte vědět.

Těmto řešením se věnuje web nobackend.org, kde se dají najít tyto řešení:

• Backendless
• deployd – example in angularjs
• Firebase
• Hoodie
• Kinvey
• Parse
• remoteStorage
• Sockethub

Bohužel jsem neměl tolik času, abych podrobně prozkoumal všechny řešení. O Firebase jsem se dozvěděl z přednášky na meetupu:

Z této přednášky jsem vycházel pro svoji přednášku na PragueJS.

Firebase

Zajímavé na tomto projektu je, že je to poměrně mladý projekt, ale který vznikl z projektu Envolve (2009), což je skupinový chat pro tisíce websites. Zjistili, že vyvíjený backend je užitečný pro více druhů aplikací než jenom chat a nabídli ho jako produkt Firebase.

Hlavní věci, které dělají Firebase zajímavou jsou: – JSON formát pro data – je to dokumentová databáze v mnoha směrech mi připomíná práci např. s CouchDb – REST každý dokument má HTTP endpoint s kterým se dá pracovat, můžete používát API v přes HTTP, nativní knihovny pro Android (Java) a iOS (Objective-C) a javascript. – přímo od autorů je knihovna pro práci s AngularJS – AngularFire a pro práci s Backbone – BackFire. – real-time synchronizace dat, pokud přistupujete z více klientů tak se změny projeví v milisekundách – automatic scaling je pěkná věc pokud potřebujete opravdu řešit hodně klientů, autoři slibují, že je jedno pokud máte 1 klienta nebo 1 milion a že nebudete muset nic na aplikaci měnit, což je dost ambiciózní, ale vzhledem ke klientům jako je Atlassian, CodeAcademy, CBS a další řekl bych že už si to více než ověřili – security – bezpečnost je řešena celkem jednoduše a přitom celkem se dá dobře nastavit přes security rules. Vlastní přihlašovnání je podporováno přes jejich Firebase Simple Login nebo můžete použít nějakou vlastní implementaci. – servery nepotřebujete. Firebase je schopná nahradit aplikaci psanou na serveru, jde jen o to zvážit kdy to ještě stačí a kdy už potřebujete nějaké další části infrastruktury navíc.

AngularFire

AngularFire je modul, který řeší vlastní authentikaci pomocí angularFireAuth.

Stačí mít includnuté tyto soubory pro práci s firebase.

<script src="https://cdn.firebase.com/v0/firebase.js"/>
<script src="https://cdn.firebase.com/v0/firebase-simple-login.js"/>
<script src="angularFire.js"/>

potom v controlleru se předá angularFireAuth přes dependency injection

function MyController($scope, angularFireAuth) {
    var url = "https://<my-firebase>.firebaseio.com/";
    angularFireAuth.initialize(url, {scope: $scope, name: "user"});
}

v šabloně potom máte vlastní přihlašování

<span ng-show="user">
 | <a ng-click="logout()">Logout</a>
</span>
<span ng-hide="user"><a ng-click="login()">Login</a></span>

metody pro login přes Firebase simple login, které použijí facebook takto jednoduše deklarujete

$scope.login = function() {
    angularFireAuth.login("facebook");
};
$scope.logout = function() {
    angularFireAuth.logout();
};

AngularFire podporuje implicitní a explicitní data binding. Příklady najdete v dokumentaci.

Firebase Open Source

Na githubu najdete všechny příklady a zdrojové kódy, ke všemu co se vyvíjí kolem Firebase. Postupně to přibývá a většina demo příkladů jsou reálně použitelné za ty nejzajímavější bych zmínil:

• Firepad
• Firechat
• Firefeed

Závěr

Tyto nové databáze jsou velmi zajímavé, ale těžko se asi porovná to nejzajímavější a to jak se vypořádají s konflikty při synchronizaci. Pokud používáte nějako jako je Evernote nebo nějaký todo list a máte ho na počítači, mobilu a tabletu. Sami víte jak je obtížné pokud nejsou všechny zařízení stále online občas udržet konzistenci. Ve Firebase se to dá částečně řešit pomocí security rules, ale stejně si občas myslím, že může být problém.

ng-animate

Deklarativní animace pro aplikace v Angularu. Podpora pro CSS animace a přechody s možností fallbacku pomocí JS. Pro vlastní animace je dobré použít některou s knihoven pro CSS animace (Greensock.js, Animate.css, Custom CSS3 Keyframes). Direktiva se stará o práci s DOMem, nastavuje potřebné třídy a timing, také zabraňuje vnořeným animacím.

$http

Měla by být přidána podpora pro blob a authentication (metoda withCredentials). Budete si moci více nastavit XSRF header a názvy cookie. Přidá se podpora pro zrušení requestů a podpora pro around interceptors.

Around interceptors se dají dobře využít například při authentication, asynchronní zpracování request/response a práci s chybami. Například chcete provést request a server vrátí, že vypršela session a pomocí interceptoru vyvoláte přihlášení a potom pokračuje původní request.

$resource

Více konfiguračních nastavení (hlavičky, url), api bude vylepšené o podporu promise a měli by být k dispozici i interceptory.

$route a ngView

Separátní moduly, rozšíření o možnost zachycení všech parametrů a přidána podpora pro animace.

    when('/users/:userId/params/*params/'

ngRepeat

V této snad nejpotřebnější direktivě je přidána podpora pro animace, potom je možnost opakovat sadu elementů (multi-element repeater) pomocí ng-repeat-start a ng-repeat-end a v neposlední řadě podpora track by paramteru, kdy se dá kontrolovat asociace mezi modelem a DOMem.

Controller as

Tato konstrukce nám umožní jednoduší zápis a není potřeba používat v controlleru $scope (samozřejmě pokud ho nepotřebujete např. při $watch()).

    <body ng-controller="DemoController as demo">
    <tr ng-repeat="student in demo.students">
        <td></td>
    </tr>
    </body>

    function DemoController() {
        this.students = [ ... ]
    }

ng-if

Tato direktiva přejatá z projektu AngularUI umožňuje udělat podmínku na kompilaci části šablony a reší některé problémy, které se nadali zvládnout pomocí ngShow a ngHide.

Expressions

Podpora pro nové operátory: ===, !==, ? Konečně lze napsat:

    ng-class="loggedIn ? 'user': 'anonym'"

ngTouch

Podpora pro touch eventy v ngClick a ngSwipe.

Shrnutí

Přibude jestě několik vylepšení pro bezpečnost (CSP) a vylepší error hlášky, také by se měla zlepšit dokumentace a bude interaktivní tutorial. Dema a detaily najdete také ve videu na youtube.