2017-08-16 4 views
0

Alors, voici ce que je suis en train de faire:Impossible de se connecter au conteneur docker lié dans ECS

conteneur Nginx lié à -> Rails conteneur en cours d'exécution Puma

En utilisant docker-Compose, cette solution fonctionne très bien. Je suis capable de démarrer les deux conteneurs et le conteneur NGINX a accès au service s'exécutant sur le port 3000 dans le conteneur lié. J'ai été confronté à de nombreux casse-tête lors du passage à AWS ECS, malheureusement.

D'abord, les bits correspondants Dockerfile pour Rails:

ENV RAILS_ROOT /www/apps/myapp 

RUN mkdir -p $RAILS_ROOT 
WORKDIR $RAILS_ROOT 

.... lots of files get put in their proper places .... 

EXPOSE 3000 

VOLUME [/www/apps/myapp/] 

CMD puma -C config/puma.rb' 

Je confirme que pumas commence comme prévu et semble servir le trafic tcp sur le port 3000.

parties pertinentes de mon nginx config:

upstream puma { 
fail_timeout=0; 
    server myapp:3000; 
} 

server { 
    listen 80 default deferred; 

    server_name *.myapp.com; 

    location ~ (\.php$|\.aspx$|wp-admin|myadmin) { 
    return 403; 
    }  

    root /www/apps/myapp/public; 
    try_files $uri/index.html $uri @puma; 

Nginx dockerfile:

ENV RAILS_ROOT /www/apps/myapp 

# Set our working directory inside the image 
WORKDIR $RAILS_ROOT 

EXPOSE 80 

Voilà ma définition de tâche ECS:

{ 
"family": "myapp", 
"containerDefinitions": [ 
{ 
    "name": "web", 
    "image": "%REPOSITORY_URI%:nginx-staging", 
    "cpu": 512, 
    "memory": 512, 
    "portMappings": [ 
    { 
     "containerPort": 80, 
     "protocol": "tcp" 
    }, 
    { 
     "containerPort": 443, 
     "protocol": "tcp" 
    } 
], 
"links": [ 
    "myapp" 
], 
"volumesFrom": [ 
    { 
     "sourceContainer": "myapp", 
     "readOnly": false 
    } 
],   
"essential": true,  
"logConfiguration": { 
    "logDriver": "awslogs", 
    "options": { 
     "awslogs-group": "awslogs-myapp-staging", 
     "awslogs-region": "us-west-2", 
     "awslogs-stream-prefix": "awslogs-myapp-nginx" 
    } 
} 
}, 
{ 
    "image": "%REPOSITORY_URI%:v_%BUILD_NUMBER%", 
    "name": "myapp", 
    "cpu": 2048, 
    "memory": 2056, 
    "essential": true, 
    ...bunch of environment variables, etc. 
} 

Je suis en mesure de ping le conteneur monappli de l'intérieur de mon récipient nginx, donc je ne pense pas que ce soit un problème de groupe de sécurité.

+0

Est-ce que votre conteneur myapp inclut le portMapping for 3000 - vous avez tronqué votre définition de tâche pour myapp - je suppose qu'il est manquant - d'où vous pouvez ping myapp mais pas se connecter à 3000 – abdollar

+0

Voir si cela vous aide? https://stackoverflow.com/questions/34517265/linking-containers-between-task-definitions-in-aws-ecs –

+0

Les conteneurs sont dans la même définition de tâche, donc je ne devrais pas avoir besoin de mapper le port ou faire quelque chose de bizarre découverte de service. J'essaye de modeler ma solution hors de ceci: https://aws.amazon.com/blogs/compute/nginx-reverse-proxy-sidecar-container-on-amazon-ecs/ Je creuserai dans la mise en réseau de docker sur ECS cependant, peut-être qu'il y a une solution là-bas. – mcheshier

Répondre

0

Cela s'est avéré être un problème de groupe de sécurité AWS. Je m'attendais bêtement à ce que l'application Rails m'indique peut-être qu'elle ne pouvait pas atteindre la base de données, mais qu'elle restait suspendue là pour toujours jusqu'à ce que je la démarre manuellement avec des rails c. Puis j'ai eu le timeout qui a conduit à une résolution rapide.