Конференции для программистов и сочувствующих. 18+
687,81
рейтинг
13 августа 2015 в 12:46

Разработка → Docker в банке. Видео с лекции Александра Тарасова из Альфа-Банка

Docker — технология, вокруг которой нынче огромное количество хайпа. «Shitstorm» — именно таким словом окрестил в твиттере докеровые войны один из моих немецких знакомых. Ну и конечно, вместе с «Microservices» и «Reactive», слово «Docker» прочно вошло в тройку ведущих айтишных баззвордов последних двух лет.

Неделю назад на московской встрече CodeFreeze Александр aatarasoff Тарасов из Альфа-Лаборатории (подразделение Альфа-банка) рассказал от том, как они внедряли у себя Docker, какой получили профит, какую боль и т.п. Интрига в том, что, с одной стороны, Альфа-банк — это банк, то есть, «кровавый энтерпрайз». С другой стороны… внедрили же.



Под катом — короткое описание того, о чем рассказал нам Александр и видеозапись его выступления.


Docker в банке

Docker на локальной машине и Docker в продакшене — это две большие разницы. Поиграться с технологией легко, заставить работать в промышленных масштабах — сложно.

Полгода назад в недрах Альфа-Лаборатории (Альфа-Банк) Александр Тарасов с коллегами начали строить новую микросервисную архитектуру для одного из пилотных проектов. Они почти полностью поменяли стек используемых технологий на фронтенде и существенно изменили его на миддленде. В качестве средства упаковки и дистрибуции выбрали Docker. Два месяца назад они довели начатый проект до боя и открыли сервис клиентам.

В докладе освещены следующие темы:
  • причины выбора Docker'а;
  • почему один Docker — в поле не воин, и что нужно ещё для продакшена;
  • какой итоговый стек технологий использовали в своём решении;
  • какие преимущества получили;
  • с какими проблемами столкнулись и как их решали.


В докладе мало теории, но много практики, личного опыта и ощущений.

Автор: @23derevo
JUG.ru Group
рейтинг 687,81
Конференции для программистов и сочувствующих. 18+

Комментарии (13)

  • 0
    Александр, жаль что так поздно читал этот доклад( Если бы в 18:00, было бы гораздо больше народа из Deutsche Bank
    • +2
      В 18:00 многие ещё работают, а до места ещё добраться нужно.
      Ну а если не смогли попасть — смотрите видео, а возникшие вопросы всегда можно задать докладчику.
      • +1
        Бегло посмотрел. Спасибо, интересный доклад!

        Видел решение по работе с kubernetes через браузер в проекте fabric8
        hawt.io screenshot
        hawt.io

    • +1
      Игорь, и гораздо меньше народу из сотни других компаний. Не дойчем единым :)

      Мы раньше проводили ивенты в 19:00, но потом перенесли на 20:00, чтобы все спокойно успевали добраться.
  • +1
    Спасибо, очень интересный доклад.

    Вопросы к докладчику, если aatarasoff читает этот пост.

    Ну во первых прошу прощения, т.к. видио смотрел по диагонали (нет у меня 2х часов времени сейчас), вопросы могут быть не актуальные из за того что нибудь просмотрел.

    Какие базовые образы вы используете? Пробовали ли alpie?

    Как связываете контейнеры? dns через дирижёра? если так то как боритесь с падением nginx при запуске если dns не доступен?
    • +2
      >Какие базовые образы вы используете? Пробовали ли alpie?
      Debian, Ubuntu, Alpine. Образы в основном собираем сами и кладём в приватный репозиторий.

      >Как связываете контейнеры?
      В основном nginx на том же хосте работает как прокси, либо через клиентский экземпляр consul-а (HTTP + DNS).

      >dns через дирижёра?
      Есть локальные клиенты на каждом сервере, где требуется discovery.

      >как боритесь с падением nginx при запуске если dns не доступен?
      Nginx конфигурируется с помощью consul template, который не использует DNS, и строго говоря nginx зависит от consul-a лишь через сгенерированный конфигурационный файл, который просто не будет обновляться, если с последним возникнут какие-либо проблемы.
      • 0
        За consul template большое вам спасибо, бегленко глянул, выглядит очень интересно
      • +1
        nginx можно заставить не падать при недоступном dns. Для этого в директиве проксирования адрес бэкенда должен быть не фиксированным, а содержать хотя бы одну переменную. Тогда ресолвер работает не на старте, а на каждом запросе. И не крашит nginx, если dns недоступен. Есть и недостатки у такого подхода, как вы понимаете.
  • +1
    Интересный доклад. С удовольствием послушал.
  • 0
    Для ентерпрайза сыровато.
    Вот, например, из совсем недавнего github.com/docker/docker/issues/14181
    • 0
      ну-ка, покажите мне софт без багов
      • 0
        Чтобы вот так вот сразу kernel panic? Затрудняюсь найти подобное что-то.

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

Самое читаемое Разработка