Разработка приложения услуг для Туркменистана

Денис Гордиенко, генеральный директор Bright Mobile, о нюансах разработки за рубеж.

Сегодняшнюю статью я хочу посвятить особенностям разработки клиентам из зарубежья. Обычно, услышав «зарубежье», люди представляют себе Европу или Штаты. У нас такие клиенты были, и никаких проблем с ними у нас в техническом плане никогда не было. Но недавно к нам обратился клиент из Туркменистана, и беда пришла откуда не ждали.

Туркменский фаервол на защите данных

Как оказалось, на территории Туркменистана действует некое подобие китайского фаервола. Наверняка вам известно, что в КНР свой интернет и своя атмосфера, многие ресурсы блокируются, и вот в Туркменистане, как выяснилось, имеется примерно такая же штука, правда в несколько ином формате.

Эта статья пригодится вам, если вы:

  • находитесь в Туркменистане и планируете заказать разработку в России;
  • являетесь программистом и рассматриваете сотрудничество с клиентами с ближнего зарубежья.

Как работает «туркменский фаервол»?

Есть информационная территория РФ, есть такая же у Туркменистана. Одни серверы наши, другие – туркменские. Мы, не зная, о блокировках, пошли по стандартному сценарию, предложив клиенту зарегистрировать VPS в России, но он ответил, что ввиду определённых юридических нюансов, связанных с персональными данными, сервер должен располагаться на территории Туркменистана. Клиент прислал, и… ничего. Пытаемся подключиться по SSH – ничего не работает.

Сначала мы решили, что у клиента что-то не получилось или проблема в дата-центре. Благо у клиента был свой системный администратор, который следил за его другими проектами, поэтому мы перешли к диалогу с ним. Тогда-то мы и выяснили (для него, кстати, это тоже оказалось сюрпризом), что на уровне государства провайдер блокирует все внешние входящие запросы по портам, связанным с управлением сервером: SSH, FTP, SFTP и прочим, через которые потенциально можно подключиться к внутреннему туркменскому серверу и управлять им.

Как решить вопрос

Первое и довольно очевидное – настроить прокси. В этом случае внутри контура, имеющего доступ к управлению сервером, поднимается прокси, мы подключаемся к нему, и затем уже через него работаем с сервером. Вариант довольно сомнительный: раз блокируют напрямую, что помешает заблокировать через прокси? Придётся снова изощряться, и этому не будет конца.

Рассматривали вплоть до того, что для ручного доступа управлением компьютера заказчика устанавливался какой-нибудь TeamViewer, и все действия мы производим уже через него. Но все эти манипуляции выходят за рамки настройки нашей заготовки для агрегаторов услуг, которую приобрёл клиент, а такие танцы с бубном по стоимости могли бы оказаться дороже самого решения.

Представьте: нужно было, чтобы мой технический специалист всегда был на связи, был включён компьютер сисадмина на неопределённо долгий срок, этот компьютер должен иметь возможность подключаться к управлению сервером… В общем, мороки слишком много, и сама схема вся была какая-то неустойчивая. Поэтому мы её отметили как потенциально рабочую, но решили поискать другие варианты.

Второе, что пришло в голову – разместить сервер клиента всё же на территории Российской Федерации, и часть данных, которая связана с персоналкой, хранить в Туркменистане. Однако подобная доработка баз данных по стоимости была даже больше стоимости самого продукта. Так что делать такое клиенту было просто экономически нецелесообразно.

И наконец, третий вариант, который может в аналогичной ситуации оказаться полезным – если не в случае с Туркменистаном, то с Китаем или другим государством, которое точно так же закрывает доступ к управлению серверами внутри своего контура.

Мы заводим dev-сервер внутри России, на котором будет происходить вся разработка до момента, когда мы сдадим проект клиенту. Сдаём мы его на территории России, он смотрит, одобряет, а затем мы либо делаем снепшот сервера, либо, если это технически не поддерживается хостером на стороне Туркменистана, делаем полный бэкап Битрикса (на котором у нас всё и работает), системный администратор, уже на сервере продакшн, разворачивает чистый Битрикс, а мы по обычному веб-каналу подключаемся к продуктовому серверу, накатываем туда все бэкапы, которые были сделаны на серваке в России.

