Written by Jak se v HP Helion Development Platform postavené na Cloud Foundry řeší obvyklé členění do vývoje, testování a produkce v rámci procesu nasazování aplikace?
Cloud Foundry: Space
Cloud Foundry a HP Helion Development Platform umožňují v rámci členění na organizace v těchto vytvářet prostory, dílny. Typické použití je právě pro zavedení písečku pro Dev (vývoj), Test (QA) a Prod (produkci). Každému prostoru je možné přiřadit limity využitelných zdrojů. V Dev dílně tak budete asi zdroje docela omezovat a přístup do něj dostanou vývojáři pro práci na nových funkcích. Vývojář snadno a jednoduše svůj kód spustí, PaaS mu přihodí potřebné služby (například databázi) a je tak možné efektivně a rychle psát kód. Jakmile je vývojář spokojen může někdo jiný výsledek jeho práce otestovat v QA pískovišti, které už má zdrojů trochu víc – takže Dev si určitě vystačil s jednou instancí (nejde mu o výkon, ale funkce), zatímco QA už možná spotřebuje zdrojů víc (aby bylo možné vidět i vlastnosti balancingu, většího výkonu a řešení se blížilo produkčnímu prostředí). V produkci pak může být počet instancí nejen vyšší, ale třeba elasticky automaticky řízený díky auto-scale vlastnostem HP Helion Development Platformy. PaaS tedy sama dokáže naklonovat další kontejnery, pokud aplikační výkon přestává stačit.
Podívejte se jak to funguje v jednoduchém českém demu:
Naprosto konzistentní prostředí
To, že máme různé písečky, ale nijak nesnižuje obrovskou přidanou hodnotu PaaS ve formě konzistence prostředí. Díky buildpackům a explicitně definovaným návaznostem se droplet a následně Docker kontejner automaticky připravuje pokaždé stejně a naprosto konzistentně bez ohledu na to, jestli směřuje do Dev, QA nebo Prod. Prostředí tak mají odlišný výkon a redundanci (a tedy spotřebu zdrojů), ale veškeré komponenty, dependencies a způsob připojení služeb (databáze, message bus, memcache, …) jsou konzistentní.
