I want to tell you this story because I wasted about 14 hours to realize how to achieve it correctly.

NB!: Sometimes working with Elastic Beanstalk can be like this.

Long story short

To successfully run GeoDjango on Elasticbeanstalk container using Python 3.6 you need to follow these steps:

1. Launch EC2 instance from ElasticBeanstalk image ami-0a2fbeb2675c47493. NB! Do not use EC2 instances under the control of ElasticBeanstalk for that purpose. Launch an instance from the source image used by Beanstalk;
2. Install GDAL 2;
3. Create a custom AMI;
4. Run your Django app using this AMI.

The road so far

We have been using ElasticBeanstalk for 2 years to deploy our Django application in one of our projects. However, we weren’t using Geocoding features for our Django app. In one of our services, we decided to use Geo features of Django and enable PostGIS support for the project.

The problem was with missing GDAL 2 library, required for Django. There is GDAL 1 in Amazon Linux’s repositories, but it’s outdated dependency to make Django enable its GeoSpatial features.

I tried to build it from sources, installed on running instance and deployed code. Everything was fine, but I wanted to make it more reliable and be sure that it would work constantly because my changes would be deleted by autoscaling. Hence, I wanted to build a custom** AMI image **with required libraries (I needed two more, that didn’t exist in repositories).

Okay. I ran a clean configuration of the Elastic Beanstalk environment, installed everything, and created a custom AMI from EC2 instance I created using ElasticBeanstalk.

Seems pretty easy, I thought. I tried to create a new environment using this image and I found a problem with environment variables. For an unknown reason, Python container didn’t see the variables I set in the web interface.

I tried to set them using eb command and tried to set them using .ebextensions. Finally, I set them manually and had luck running the Django app, but it was unable to deploy it using eb deploy command.

In the next step I tried to use an updated image with Python 3.7 and Amazon Linux 2, but there were a lot of differences between Amazon Linux and Amazon Linux 2 that required a lot of changes in my deployment configuration.

I started thinking about what’s wrong with my configuration and why it didn’t work. I made a suggestion, that I built custom AMI wrong way and I started from the beginning.

#elastic-beanstalk #aws-elastic-beanstalk #django #python #coding #amazon #aws #ec2