I made a Django project and have successfully deployed it to an Elastic Beanstalk environment, let's say it's called app_name. However, I realized I needed 2 environments: development and production. The purpose of this is so I can try things out in development, and when I know it's fully working, I can deploy it in production for the public to use.
I tried looking around their documentations and found Managing multiple Elastic Beanstalk environments as a group with the EB CLI . It basically says you can create a group of environments in one project with the command:
~/workspace/project-name$ eb create --modules component-a component-b --env-group-suffix group-name
However, I'm not sure what a group means. I mean, I just need a development and production environment.
I'm fairly new at this. How do I create and manage development and production environments for this purpose? I would ever be so grateful if someone were to shed some light to my problem.
Running a group of environments is more for different services doing different things. You would have an environment that handles Service One, and an environment that handles Service Two etc. This isn't really what you want.
You just need an environment in the same application as your production environment. It doesn't have to be in the same application but I like it that way because its useful for deploying an app version to dev, and then deploy the app version to prod once it's tested.
An easy way to do this is run
eb clone app_name (where app_name is the name of your production environment)
This will clone your production environment and prompt you to give it a name, which you might set to app_name_dev. From there you can edit your dev environment to make it more suitable for dev (maybe you'd make the instances smaller, change software variables like MAIL_DRIVER=mailgun to MAIL_DRIVER=mailtrap, connect it to a dev database instead of your prod database, etc)
The downside of doing this would be if your production environment is currently running jobs or doing anything meaningful, you may not want to clone it right away since the new dev environment could start doing these things too, before you manage to update its config to point to a dev DB etc! If this is the case, you would just run eb create my_app_dev and configure it from scratch.
Related
I have recently deployed my Django application on Elastic Beanstalk.
I have everything working now, but I'm curious what the best way to develop locally is.
Currently, after I make a change locally, I have to commit the changes via git and then run eb deploy. This process takes 1-3 minutes which is not ideal for making changes.
The Django application will not run on my local machine, as it is configured for EB.
You are right, having to deploy remotely during development isn't best practice.
Have you considered Docker?
To run a typical Django app locally using Docker, you'll need to dockerize:
The Django app
Database eg Postgres
Worker eg Celery
Local mailer eg Mailhog
Not a very long list.
Obviously you'll add or remove from that list depending on how complex or simple your app is.
Although my specific example involves Django, Docker, and Heroku, I believe these are pretty general testing/QA questions.
I have a dockerized Django app tested in dev with Selenium confirming that my static files are being served correctly from my local folder (EXPECTED_ROOT = '/staticfiles/'). This app is deployed to Heroku and I can see (visually and in the dev tools) that the static files are being pulled in from CloudFront correctly as well. I want to formalize this with the same test I'm using in dev. My first question is related to if/how environment variables are used for tests:
Do I add for example EXPECTED_ROOT = 'https://<somehash>.cloudfront.net/' as an env var to Heroku and use it in the Selenium test?
Also, to run this test in staging I would need to install Firefox in my Docker image like I do in dev. Perhaps this is ok in staging, but in prod I believe I should be aiming for the the smallest image possible. So the question is about differences between staging and prod:
Do I keep Firefox in my staging image, run the tests, and then send
to production a replica of that Dockerfile, but now without firefox?
Any help is appreciated.
The idea of Config Var is to setup configuration variables that differ from environment to environment. Having said that you are in control of the environment and can define what you need.
I personally would use a different approach: create a test that is independent of the environment (for example instead of testing the expected root I would confirm a given DIV ID is found, or some other element).
This would be enough to confirm the test is successful and the functionality works as expected.
The production Dockerfile indeed does not need Selenium and can be different from the one from staging.
I have a Django project. I am considering adding Docker to it before deploying to Elastic Beanstalk. I am very new to Django and Docker and want to know what are the benefits of using Docker when deploying a Django app to Elastic Beanstalk. Thanks!
The general benefits of using Docker in EB, as compared to regular Python EB environment portability and reproducibility.
If you bundle your django app as Docker container, you know that you your development environment will be exactly same as your production one. All the dependencies, package versions, tools will be same in the container, regardless if it runs on your local workstation, home laptop or on EB platform.
However, when you use regular Python platform, the portability and reproducibility can be difficult to guarantee. The current Python platform is based on Amazon Linux 2. So the question is, is your development environment at home or work exactly same? Usually this is not the case, which often leads to issues in the vain of "It works on my local ubuntu workstation, but not on EB".
Also, one day you may decide to migrate your app out of EB or even AWS. It will be much easier to do that when using docker. This is because EB is a custom product from AWS, not available in other could providers with its own settings and requirements.
EB supports two types of docker-based environments:
single-docker
multi-docker
Depending on your requirements, you would have to use one of them. Each of them has its own use-cases, which I think are out of the scope to discuss for this question.
I recently started using AWS EBS and was confused as to what environment and application is and what is the difference?
Could I use environment to have a development testing and production environment and then have several applications in each environment?
Thanks!
Quoting the docs:
Application: An Elastic Beanstalk application is a logical collection of Elastic Beanstalk components, including environments, versions, and environment configurations. In Elastic Beanstalk an application is conceptually similar to a folder.
Environment: An environment is a collection of AWS resources running an application version. Each environment runs only one application version at a time, however, you can run the same application version or different application versions in many environments simultaneously.
Back to your question:
Could I use environment to have a development testing and production environment and then have several applications in each environment?
No. Its the other way around. One application can have multiple environments.
For example. If you application is called: my-first-web-application, then you could have three independent environments in it:
prod - environment stable serving real life requests, running stable version of my-first-web-application code base.
dev - development environment when you develop and tests new version of your my-first-web-application code base.
staging - final testing of a new version of your app, before it gets put into production environment.
I have a flask app that uses a different database based on production vs development environment variables. I am worried about a developer forgetting to set FLASK_ENV=development before running their local flask app, and suddenly they are making updates to a production database.
My only easy solution I have thought of is restricting the production DB to only accept requests from the production server IP so that way everything will error out if the developer forgets to set the environment variable, but I was wondering if there are better solutions for this issue.
First of all, it is a good practice to limit access to your production database to trusted IPs only.
As you can read in Configuration Handling: Development/Production (Flask Docs), you can have multiple configurations and use inheritance.
class Config(object):
DATABASE_URI = 'sqlite:///:memory:'
class ProductionConfig(Config):
DATABASE_URI = 'mysql://user#localhost/foo'
class DevelopmentConfig(Config):
pass
You can load, all the time, the default configuration that is safe. Only if the production environment variable is set, the real database configuration will be loaded.
Another solution is to use the instance folder (Flask Docs) that mustn't be a part of your git repository.
The instance folder is designed to not be under version control and be deployment-specific.
So, when you deploy your app, just add your production configuration to this instance folder, and nobody would have the prod configuration on their local machine.
They have a few examples and explain very well how to use it in the link that I gave you above.
You can prewrite the environment variables in .flaskenv:
FLASK_ENV=development
Then install python-dotenv:
pip install python-dotenv
Now if you run your application locally with flask run, Flask will automatically read the .flaskenv and set the environment variables in it.