Prepping Your Project for Production

Prepping Your Project for Production

Django makes it easy to run a project locally in development where you are the only user and manage.py runserver “just works”. When you start thinking about moving that project to production and running it on the internet; it’s a bit more difficult. You’ll need to consider the following:

* How should I host my site (PaaS, FaaS, unmanaged hosting)?
* Should I be using Docker and/or Kubernetes?
* How do I serve my static/media assets?
* How should I handle my settings?
* Which database should I use and what are the performance considerations?
* How should I handle other supporting services (email, search, cache, etc.)
* Which web server should I use and how should I configure it?
* How do I serve my site via HTTPS?
* How do I protect my site from evil bots and blackhat hackers?

Unfortunately, the answers to these questions aren’t one-size-fits-all. In this talk, I’ll discuss the pros and cons of common approaches and recommend the best option for different scenarios. I’ll also call out various security and performance considerations along the way.

A464f1f39d9d840f9ca156e9abcfd4a9?s=128

Peter Baumgartner

September 23, 2019
Tweet

Transcript

  1. 1.
  2. 2.
  3. 5.

    Hosting Configuration Web Server Assets (static and media) OVERVIEW Additional

    Considerations: Performance Security Observability
  4. 6.
  5. 8.

    PROS CONS PLATFORM AS A SERVICE (PAAS) Managed Monitored Secured

    Supported Backing services may be included Performance Less flexibility Cost*
  6. 9.

    FUNCTIONS AS A SERVICE (FAAS OR SERVERLESS) AWS Lambda (with

    Zappa) Google Cloud Functions Azure Functions ZEIT
  7. 10.

    PROS CONS FUNCTIONS AS A SERVICE (FAAS OR SERVERLESS) Managed

    Monitored Secured Less expensive* New = rough edges Performance and cold starts Management commands
  8. 11.
  9. 12.
  10. 17.

    MANAGED SERVICES Database (Amazon RDS, Cloud SQL, Heroku Postgres, etc.)

    Object Storage (Amazon S3, Google Cloud Storage, etc.) SMTP (Amazon SES, Sendgrid, Mailgun, etc.) Elasticsearch Redis
  11. 25.
  12. 26.

    GOODCONF Configuration via file or environment variables Type casting for

    environment variables Auto-generate documentation Auto-generate commented sample configs
  13. 27.
  14. 28.
  15. 32.
  16. 33.
  17. 37.
  18. 38.

    NODE.JS Source files in version control Webpack/Parcel to generate static

    files during build Add build destination to STATICFILES_DIRS django-webpack-loader if bundle-splitting
  19. 39.

    MEDIA Use django-storages with your preferred backend (Amazon, Google, Azure,

    etc.) Be careful of public vs. private AWS_DEFAULT_ACL AWS_QUERYSTRING_AUTH AWS_QUERYSTRING_EXPIRE
  20. 41.
  21. 43.

    USE AN APM Third-party: NewRelic, Scout, Datadog Provider: AWS X-Ray,

    Google Stackdriver Trace Self-hosted: Elastic
  22. 45.

    DATABASE Use Postgres (unless you have a good reason not

    to) CONN_MAX_AGE Reduce queries select_related prefetch_related Indexes db_index index_together
  23. 48.

    CDN

  24. 52.
  25. 53.

    CODE Monitor dependencies for vulnerabilities
 (GitHub Security Alerts) Use a

    lockfile (pipenv, poetry, pip-compile) Consider an external audit
  26. 55.

    AUTHENTICATION (ESPECIALLY THE ADMIN) MFA django-two- factor-auth External provider (G-

    Suite, AWS Cognito, etc.) Rate limiting (Cloudflare, Nginx, AWS WAF, Django) Firewall/VPN
  27. 61.

    MONITORING & ALERTING Third-party: Internal: Datadog External: Pingdom, StatusCake, Datadog

    Alerts: PagerDuty, OpsGenie, Slack Provider: Cloudwatch, Stackdriver Self-hosted: Prometheus, Grafana