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...

Bohuzel jsem ELB nepouzival, ale nemelo by stacit mit nastavene portMapping jako vsude v dockeru?

{
  "taskDefinitionArn": "arn:aws:ecs:xxxxx",
  "revision": 1,
  "containerDefinitions": [
    {
      "volumesFrom": [],
      "portMappings": [
        {
          "hostPort": 80,
          "containerPort": 80
        }
      ]
...

a v druhem neco jako

{
  "taskDefinitionArn": "arn:aws:ecs:xxxxx",
  "revision": 1,
  "containerDefinitions": [
    {
      "volumesFrom": [],
      "portMappings": [
        {
          "hostPort": 8080,
          "containerPort": 80
        }
      ]
...

V elb nastavis jednu cestu na 80 a tu druhou na 8080, jinak fakt netusim a spis bych rekl, ze to nepujde.

Chci aby běželi 2 stejné containery kvůli redundanci (když pak udělám update poběží chvilku 3 když bude novej OK tak se postupně zabijou starší až skončím zase u 2). A ELB nemůžeš nastavit aby jeden port loadbalancoval na 2 další.

Vpodstatě jednoduše řečeno chci loadbalancing mezi containerama a né mezi EC2 instancema.

Možná na to jdu úplně špatně.

Proto mám task v network modu Host a ne Bridge abych nemapoval porty na host instanci a neměl tak konflikt.

Jo tak to je mi jasne, musis mit vic EC2 instanci kde ti to bezi pro loadbalancing, to nejde delat na 1 stroji. Ja mam 2 stroje prave kvuli tomu, abych mohl to mit rozlozene kdyby jeden padnul nebo ho upgraduju.

Myslim, ze to je celkem jasne i z toho obrazku tady http://docs.aws.amazon.com/AmazonECS/latest/developerguide/application_architecture.html musis to proste rozdelit.

Přesně od toho je Application Load Balancer (a tvoje otázka důvod, proč jsme plně na ECS nepřešli ze začátku a zvažovali Kubernetes cluster). S klasickým ELB lze jen jeden typ tasku na instanci. My práve chtěli mít heterogenní spot fleet a spoustu různých miniaplikací (integračních pluginů co máme). Občas by to znamenalo, že hodíme dva kontejnery stejnýho typu na jednu instance (ideálně mít alespoň dva kontejnery na dvou instancích, zbytek ale už může být klidně na stejně, jde jen o škálování výkonu)

http://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html:

Support for containerized applications. Amazon EC2 Container Service (Amazon ECS) can select an unused port when scheduling a task and register the task with a target group using this port. This enables you to make efficient use of your clusters.

To asi nepůjde. Už vůbec ne s classic balancerem, který ani nechápe containery a balancuje jen na instanci. A ve specifikaci ALB zase je, že každý port může jít na jednu instanci (ono to dává smysl).

Řeší trochu jinou situaci - kdy různá části aplikace jsou v různých containerech. Zvenčí je pak port 443, ale uvnitř jde /js/ na porty 10121, /css/ na 10122 atd.

To co se ty snažíš vyřešit bych spíš udělal přes jednoduché haproxy na instanci a mít pak dva tasky - každý s jiným portem a deploy do nich udělat postupně. Každopádně to ale jde celé proti logice ECS a asi i AWS obecně, takže se moc nevyužije a bude se to muset částečně lepit ručně.

My práve chtěli mít heterogenní spot fleet a spoustu různých miniaplikací

Přesně na to mi začalo celé ECS (a docker v cloudu obecně) dávat smysl. Nakoupím levné instance ve spot fleet, nechám je balancovat podle procesoru. Je mi celkem jedno kolik jich je a můžou být všemožných typů. Běží na nich pak nesourodé containery a všechno krásně funguje.

Super to je pro tasky, které běží jen chvíli. Nemusím pro ně extra řešit instance a jen se přiživí na téhle hromadě containerů.

Mimochodem to výše s ALB nemám vyzkoušený, pokud to rozběháš, budu rád za potvrzení :) Možná má pravdu souki

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.