«Резиновый хозяин искать на Алибаба облако»: размещаем Elasticsearch на мощностях Alibaba Cloud



    Некоторое время назад я рассказывал о нашем опыте решения сложных задач с помощью Elasticsearch. Это была история про колбасу, где мы разработали поиск по базе минимум из 50 000 документов, который позволяет искать ингредиенты в составе продуктов и автоматически формировать по ним описание изделий.

    Недавно к нам в компанию вновь пришел интересный проект, требующий использования Elasticsearch. В этот раз перед нами стояла задача развернуть ES для работы в приложении на китайской облачной платформе Alibaba Cloud. Здесь помимо технических проблем мы столкнулись с такой неожиданной вещью, как китайский менталитет.

    В этой статье речь пойдет исключительно о нашем личном опыте работы с Alibaba Cloud, а не об интерфейсе или стандартных опциях. Я расскажу, что удалось выяснить в общении с представителями платформ Elasticsearch и Alibaba Cloud, и как мы это использовали в решении нашей проблемы.

    Замах на Китай


    В начале проекта заказчик сообщил, что первый запуск приложения будет в Китае. Это значительно усложняло задачу: китайское законодательство доставляет довольно много неудобств разработчикам и владельцам сайтов. Одно только получение домена из-за местной бюрократии растягивается на три месяца. А что, если хостить приложение за пределами Китая? — спросите вы. А я в ответ пожелаю вам удачи с запуском в китайской зоне, потому что там подобные трюки практически вне закона.

    Нам дали доступ к серверу клиента на Alibaba Cloud и попросили развернуть на нем докер-контейнеры с приложением. Это было первой, но не главной проблемой. Мы пробросили доступы из контейнера в файловую систему, чтобы иметь доступ к файлам проекта на уровне сервера, и вот тут проблемой стало то, что на самом сервере кроме докера ничего не было: ни git, ни nginx, ни php. Все выполнялось на уровне контейнеров, а сервер был только хранилищем данных. Поэтому простой git pull превращался в следующее:

    docker exec -it b33aee747c5e git pull

    Из-за этого нам пришлось для каждого контейнера писать bash-скрипт, например, с именем git:

    docker exec -it b33aee747c5e git $@

    Дальше приключение только усложнялось: нам нужно было каким-то образом установить на это ES. Через консоль управления Alibaba Cloud мы поставили образ Elasticsearch 6.0.0 и…
    …И через некоторое время начали ловить ошибки. То система контроля доступа X-Pack начнет «ругаться», что через 28 дней у нас истекает лицензия, то закончится оперативная память при индексации каких-то 500 документов. Не «взлетело».

    Проблемы лаоваев


    Все это время мы думали, что причина неудачи заключается в X-Pack, что это именно он не дает нам нормально работать.

    «Ну что поделать, — сказал заказчик, выслушав нашу версию. — Значит, будем покупать лицензию X-Pack. Пиши в Elasticsearch, может, они сами что-нибудь посоветуют». Я написал в аккаунт-службу, и мне ответил консультант из голландского офиса Дритон Халили (если вам доведется с ним работать — передайте привет от меня, он клевый). Да, Восточной Европой и Россией у них заведует голландский офис, в котором работают турки.

    Консультант рассказал мне про систему оплаты лицензии X-Pack и спросил, где мы хостимся.
    В Китае, ответил я.

    — Это проблема, — огорчился он. — Вашему заказчику надо самому написать в наше китайское отделение, чтобы ему помогли с этой проблемой.
    — А еще варианты есть? — спросил я.
    — Попробуйте связаться с Alibaba Cloud. Дело в том, что мы с ними недавно заключили партнерское соглашение, и теперь они предоставляют Elasticsearch как сервис.
    — Так мы у них и хостимся, — удивился я.
    — Тогда зачем вы мучаетесь с контейнером вместо того, чтобы взять у них напрямую?!
    Закончив разговор, я пересказал все это заказчику.
    — В смысле — у Alibaba есть Elasticsearch as a Service?! — негодованию клиента не было предела. После этого он отправился поговорить с «китайскими коллегами», а на следующий день поведал следующее:
    — Эти люди сказали, что я «лаовай», и на моем «лаовайском» аккаунте мне не положено иметь Elasticsearch.
    Лаоваями, как нетрудно догадаться, китайцы называют иностранцев, нередко используя это слово с пренебрежительным оттенком. Можно сказать, это такое китайское «понаехавшие».
    — Они там пуэра перепили, что ли?
    — Не знаю насчет пуэра, но после моей вдохновляющей речи о том, что они несколько не правы и за что я им вообще плачу деньги, мне дали «секретную» ссылку на Elasticsearch, которая теперь будет отображаться у нас в консоли облака. Настраивай и будем переезжать.

    Что делать, чтобы «взлетело»


    Недели через три в меню консоли управления появилась ссылка на Alibaba Cloud Elasticsearch (в разделе DTplus, в самом низу).



    Из этого можно сделать вывод, что если китайцы все-таки дадут вам ссылку, доступа придется некоторое время подождать (о цене точно сказать не могу, по-моему, стоимость подписки нам это не увеличило).

    И еще: вам, конечно же, дадут доступ к настройкам, нормальный URL, Kibana для мониторинга. Только вот при попытке достучаться до ES откуда-то еще вы получите 505.

    Как я решал эту проблему?

    По умолчанию Elasticsearch у Alibaba Cloud Console доступен только из Kibana и проксирует вызовы с нее на 127.0.0.1 внутри сервера, где расположен сам ES. Тут я задумался: какие IP-адреса у нас внутри между контейнерами? Я вошел в настройки и увидел, что все они у нас крутятся в достаточно привычной подсети 192.168.0.*. Я не был до конца уверен, поэтому записал себе еще парочку адресов, на случай если не «взлетит».

    Также я задумался о том, что будет, если мне самому понадобится отправлять в ES запросы с моего рабочего места, поэтому записал на листочек еще и свой IP-адрес.

    Далее нужно проделать следующее.

    Заходим в Alibaba Cloud Console, открываем Cluster -> Manage -> Network and Snapshots -> раздел Cluster Network Settings -> пункт Public IP Address Whitelist -> Update. И сохраняем здесь все адреса, которые пригодятся – и личные, и публичные. После этого уже можно работать и стучаться в ES и из контейнеров с приложением, и из других мест.



    Переезд занял меньше двух часов. Я, правда, еще неделю испытывал паранойю на тему того, что все может упасть, но пока ничего не упало. Уже три месяца как ни разу не упало.

    Итого мы потратили около трех недель на попытку решить проблему, которой нет. Просто китаец очень хитрый и не хочет давать доступ к своим услугам всяким «лаоваям». Для человека с нашим или западным менталитетом это странно, тем не менее, мы справились с этой проблемой, и это был довольно интересный опыт.

    Спасибо за внимание!
    Поделиться публикацией
    Комментарии 12
      0
      Наверное, несколько грубо и надуманно (не так уж и много технических деталей в статье), но может быть кому-то полезно:
      1 Скорее всего, слишком мало давали ElasticSearch ресурсов, он много хочет (минимум 1-2 cpu, 2gb). В принципе, это пример open source софта, сильно ориентированного на платную поддержку, тяжело даже просто запустить.
      2 Ну и неверится, что сервис бесплатный: обычно БД как сервис стоят заметно дороже соответствующих виртуалок там же.
      3 git внутри docker — это что-то явно не то: когда заказчик просит докер, но не понимает как проверить, а исполнитель решает задачу максимально формально, устраивая себе и заказчику проблемы из-за некомпетентности в этом вопросе
        0
        1 и 2. Вполне возможно, я не в курсе про ценовую политику и железо, нас просто не посвящали в эти подробности.

        3. Я спросил почему так, ответом было то что у них так сервера устроены: через веб-морду просто ставится нужный докер контейнер… и все. Когда заходишь на сервер по ssh то ничего кроме docker ps не получится сделать.
          0
          Кастомный образ прям совсем никак не залить?
            0
            Кастомный образ у нас на само приложение, а лезть и переделывать под себя ES… мы решили так не делать.
              0
              Я имею ввиду вот что — неужели там никак нельзя залить image каждого куска приложения приватно?
              Если можно, то просто подготовить image кастомных частей, часть можно использовать из публичных образов (тот же nginx если подойдет), а image непосредственно php-fpm залить руками (git pull из кастомного docker регистра?).
                0
                Можно. Но там есть своя «особая магия» которая заключается в том что ты ставишь образ не ручками, а через вебморду алибабы и там уже свое колдунсво.
                  0
                  Но ведь так проще делать.
                    0
                    Не для них. На любом другом сервисе это было бы в разы проще и удобнее. Но нам нужно было в китае разворачиваться поэтому такое происходит.
                      0
                      Я вижу обычную загрузку image с прописыванием приблизительно того же что и в docker-compose.yml. После заливки всех образов их останется запустить и все. Была какая то еще сложность?
                        0
                        Сложность в том что ты не можешь просто зайти на сервер, сделать docker compose и радоваться жизни — под капотом происходит еще много махинаций, которые были нам например не видны.
                        Забавная сложность связана с ветками. У нас так воркфлоу построен, что у каждого разработчика своя ветка, под которую запускался инстанс приложения. А теперь прикол — ты указал в настройках что докер сам должен переключить ветку на origin/petrov, а он тащит origin/master. И нужно руками залезть на сервер, сделать git checkout petrov и молиться что composre install не будет качать зависимости час (китайский файервол то зло)
        0

        А что нельзя было решить проблему лицензий? В elasticsearch до 6.3.0 есть версии без Xpack — так называемые oss.

          0
          Проблема была собственно не в лицензии, а в том что не было на тот момент заложенного бюджета на сервер с на 16Гб оперативной памяти.

          Ну и еще нам все таки X-Pack нужен был, тут вообще ничего сделать нельзя было.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое