*В архиве*
= Лучший облачный хостинг? знак равно

Привет, ребята, Итак, я хочу развернуть свой бэкэнд API Django, но не для производства, для разработки. Какой облачный сервис вы предпочитаете для этого? Итак, я нашел сервис Ngrok и Amazon AWS, и Дженкинс, и я понимаю каждый из них до глубины, чтобы провести сравнение. Я хочу знать из вашего опыта, какую услугу вы предпочитаете

P.S: в последнее время я получил очень враждебный ответ из-за отсутствия у меня опыта и просто за попытку помочь - я увидел, что этот саб постепенно становится враждебным и агрессивным, как и другие веб-сайты (очевидно, простое упоминание названий других веб-сайтов приводит к удалению вашего сообщения)

Поэтому, пожалуйста, извините за недостаток опыта, который вы найдете в моем посте (или будущих постах/комментариях).

РЕДАКТИРОВАТЬ: Я не ожидал, что так много ответов, спасибо всем за ваши ответы, я постараюсь ответить всем

Если он развертывается на удаленном сервере, то на самом деле не имеет значения, предназначен он для производства или нет — большинство вещей будет одинаковыми. Для бесплатного и относительно простого развертывания попробуйте Pythonanywhere или Heroku. Если вы хотите больше контроля, попробуйте Digital Ocean. Я написал (на мой взгляд, довольно подробное) руководство по развертыванию вашего
*первое* приложение Django для Digital Ocean здесь

Да, цифровой океан, безусловно, является жемчужиной, если вам нужен контроль, конечно, вы не развернетесь за полминуты, но он определенно превосходит большинство других вариантов, если вы хотите больше контроля.

Pythonanywhere, кажется, соответствует моим потребностям в 90% случаев, не слишком много контроля, не слишком много автоматизации и удержания рук, где-то посередине

У меня огромный опыт работы как с AWS Lambda, так и с Django. Я не могу придумать ни одной веской причины использовать Django вместо AWS Lambda. Мол, ни одной причины. Чрезвычайно сложный для такой небольшой отдачи, особенно когда ваши зависимости становятся даже немного более чем тривиальными. Вы не хотите играть в игру оптимизации зависимостей с ограничением размера файла в 250 МБ. Если у вас действительно есть проблемы с масштабируемостью для проекта django, я бы сказал, что решение, вероятно, представляет собой некоторую комбинацию ECS, сельдерея и облачного фронта.

Heroku очень легко развернуть, бесплатно, пока вы не достигнете определенного предела, pythonanywhere такой же, но немного сложнее, так как вам нужно настроить некоторые вещи вручную, что требует базового понимания команд Linux (ничего продвинутого)

У обоих есть возможность заблокировать сайт с помощью пароля, если вы не хотите, чтобы люди посещали его или подключались к нему, если они не авторизованы.
Я использую Heroku уже пару лет. Моя БД - это бесплатный уровень postgres. Это прекрасно работает, и я плачу в общей сложности 7 долларов в месяц. Дайте мне знать, если у вас есть более конкретные вопросы. Их документация очень хороша, и у меня было минимальное количество проблем. У меня есть собственный URL, https, все это

Я развертываю все свои проекты Django в Google Cloud Run. мне действительно нравится это

Вот как я это делаю:
Я начинаю с развертывания моей базы данных разработчиков в Google Cloud SQL. Я использую тот же облачный экземпляр mySQL для локальной разработки и облачной подготовки и тестирования.

**Локальный разработчик. Я запускаю 3 контейнера докеров с помощью docker-compose:
- мое приложение Джанго. В контейнер включен nginx. БД указывает на контейнер прокси SQL
- стандартный образ прокси Google SQL. Требуется учетная запись службы Google json

- стандартный контейнер phpmyadmin. В основном для устранения неполадок mySQL
**Облачное развертывание. постановка и продюсирование
- У меня есть файл cloudbuild.yaml для моего приложения Django. В нем описывается, как создать и развернуть приложение Django в Google Cloud Run.

