Tato novinka je dostupná v poslední verzi Dockeru 17.05, musíte mít Edge edici a se zapnutými experimentálním funkcemi, ale objeví se to v další stabilní verzi. Je pro jistotu tady je výpis z mého docker version.

$ 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

Dnes Jenkins zveřejnil betu nového formátu pro popis Continues Delivery Pipelines.

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.

V minulé části jsem probíral proč je důležité mít definice v souboru a proč potřebujeme Continues Delivery Pipelines.

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.

Jenkins je nejznámější řešení na Continues Integration, který existuje už řadu let. Od září je venku konečně verze 2.x (aktuálně 2.19.1 LTS), která obsahuje několik zásadních novinek.

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.

O SRE ve startup budu mluvit 31. řijna na DevOps Meetupu. 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.

Letošní SREcon byl zase v Dublinu. Od 11.7. do 13.7. se zde setkali velcí hráči (Google, Facebook, Microsoft, Amazon) s těmi menšími a vyměňovali si spoustu zkušeností. Letos jsem se mohl poprvé zúčastnit. Nebyl jsem z ČR sám, zastoupení měli Avast, Seznam nebo Skype či Algolia. Dohromady asi 5 lidí. Konference byla vyprodaná a hodně míst měli lidé z Googlu a pokud vás zajímalo jak se pracuje v Dublinském Googlu nebo Facebooku mohli jste si o tom s lidmi promluvit. Celá konference byla ve 4 sálech a to jeden hlavní, který se po keynote rozdělil na dva a potom poslední dva byli hlavně pro workshopy a lighting talky.

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.