company_banner

Видео докладов с DevOps Meetup про Docker

    Недавно в офисе Badoo проходил DevOps Meetup про Docker и контейнерную виртуализацию. Делимся с вами видео докладов.

    1. «Docker в Badoo: от восторгов к внедрению».
    Антон banuchka Турецкий, Раудсепп Илья, Badoo.




    2. «Teaching Dockers to use CRanes»/«Оснастите свои доки кранами».
    Павел Емельянов, Parallels.




    3. «Sysadmin tasks (backups, logging, remote access, debugging, network analysis...) with Docker, aka „life without SSH“.
    Jérôme Petazzoni, Docker.

    Метки:
    • +32
    • 14,9k
    • 5
    Badoo 387,95
    Big Dating
    Поделиться публикацией
    Похожие публикации

    Вакансии компании Badoo

    Комментарии 5
    • +2
      Звук как-то «интересно» записан. На отдельные микрофоны для видео звук писался? Гул стоит страшный конечно, когда спикер говорит в микрофон в руке еще.
      :(
    • 0
      confd?
    • 0
      1. А как у вас организовано ли CI контейнеров? Как собираются контейнеры для тестирования?
      2. У вас в контейнерах с php-кодом в качестве entrypoint'а/cmd выступает php-fpm?
      3. Как у вас организован service discovery? Или повсеместно используются etcd/confd?
      4. Как ваша система деплоя понимает, где и в каких количествах нужно разворачивать контейнеры определенного типа?
      • 0
        На второй вопрос ответ уже получил из видео.
      • +1
        Добрый день,

        попробую ответить на ваши вопросы:

        1. У нас для сборки «тестовых»(а потом уже и не тестовых, после тестирования) образов на той машине, где происходит сборка осуществляется поддержка структуры каталогов для сборки через Puppet. Я понимаю, что это может быть не самое красивое решение, но нам для переходного этапа, когда часть сервисов в контейнере, а часть по прежнему на «голом железе» этот вариант кажется самым предпочтительным. Т.е. у нас получается так:
        Build_Directory/
        — service_name/
        — Dockerfile
        — file1
        — file2


        т.е. автоматически наполняем Dockerfile и всю необходимую структуру.
        Далее, когда в build системе происходит сборка бинаря/приложения, то оно на основании «шаблона» собирает образ. Тут есть 2 варианта: собралось/не собралось. Если собралось, то тегируем образ, пушим в registry, сообщаем команде тестирования о том, что есть новый образ и нужно начать его тестировать(образ оказывается на нужной для тестирования машины, в задаче на тестирования присутствуют все нужные параметры для запуска контейнера из образа).
        2. тут вы уже сами ответ нашли.
        3. У нас нет как такого глобального service discovery. У нас есть «карта сервисов», на основании которой мы регулируем то, на каком хосте и кто/что у нас должно работать.
        etcd/confd используется уже на отдельновзятом хосте, если мы точно знаем о том, что сервис может быть перезапущен с переключением нагрузки на второй/третий/… инстанс. Да, не все сервисы, к сожалению, умеют так делать. Многим нужен корректный shutdown перед тем, как запустить вторую копию и прочее. Именно поэтому реализация «плавного» перезапуска у нас сделана «поштучно».
        4. У нас есть «карта» сервисов, которая поддерживается инженером, на основании которой уже и происходит принятие решений о том кого где и сколько. Т.е. вариант «вот тебе вычислительные мощности — запусти мне где-нить 10-ку инстансов и мне все равно где...» нам не подходит.

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

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