Comments 28
Не надо screen, пожалуйста. Возьмите хотя бы systemd, он поддерживает автозапуск (например, когда сервер ВНЕЗАПНО перезагрузился глубокой ночью) и автоматический перезапуск в случае аварийной остановки. Screen хорошо подходит, когда надо небольшой скриптик в фоне запустить, а потом через какое-то время посмотреть, как оно там выполняется. Но в данном случае лучше выбрать что-то получше.
Так упор на простоту) В своих проектах я использую systemctl, но, скажу честно, попервой сам юзал SCREEN, чем не горжусь) Как по мне для тех кто знакомится только с темой VPS - SCREEN самое то, но замечание принимаю)
Я тоже использовал screen в начале своего пути. Отхлебнул кучу проблем, а systemd не сильно сложнее.
Ну SCREEN в пользовании не отличается особо от того же запусков скриптов на своем компе. Допустим тот же print, Все же его на старте используют, а в SYSTEMCTL уже не поиспользуешь это - только логирование, а это уже дополнительные знания какие-никакие и дополнительный опыт нужен. Так что вторую часть точно вокруг SCREEN закрою, но туториал по SYSTEMCTL, если кому нужен будет, тоже набросаю)
Поддерживаю, через службу самое оно. Ещё варианты: запускать сессию tmux при запуске системы с запуском сервиса (практически аналог screen), собрать контейнер и так же стартовать его при запуске.
Хост "0.0.0.0" указывается чтоб он слушал все что будет подключаться к fast api.
Зачем FastAPI высовывать наружу, если его туда будет nginx проксировать?
Упор на простоту и не то чтоб информация о боевом проекте) Смысл в том, чтоб новички, которые впервые взаимодействуют с VPS и FastAPI получили первый положительный опыт. Потратили пол часа и подняли свое первое приложение на своем VPS, а все остальное это с опытом приходит)
Ну и в целом же есть преимущества. Например это локальное тестирование. Не нужно замарачиваться на старте. Оно одинаково будет запускаться что на локальной машине что на сервере. Далее.Настройки становятся более гибкими. Иногда возникают ситуации, когда нужно предоставить доступ к FastAPI напрямую, минуя NGINX. Например, для доступа к административным функциям или для удобства тестирования определенных эндпоинтов. Ну и на более глубоких материях - масштабирование по горизонтали)
Напрямую...куда? На 127.0.0.1/<эндпоинт>? Чем это будет отличаться от
location / {
proxy_pass http://127.0.0.1;
}
?
Ну и на более глубоких материях - масштабирование по горизонтали)
А разве горизонтальное масштабирование как раз не достигается с помощью того же round-robing балансировки? Прямой же доступ как раз усложнит такое. С одной стороны через nginx прописать RR и он сам будет крутить адреса в локальной сети, с другой - на клиенте менять порт приложения, на который нужно сходить. Что-то у вас не сходится
Очередной гайд копипаста от прошедшего курсы курсы месяц назад. Я не знаю как это охарактеризовать. Всё что выше и ниже напихают автору - всё по дело.
Обычно я пропускаю такие статьи и просто плююсь что потратил время, но как же уже накипело.
Что вы привнесли этим? Тут есть что-то новое? Это даже хуже - это что-то 10 летней давности.
Но даже такую копипасту можно было бы разбавить, добавив пример systemd юнита, а может кто-то альпайн хочет на VPS - опишите как там демона написать, заодно сами разберетесь.
Еще больше я в шоке что не вижу ни рекламы, ни ссылок на очередной телеграм канал - нафига это вообще существует?
Вы я так понимаю супер опытный python разработчик. Представим. А теперь представим себя на этапе когда у вас вообще нет опыта, вы впервые заходите на VPS сервер, впервые запускаете FastApi, а вам начинают с проходняка рассказывать про systemctl и прочее. Где ваши личные публикации, ваши работы? Вы не зная ничего читаете пост человека который поделился своим опытом и начинаете его обмазывать в непонятную субстанцию) Зачем существуют такие комментарии?
Есть гугл с намного более подробными и верными руководствами, чем ваше. Помимо этого на хабре. О! Я вам помогу, а заодно тем кто наткенется на эту копипасту (вы тут на какие-то мои отсутствующие статьи наезжаете, а где у вас тут оригинальность? Как докажете?).
Просто выборка с хабра:
Краткая история о том, как развернуть веб-сервер Flask в docker контейнере
Подготовка сервера для публикации web-app на Python
Фантастически быстрый деплой веб-приложения
Несколько советов по организации Python-приложения на сервере
Установка Django-проекта на VPS (centOS 7) [Для новичков]
site:habr.com python сервер как развернуть
Вы даже про nginx не описали, что тут вообще читать? Зачем разбивка на части? Может быть чтобы просто нафармить кармы на этой копипасте растянув казалось бы конечную мысль на несколько маленьких статей? Да нет, не думаю что вы на столько меркантильны
Ну это вообще интересно) Ну давайте вы мне напишите как через SSH заходить на сервак) Все способы, а я вам в ответ статьи поскидываю) Далее. Давайте вы расскажете как с кода запустить фаст апи через приложение и туда же вам статьи скину) Естественно в интернете много публикаций об этом, так что это знчит. Повторюсь. Прошлая статья в контексте которой идет эта) Если я копипастом занимаюсь - покажите примеры в рунете. Именно 3.7) На дворе 2024-й год каждый уже о чем то сказал и это нормально. Есть вопрос личного опыта не более того. У меня за спиной более 100 проектов разных с разной нагруженностью, а вы тут рассказываете о курсах которые месяц назад я прошел. В этом прикол, в токсичности. Благодаря таким как вы люди просто не хотят делиться опытом или прочтут коммент ваш и подумают "Ну это лажа", а после не разобравшись с вопросом забъют или на тему или на программирование. Я очень много времени потратил на старте на разные вопросы, потому что на старте трудно все это. Сервера, VPS, фаст апи, постгресы и прочее прочее прочее. В общем считаю так, если вам что=то не понравилось - держите свое мнение при себе или делитесь конструктивной критикой. Благодарю за внимание)
Считаю что поделился более чем конструктивной критикой пусть и долей токсичности. Выше комментарии вам так же по делу напихали.
Это смешно мерятся кол-вом проектов, а тем более советовать что-то писать. Вы из тех кто "сначала сам сделай, а потом критикуй"? Тогда понятно почему у вас так пригорает. Я, да и думаю многие, не пишут на хабр просто потому, что это не принесет чего-то нового. Конечно, есть статьи где люди описывают свой опыт, как применяли что-то и там как бы объективно ничего нового может не быть, но хотя бы интересно читать как люди приходят к тем или иным решениям, оценивают разные инструменты и т.п.
А у вас, повторю, просто вредные советы... в 2024 году
А, ну и по второй части, да текста и так дофига. На минуточку, это вообще всего вторая публикация моя тут) Я не особо ещё разобрался)
Ну и давайте начнем с того что этот пост идет в контексте предыдущего. Там я сказал "представим что мы это умеем". Тут я написал самое простое решение из возможных. Хук ничего сложнее чем изложено в этой публикации и в следующей не требует (кстати за копипасту, покажите мне пример копипасты прошлой статьи или курс на котором рассказывают как на aiogram3.x настроить вебхук в связке с fastapi
Вероятно вам стоило бы отредактировать ту статью и дополнить, тогда бы она получилась максимально емкой и полезной в закладках, про неё речи вообще нет.
Я вот листаю ленту, вижу заявленную тему, читаю отсылку к вашей прошлой статье, понимаю в целом мне не так важно её знать как заявленную тут тему, а тут я получаю плохие советы, устаревшую практику, еще и разбивку зачем то на несколько частей. Вау.
Вопрос в том как я пишу. Без вопросов, практики могут быть устаревшими, но как быть если такой у меня стиль. Выработанный годами. Там выше писали за 0.0.0.0 я прокомментировал как и тему со SCREEN. В остальном то что не так?) Любой новичек прочитав мою статью сможет повторить код и запустить его. Для меня это важно. Чтоб это было просто и легко для каждого, так как я десятки часов в свое время потратил на поиск этой инфы. Вот и все. И дальше я планирую делиться своим опытом. Вот таким какой он есть, даже если он капец как устарел)
Напишу отдельный комментарий общий. По возможности дайте реакцию. Суть такая. У меня есть некий стиль написания кода (возможно устаревший, некорректный, плохо наученный и прочее, а возможно неповторимый, обалденный и вообще все мечтали о нем услышать, я просто не в курсе дела). Я планирую ним делиться тут. Вот так как есть, так как я пишу и так как можно писать. Неплохо ориентируюсь в темах парсеров, ботов в телеграмм, автоматизации, серверов, фаст апи, базы данных ну и прочее. Вопрос такой. Есть ли смысл делать публикации с учетом того что мой код может оказаться плохим? Смысл делиться опытом который может оказаться плохим? Вопрос действительно важный. Спасибо за ответы)
Проблема в вашей реакции на комментарии. Вы публикуете в открытом источнике, с открытыми комментариями, зачем то спорите не по делу.
Без всякого негатива - хорошо что вы осознаете что у ваши практики устарели, но может немного для себя стоит тогда пересмотреть что сейчас актуально? Я много лет писал только бэки, а когда пришлось заниматься фулстаком, то с удивлением обнаружил для себя, что сейчас все уже давно пишут на ванильном JS без JQuery, да и вообще существуют более удобные вещи типа vue для ускорения написания фронта со всеми современными фичами.
Слушайте, когда вы позиционируете ваши статьи для новичков, то всё же стоит показывать сразу как правильно. Это для новичков справедливо, что их код хороший, если он просто запускается и делает то что ожидалось и плевать какой там стиль.
Если ваша цель не просто фарм кармы для чего-то и добавление в резюме что "вот, а я на хабре пишук", а вы действительно горите желанием поделится опытом, то просто немного освежите знания, даже не навыки.
Как вы думаете, почему я вообще эту статью открыл, хотя она очевидно для новичков? Я ожидал увидеть для себя что-то новое, может какая-то хитрая настройка nginx появилась, может какой-то ASGI новый появился или с хитрыми настройками. Да даже если бы не увидел нового, но это просто тут было бы - это уже ок.
Это просто ИМХО, в открытой статье с открытыми комментариями. Единственное зачем я пишу что-то критическое в комментариях - это получить от авторов фидбэк в виде следующих хороших статей, надеюсь у вас они так же будут. Прошлая статья ведь действительно полезная у вас.
Была на Хабре некая программистка на PHP и React, у которой тоже был свой стиль и видение кода. Победительница всесоюзных олимпиад и т.п. Писала гайды для новичков и статьи про чистый код. Когда ей объяснили, что парсить csv через explode не совсем правильно, axios не нужен, не использовать хуки и ts в 2022 как-то странно, да и в принципе весь ее код, мягко говоря, не тянет даже на позицию Junior (она позиционировала себя как Senior), у нее не выдержала психика и она начала кричать "спервадобейся!" и "покажимнесвоистатьи!". Закончилось все read-only.
Тут вопрос больше к вам. Готовы ли вы к критике? Ведь может оказаться, что Опытный python разработчик с многолетним стажем - это лишь ваше восприятие себя, а вам тут будут объяснять, что на самом деле это не так.
Пожалуйста, не надо делиться таким. Вам явно не хватает чувства меры. Если цель это Телеграм-бот и вы взяли aiogram, который уже использует aiohttp, то зачем приплетать довольно жирный FastAPI и к нему вдобавок Jinja? Преимущество FastAPI перед aiohttp в валидации и автодокументации, у вас это не применяется, так зачем? Зачем раздаёте статические файлы через приложение, когда изначально заявлен Nginx? Про print для логирования и screen для деплоя уже намекнули, не надо это новичкам.
Есть такая штука как WEB-приложения в telegram. Когда нужно прикрутить его к боту намного проще когда все крутится на одном FastApi приложении. Так же, достаточно часто бывает когда есть 1 сервер и к нему прикручено 1 доменное имя, а клиент хочет и сайт себе и бота. Тогда так же удобнее FastApi использовать. Ну и как по мне проще FastApi настраивать в контексте вебхуков, даже если оно тяжелее идет. Далее print и Screen для деплоя. Я думаю что мне виднее как писать, правда?) В следующий раз распишу про systemctl если нужно будет это кому-то)
Простая настройка VPS, NGINX и FastAPI: Пошаговое руководство. Часть 1