Было бы неплохо еще в этом посте собрать варианты действий, если ваш ресурс попадает под блокировку. Расскажу про свой опыт. У меня один обычный сайт на EC2 попал под блокировку (его elastic ip оказался в заблокированной подсети). Он открывался через friGate, но был недоступен напрямую.
Вначале я попробовал просто получить новый elastic ip и перевести домен на новый IP. Но оказалось, все не так просто — Amazon выдает адреса обычно близкие друг к другу и велика вероятность, что они все будут в заблокированных подсетях.
Мне пришли в голову 2 варианта:
1) Получить elactic ip в другом удаленном регионе и перевести instance туда. Но это ухудшает работу ресурса, так как он рассчитан на пользователей из России, а CDN не используется. И это требует большей возни: нужно выключать instance, снимать с него образ и разворачивать его в другом регионе. Поэтому я пошел по второму варианту.
2) Купить reverse proxy и перевести домен сайта на него. Я купил за 10 долларов reverse proxy в Люксембурге (x4b.net), в качестве бекенда для прокси прописал свой elastic ip на Amazon и буквально через 5 минут сайт вновь заработал, как ни в чем не бывало. Очень надеюсь, что через некоторое время блокировки снимутся и можно будет отказаться от reverse proxy!
На очень многих ресурсах наблюдаю проблему с частичной недоступностью картинок, файлов и прочего. Многие сайты из-за этого очень долго грузятся, какие-то становятся в полурабочем состоянии. Вот например, эти иконки на bitbucket.com загружаются из S3.
Спустя какое-то время, видимо, блокировка снимается с части адресов и ставится на новые адреса.
Но в целом получается, чтобы нормально пользоваться интернетом в России теперь нужно пользоваться VPN. Забавным выглядит на фоне этого высказывания РКН, что блокировка Telegram не нарушила работу других сайтов. Наверное, мы с ними пользуемся разными Интернетами.
РКН напоминает чуму или проказу. Она поражает несчастного, в данном случае Телеграм, и дальше куда бы он ни пошел, вымирают целые деревни. И этого несчастного будут дальше палками гнать ото всюду, чтобы он не принес заразу в деревню.
Пишу сугубо свое мнение, могу ошибаться. Я считаю, что эти проекты — следствие того, что AWS вовремя не создал адекватные средства для удобной разработки бессерверных приложений. Люди не хотели ждать, и это понятно, поэтому появились эти проекты. По своей сути, это «костыли» или временные решения. Автор плагина serverless-offline уже объявил о своем нежелании продолжать проект и просит кого-то его подхватить. В общем будущее за SAM и sam-local, именно на этих технологиях стоит выстраивать процесс разработки в долгосрочной перспективе.
1. Насчет Vue.js — согласен, отличный фреймворк. Но вы смотрите на вопрос, как программист. Да, Vue.js может здорово повысить продуктивность написания кода для некоторых типов приложений. Но сколько программистов знают Vue.js и сколько знают jQuery? На сколько больше нужно платить программистам Vue.js? В общем это не столь однозначный вопрос. И я больше склоняюсь к тому, что нам не нужен фреймворк, если взвешивать все за и против и оценивать пользу фреймворка для конкретного типа приложений. Наши приложения — это ERP-системы, которые состоят в основном из форм и таблиц.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
Переменные, объявленные вне вызова функции handler, при повторных вызовах обычно не инициализируются повторно. То есть соединение с БД не будет каждый раз устанавливаться заново, если функция вызывается достаточно часто. Lambda сохраняет контейнер функции в «горячем» состоянии. Вот интересный пост на эту тему: https://www.jeremydaly.com/reuse-database-connections-aws-lambda/.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.
Площадь равнобедренной трапеции равняется произведению полусуммы оснований на высоту. А у вас в первой формуле идет деление на высоту, по-моему ошибка.
В целом, согласен, что можно вывести гораздо проще, чем у меня. Благодаря тому, что тут равнобедренные трапеции, — частный случай многоугольника. Зато мой вариант позволяет применять его к любым четырехугольникам.
Cognito, S3 и CloudFront — все это в общем-то стандартные сервисы AWS.
Что касается Лямбды. Мы пошли по пути приложения без бэкенда, потому это самый экономичный и самый эффективный вариант. Экономичный, потому что весь код работает только в браузере на компьютере пользователя, и мы за это ничего не платим. Эффективный, потому что взаимодействие с хранилищем происходит напрямую без «прослойки» в виде бэкенд-кода.
Правда, опять же есть и обратная сторона медали. Так как весь код приложения доступен пользователям, труднее предотвращать XSS, контролировать лимит на хранение данных и некоторые другие аспекты.
Да, интересная мысль, не думал об этом в таком ключе. Похоже пользователю действительно важно понимать, каков план монетизации, что будет происходить с сервисом в будущем. Без этого все выглядит довольно неопределенно.
AB-DOC — это дерево папок и документов, все верно. В отличие от гуглдокс и ядиск мы строим приложение по принципу share-first. Сам придумал этот термин сейчас, по аналогии с mobile-first подходом при разработке веб-приложений. То есть идея AB-DOC в том, чтобы создать глобальный сервис обмена полезной информацией.
Я в общем-то согласен с автором статьи.
Есть по большому счету две модели общения: синхронная (личная встреча, телефон, чаты) и асинхронная (эл. почта, таск-треккеры).
Синхронная модель — это царство обрывочных мыслей, рассеянного внимания и больших потерь времени. На мой взгляд, синхронная модель нужна только в редких случаях, когда случился форс-мажор. Ну или может когда нужно выразить и передать эмоции.
Асинхронная модель, я считаю, наилучший вариант для разработчиков. Для продуктивной работы асинхронная модель общения должна составлять где-нибудь 80-90%.
Накидайте мне, пожалуйста, очень озадачился в связи с этими блокировками.
Свой URL по идее будет все равно через CNAME направляться на endpoint S3. У меня пока есть идея только в самой сети амазон делать свой прокси сервер на nginx, который будет отдавать контент с S3 или использовать CloudFront перед S3. Не понятно также, что делать если заблокируют endoint, который используется при загрузке файлов в S3. Мы делаем загрузку в браузере используя CORS. Вероятность блокировки этих endoint-ов по регионам довольно мала, т.к. они не используются вроде бы для скачивания контента и соответственно не могут попасть под санкции.
Но что если заблокируют весь amazonaws.com :)
У меня вчера вечером было заблокировано, потом вроде разблокировали. Сейчас все работает. Москва, Акадо.
Задал вопрос на форумах Амазон https://forums.aws.amazon.com/thread.jspa?threadID=234105. В целом это, конечно, дурдом.
Вначале я попробовал просто получить новый elastic ip и перевести домен на новый IP. Но оказалось, все не так просто — Amazon выдает адреса обычно близкие друг к другу и велика вероятность, что они все будут в заблокированных подсетях.
Мне пришли в голову 2 варианта:
1) Получить elactic ip в другом удаленном регионе и перевести instance туда. Но это ухудшает работу ресурса, так как он рассчитан на пользователей из России, а CDN не используется. И это требует большей возни: нужно выключать instance, снимать с него образ и разворачивать его в другом регионе. Поэтому я пошел по второму варианту.
2) Купить reverse proxy и перевести домен сайта на него. Я купил за 10 долларов reverse proxy в Люксембурге (x4b.net), в качестве бекенда для прокси прописал свой elastic ip на Amazon и буквально через 5 минут сайт вновь заработал, как ни в чем не бывало. Очень надеюсь, что через некоторое время блокировки снимутся и можно будет отказаться от reverse proxy!
Спустя какое-то время, видимо, блокировка снимается с части адресов и ставится на новые адреса.
Но в целом получается, чтобы нормально пользоваться интернетом в России теперь нужно пользоваться VPN. Забавным выглядит на фоне этого высказывания РКН, что блокировка Telegram не нарушила работу других сайтов. Наверное, мы с ними пользуемся разными Интернетами.
Непонятно, что делать, ну сменю я ему elastic ip, но надолго ли это поможет? Если РКН хаотично рубит все подряд…
Упс. Промахнулся. Отвечал zaikin-andrew.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.
В целом, согласен, что можно вывести гораздо проще, чем у меня. Благодаря тому, что тут равнобедренные трапеции, — частный случай многоугольника. Зато мой вариант позволяет применять его к любым четырехугольникам.
Что касается Лямбды. Мы пошли по пути приложения без бэкенда, потому это самый экономичный и самый эффективный вариант. Экономичный, потому что весь код работает только в браузере на компьютере пользователя, и мы за это ничего не платим. Эффективный, потому что взаимодействие с хранилищем происходит напрямую без «прослойки» в виде бэкенд-кода.
Правда, опять же есть и обратная сторона медали. Так как весь код приложения доступен пользователям, труднее предотвращать XSS, контролировать лимит на хранение данных и некоторые другие аспекты.
А пользовательское соглашение у нас, кстати, есть. Цен нет, сервис бесплатный.
Есть по большому счету две модели общения: синхронная (личная встреча, телефон, чаты) и асинхронная (эл. почта, таск-треккеры).
Синхронная модель — это царство обрывочных мыслей, рассеянного внимания и больших потерь времени. На мой взгляд, синхронная модель нужна только в редких случаях, когда случился форс-мажор. Ну или может когда нужно выразить и передать эмоции.
Асинхронная модель, я считаю, наилучший вариант для разработчиков. Для продуктивной работы асинхронная модель общения должна составлять где-нибудь 80-90%.
Свой URL по идее будет все равно через CNAME направляться на endpoint S3. У меня пока есть идея только в самой сети амазон делать свой прокси сервер на nginx, который будет отдавать контент с S3 или использовать CloudFront перед S3. Не понятно также, что делать если заблокируют endoint, который используется при загрузке файлов в S3. Мы делаем загрузку в браузере используя CORS. Вероятность блокировки этих endoint-ов по регионам довольно мала, т.к. они не используются вроде бы для скачивания контента и соответственно не могут попасть под санкции.
Но что если заблокируют весь amazonaws.com :)
Задал вопрос на форумах Амазон https://forums.aws.amazon.com/thread.jspa?threadID=234105. В целом это, конечно, дурдом.