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:
- 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;
- Install GDAL 2;
- Create a custom AMI;
- 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.
Creating custom AMI
- Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/;
- Choose Launch Instance;
- Choose Community AMIs;
- Insert ami-0a2fbeb2675c47493 to a search bar;
- Choose Select to select the AMI;
- Launch instance;
- Connect with SSH.
Building GDAL
- Go to EC2 Instances page;
- Select created instance;
- Go to Actions -> Images -> Create image.
Running ElasticBeanstalk using newly created image
Create an EB environment as you got used to it, you need to do the following steps:
- Go to "Configure More options";
- Go to Capacity;
- Click Edit;
- Paste ID of a new image in AMI ID field;
- Press save;
- Configure rest parameters;
- Launch application.
Deploy your Django application and enjoy it!
P.S. Try to move to EKS, sometimes Beanstalk can get you some problems:
- Elastic Beanstalk is a wrapper around Amazon Elastic Container Service and it already has some automation (by choosing actions in the UI interface). Thus you can't well describe your Infrastructure using the IaaC approach.
- The instances in each environment run the same set of containers. For instance, you have one frontend application and one backend application. You can't scale them independently from each other.
- It has a hard limit of 4KB to store all key-value pairs, thus you can't set as many env variables as you want.
- One Elastic Beanstalk task is one ECS cluster (EC2 mode).
But it has the following pros:
- It's one of the easiest ways to deploy a simple application to AWS;
- AWS Elastic Beanstalk is a good choice for a newly started application on a staging environment;
- It offers multi-container Docker;
- Has a user-friendly UI.
And, it also has some cons:
- It loses independently schedule a replicated set of apps on the cluster;
- One Elastic Beanstalk task is one ECS cluster (EC2 mode).
Conclusion
I hope my experience will save you time, and you'll successfully run GeoDjango on Elasticbeanstalk container. Good luck with your next Beanstalk deployment.