Кто-нибудь в курсе, какой latency от серверов Hetzner до какой-нибудь европейской локации AWS?
Использовать Amazon DynamoDB в качестве kv-хранилища для веб-приложения, которое находится на сервере в ДЦ Hetzner - это хорошая идея? В плане времени соединения и т.д. Меня 30-40 мс устроят на всё про всё.
И еще отдельный вопрос про MySQL в облаке - опять же, хорошая ли идея использовать какое-нибудь облако совместно с Hetzner в плане latency?
Может у кого есть опыт. Пилю проект, и хочу пидорнуть с сервера redis, mysql, rabbitmq в пользу aws чтобы не ебать с ними мозги, а ловко использовать amazon sdk и всё. Но чет боюсь, что время отклика будет больше 200-300 мс, что меня уже не устроит.
Спасибо.
Ещё есть такой нубский вопрос: не придумали ли чего-нибудь такого, что может поддерживать постоянное "горячее" соединение между сервером Hetzner и эндпоинтом AWS ? Чтобы не тратить каждый раз время на соединение, проверку сертификата, и прочее.
Вроде бы, что-то такое соорудил для себя Cloudflare на http2.
Просто реально есть куча сервисов AWS, которыми я мог бы пользоваться почти бесплатно, но не хочется, чтобы это всё тормозило.
Полностью на AWS хостится не хочу, т.к. непосредственно хостинг там дорогой в плане вычислительной мощности \ трафика \ ram.
- MS Azure
- Google Cloud
- Yandex Cloud
- DigitalOcean \ Linode (вроде там есть db as saas, load balancer, object storage и т.д.)
Всегда не понимал, какие юзкейсы у этих крутых штук кроме энтерпрайза, который бабки по копейкам не считает и делает всю инфраструктуру в одном облаке полностью и платит 100k$+ в месяц.
Что же это за проект такой, что тебе нужны такие низкие задержки? У Хетзнера сервера в Германии и Финляндии. Сомневаюсь, что ты сможешь выжать такие низкие задержки, даже если развернешь свою динаму в ДЦ Амазона поблизости.
Ты еще не забывай о том, что всякие динамодб ограничивают фри тир по количеству запросов и пересылаемых данных. Исходящий трафик тоже в скором времени станет не бесплатным после определенного порога.
Очевидно, что для замера сетевых задержек нужно будет запустить сервис на AWS, затем с VPS от хетзнер запустить бенчмарк, который будет гонять данные туда-сюда и мерить время исполнения.
>Полностью на AWS хостится не хочу, т.к. непосредственно хостинг там дорогой в плане вычислительной мощности \ трафика \ ram.
>Просто реально есть куча сервисов AWS, которыми я мог бы пользоваться почти бесплатно, но не хочется, чтобы это всё тормозило.
С таким раскладом тебя может устроить AWS Lambda для бекенда, AWS S3 для хостинга и AWS Gateway для REST маппинга.
Относительно крупный отзовик по образу и подобию otzovik.com и прочих. Около 100к дейли трафика.
Сейчас переписываю всё приложение полностью, и мой лимит по ответу сервера (на всю хуйню на бекенде) - 250 мс, чтобы не отставать от конкурентов или даже получить преимущество. Из них 150 мс забирает MySQL - там запросов 30-40 в пике на страницу, которые я потом кеширую в Redis до обновления. Ну там ещё туда-сюда php, rabbitmq дергается, короче на KV остается 50 мс. Локальный редис отрабатывает вообще за 10 мс и меньше.
Я просто прикручиваю сейчас некоторые сервисы от амазона (типа проверки загружаемых картинок на NSFW контент) - и подумал, что было бы круто избавится от зоопарка ПО на бекенде.
Ну и еще у меня есть парочка других сервисов поменьше - было бы круто весь гемор с ПО спихнуть на Амазон или другое облако в плане доп. сервисов вроде redis, rabbitmq и пр. (сейчас вот читаю доку по сервису аутентификации).
>AWS Lambda для бекенда, AWS S3 для хостинга и AWS Gateway
>AWS S3
дороха по сравнению с hetzner, мне нужно хранить около 9 ТБ картинок и прочего, сейчас этим занимается отдельный сервер за 55 евро.
Про остальное в первый раз слышу - почитаю, спасибо.
Вопрос про задержки остается в силе. Я пока решил узнать, может кто в курсе. Наверняка многие пользуются MySQL\Mongo в облаке, и мне интересно как это обычно устроено - т.е. там подразумевается что запрос от приложения идет из облака же, или со стороннего сервера из другого ДЦ тоже норм?
>Относительно крупный отзовик по образу и подобию otzovik.com и прочих. Около 100к дейли трафика.
Хуй знает кому это всралось. Не ебал бы мозги и просто развернул все на VPS от хетзнера.
>Из них 150 мс забирает MySQL
>там запросов 30-40 в пике на страницу
Тебе нужно читать как тюнить MySQL, настраивать индексы и писать быстрые SQL запросы, а не на облачные базы данных дрочить для лоу лэтенси, лол.
>короче на KV остается 50 мс
Ты какой-то херней занимаешься, если честно. Облачная база данных, которая будет висеть вообще в другом ДЦ не ответит тебе за такое маленькое время отклика.
Не занимайся херней, едрен-батон.
Короче, ты просто не сечешь в теме, чувак. Зачем-то притащил MySQL в проект, который отлично ложится на NoSQL документоориентированную структуру. За каким-то хером делаешь до 40 запросов на одну страницу, лол.
У тебя какой-то мутный сервис отзывов, который никому не всрался кроме как твоим односельчанам. Картинки какие-то на 9 ТБ, лул. Ты просто никогда не занимался разработкой высоконагруженных сервисов.
Придумал себе проблем, а теперь героически их пытаешься решить.
Я и развернул, только на dedicated, а не на vps.
>Зачем-то притащил MySQL в проект, который отлично ложится на NoSQL
Лол
>Ты просто никогда не занимался разработкой высоконагруженных сервисов.
И слава богу.
>Картинки какие-то на 9 ТБ, лул.
Ебать ржака, 9 ТБ картинок да, они оптимизированы. приятным микросервисом на Go, который крутится на том же сервере.
>У тебя какой-то мутный сервис отзывов, который никому не всрался кроме как твоим односельчанам.
Так и знал, что не стоило писать, что за приложение.
Что касается оптимизации запросов - раз я на дваче пишу, это сразу значит, что я не знаю что такое индекс? Я владею SQL ну уровне среднего DBA точно, все запросы, типы данных и структура таблиц неплохо оптимизированы.
>За каким-то хером делаешь до 40 запросов на одну страницу, лол.
30-40 это верхний потолок на некоторых больших страницах, где много бизнес-логики. Просто указал по максимуму. И я лично не вижу проблемы именно в их количестве, главное это время исполнения. Ты в курсе, что в некоторых пособиях для DBA по MySQL рекомендуют не превышать среднее значение в 70? Думаю, что нет.
>Ты какой-то херней занимаешься, если честно. Облачная база данных, которая будет висеть вообще в другом ДЦ не ответит тебе за такое маленькое время отклика.
Почему нет? Я думаю что ответит и даже за меньшее, если например взять сервер hetzner во франкфурте и локацию AWS там же.
Просто стало интересно, я и спросил, может у кого был такой опыт. А не просто из серии "ну я думаю не полетит" - т.е. то что я вижу в треде сейчас.
30-40 от дунамодб до дц или вообще всё? лол
Так, теперь глянул ping от сервера до нескольких IP aws во франкфурте:
от 25 мс до 28 мс.
Как бы теперь сэмулировать реальное время отклика для приложения?
Т.е. когда я из бекенда буду отправлять запрос на поиск по ключу, и получать ответ. Наверняка это будет несколько больше, чем ping.
Привет
Занимаюсь разработкой бэкенда для омерики, который работает как раз с3 через aws
Да, задержка. Ну а что ты хотел, сервис омериканский, задержкта минимальная только в омерики
Но я не php-вкатун.
К бекенду, который отрабатывает на php 7.4 за 9 мс у меня нет никаких претензий. Думал, может на питоне - но решил что ну его нахуй - php удобнее и кстати зачастую производительнее.
И кстати - ладно ещё php, который ты наверняка видел в последний раз году так в 2007. Но к mysql-то какие претензии?
У тебя там крудо-магазин или криптобиржа, сорта лоу-лоуда
9 мс - это время, которое тратится на php рантайм.
Вопрос:
Кто-нибудь в курсе, какой latency от серверов Hetzner до какой-нибудь европейской локации AWS? Не в вакууме, а в случае использования такой схемы: приложение на сервере Hetzner <> KV-хранилище в AWS Европа. Оно же наверняка будет отличаться от ping.
>Даже 300мс это не задержка.
Я просто поставил планку по среднему значению на бекенде в 250 мс. Stackoveflow, например, эту планку поставил в 150 мс вообще - и у них там perl и MS SQL, если мне память не изменяет.
Просто хочется, чтобы сайт был очень быстрый - и там ещё фронтенд есть со своими задержками.
>У тебя там крудо-магазин или криптобиржа, сорта лоу-лоуда
Не понял щас.
>Stackoveflow, например, эту планку поставил в 150 мс вообще - и у них там perl и MS SQL, если мне память не изменяет.
WISC. Надеюсь, я сделал тебе больно.
>Я просто поставил планку по среднему значению на бекенде в 250 мс.
Ты просто долбаеб. AWS - это набор разных сервисов, на время которых влияет дохуя факторов.
>>1632158
>AWS Lambda для бекенда
Не любое решение ложится на серверлесы и там нет пыха.
>>1632187
>Из них 150 мс забирает MySQL
Выкинь нахуй мускл, найми дба, забудь про авс.
Вопрос: какое латенси от хетцнера до авс если использовать динамодб.
Ответы:
1) выкинь нахуй mysql
2) да там похапе нуб какой-та
3) ты долбаеб
4) ты ваще не шаришь
5) 9 тб картинок, лол
Ну вы и мудаки, ебаный в рот.
Чёто не ожидал.
Ты просто тупой школьник. Если ты не пиздишь про 100к уников для своего ололо-сайта, то мне даже страшно становится, как такие деревенские могут писать говнокод и все равно собирать аудиторию.
Тебе уже сказали, что твоя проблема в 40 запросах в базу на каждую страницу, а ты про какие-то облачные базы рассказываешь, лол.
Какая нахуй проблема, можешь объяснить? Меня не ебет пусть их там будет хоть 9000, покуда они выполняются за 150 мс. Это простые селекты с where и limit, которые используют индекс.
К тому же, я только что уточнил: макс. запросов на страницу: 19
Тоже дохуя? Я так понимаю, правильный ответ это 0 запросов? Даже и говорить не стоит про то, что все эти результаты запросов потом кешируются в редисе до обновления родительского обьекта, и достаются за 10 мс.
Сука, на php не пиши, mysql выкинь, а спросил-то я про целесообразность использования облачных saas с выделенного сервера в германии.
> ловко использовать amazon sdk
Ты делаешь это неправильно. Деплой через terraform, Дискавери через consul
Хз, есть AWS Ping test
Сам aws говорит менять с помощью hping3
https://aws.amazon.com/ru/premiumsupport/knowledge-center/network-issue-vpc-onprem-ig/
> Поддерживать соединение
Обычно это делает клиент к бд - один хуй у всех сейчас балансировка по нодам, в том числе клиентская.
Можешь конечно поиграть с socat, ssh или ещё какими тоннелями, но жди что оно наебнётся.
Всякие managed бд есть и у других провайдеров, как ты подметил, у Гугла есть az в Германии, Швейцарии и Голландии, у Яндекса всё в Европейской части РФ, у Azure
хз - попробуй разные из ближайших.
> Запрос из другого ДЦ норм?
Если это ДЦ одного облачного провайдера, то норм. Если нет, это всё равно что бд где-то в интернете и sla по latency тебе никто не гарантирует. Ещё у облачных провайдеров исходящий траффик в интернет биллится - тут поосторожнее и смотри сколько стоит сеть.
> который бабки по копейкам не считает
Считает. И строить и обслуживать собственный ДЦ выходит очень дорого, и хуй знает отобъётся ли ещё. Не говоря уже о сертификациях и прочем бумажном говне.
Анон, поясни по хардкору нужно\не нужно?
Рассматриваю с точки зрения прибавки к зп и востребованности на рынке труда.
http://35.203.9.207/
Если хетснер в европе и ноды авса в европе, то латенси должен быть нормальным. Если что-то в сша находится - то пизда рулю.
>И еще отдельный вопрос про MySQL в облаке - опять же, хорошая ли идея использовать какое-нибудь облако совместно с Hetzner в плане latency?
Вообще базу лучше держать как можно ближе к приложению.
>который бабки по копейкам не считает и делает всю инфраструктуру в одном облаке полностью и платит 100k$+ в месяц.
Еще как считает! Только очень большой бизнес может позволить сделать свое собственное облако на каком-нить опеншифте.
Но при этом облака держать дешевле час стадо немытых админов, которые будут все ронять.
Из плюсов - меньше приходится запариваться на счет инфраструктуры. И еще можно достаточно быстро вводить новые машинки в бой, очень полезно для стартапов, когда уже вчера надо держать 100к посетителей.
>кроме энтерпрайза
Хз, из моей практики любой проект после стадии MVP сразу переходит c хероку на AWS/Google Cloud/ect, а сейчас многие сразу на них и начинают. Работаю долгое время в основном со стартапами/начинающими продуктами, последний раз видел проект не в клауде лет 7 назад, и это как раз был тырпрайз со своим зоопарком серверов и самописных перделок, фу бля.
В смысле недоступен? Вот есть же для жабы
https://docs.aws.amazon.com/lambda/latest/dg/lambda-java.html
Да и дело же вообще не в серверах, а готовой инфраструктуре, плюс можно менять настройки, интегрироваться и скейлиться лениво тыкая мышкой в гуйне.
1) Ставишь k8s а Hetzner https://community.hetzner.com/tutorials/install-kubernetes-cluster
2) Находишь helm-chart'ы под свои нужды.
3) Ни с чем не ебёшься, тратишь мало денег, получаешь хороший перфоманс.
Перевёл инфраструктуру нашей компании с Azure в Hetzner, снизил косты с $100k/month до $20k/month. Можно было бы ещё 8к скинуть, но лень.
Кукаретики про удобство, стабильность, и итоговую выгоду клаудов идут строго нахуй.
>перевёл инфраструктуру нашей компании с Azure в Hetzner, снизил косты с $100k/month до $20k/month.
Как ты их убедил? Моя платит over $200k/month за AWS, я быстро прошелся и там много тяжелых серваков EC2, которые не используются практически. Написал им мол вы слишком много платите за AWS, можно сделать как минимум в половину дешевле - сказали спасибо, на этом забили хуй, лол. Наверное, это для меня большие деньги, а им похуй, не трогай пока работает.
1) Найти людей, которые бы обрадовались срезанию $100k/month. Финансы, какой-нибудь верхний менеджмент, IT-директор.
2) Делаешь короткую и ёмкую презентацию своей идеи, с конкретными цифрами и сроками. Не начинаешь никаких разговоров без презы.
3) Сразу договариваешься о бонусах, которые получишь во время и после этой трансформации. За сделанную работу никто потом не платит.
А так-то да, большинству в компании похуй, ибо это не их деньги. А зачем что-то трогать с риском сломать, если профита с этого не видно?
И да, железки/виртуалки в Hetzner стоят в 8 раз дешевле, чем в больших клаудах. И в тех же больших клаудах серваки — говно медленное. И у большинства компаний инфраструктура засрана очень сильно, там просто уборка мусора может снизить косты в 2 раза. А потом ещё и затюнить под реальные требования. А потом ещё уволить ненужных админов...
>1)Найти людей, которые бы обрадовались срезанию $100k/month. Финансы, какой-нибудь верхний менеджмент, IT-директор.
>2) Делаешь короткую и ёмкую презентацию своей идеи, с конкретными цифрами и сроками.
Все так, но для удаленного сыча это практически нереально. Особенно написать "через голову" своего менеджера, который игнорировал твой совет первоначально. Вот тут зарешали бы софт-скиллз конечно. Вообще поражает иногда сколько денег компании выкидывают в пустую, при этом экономя гроши на зарплате программистов.
>1) Ставишь k8s а Hetzner https://community.hetzner.com/tutorials/install-kubernetes-cluster
>2) Находишь helm-chart'ы под свои нужды.
>3) Обнаруживаешь кучу незакрытых портов в которые уже ломятся братушки из Китая
>4) Кое как закрываешь порты, пытаешься настроить фаерволл и настроить SSH доступ до VPS
>5) Приходит время выкатывать обновление твоего сервиса - выключаешь свой HTTP сервер, подсовываешь новый билд и делаешь перезапуск. Клиенты орут, что ничего не работает и ты все поломал. С мокрой жопой начинаешь судорожно вспоминать, что ты мог поломать...
>6) Приходит время накатывать обновления на OS. Качаешь обновы и перезапускаешь сервер. Клиенты снова орут, что ты все запорол и сервис не работает
>1) Написал свой сервис и задеплоил его на AWS Lambda
>PROFIT
Ты серьёзно советуешь самим поставить кубик и потом менеджить его людям которые о нем толком не знают? На моей практике даже переехать на EKS не так просто оказалось. Не знаю что там у тебя за ситуация, какой опыт и команды девопсов, но думаю ты недооцениваешь риски такого переезда для других, а может и для себя, если вообще не напиздел конечно.
> Кукаретики про удобство, стабильность, и итоговую выгоду клаудов идут строго нахуй.
Hetzner это клауд.
>>1632000 (OP)
Уже не актуально наверное, но почему просто не переехать в AWS? Только разница с S3 в 150$? И что это за отдельный сервер у тебя такой для хранения картинок?
Подскажите, когда мне может понадобиться использовать k8s вместо простых PaaS таких как App Engine/AWS Bean Stalk?
>Hetzner это клауд.
Hetzler это все виды услуг, с упором на vps/dedicated.
> команды девопсов
Это преувеличение какое-то. Что за проблемы с обслуживанием файлового сервера? Зачем там команда девопсов? Там один раз настроил, потом по инструкции дампы делать и если что, новый сервер поднять.
Облака это конечно модно и молодёжно, но пипец как накладно. 1Тб трафика в амазонах стоит 50-100 долларов, в Хетцнере, посмотрел, 1евро. С диском схожая история.
хочу попробовать эти ваши облака, чисто под пет-проджект на 1 RpS. На какое облако проще вкатиться именно с точки зрения полного нуба (читай минимальны настройки и танцы с бубном)?
А если хочется именно в облаках, типа современно и всё такое?
Скажем мини-прожект на питоне или ноде, что-то или тупо сохраняет в файл, или в базу постгрю или редис.
Что для этого надо? В докер упаковать не проблема. Где проще и мне, и другим, если инструкцию составить? И какой минимальный прайс будет, если с базой вместе? Размеры и трафик никакие.
Вобще на AWS мелкая хуйня из пары медиум т2 инстансов, пары дб (не продукшен), лодбалансер уже блять чета уровня 500 баксов выходит в месяц мне начальник грил, даже пришлось чистить докер репозиторий в ECR потому что там сумма набигили больше чем на инстансы
Мне нужно модное молодёжное бизнес облако, потому что 2020. А не впс. Ну чтобы я там зашёл в веб-аккаунт, кликнул где-нибудь "поднять инстанс" и всё заработало.
Так ведь должно быть. Что надо для этого?
Сам имидж, в каком формате? В докер-репозитории или ещё как?
Чем он ахуенен? Ты сравниваешь кислое с мягким. AWS - полноценный клауд провайдер с базами данных в облаках, сервисами авторизации, серверлесс платформой и еще несколько десятками всевозможных сервисов. Хетзнер же просто торгует виртуальными и дедикейтед серверами на которые он разве что убунту тебе накатит.
>Сам имидж, в каком формате? В докер-репозитории или ещё как?
Никаком, лол. Записывай в notepad.exe набор команд для установки пакетов. Не ведись на centos и redhat - получишь такой же эффект.
Ты что не можешь потратить 15 минут чтобы в линуксе из пакетов поставить софт?
ansible ведь для другого, чтобы выкатывать конфигурации на обычные впс даже без докера. Это для красноглазых немытых админов. Я может хочу с айпада запускать всё.
>понятие infrastructure as code
Да слышал я эти понятия, рекламы этого говна больше, чем бесплатного проно. Как этим пользоваться? Чтобы мануал был не больше, чем у кубернетиса?
>Ты что не можешь потратить 15 минут чтобы в линуксе из пакетов поставить софт?
В 2020 надо уже поднимать в облаках. Это современно и модно. На линуксе я и раньше умел.
Нет задач.
Для трейдинг приложений где пинг критичен это всё равно не зарешает, там счёт идёт на сантиметры кабеля, и никакими клаудами там офк никто не пользуется. А для дженерик сервиса, где статика отдаётся через CDN, а динамический контент генерится приложением, ходящим в базу и т.д. ты невооружённым глазом разницу между aws east-europe и своей хуйнёй не увидишь.
>ты невооружённым глазом разницу между aws east-europe и своей хуйнёй не увидишь.
отгадай как я в s3 в us заливаю кучу мелких файлов?
арендую, блядь ec2, закачиваю zip и уже оттуда заливаю.
пиздец, просто. иначе это неделями длилось бы.
а если в заливке этих файлов и была бы суть моего сервиса?
Хуй знает, у меня был сервис который в реалтайме заливал чанками тысячи одновременных видеокофнеренций на с3, разумеется s3 и ec2 были в одной локации, но вообще в другой части мира от того, где треть клиентов находилась. Было вполне норм по скорости, разница в сотню-две миллисекунд, не больше.
>десятки тысяч долларов
Зарплата западного айтишника считай сотня в год. Если проект большой, то для бизнеса не вопрос заложить расходы на уровне одного сотрудника в инфраструктуру. Что у них, что у нас, у нас просто айтишники сильно дешевле, а услуги облаков стоят столько же. Пропорция меняется.
Бизнес иначе деньги считает, он считает конечную сумму, включая расходы на зарплаты, офисы и т.п. А это большие расходы.
Правда другая проблема есть. А точно ли работать с облаками проще, чем с обычной инфраструктурой? К этим грёбаным облакам так просто не подступишься, дохрена всего учить надо. В итоге может даже на зарплаты тратить придётся не меньше.
Благодаря контейнерам и виртуализации управление инфраструктурой сильно упрощается, научиться этому быстрее можно. Уже не нужен админ, который будет ебстись с каждым конкретным сервером, достаточно просто подготовить конфиги нужные.
Короче ХЗ.
>не понятен твой водораздел бизнесов.
Наверно надо считать по расходам на инфраструктуру в расчёте на одного клиента и на прибыль с одного клиента.
Если ты получаешь от одного клиента в среднем 1 доллар в месяц (например только небольшая часть платными сервисами пользуется), и в среднем клиент потребляет ресурсов на 10 центов, то почему нет?
Многие задачи не требуют больших ресурсов, работа только по подписке, каждый пользователь приносит приличные деньги. А для тебя критична в первую очередь надёжность, чтобы аптайм хороший был, и главное, ни в коем случае не проебать данные.
>Благодаря контейнерам и виртуализации управление инфраструктурой сильно упрощается
только не надо забывать что кубернетис не работает с файлом подкачки и если твое приложение пожрет оперативку, то все наебнется нахуй весь инстанс ec2 морозится даже по ssh перестает реагировать
Логика бизнеса такая, что если у тебя три разработчика работает и ты можешь платить им зарплату 2000 долларов в месяц, то и платить 1000 долларов в месяц за облака ты тоже, в принципе, можешь.
Другая логика в том, что эти тарифы дороги, когда у тебя большой трафик при малой прибыли с одного посетителя. А есть масса задач, где один пользователь стоит много денег, а трафик от него очень умеренный. Или даже трафик большой, но пользователи по подписке его оплачивают. Тогда получается, что расходы на инфраструктуру не такие уж и большие, можно не жадничать.
Короче, всё относительно. Есть масса жирных пользователей у AWS, причём из тех, кто инфраструктуру и персонал свой имеют. Типа фейсбука, твиттера или даже нетфликса. Но конкретно эти точно только часть трафика через aws пускают. Наверное это им выгодно.
Есть ещё чисто энтерпрайз сектор, где совсем иначе деньги считают.
Делают же как-то всякие ораклы продажи на миллиарды в год, хотя по куче продуктов существуют серьёзные бесплатные аналоги.
Ну ты сравнил, конечно. Если тебе работать на дядю, то логичнее изучать AWS и сопутствующие тулы на подобии терраформа, чтобы автоматизировать деплой сервисов.
А если ты пердолишь мелкий пет-проект, то завязываться на AWS - это практически всегда прямая дорога к нищете и безденежью, т.к. с его тарифами ты просто в трубу вылетишь. Взять хотя бы Dynamo, Lambda и API Gateway. Там такие ценники, что ты Free tier выжрешь в первую неделю, а потом начнет капать счетчик на каждый селект в базу, на каждый вызов лямбды и раутинг через гейтвей. Это я еще не считаю всякие SQS, S3, оплату трафика и прочие сервисы.
AWS универсальнее в смысле поиска работы. Про кубик лучше поверхностно почитать чтобы понимать его концепции, когда попадешь в компанию где его использую, на практике пощупаешь.
>>1686398
>Это я еще не считаю
Ты ничего не считаешь, просто пугаешь какими-то огромными ценниками.
>The AWS Lambda free usage tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month.
У тебя мелкий пет-проект будет миллион реквестов в месяц обслуживать?
Не знаю что там с DynamoDB, но зачем она тебе для пет-проекта? Возьми себе самый маленький инстанс RDS за 30 баксов в месяц. Никакого счетчика на каждый селект там нет.
Что важнее для пет-проекта, так это то что тебе не нужно ебаться с техническими деталями вроде деплоя, ты сможешь быстро понять что идея несостоятельна и перейти к следующей.
Если ты пишешь свой веб-сервис, который будет реализовывать REST-API поверх Lambda, то ты мигом вылетишь в трубу с такими ценами. Один пользователь может запросто отправлять несколько сотен запросов за 5-10 минут. А тебе еще нужно как-то проксировать эти запросы через API Gateway. Тут мы еще не учитываем стоимость исходящего трафика.
Ну и проиграл с маленькой базы данных за 30 баксов.
Я лучше возьму пару дешевых VPS'ок от диджиталоушен, скейлвей или хетзнер и разверну там все за пару минут через ansible или terraform.
>Что важнее для пет-проекта, так это то что тебе не нужно ебаться с техническими деталями вроде деплоя, ты сможешь быстро понять что идея несостоятельна и перейти к следующей.
Для пер-проекта как раз AWS совсем несостоятельны, лучше потратить время и освоить докер, это реально полезно. После этого поднимать инстансы ты будешь быстро и непринуждённо, они готовы и настроены уже. И всё это бесплатно на почти любой впс, надо только чтобы там нормальная виртуалка была, а не ущербная.
Вот для небольших коммерческих проектов другая история может быть. В первую очередь завязанные на данные. Нельзя терять данные, а все эти бэкапы и репликации - возня, уже уметь надо и поддерживать. Тут может реально проще платить 30-200 долларов в месяц и не бояться.
>Один пользователь может запросто отправлять несколько сотен запросов за 5-10 минут.
О да, в твоих мечтах конечно будет. А на деле у тебя будет 1000 запросов в сутки.
Хотя очевидно что с определенного момента lambda будет дороже чем сервер с постоянно поднятым сервисом.
>Тут мы еще не учитываем стоимость исходящего трафика.
Ну так учти, а не пугай страшными ценниками. Сколько там гигабайт стоит, 10 центов?
>Ну и проиграл с маленькой базы данных за 30 баксов.
Вот специально зашел проверил - 15$ стоит минимальный инстанс RDS Postgresql во Франкфурте.
У меня такое впечатление, что ты говоришь о нагруженном проекте который должен зарабатывать деньги, а не пет-проджекте.
>Я лучше возьму пару дешевых VPS'ок
Возьми EC2 интстансы на AWS. Что дешевле не знаю, давай сравним.
>разверну там все за пару минут через ansible или terraform
Только для этого их нужно знать.
>>1686589
У меня есть ощущение что ты не понимаешь что такое докер, но может мы говорим о разных вещах. Как докер сам по себе помогает деплоиться? Вот у меня есть код, вот компилятор, вот докер файл. Что мне нужно сделать чтобы новая версия завелась по адресу my-pet-project.com?
>Возьми EC2 интстансы на AWS. Что дешевле не знаю, давай сравним.
Бюджетные ВПС стоят 10 долларов и с очень хорошими показателями. Это от десятка до сотен гигабайт диска, от нескольких ТБ до нескольких десятков ТБ трафика в месяц, несколько гигов оперативки.
https://www.digitalocean.com/pricing/#Compute
Memory vCPUs Transfer SSD Disk Price
1 GB 1 vCPU 1 TB 25 GB $5/mo
https://www.hetzner.com/cloud#prices
1 vcpu 2 gb ram 20 gb disk 20 tb traffic 2.96 euros
https://www.scaleway.com/en/pricing/#virtual-instances
2 vCPUs
2 GB
20 GB
NVMe
200 Mbit/s
€2.99/month
Terraform/Ansible/Chef/Salt - ты все равно будешь учить, т.к. ты же не собираешься деплоить свои приложения вручную через админку хетзнера или АВС, верно?
>У меня есть ощущение что ты не понимаешь что такое докер, но может мы говорим о разных вещах. Как докер сам по себе помогает деплоиться? Вот у меня есть код, вот компилятор, вот докер файл. Что мне нужно сделать чтобы новая версия завелась по адресу my-pet-project.com?
А о чём ты говоришь? А как деплоить на aws свой сайт на ноде, да ещё чтобы подключить базу?
Для пет-прожеста проще всего через гит на сервере выкачать исходники, что можно автоматизировать при желании, в исходниках лежат Dockerfile и docker-compose.yml.
Делаешь docker-compose down/up и всё. Причём даже через ssh заходить не надо, можно с докера на своём компе управлять.
Главный профит в том, что ты легко можешь поднимать разные инстансы стороннего софта, и легко манипулировать разными версиями своего приложения.
Если не пет-прожект, а что-то распределённое и серьёзное, то сложнее, конечно. Уже надо в swarm-режиме работать, через репозиторий контейнеры распространять и т.п., иначе глушить-поднимать, чтобы даунтайма не было и т.п. Но я думаю даже это проще, чем с aws.
Ок, а что нужно сделать, чтобы на aws поднять свой пет, на nodejs, использующий редис и постгрес, работающий с вебсокетами, и чтобы его регулярно обновлять?
Ты еще не забывай, что завязавшись на AWS ты получаешь вендор-лок и проблемы с тестированием своего проекта. Когда у тебя все сервисы разворачивают в виде докер контейнеров и ты деплоишь на прод через terraform, напримре, то ты можешь легко поднять весь проект локально или развернуть его на стейджинге.
Писать какие-нибудь интеграционные или нагрузочные тесты тоже максимально просто - поднял контейнер, прогнал запросы, сверил ответы и на этом все.
>https://www.digitalocean.com/pricing/#Compute
Если смотреть на базы, то у этих что-то близкое к амазону и другим. Только трафик вроде бы дешевле.
ХЗ кто ту о чём говорит. То о петах, на которые 10 долларов в месяц жалко, то какие-то энтерпрайзы за 100k$ в месяц.
Для петов aws заведомо не нужны, впс лучше. Если только цель пета не в том, чтобы научиться с aws работать.
Вообще, девиз всех эти облаков "вы нам платите деньги, а мы берём вашу головную боль на себя."
Не может быть такого, что облака с поддержкой будут стоить дешевле железок на самообслуживании. Разработка ведь всё равно дороже, чем ресурсы. Если фирма какая-нибудь не готова платить 100 долларов в месяц на инфраструктуру для их сайта, на который они завязаны, то тут в консерватории проблемы какие-то серьёзные.
Амазон просто очень жадный и хочет рубить бабло на всём. Поэтому такие конские тарифы на трафик и вычислительную мощь.
А ради чего ставить цель кормить Амазон?
Докер тебе нужен в том числе для локального тестирования и обмена между другими разработчиками. Если ты умеешь с ним работать локально, то почему не поднять на впс?
Что конкретно облегчит aws, чтобы тратить время на его изучение и деньги на его инфраструктуру?
У AWS есть географически распределенная очередь сообщений SQS, serverless платформа Lambda, базы данных в облаке, которые сами бэкапятся и сами скейлятся, сервисы авторизации и рассылки sms. Это только первое что пришло в голову. Если у тебя стоит задача просто раздавать данные из базы через REST API и ты просто хочешь проверить работоспособность идеи, то дешевле арендовать VPS на хетзнер за 5-8 евро в месяц и поднять все на одном сервере.
>serverless платформа Lambda
Вот это вот зачем, какой смысл несёт, чтобы на это переходить и платить ещё приличные деньги?
Для меня понятны базы. Сервисы рассылки СМС тоже, но остальное уже как-то из пальца высосано, просто рекламные прокспекты маркетологов Амазона, надо же им на чём-то деньги зарабатывать.
>Если у тебя стоит задача просто раздавать данные из базы через REST API и ты просто хочешь проверить работоспособность идеи
И нет, для серьёзного проекта тоже лучше свои ресурсы иметь, просто это уже будет несколько серверов разного назначения. Когда проект большой, в любом случае свои девопсы-дба нужны.
Удел AWS - это коммерческие фирмы, у которых своего IT-отдела нет, а какая-то надёжность нужна.
Ну прикинь, что тебе нужно обрабатывать файлы, которые загружаются на S3 и при этом это происходит не очень часто. Держать EC2 инстанс постоянно включенным накладно, т.к. они дорого стоят. Ты можешь накидать Lambda функцию, которая будет тригериться на добавление файла в S3, читать его и что-нибудь с ним делать. Платить ты будешь только за реальное время работы ламбды, плюс затраченную память и фиксированную сумму за вызов.
>t3.micro 2 Variable 1 GiB EBS Only $0.012 per Hour
Можно и чуть дешевле найти, но меньще 0.01$ наверное нет. Итого 8-9$ в месяц.
>ты же не собираешься деплоить свои приложения вручную через админку хетзнера или АВС
Я хотел иметь автоматизированный пайплайн на тулах провайдера. Это для пет-поделки конечно, хотя и для небольшой команды с несложным проектом пойдет. Вот пример:
https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-codecommit.html
>>1686808
>А о чём ты говоришь? А как деплоить на aws свой сайт на ноде, да ещё чтобы подключить базу?
>Ок, а что нужно сделать, чтобы на aws поднять свой пет, на nodejs, использующий редис и постгрес, работающий с вебсокетами, и чтобы его регулярно обновлять?
Базу отдельно делаешь (RDS), редис тоже (elasticache), url их в конфиг прописываешь, а дальше все как по ссылке выше. Что для вебсокетов нужно, прям сейчас не скажу, знаю что это точно можно сделать и это не сложно.
>Делаешь docker-compose down/up и всё.
А как образ в registry попадет?
>Главный профит в том...
Это верно, но для деплоя мало.
>>1686813
Я не говорю что docker для тестов это плохо, это замечательно. Но вариант базу на проде использовать дял тестов тоже есть. Не в смысле данные смешивать, на например разные схемы завести.
>>1686920
>Разработка ведь всё равно дороже, чем ресурсы.
У них эффект масштаба работает, как и во всем софте, собственно.
>>1686965
>Удел AWS - это коммерческие фирмы, у которых своего IT-отдела нет, а какая-то надёжность нужна.
Ты бы хоть погуглил для начала. Две мои последние компании использовали AWS, бизнес обеих - SaaS.
>А как образ в registry попадет?
А зачем? Ты образ и контейнер можешь собрать прямо на машине. Твою ссылку не изучал, но там что-то говорится про аналогичную схему, всё собирается на машине.
Докер можно использовать в двух режимах, в режиме одной машины и в swarm-режиме. В первом случае ты можешь просто собирать образы и контейнеры на сервере. Обычно это нормально. Swarm так работать не будет, ему нужны готовые образы, но это тоже не так сложно. Ты может пользоваться докер-хабом, можешь поднять свой репозиторий, это совсем несложно, вся возня идёт из-за ключей, авторизации, сертификатов и т.п. В aws скорее всего тоже плясать надо.
>Базу отдельно делаешь (RDS), редис тоже (elasticache), url их в конфиг прописываешь, а дальше все как по ссылке выше.
Вот и получается, что всё ничуть не проще, чем традиционными способами.
И AWS скорее маркетинг, впихнуть какие-то решения, которые не нужны. Посмотрел SQS, они во многом проигрывают традиционным альтернативам, которых несколько на разный вкус, под задачи их подбирают. Но в рекламном проспекте о том, какой это космический рокет саенс у нас.
Задача AWS в том, чтобы подсадить на себя, максимально привязать к себе, а потом доить, доить и ещё раз доить. И вот ты такой прилизанный, в свежей сорочке и в галстуке сидишь в кабинете у начальника, листаешь рекламный буклет от AWS и думаешь, какое бы ещё решение купить, чтобы поправить проект.
Не понимая, что есть масса готовых, удобных и простых решений, которые даже бесплатно доступны, ничего не будут стоить и ресурсы на них никакие нужны. Но ты уже привязан намертво к AWS.
Вы, авээсники, какие-то долбанутые со своими лямбдами. Вам реально все мозги промыли начисто, думать разучились.
Интернет в Японии ничем не отличается от интернета в Нью-Йорке. Если тебе надо оптимизации какие-то делать, сократить время ответа от очереди, то можно делать схемы с парой последовательных MQ.
Но прежде чем городить схемы, надо разобраться с логикой работы сообщений. Что за сообщения, какие требования, кто их посылает и кто получает, в частности как отправитель в Нью-Йорке понимает, что сообщение надо отмаршрутизировать именно в Японию и как это выглядит в самом приложении. Как это в твоём коде выглядит, который SQS использует?
Как только про логику начинаем задумываться, вдруг понимаем, что ничего реально эти aws не решают, а только создают дополнительные проблемы. А обычными инструментами проблемы решаются ничуть не сложнее.
>А зачем? Ты образ и контейнер можешь собрать прямо на машине.
Ясненько. Я так и голый jar могу деплоить через scp/ssh скриптом. Тоже вариант, многие так и делали, лет 1 назад.
>Твою ссылку не изучал, но там что-то говорится про аналогичную схему, всё собирается на машине.
А ты изучи, может поймешь о чем вообще речь идет.
>>1687312
Сразу оговорюсь, я не то чтобы фанат амазона, все что я говорю касается любого клауда, который предоставляет похожие сервисы (гугл клауд точно, наверное и ажур, а может и вендоры помельче).
>Вот и получается, что всё ничуть не проще, чем традиционными способами.
Ты не рассказал свой способ. В облаке я нажимаю несколько кнопок и получаю полностью работающую систему и CI/CD пайплайн, как которые я при надобности могу накручивать метрики, алерты, балансировку и масштабирование (если проект начнет пользоваться каким-то вниманием).
>Посмотрел SQS, они во многом проигрывают традиционным альтернативам, которых несколько на разный вкус, под задачи их подбирают.
Плюс SQS (а еще Kinesis есть) не в том что он лучше альтернатив, а в том что его не нужно поднимать самому и следить за ним.
>Задача AWS в том, чтобы подсадить на себя, максимально привязать к себе
Тут сложно спорить, но вендор-лок может и не быть проблемой.
>Не понимая, что есть масса готовых, удобных и простых решений, которые даже бесплатно доступны, ничего не будут стоить и ресурсы на них никакие нужны.
Ты очень недооцениваешь количество усилий которые нужно потратить на то чтобы сделать работающую инфраструктуру из опенсорсных решений и сколько такие девопсы стоят. Я с этим сталкивался на 3 проектах за последние 5 лет.
Ну и S3 сложно заменить вообще - есть Ceph, но во-первых, я не знаю насколько сложно его развернуть и поддерживать (по опыту HDFS думаю очень непросто), а во-вторых, вряд ли стоит ли этим заниматься чтобы отдавать несколького гигабайт статики, например.
>Ясненько. Я так и голый jar могу деплоить через scp/ssh скриптом.
Ты определись, тебе пет-прожект или большую систему. Под любой уровень есть инструменты и способы.
Главное, что собирается просто, одной командой, это адекватно для пет-проекта. Но ты можешь и свой репозиторий поднять, это делается несложно.
>А ты изучи, может поймешь о чем вообще речь идет.
Я вижу там несколько страниц и кучу действий. Обычный пайплайн настраивается не сложнее, их много разных, это зависит от проекта. В итоге у тебя выгрузка идёт парой команд.
>>1687466
>Ты очень недооцениваешь количество усилий которые нужно потратить на то чтобы сделать работающую инфраструктуру из опенсорсных решений и сколько такие девопсы стоят.
Благодаря докеру все инструменты работают почти из коробки. Сложно будет, если ты на пределе производительности работаешь.
У тебя сама настройка малый процент усилий забирает, тебе всё равно нужны специалисты, которые понимают, как эти инструменты работают и как их использовать, как оптимально строить с ними работу, чтобы выжать максимум производительности. То, что у тебя БД в облаках, не освободит тебя от профилирования запросов и необходимости понимать массу нюансов БД. Тебя только от настройки репликации это освободит.
Причём когда нагрузки большие, счета от облаков тоже будут космическими.
>Ты определись, тебе пет-прожект или большую систему.
Мы действительно никак не может определится. Пет-проект я могу и со своей тачки запускать. Давай возьмем стартап из двух друзей-программистов (CEO и CTO, лол) и дизайнера-фрилансера за денежку, делают они его в свободное время. Трафик очень маленький, но растет, парни ответственно относятся к проекту, не хотят даунтаймов, хотят понимать что с ним происходи и быстро выкатывать фичи. Думают о том чтобы нанять пару студентов, а самим заняться продвижением, например. Как ты себе представляешь постановку их процессов?
>Я вижу там несколько страниц и кучу действий.
Это потому что там подробнейшая инструкция для любого, абсолютно некомпетентного человека. И это хорошо что такая есть.
>Обычный пайплайн настраивается не сложнее
Давай ссылку хоть на какой-то, чтобы предметно говорить. То что они есть, я в курсе, не раз пользовался такими поделиями.
>Благодаря докеру все инструменты работают почти из коробки.
Ты не понимаешь о чем говоришь. Вот у тебя есть образ с эластиком и графитом например. Чтобы из них сделать работающую систему сбора логов и метрик, нужен еще вагон работы.
>У тебя сама настройка малый процент усилий забирает, тебе всё равно нужны специалисты, которые понимают, как эти инструменты работают и как их использовать, как оптимально строить с ними работу, чтобы выжать максимум производительности. То, что у тебя БД в облаках, не освободит тебя от профилирования запросов и необходимости понимать массу нюансов БД. Тебя только от настройки репликации это освободит.
Толко дело в том что я, например, разбираюсь в базах и профилировании, а во всякой девопсятине - не очень.
>>1687546
Чтобы файлы отдавать. Как KV-store можно использовать. Что как альтернативу предложишь?
>Как ты себе представляешь постановку их процессов?
Стандартный процесс без всяких докеров - есть гит, есть система тестов после коммита, если тесты пройдены, он деплоится или в тестовое окружение, или в продакшен.
Есть разные утилиты для этого. Так работают многие в больших компаниях, я так работал.
Докер упрощает процесс тестирования и внедрения, когда у тебя сложное окружение, тебе намного проще его воспроизвести у себя.
Главные засады и грабли с портированием данных, если надо, скажем, миграцию в базе сделать. Но это проблема будет и в облаках ровным счётом такая же.
Главная идея - интеграция с гитом всего. Сервисы гитхам-гитлаб-битбакет поддерживают интеграцию. Посмотри пайплайн от гитлаба, gitlab ci/cd. Я его не пробовал, поэтому не описываю.
Все эти проблемы сильно преувеличены. Ты пытаешься найти какое-то преимущество облаков и дальше подогнать задачу под них, как будто нельзя или как-то сложно без них работать. Облака очень узких класс задач решают, особенно сейчас, когда столько свободного софта появилось.
Самые большие проблемы, когда много человек работает - это синхронизировать разработку, консистентность, чтобы работа одних не шла вразрез с работой других. Фронт завязан на бек, например.
Синхронизация кода идёт через гит, один или несколько репозиториев, если хочешь разграничивать доступ. Я думаю, что сейчас так уже везде.
В репозитории ты можешь и должен держать файлы, описывающие конфигурацию системы, докер-файлы разные, конфиги и т.п.
Поэтому, если на сервере у тебя есть гит, ты можешь одной командой поднять систему. Либо можешь обновить только часть сервисов.
Если у тебя всё работает на одной машине без swarm, ты можешь часть контейнеров использовать из продакшена, часть отдельно будет тестироваться. Без даунтайма просто переключить трафик с одного воркера на другой, network disconnect/connect в композе.
Для полноценного проекта уже будет сварм или кубер. Там хитрее. Для сварма тебе надо поднять свой репозиторий контейнеров, это самое правильное, или пользоваться чужими, что тоже вариант.
Нет никаких проблем вообще.
>есть гит, есть система тестов после коммита, если тесты пройдены, он деплоится или в тестовое окружение, или в продакшен.
Вопрос в том как именно это реализовано.
>Так работают многие в больших компаниях, я так работал.
И я тоже. Ничего стандартного здесь нет, в каждой компании, я иногда даже в команде городится своя поделка, часто с багами. Когда нужно сделать логи, метрики и алерты - это вообще пиздец, годами сырую хуйню используют.
>Докер упрощает процесс тестирования и внедрения
>Главные засады и грабли с портированием данных
Это понятно, это уже проблемы программистов (наши, если угодно). Я про построение самого процесса.
>Главная идея - интеграция с гитом всего. Сервисы гитхам-гитлаб-битбакет поддерживают интеграцию. Посмотри пайплайн от гитлаба, gitlab ci/cd. Я его не пробовал, поэтому не описываю.
Да что тут смотреть, я gitlab CI как минимум на двух проектах использовал, включая текущий. Только для деплоя контейниризированных сервисов мы используем собственный самописный сервис, а даже есть отдельная команда программистов которая его развивает.
>Ты пытаешься найти какое-то преимущество облаков и дальше подогнать задачу под них, как будто нельзя или как-то сложно без них работать.
Я работал с и использованием этих технологий и без. И если у меня стоит задача для маленькой команды поставить процесс - ответ максимально очевиден.
>>1687660
>гит
Это и так все ясно, не в 90-х живем. Только чтобы поднять систему по коду из репы нужно сделать какие-то действия. Их, по моему мнению, некоторые тулы от клауд-провайдеров облегчают в разы. Если вы считаете что с этим
>Нет никаких проблем вообще.
то думаю у вас мало опыта пожирания говна построения процессов.
>Я про построение самого процесса.
ты опоздал
https://www.youtube.com/watch?v=17Kv1umL1M4
>Вопрос в том как именно это реализовано.
Очевидно, что это зависит от конкретного проекта. Они все разные, у всех свой стек и своя специфика.
>Когда нужно сделать логи, метрики и алерты - это вообще пиздец, годами сырую хуйню используют.
И все логи-метрики тоже разные. Потому что в разных задачах меряют разное, их надо загнать в вид, в котором их надо использовать.
>Только чтобы поднять систему по коду из репы нужно сделать какие-то действия.
Да ладно, какие? Команду make набрать? Или docker build? Если сборка падает на этом этапе, то коммит не пройдёт начальное тестирование и будет отклонён.
Вся сила докера в том, что бы тестовое окружение можешь элементарно поднять и элементарно синхронизировать тестовую инфраструктуру и рабочую. Потому что у тебя всё описано в конфигах, и всё собирается одной командой.
А вот с облаками не так, ты их не можешь локально протестировать и у себя воспроизвести. Уже проблема.
Используют docker swarm. Не могу сказать ничего по личному опыту, но думаю это его тоже непросто менеджить самому, как и кубик, и у него есть свои концепции, которые нужно освоить.
>>1687698
>Очевидно, что это зависит от конкретного проекта. Они все разные, у всех свой стек и своя специфика.
И получается каждый раз кастомная куча дерьма. Иногда это оправдано, но не для простых проектов.
>И все логи-метрики тоже разные. Потому что в разных задачах меряют разное, их надо загнать в вид, в котором их надо использовать.
Чет ты уже хуйню какую-то начитаешь нести. Какие разные логи и метрики? Формат логов или что? Метрика это вообще пара имя-значение, что там разного? Или ты про разные стеки их обработки? Факт остается фактом - это нихуя не так просто как кажется, а амазон дает тебе решение - cloudwatch, и кучу документации и туториалов как его использовать.
>Да ладно, какие? Команду make набрать? Или docker build? Если сборка падает на этом этапе, то коммит не пройдёт начальное тестирование и будет отклонён.
Что ты вообще набирать собрался? Ты руками предлагаешь деплоить или что?
>А вот с облаками не так, ты их не можешь локально протестировать и у себя воспроизвести. Уже проблема.
Зависит он того что бы используешь, но в общем да, это может быть проблемой. Сейчас вот я например BigQuery хотел бы иметь в докере, но его нет.
>>1687713
Этот сервис был написан до того как кубик можно было использовать, во всяком случае без существенных рисков. Сейчас много есть разговоров о переезде на него, но есть много препятствий, в том числе и сложность самого кубика, даже EKS. На предложения самим его разворачивать некоторые девопсы говорили прямым текстом о том что предлагающие ебанулись.
>Что ты вообще набирать собрался? Ты руками предлагаешь деплоить или что?
Решение о выгрузке в продакшен принимает человек. Он набирает команду для деплоя, полного или частичного. Или мышкой тыкает.
Ты постоянно мешаешь, то мелкие проекты для пары человек на стадии бета-версии, то мега трансконтинентальные хайлоад реалтайм бигдала зеро-аутаж с сотнями разработчиков и миллионами пользователей.
Чем больше проект, чем сложнее инфраструктура и сборка.
Я представляю, что такое поднимать даже маленький проект руками. Это жопа. И хрен отладишь, надо полностью независимую систему-клон собирать. Уже на маленький проект нужен считай девопс.
Появились контейнеры и докер, и всё. Клонировать проект просто, оттестировать не менее просто. Заменить часть и откатить, протестировать одновременно несколько разных версий - да не вопрос.
Хочешь поставить БД себе, или MQ, или что ещё - просто docker pull, берёшь чужой грамотный конфиг или быстро лепишь свой и можешь запускать, причём несколько копий одной софтины одновременно, они друг друга не ломают (килл фича докера, ты же не поднимешь так просто на одной системе два постреса без очень большой возни).
Управлять на среднем уровне системой среднего проекта может обычный разработчик.
Конечно спец по инфраструктуре в любом случае нужен. Даже для облаков.
Ладно, идея вот в чём. Я помню, как раньше поднимали проекты даже простые. Были инструкции в интернетах, как всё собрать. И это была еботня, потому что каждый компонент надо ставить отдельно. А установка в каждой системе своя, своя система пакетов, свои версии в пакетах, конфликты возможные с другими версиями используемыми для других программ.
Это тяжело и муторно, с этим надо разбираться. И естественно, очень хочется такие вещи переложить на сервисы, на тот же Амазон.
Что сейчас? Небольшая система и нескольких компонентов описывается буквально одним файлом докера, ставится буквально одной командой, не зависимо от системы. Уж от дистрибутива линукса точно. Никаких конфликтов. Взял и запустил. Внезапно потребность в услугах сторонних сервисов резко отпадает. Потому что с ними надо разбираться и они дороги.
На самом деле они конечно иногда могут быть полезны, но сильно-сильно реже.
Это полезно, если ты делаешь какой-нибудь небольшой проект для третьих лиц. Ты делаешь контейнеры, выгружаешь их в репозиторий. Создаёшь аккаунт, выгружаешь контейнер, создаёшь базу в облаках.
Отдаёшь это заказчику, говоришь "платить вот сюда, 50-100 долларов в месяц, столько эти услуги стоят, типа это серьёзно", и всё, забываешь. При этом сервис может быть интегрирован с твоим, на твоём сервере, через API.
В общем для таких целей самое оно.
Но когда команда из нескольких разработчиков, то я бы не стал на такие решения завязываться.
> И это была еботня, потому что каждый компонент надо ставить отдельно. А установка в каждой системе своя, своя система пакетов,
пиздешь. в нормальной инструкции просто ставили debian и все согласованно устанавливалось.
в доконтейнерную эпоху яндекс даже пытался свой дистр дебиана создать. были на хабре статейки про это.
>Ты постоянно мешаешь, то мелкие проекты для пары человек на стадии бета-версии, то мега трансконтинентальные хайлоад реалтайм бигдала зеро-аутаж с сотнями разработчиков и миллионами пользователей.
Ничего не мешаю. Пример проекта смотри выше. Про трансконтинентальность вообще другой челик говорил.
>>1687894
Да, докер это хорошо по многим причинам. Просто его мало. Его хватает для разработки, но не для беты. Swarm - другое дело.
>>1687906
Я тоже никакой не амазон-гуру, но мне как раз кажется что как раз для маленькой команды это очень удобно - что нужно наклацал в амазоне, конфиги в репе создал и не думаешь о девопсе. С другой стороны, если у тебя есть заготовка на другом стеке, который ты знаешь и любишь, почему бы его не использовать. Но хотя бы представлять что тебе дает клауд нужно. Для этого достаточно просто потратить выходные и поднять сервис с метриками, логами, базами и вебсокетами, просто для сравнения с тем что у тебя есть.
Говорят, кстати, что гугл-клауд намного продуманнее и юзер-френдли.
Все может, но я не понимаю почему нужно вообще говорить об одиночной машине? Это исключительно для разработки, деплоишь ты все равно на несколько, если у тебя несколько компонент. Если у тебя один твой сервис, зачем тут compоse нужен, да и докер вообще - java -jar и поехали. Да и VPS зачем тебе? На своей тачке запускай все, вон целый двач так работал но это не точно.
Многие сайты, даже коммерческие и с нагрузкой, вполне себе обходятся одной впс, на которой ты может и базу, и редис, и MQ, и кучу воркеров и что-то ещё держать.
Если ты себе заводишь выделенные сервер, так вообще, ты очень серьёзные проекты можешь тягать.
> зачем тут compоse нужен, да и докер вообще - java -jar и поехали.
Очевидно, чтобы дружить кучу зависимостей, как БД, кеши, разные свои микросервисы и т.п. Иметь возможность для удобного тестирования, замены отдельных компонент и прочее, прочее, прочее.
>и базу, и редис, и MQ
>кучу зависимостей, как БД, кеши, разные свои микросервисы
А вот такого я не ожидал. Что ты будешь делать когда все это упадет? Зачем тебе вообще такая сложная система на одной машине? Я кажется начинаю понимать, что у тебя реально нет или очень мало опыта не только построения процессов, но и тяганияпроектирования систем как таковых. Или это уже сверхтонкий троллинг пошел?
Товарищ попросил сделать одну штуку, чтоб стоило минимально в процессе работы. Задача такая:
- есть список ресурсов (акки в инсте, жж, какие-то интернет-магазины, группы вк);
- надо собирать с них ресурсы (фотки и посты) раз в день;
- сохранять у себя в базу и генерить html-ки с этим контентом;
- раздавать этот контент как статику ("нагрузки" в среднем около 10-15к запросов страниц в сутки);
- давать возможность через простой интерфейс "админки" редактировать контент;
- собирать статистику по этому и показывать "ну чтоб красиво и понятно".
Я сначала думал это все зафигачить на VPS'ку какую-то и намутить бэкапы, чтоб ничего не потерялось. Но потом про AWS вспомнил.
Вопрос: что лучше выбрать? AWS привлекает тем, что сам его пощупаю (очень хочется) и S3 вроде надежны, можно не бэкапить эти данные, наверно, добавить Cloudfront, лямбдами тащить контент по крону. Но не будет ли это дороже? Мб лучше не извращаться и просто на VPS за 5$ повесить все? Может я какие-то прямо прикольные штуки и явный профит упускаю?
Собственно т.к. я вообще ничего не шарю я просто для теста залил файлы на бесплатный хостинг и по хттпс с ними работал и тестил, все вроде заебись. Но понятно, что на хостинге большой объем не сделаешь, да и пидорнуть могут, запрещено вроде файлохранилища устраивать.
Собственно, начал гуглить что и как и вроде как понял, что мне нужно арендовать себе VPS, шоб там и ресурсов больше, и свобода, делай что хочешь только ЦП не заливай. Меня вроде бы все устраивает (кроме ебли с настройкой этого всего), но что-то дорого все пиздец. Бездуховные сервисы по 5-10 баксов, наши по 150 деревянных, да и из своего кармана платить тоже жаба душит, а надонатили мне пока баксов 50 всего.
И тут я наткнулся на предложение ФТП, там и места побольше, и трафик неограничен, есть доступ по хттп и всего 40 рублей в месяц, что, понятно, просто заебись.
Вопрос, будет ли оно норм работать? Или ФТП будет лагать безбожно и мне лучше таки раскошелиться на ВПС?
Повторюсь, я полный профан во всем, в шарпе, в пхх, в сервачках этих, в линуксе тем более, но с помощью гугла вроде осваиваю без проблем. Но бабки канать на ветер не хочется.