- В Google Cloud Run я установил триггер для создания/развертывания моего приложения на основе git-коммитов для моего приложения. Это считывает файл cloudbuild.yaml и автоматизирует развертывание моих изменений в облаке.

- Я установил, что все мои переменные ENV в триггерах будут передаваться в cloudbuild.yaml и, в конечном итоге, в экземпляры Cloud Run. Конечно, они отличаются для постановки и производства.

**Почему мне это нравится**
- Первоначальная настройка непростая, но автоматизация, которую она дает мне, потрясающая

- Стоимость инстансов разработки очень низкая. Google Cloud Run взимает плату только за использованные секунды. Таким образом, несколько долларов в месяц Теперь экземпляр Cloud SQL — это то, где стоимость, поскольку он запускает виртуальную машину, которая всегда работает. Низкопроцессорные получают менее 10 $ / месяц

- Для ваших рабочих экземпляров вы получаете всю мощь Google Cloud Platform. Бесконечное горизонтальное масштабирование (пока ваше веб-приложение не имеет состояния). Cloud Run будет масштабироваться автоматически. Вы также можете масштабировать Cloud SQL вверх и/или горизонтально.

- Google Cloud Run поставляется с конечными точками http/https, которые вы можете сопоставить со своим доменом. Никаких проблем с конфигурациями SSL-сертификатов. Мне это нравится

Дайте мне знать, если вы заинтересованы, я могу предоставить более подробную информацию. Теперь я думаю, что я должен написать подробную статью о том, как это сделать
А вот и мои последние веб-приложения Django, развернутые в Google Cloud Run.
Если вы уже изучаете различные услуги облачного хостинга, было бы неплохо проверить Engine Yard. Я использовал Engine Yard для развертывания различных приложений в облаке, и я бы сказал, что это очень динамичная и удобная платформа для развертывание ваших приложений в облаке
Engine Yard Cloud (EYC) — это широко распространенная платформа как услуга (PaaS) для хостинга приложений Ruby, Node и PHP. Он имеет надежную, полностью управляемую инфраструктуру, а также поддержку мирового класса. Он имеет довольно безопасную инфраструктуру, а исправления постоянно обновляются для вашего удобства. У вас нет накладных расходов на управление полным стеком, включая базы данных и балансировщики нагрузки. Обо всем этом позаботятся. Резервное копирование происходит автоматически. На мой взгляд, Engine yard — это платформа для экономии времени и средств.

Вы также можете изучить Контейнеры машинного двора (EYK). Это платформа нового поколения. Я попробовал это и нашел, что это достойная миграция. Он поддерживает несколько стеков, автоматическое масштабирование в реальном времени и многие другие функции. Вы можете найти как Engine Yard Cloud, так и Engine Yard Kontainers.

Я рекомендую использовать App Platform в Digital Ocean. Он похож на Heroku, но обеспечивает гораздо большую мощность за долю стоимости Heroku.

Он не имеет всех функций, которые есть у Heroku, но, по крайней мере, для меня их достаточно для работы.

Я не DevOps, поэтому я не знаю, как безопасно настроить обычную каплю. Вот почему App Platform работает намного лучше - мне не нужно думать о потере мер безопасности, кроме как в моем приложении.

Все мои личные проекты упакованы в контейнеры докеров и развернуты в кластере kubernetes с одним узлом на Scaleway.com. Это довольно круто и требует минимального обслуживания, и если вы достигаете определенного масштаба, я могу легко переместить их либо в более крупный кластер, либо в другую службу развертывания контейнеров (например, ECS, или даже развернуть их самостоятельно на экземпляре с установленной только средой выполнения контейнера). )

В прошлом я развернул сервис django на AWS Lambda с помощью Zappa, но вы потеряли большую часть контроля, и есть некоторые мелочи, которые вам нужно изучить и внедрить (например, использование бессерверной среды, управление версиями, сохранение вашей лямбды «теплые» и т. д.).