¿Por qué AWS Elastic Beanstalk podría seguir publicando una versión de la aplicación anterior?

Desarrollé una aplicación en Django y la configuré para desplegarla en AWS Elastic Beanstalk . Una versión anterior de la aplicación tenía habilitada la administración. He desactivado lo mismo en la nueva aplicación.

Aquí está el url.py de la aplicación.

from django.conf.urls import patterns, include, url #from django.contrib import admin #from django.contrib import admin.site.urls #admin.autodiscover() urlpatterns = patterns('', # Examples: url(r'^$', 'firstapp.views.home', name='home'), url(r'^jd/', include('jd.urls')), # url(r'^admin/', include('admin.site.urls')), ) 

Pero cuando navego por la URL de la aplicación, la que se sirve sigue siendo la anterior. Entré en el server y revisé los files. Los files son los de la aplicación anterior. La console EB de AWS muestra la nueva versión de la aplicación implementada en el entorno. También descargué el código del panel EB de AWS y el código pertenece a la nueva aplicación.

La URL de env Elastic Beanstalk es: http://secondapp-env.elasticbeanstalk.com/

El panel de administración se puede acceder aquí: http://secondapp-env.elasticbeanstalk.com/admin/ Idealmente, esta url debería dar como resultado un 404.

El problema es que en toda la console EB de AWS veo la nueva versión de la aplicación implementada y en funcionamiento (he intentado con ambos presionando código usando git aws.push y cargando en la console ews de aws), sin embargo, el código real que reside en El server ec2 sigue siendo la versión más antigua de la aplicación.

¿Cómo puedo forzar la carga del código? ¿Hay un retraso en la implementación real del código (aunque ha pasado más de una hora desde que implementé la nueva versión y el código es bastante pequeño)

Si AWS Management Console muestra su nueva versión de la aplicación AWS Elastic Beanstalk tal como se implementó, este debería ser siempre el caso, todo lo demás sería un error crítico del lado de AWS y es un poco dudoso en consecuencia.

Desde ese ángulo, es de esperar que no estés mirando los resources correctos de una forma u otra, por ejemplo, ¿podría ser que accidentalmente hayas desplegado una versión en una región diferente? (Ver la región equivocada probablemente le suceda a casi todos en algún momento cuando se trabaja con AWS;)

Por supuesto, no puede tener dos aplicaciones implementadas con el URL de entorno idéntico, por lo que uno tendría que implementarse con uno diferente (quizás Elastic Beanstalk haya elegido uno automáticamente, lo que puede suceder según el escenario de implementación): aquí hay algunas cosas para probar:

  1. Verifique que la URL del entorno del nuevo que está viendo sea, de hecho, la que usted quiere que sea y no una que se genera automáticamente.
  2. dado que esto es solo una implementación de testing, simplemente eliminaría la nueva y esperaría que la anterior todavía esté disponible en esa URL

Ambos confirmarían la sospecha de que estás ejecutando dos entornos de hecho, encontrando que el otro debería ser simple en ese punto.

¡Buena suerte!

Es muy posible que esté haciendo reference a dos files o estructuras diferentes.

Dependiendo de la API que esté utilizando, muchos de ellos tienen npm build en ellos. Es posible que esté editando el código "en bruto", no comstackndo, y luego implementando los mismos files comstackdos. Si este es el caso, deberá ejecutar su herramienta de compilation: gulp, webpack o grunt, y luego implementar de nuevo.