Разработка приложения услуг для Туркменистана
Денис Гордиенко, генеральный директор Bright Mobile, о нюансах разработки за рубеж.
Сегодняшнюю статью я хочу посвятить особенностям разработки клиентам из зарубежья. Обычно, услышав «зарубежье», люди представляют себе Европу или Штаты. У нас такие клиенты были, и никаких проблем с ними у нас в техническом плане никогда не было. Но недавно к нам обратился клиент из Туркменистана, и беда пришла откуда не ждали.
Как оказалось, на территории Туркменистана действует некое подобие китайского фаервола. Наверняка вам известно, что в КНР свой интернет и своя атмосфера, многие ресурсы блокируются, и вот в Туркменистане, как выяснилось, имеется примерно такая же штука, правда в несколько ином формате.
Эта статья пригодится вам, если вы:
- находитесь в Туркменистане и планируете заказать разработку в России;
- являетесь программистом и рассматриваете сотрудничество с клиентами с ближнего зарубежья.
Как работает «туркменский фаервол»?
Есть информационная территория РФ, есть такая же у Туркменистана. Одни серверы наши, другие – туркменские. Мы, не зная, о блокировках, пошли по стандартному сценарию, предложив клиенту зарегистрировать VPS в России, но он ответил, что ввиду определённых юридических нюансов, связанных с персональными данными, сервер должен располагаться на территории Туркменистана. Клиент прислал, и… ничего. Пытаемся подключиться по SSH – ничего не работает.
Сначала мы решили, что у клиента что-то не получилось или проблема в дата-центре. Благо у клиента был свой системный администратор, который следил за его другими проектами, поэтому мы перешли к диалогу с ним. Тогда-то мы и выяснили (для него, кстати, это тоже оказалось сюрпризом), что на уровне государства провайдер блокирует все внешние входящие запросы по портам, связанным с управлением сервером: SSH, FTP, SFTP и прочим, через которые потенциально можно подключиться к внутреннему туркменскому серверу и управлять им.
Как решить вопрос
Первое и довольно очевидное – настроить прокси. В этом случае внутри контура, имеющего доступ к управлению сервером, поднимается прокси, мы подключаемся к нему, и затем уже через него работаем с сервером. Вариант довольно сомнительный: раз блокируют напрямую, что помешает заблокировать через прокси? Придётся снова изощряться, и этому не будет конца.
Рассматривали вплоть до того, что для ручного доступа управлением компьютера заказчика устанавливался какой-нибудь TeamViewer, и все действия мы производим уже через него. Но все эти манипуляции выходят за рамки настройки нашей заготовки для агрегаторов услуг, которую приобрёл клиент, а такие танцы с бубном по стоимости могли бы оказаться дороже самого решения.
Представьте: нужно было, чтобы мой технический специалист всегда был на связи, был включён компьютер сисадмина на неопределённо долгий срок, этот компьютер должен иметь возможность подключаться к управлению сервером… В общем, мороки слишком много, и сама схема вся была какая-то неустойчивая. Поэтому мы её отметили как потенциально рабочую, но решили поискать другие варианты.
Второе, что пришло в голову – разместить сервер клиента всё же на территории Российской Федерации, и часть данных, которая связана с персоналкой, хранить в Туркменистане. Однако подобная доработка баз данных по стоимости была даже больше стоимости самого продукта. Так что делать такое клиенту было просто экономически нецелесообразно.
И наконец, третий вариант, который может в аналогичной ситуации оказаться полезным – если не в случае с Туркменистаном, то с Китаем или другим государством, которое точно так же закрывает доступ к управлению серверами внутри своего контура.
Мы заводим dev-сервер внутри России, на котором будет происходить вся разработка до момента, когда мы сдадим проект клиенту. Сдаём мы его на территории России, он смотрит, одобряет, а затем мы либо делаем снепшот сервера, либо, если это технически не поддерживается хостером на стороне Туркменистана, делаем полный бэкап Битрикса (на котором у нас всё и работает), системный администратор, уже на сервере продакшн, разворачивает чистый Битрикс, а мы по обычному веб-каналу подключаемся к продуктовому серверу, накатываем туда все бэкапы, которые были сделаны на серваке в России.
На стороне Туркменистана останется лишь настроить https на рабочий домен, можно будет подключать мобильное приложение. Доступ с App Store и Google Play там не заблокирован, спокойно подключается, и доработка приложения нормально проходит с рабочим серваком уже в контуре Туркменистана. Основатели выкладывают своё приложение на местные площадки и работают как самостоятельный проект.
Схема выглядит немножко сложной, зато по техническим затратам наиболее приемлема.
Не хотел бы быть клиентом такого чудака, который придумает мега-запутанную схему, потом перепутает что-нить в настройках сервера, как Туркменистан с Таджикистаном, и будет, выпучив глаза утверждать, что на его стороне всё работает.
Восток - дело тонкое (с)
Комментарий недоступен
Не образованный человек с провинциальным мышлением!
Комментарий недоступен
Знаете ум и мудрость не в правильных букв заключаются. Мыслю я чисто и ясно без тараканов, чего советую и вам! А то прогорите со своим мышлением о цвете кожи. Рано или поздно поймёте.
И ещё раз вы подтверждаете свою классовую принадлежность говорю с незнакомым человеком на ты.
Комментарий недоступен
Туркмения... Там же президент может не слезая с велосипеда запилить за полчаса Фейсбук с Гуглом попутно сочинив репчик о могуществе ИТ в его стране
"Схема" какая-то одноразовая.
Исправление ошибок не предполагается? Оптимистично.
Дальнейшая поддержка и развитие не предполагается? Пессимистично.
Вы же не на живую багфикс и апдейты делаете?
Тоно так же через систему бекапирования Битрикса. Ну а приложение просто собирается и заливается в стор
Я держусь от Битрикса чем дальше, тем лучше. Есть проекты, в которых обновления происходят чаще, чем 3-4 раза в неделю. Схема проста dev>(rsync&vpn\p.s. как раз для Китая)>public/in(****) далее замена symlink веб директории на новый public/in(****) и перезапуск node.js сервисов. И как бы не очень удобно использовать для этого чужих администраторов.
Про сторы приложений, конечно, вопросов нет.
Ну я слышал много негатива про Б, но за 5 лет ничего страшного не увидел. Само собой, если быдлокодить, то можно и любой фреймворк ушатать. Самые нагруженные проекты были на 100к юзеров / 10к онлайна.
Ну и для апдейта сторонний сисадмин уже не нужен, только для первоначальной настройки Bitrix VM и Firebase
А, дошло. В Битрикс можно загружать обновления через веб-интерфейс. Тогда ОК. Я бы ещё предусмотрел второй управляющий домен для откатов на пред. релизы, если что-то пойдет не так.
В параллельном мире - создание сайтов, наверное удивлю, но достаточно глянуть большую часть по госзакупкам в РФ и в живую косяки не то что исполнитель, заказчик не исправляет хоть обпишись ему не потребует исправить.
Так что нас обогнала получается тут даже страна с золотым памятником алабаю. Там косяки не прощают. И за слова отвечают.
Так дело было с клиентом из Туркменистана или Таджикистана, чет меня запутали совсем. Или все же из Китая?
Из Кыргызтана?
Вроде же из Узбекистана?
https://youtu.be/LM18xGeZPZ8
Так вы в Таджикистане или в Туркменистане запускали приложение?
Ещё не определился. Сложный выбор.
А почему нельзя было бросить впн туда или оттуда?
Почему нельзя ssh повесить на нестандартные порты?
Анализируется сам трафик, а не порт (см. NTA).
Поставлять приложение в контейнерах Docker через приватный репозиторий, к которому у обеих сторон есть доступ.
Комментарий недоступен
Из-за кого? Там культ и 30 лет назад был. И поддерживался на самых низах.
А где культа нет? 🤷♀️
По всей Ср Азии давно блокировки. Доброе утро. Причем часто там отрабатывают то что потом в рф появляется или наоборот.