Развертывание Django на AWS EC2 с помощью Docker Compose: поиск советов по безопасности, масштабируемости и лучшим практикам
В настоящее время я работаю над развертыванием приложения Django на экземпляре AWS EC2 с помощью Docker Compose. Установка включает в себя контейнеризацию приложения Django и NGINX, а для базы данных используется AWS RDS. Кроме того, планируется использовать службу Redis с рабочим Celery. Хотя процесс развертывания функционирует, у меня есть несколько вопросов и областей, которые я хотел бы улучшить.
Текущая настройка:
- Dockerfiles используются для создания образов для приложения Django и NGINX, для каждого из которых требуется переменная 'TAG'.
- Docker Compose настроен на использование переменных окружения и создание трех сервисов: Django app, NGINX и Redis (для будущего Celery worker).
- Рабочий процесс GitHub Actions реализован с помощью двух заданий: 'build' для сборки и отправки образов Docker (тег: короткая версия SHA-1 хэша последнего коммита), и 'deploy' для копирования Docker Compose на EC2 и выполнения развертывания.
Вопросы и области для улучшения:
- Реализация HTTPS: В настоящее время установка поддерживает только HTTP.
- Ограничение ресурсов: Рекомендуется ли ограничивать ресурсы в Docker Compose? На локальном уровне я изначально заметил высокое использование процессора. Как я могу контролировать это на EC2, чтобы избежать проблем с производительностью?
- Множественные окружения: Я стремлюсь создать отдельные среды для тестирования и производства. Следует ли мне использовать AWS RDS для staging или достаточно будет службы PostgreSQL в Docker Compose? .
- Вопросы масштабируемости: Как я могу гарантировать, что система сможет справиться с возросшим трафиком? Какие стратегии следует рассмотреть для масштабирования ресурсов?
- Обработка секретов: В настоящее время секреты хранятся в GitHub и передаются в EC2 через рабочий процесс GitHub Actions. Безопасен ли такой подход и рекомендуется ли он?
Заключение:
Мне нужен совет по оптимизации и доработке моей установки для повышения безопасности, масштабируемости и удобства обслуживания. Любые предложения или соображения будут высоко оценены. Спасибо!