AWS ECS Dotazy

req.md

1. Porty

Zatím mám jenom jednu ECS instanci. A mám problém s portama. Task je v modu Host a container má Port mappings: Container port 80 tcp. Pokud service nastavím Number of tasks na 2. Tj chci aby běželi 2 containery tak dostanu error.

service goodbaby-test-service was unable to place a task because no container instance met all of its requirements. The closest matching container-instance bcf744e7-7ad5-xxxx-xxxx-ab277caa9c0d is already using a port required by your task. For more information, see the Troubleshooting section.

Celé to je napojené na ELB (classic protože TCP).

2. Update image

S předchozím problémem se dost pravděpodobně pojí i možnost aktualizace na novější image. Protože když udělám novou revizi tasku a aktualizuju service tak se nic nestane protože porty...

Tak jsem to teď trochu zkoumal a došel jsem k tomu že abych mohl dělat update tasku tak musím mít n+1 ecs instance. Kde N = minimální počet běžících tasků. Tj pokud chci redundanci tak musí běžet min 3 instance (2 containery v redundanci = 2 instance + 1 instance kde se postupně budou aktualizovat tasky).

Škoda trochu jsem čekal že to bude scailovat a loadbalancovat mezi containery a né mezi instancema :-(

@Vrtak-CZ kvůli tomu nakonec pro spousta věcí využíváme Elastic Beanstalk s menšíma instancema (t2.micro, t2.small, t2.medium), kde jsou dobré deployment strategie (používáme většinou Rolling + Extra batch, kde nejdřív zkusí nasadit změnu na +1 a pokud projde health check, vymění zbytek).

• Přijdeš tam ale o efektivitu větších instancí, což je hrozná škoda (je lepší mít několik kontejnerů na c4 nebo m4 než separátně po t2)
• A na t2 je potřeba dát pozor, protože když jim dojdou CPU kredity, tak jsou k ničemu.

U AWS (a cloudu obecně) začne většina věcí dávat smysl až při větším počtu instancí. Dobře se tomu jde naproti zmenšováním aplikace, aby běžela na slabších instancích. Tzn místo jedné c4.xlarge mít raději dvě c4.large a podobně.

U ECS mi ale vadilo, že deployment dost trval. Než se všechno odregistrovalo z balanceru, aktualizovalo, registrovalo, .... Máme proto teď dva způsoby pro deploy - opatrný, který tohle všechno dělá a pak přímý, který akorát na všech instancích udělá git pull z repozitáře s buildovanou aplikací. Většinu času se pak dělá ten přímý, protože většina úprav se týká nějaké konkrétní funkce a nemá vliv na nic dalšího.

Me tam bezi ted vicemene tasky, ktere prekracuji 5min co ma lambda nebo to neslo jednoduse portnout na lambdu. Ale v poslednich mesicich jedeme vsechno vlastne uz na Lambde mimo ECS. Stale mame obcas problemy i s tou jejich registry, ze nejde pullnout image a to se to dost zlepsilo, drive to bylo o dost casteji.

Kazdopadne mi prijde dnes Kubernetes jako lepsi reseni, uvidime co predstavi na reInventu.

@vvondra to je přesně to na co narážím aktuálně máme jeden image a chceme škálovat počet containerů. Což by se super dělalo třeba právě nad c4 instancema. t2 je v tomhle ohledu fakt na ***.

@soukicz

Máme proto teď dva způsoby pro deploy - opatrný, který tohle všechno dělá a pak přímý, který akorát na všech instancích udělá git pull z repozitáře s buildovanou aplikací.

Jako že to udělat git pull v běžícím containeru?

Každopádně díky kluci (@soukicz, @vvondra a @abtris) za info! Skoro bych řekl, že pro náš use-case zatím ECS moc vhodné není.

Používáme ALB spolu s ECS na produkci na amateri.com (peak 22tis req/min). ECS bezi na EC2 spot fleetech s autoscalingem (diky @soukicz). EC2 pouzivame c(3/4).(x)large. Na jednom serveru bezi nekolik docker instanci (klasicke i crony). Deployment je automaticky z gitu->jenkins->docker image v ecr->deployment. Cele je to na par minut. Problemy s ECR jsem nikdy nezaznamenal. Cele to bezi z eu-west-1 (Irsko).

@dada-amater jak řešíte loadbalancing vice "web" / "app" containerů na jedné instanci?

@Vrtak-CZ o vsechno se stara application load balancer. Staci nastavit mapovani v docker kontejneru na port 0 (vybere se nahodne) a v ECS si pak nastavite pri nastavovani service svuj loadbalancer. Pak to funguje zcela automaticky.

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html

My jsme driv pouzivali na hostingu Marathon/Mesos/Chronos. Pripravili jsme si to i pro AWS prave kvuli tomuhle. Nakonec tesne pred spustenim v lete prislo AWS s ALB a tak jsme tomu dali sanci. Pokud to srovnam, ECS nema moc nevyhody.

Na ECS mame vice clusteru. Drive jsem zkousel mit jeden vetsi, abych vyuzil alokovany vykon efektivneji. To se ukazalo nebyt nejlepsi, protoze jedna sluzba pak ovlivnovala druhou. Pokud jsme na AWS, tak to vlastne postrada smysl, protoze si kazdy cluster udelame tak velky jak potrebujeme. Navic kazdy cluster muze mit jinou konfiguraci a byt v jine security group, coz dela vse o kousek bezpecnejsi.