На стороне Туркменистана останется лишь настроить https на рабочий домен, можно будет подключать мобильное приложение. Доступ с App Store и Google Play там не заблокирован, спокойно подключается, и доработка приложения нормально проходит с рабочим серваком уже в контуре Туркменистана. Основатели выкладывают своё приложение на местные площадки и работают как самостоятельный проект.

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

0
27 комментариев
Написать комментарий...
Sergey Furtaev

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

Ответить
Развернуть ветку
Максим Ростокин

Восток - дело тонкое (с)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
ArtYk.inTrade

Не образованный человек с провинциальным мышлением!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
ArtYk.inTrade

Знаете ум и мудрость не в правильных букв заключаются. Мыслю я чисто и ясно без тараканов, чего советую и вам! А то прогорите со своим мышлением о цвете кожи. Рано или поздно поймёте.
И ещё раз вы подтверждаете свою классовую принадлежность говорю с незнакомым человеком на ты.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Трейдер мамкин

Туркмения... Там же президент может не слезая с велосипеда запилить за полчаса Фейсбук с Гуглом попутно сочинив репчик о могуществе ИТ в его стране

Ответить
Развернуть ветку
Ярослав Яшин

"Схема" какая-то одноразовая.
Исправление ошибок не предполагается? Оптимистично.
Дальнейшая поддержка и развитие не предполагается? Пессимистично.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вы же не на живую багфикс и апдейты делаете?

Тоно так же через систему бекапирования Битрикса. Ну а приложение просто собирается и заливается в стор

Ответить
Развернуть ветку
Ярослав Яшин

Я держусь от Битрикса чем дальше, тем лучше. Есть проекты, в которых обновления происходят чаще, чем 3-4 раза в неделю. Схема проста dev>(rsync&vpn\p.s. как раз для Китая)>public/in(****) далее замена symlink веб директории на новый public/in(****) и перезапуск node.js сервисов. И как бы не очень удобно использовать для этого чужих администраторов.
Про сторы приложений, конечно, вопросов нет.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Ну я слышал много негатива про Б, но за 5 лет ничего страшного не увидел. Само собой, если быдлокодить, то можно и любой фреймворк ушатать. Самые нагруженные проекты были на 100к юзеров / 10к онлайна.

Ну и для апдейта сторонний сисадмин уже не нужен, только для первоначальной настройки Bitrix VM и Firebase

Ответить
Развернуть ветку
Ярослав Яшин

А, дошло. В Битрикс можно загружать обновления через веб-интерфейс. Тогда ОК. Я бы ещё предусмотрел второй управляющий домен для откатов на пред. релизы, если что-то пойдет не так.

Ответить
Развернуть ветку
Vladimir Batenev
Вы же не на живую багфикс и апдейты делаете?

В параллельном мире - создание сайтов, наверное удивлю, но достаточно глянуть большую часть по госзакупкам в РФ и в живую косяки не то что исполнитель, заказчик не исправляет хоть обпишись ему не потребует исправить.

Так что нас обогнала получается тут даже страна с золотым памятником алабаю. Там косяки не прощают. И за слова отвечают.

Ответить
Развернуть ветку
Rad Warwar

Так дело было с клиентом из Туркменистана или Таджикистана, чет меня запутали совсем. Или все же из Китая?

Ответить
Развернуть ветку
Andrey Krasikov

Из Кыргызтана?

Ответить
Развернуть ветку
Johnny Vorony

Вроде же из Узбекистана?

Ответить
Развернуть ветку
Руслан Семагин
Ответить
Развернуть ветку
Komron Mardoni

Так вы в Таджикистане или в Туркменистане запускали приложение?

Ответить
Развернуть ветку
Руслан Семагин

Ещё не определился. Сложный выбор.

Ответить
Развернуть ветку
Василий Петров

А почему нельзя было бросить впн туда или оттуда?

Почему нельзя ssh повесить на нестандартные порты?

Ответить
Развернуть ветку
Ярослав Яшин

Анализируется сам трафик, а не порт (см. NTA).

Ответить
Развернуть ветку
Пит Подлый

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Ренат Ренатович

Из-за кого? Там культ и 30 лет назад был. И поддерживался на самых низах.

Ответить
Развернуть ветку
Evil Pechenka

А где культа нет? 🤷‍♀️

Ответить
Развернуть ветку
Sergei Korneev

По всей Ср Азии давно блокировки. Доброе утро. Причем часто там отрабатывают то что потом в рф появляется или наоборот.

Ответить
Развернуть ветку
24 комментария
Раскрывать всегда