Как стать автором
Обновить

Комментарии 14

Да, контейнеры удобны, когда нужно на сотни серверов накатить одно и то же ПО. И удобно поиграться с каким то продуктом, потыкать. А при основательной разработке, считаю лучше всего работать непосредственно на сервере, чтобы получить максимальное быстродействие.

Мы рассказывали в первой статье про ценообразование. Разрабатывать на сервере, и брать целый сервак под разработку, по нашему опыту, не всегда лучшее решение. И уж точно не самое экономичное.

а можно примеры сервисов с такими ценами? 100 рублей в месяц за сервер с 2 vCPU и 4 Gb оперативки, можно в личку, если тут нельзя

Конечно, можно: https://l1vestack.ru

Смысл тут как раз в том, что при простое тарификация не начисляется. А как показывает практика, для большинства ненагруженных проектов 99% времени - это простой. Пока проект в бете - тарификация вообще не начисляется. Не благодарите)

Не могли бы вы пояснить, что означает что бот должен выдерживать большие нагрузки? Например в телеграм есть ограничение - не больше 30 сообщений в секунду.

Webapp не оперирует понятием сообщений. Общение идет исключительно между вашими контейнерами с webapp и backend. Это web приложение с любым интерфейсом и оно не привязано к формату работы самого Телеграма

Какой ужас. Это по вашему просто? Вот в Digital Ocean просто указываешь репозиторий и... Все. DO автоматически подцепляет Dockerfile, и сам на каждый коммит запускает пересборку образа и запуск контейнера. Стоит каких то 5 долларов в месяц

Не вижу, чем работа с. DO проще? Если расписать ваш вариант с самого начала, шагов будет не меньше. А объяснение, как заплатить 5$, потянет на отдельную статью. :)

Есть такое когнитивное искажение, как проклятие знания (https://ru.wikipedia.org/wiki/Проклятие_знания). Достаточно погуглить инструкции по деплою в DO.

А из минусов — дать доступ к репозиторию какому-то хостингу. Уж лучше пусть сам GitHub бесплатно соберет образы через GitHub Actions при каждом изменении.

И не совсем корректно сравнивать сервисы, которые позволяют запустить один контейнер, с платформой запуска и оркестрирования микросервисных систем. Например, 7 контейнеров-сервисов в рамках трех окружений (dev, stage, prod) превращаются уже в 21 контейнер и их надо мониторить и управлять ими.

Какой-нибудь простейший облачный кубер кластер стартует от 3000р-5000р в месяц, а свой DevOps отдел от 1000р в час.

шагов будет не меньше

В том то и дело что кратно меньше. В этой статье какие-то лютые приседания на ровном месте с кучей boilerplate конфигурации в разных местах. Тем временем Digital Ocean для деплоя приложения в App Platform действительно не требует ничего кроме Dockerfile. Не нужно возиться с registry, настройкой CI, и создавать какие-то папки и конфиги. Просто Dockerfile, и все. Digital Ocean сам соберет образ, развернет контейнер. Сам запомнит что это был за репозиторий на GitHub и сам будет проделывать все заново на каждый следующий commit.

объяснение, как заплатить 5$, потянет на отдельную статью

Это если вы из рф. Даже если принять это во внимание, это все равно не оправдывает всю эту сложность описанного в статье сервиса.

дать доступ к репозиторию какому-то хостингу

А дать IDE и GitHub доступ к репозиторию вас не смущает? Что вы там такое разрабатываете? В статье выше де-факто делается ровно тоже самое, ибо приложение наваяно на JS/TS (код бекенда и фронтенда будет виден хостингу в любом случае), только заморочнее с выпуском токена. Надуманный минус.

И не совсем корректно сравнивать сервисы которые позволяют запустить один контейнер

Так статья про запуск одного маленького приложения чрезмерно сложным образом. На самом деле, Digital Ocean гораздо больше позволяет. Просто не требует заранее платить за сложность, которую на данном этапе не используешь. Когда понадобится k8s кластер, на него можно из панели управления переключиться. Но в статье он не нужен.

В том то и дело что кратно меньше

Я гуглил и проверял. Для кого-то создание дроплета, регистрация, привязка карты, выбор региона — само собой разумеющиеся шаги. Из-за чего я и говорю про проклятие знания. Я не исключение и тоже подвержен когнитивному искажению. 

P.S. Я люблю DO и пользовался им почти 10 лет. Пока не дошел до их залоченных на один домен балансировщиков по 5$ каждый. С ростом приложения (а не нагрузки на него) ценник растет очень быстро.

И для начала определимся в том, что Dockerfile не умеет того, что умеет Docker Compose (docker-compose.yml). В первом случае результатом будет приложение, во втором случае — мультиконтейнерная система на основе приложений с настроенным сетевым взаимодействием и окружением.

И если для запуска Dockerfile надо обладать знаниями «X», то для запуска Docker Compose нужны знания «X+Y». Получить инструкцию проще для более сложного инструмента — не тривиальная задача.

L1vestack — это про запуск систем на основе Docker Compose. Это про плавный рост сложности приложений и его цены.

Я гуглил и проверял. Для кого-то создание дроплета

Вы что-то не то нагуглили. Для App Platform нужно никаких дроплетов создавать.

регистрация, привязка карты, выбор региона

Как будто в описанном в статье решении не нужно регистрироваться и привязывать карту...

Пока не дошел до их залоченных на один домен балансировщиков по 5$ каждый.

Вот здесь ничего не скажу. Не сталкивался с проблемой масштабирования балансировщиков

Если взять пример с самодостаточными публичными образами, например Wordpress, то запуск можно описать четырьмя пунктами:

1) Копируем код из Docker Compose файла

services:
  wordpress:
    image: wordpress:latest
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpresspassword
    restart: always

  db:
    image: mariadb:latest
    restart: always
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpresspassword
    volumes:
      - ./mariadb_data:/var/lib/mysql

2) Вставляем в своем новом проекте в l1vestack

3) Выбираем открываемый порт 8080:80 в правой панели для контейнера wordpress

4) Запускаем

И у нас есть рабочий сервер с БД и Wordpress

https://github.com/H3LLO-CLOUD/l1vestack-examples/blob/main/templates/wordpress/docker-compose.yml

А если хотим развернуть что-то из приватного контейнерного реестра, придется обзавестись токенами доступа к приватным образам. Ну а образы уже самостоятельно собрать удобными средствами.

В ближайших планах создать каждому пользователю собственный Docker Registry с нетарифицируемыми vCPU и Memory, чтобы избегать возни с токенами и доступами.

В целом я согласен, можно сделать еще проще

финальную логику можно будет прокачать позже.

Эх...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий