Ek speel met Amazon ECS ('n herverpakking van Docker) en ek vind daar is een Docker-vermoë wat ECS blykbaar nie bied nie. Ek wil naamlik graag hê dat verskeie houers in 'n instansie loop, en versoeke wat inkom na IP-adres 1 moet na houer 1 toekaart, en versoeke wat na IP-adres 2 kom, na houer 2 toekaart, ens.

In Docker word die binding van 'n houer aan 'n spesifieke IP-adres gedoen via:

docker run -p myHostIPAddr:80:8080 imageName command

In Amazon ECS blyk dit egter nie 'n manier te wees om dit te doen nie.

Ek het 'n EC2-instansie met veelvuldige Elastiese IP-adresse opgestel. Wanneer 'n houer as deel van 'n taakdefinisie gekonfigureer word, is dit moontlik om gasheerpoorte na houerpoorte te karteer. Anders as Docker, bied ECS egter nie 'n manier om die gasheer-IP-adres as deel van die kartering te spesifiseer nie.

'n Bykomende kinkel is dat ek graag wil hê dat uitgaande versoeke van houer N houer N se eksterne IP-adres moet hê.

Is daar 'n manier om al die bogenoemde te doen?

Ek het deur die AWS CLI-dokumentasie gekyk, sowel as die AWS SDK vir Java. Ek kan sien dat die CLI 'n networkBindings-skikking kan terugstuur wat elemente soos hierdie bevat:

{
  "bindIP": "0.0.0.0", 
  "containerPort": 8021, 
  "hostPort": 8021
},

en die Java SDK het 'n klas genaamd NetworkBinding wat dieselfde inligting verteenwoordig. Hierdie inligting blyk egter slegs uitset te wees, in reaksie op 'n versoek. Ek kan nie 'n manier vind om hierdie bindende inligting aan ECS te verskaf nie.

Die rede waarom ek dit wil doen, is dat ek heeltemal verskillende VM's vir verskillende kiesafdelings wil opstel, deur verskillende houers moontlik op dieselfde EC2-instansie te gebruik. Elke VM sal sy eie webbediener hê (insluitend afsonderlike SSL-sertifikate), sowel as sy eie FTP- en SSH-diens.

Dankie.

answer

Hier is 'n werklike, logiese manier om dit te doen. Dit klink te ingewikkeld, maar jy kan dit eintlik binne 'n paar minute implementeer, en dit werk. Ek implementeer dit eintlik terwyl ons praat.

Jy skep 'n taak vir elke houer, en jy skep 'n diens vir elke taak, tesame met 'n teikengroep vir elke diens. En dan skep jy net 1 Elastiese Load Balancer.

Toepassingsgebaseerde elastiese lasbalanseerders kan versoeke stuur op grond van die gevraagde pad. Deur die teikengroepe te gebruik, kan jy versoeke wat elb-domain.com/1na houer 1 kom, elb-domain.com/2na houer 2, ens.

Nou is jy net een tree weg. Skep 'n omgekeerde instaanbediener.

In my geval gebruik ons ​​nginx, so jy kan 'n nginx-bediener skep met soveel IP's as wat jy wil, en met behulp van nginx se omgekeerde proxy-vermoë kan jy jou IP's na jou ELB se paaie stuur, wat hulle dienooreenkomstig na die regte houer stuur. (s). Hier is 'n voorbeeld as jy domeine gebruik.

server {
    server_name domain1.com;
    listen 80;
    access_log /var/log/nginx/access.log vhost;
    location / {
        proxy_pass http://elb-domain.com/1;
    }
}

Natuurlik, as jy werklik na IP's luister, kan jy die server_namereël weglaat en net na ooreenstemmende koppelvlakke luister.

Dit is eintlik beter as om 'n statiese IP per houer toe te ken, want dit laat jou toe om groepe koppelmasjiene te hê waar versoeke oor daardie groepie gebalanseer word vir elk van jou "IP's". Om 'n masjien te herskep, beïnvloed nie die statiese IP nie en jy hoef nie veel konfigurasie oor te doen nie.

Alhoewel dit nie jou vraag volledig beantwoord nie, want dit sal jou nie toelaat om FTP en SSH te gebruik nie, ek sou redeneer dat jy nooit Docker moet gebruik om dit te doen nie, en jy moet eerder wolkbedieners gebruik. As jy Docker gebruik, moet jy die houer self opdateer, in plaas daarvan om die bediener met FTP of SSH op te dateer. Vir HTTP en HTTPS werk hierdie metode egter perfek.

Een opsie: Skep 'n ELB vir elke kliënt, en ken dan sekere houers aan elke ELB toe.

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

Jy kan nie aan die houer self nie, maar jy kan 'n EC2-instansie maak wat aan 'n spesifieke houer toegewy is. Dan, waar jy toegang tot daardie diens moet kry, kan jy verwys na die EC2-gasheer wat die houer bestuur.

  • Skep 'n toegewyde groepering vir jou dienste met hierdie vereiste
  • Skep 'n AMI-geoptimaliseerde EC2-instansie deur jou voorkeur-instansietipe te gebruik
    • Maak seker dat jy daardie instansie aan die bogenoemde groep toewys deur die UserData-opsie soos beskryf in daardie gids.
  • Skep 'n TaskDefinition met NetworkMode ingestel op "bridge" (dieselfde as jou lessenaar)
  • Skep 'n diensdefinisie met:
    • LaunchType gestel op EC2
    • Groepering gestel na die groepering wat jy hierbo geskep het
    • Taakdefinisie gestel na die taakdefinisie wat jy hierbo geskep het
  • Wys enige sekuriteitsgroepe aan die EC2-instansie toe soos jy andersins sou.

Alhoewel jy steeds direk met 'n EC2-instansie praat, kan jy die IP van die houer (indirek) beheer soos jy die EC2-instansie sou beheer. Dit spaar jou die kopseer om die dienste op die "bare metaal" te laat loop, sodat jy die diens en die konfigurasie daarin makliker kan bestuur en konfigureer.