Под капотом образовательного проекта Хекслет

    Привет, Хабр!



    В прошлой статье я рассказал о новой версии образовательного проекта Хекслет. В голосовании вы решили, что следующая статья будет о технической реализации платформы.

    Напомню, Хекслет — это платформа для создания практических уроков по программированию в настоящей среде разработки. Под настоящей средой разработки мы подразумеваем полноценную машину, подключенную к сети. Эта важная деталь отличает Хекслет от других образовательных проектов (например, Codecademy или CodeSchool) — у нас нет симуляторов, все по-настоящему. Это позволяет обучать и обучаться не только программированию, но и работе с базами данных, серверами, сетью, фреймворками и так далее. В целом, если это запускается на Unix-машине — этому можно обучать на Хекслете. При этом, понимая это или нет, пользователи используют Test-Driven Development (TDD), потому что их решения проверяются юнит-тестами.

    В этом посте я расскажу про архитектуру платформы Хекслет и инструменты, которые мы используем. О том, как на этой платформе создавать практически уроки — в следующей статье.




    Почти весь бэкэнд написан на Rails. Все работает на Amazon Web Services (AWS). Изначально мы старались сильно не привязываться к инфраструктуре AWS, но постепенно стали использовать больше их сервисов. В RDS (Relational Database Service) крутится PostgreSQL (основная база) и Redis. Благодаря нему нам можно не волноваться о бэкапах, репликации, обновлении — все работает автоматически. Так же в RDS мы используем автоматический failover – multiAZ. В случае падения основной машины, автоматически поднимается синхронная replica в другой зоне доступности, и в течение пары минут происходит привязка DNS-записи к новому IP-адресу.

    SQS (Simple Queue Service) для построения очередей. Вся почта отправляется через SES, домены живут в Route53. Amazon Simple Notification Service (SNS) шлет в нашу SQS-очередь сообщения о статусе доставки писем. Картинки и файлы хранятся в S3. С недавнего времени используем Cloudfront, CDN от Амазона.

    Краеугольный камень всей платформы — Докер.

    Каждый сервис у нас работает в своем контейнере. Один контейнер = один сервис. Большинство образов для контейнеров это готовые образы из tutum.co. Репозиторий для своего приложения мы храним в Docker Registry. Для стейджинга образ собирается автоматически при коммите в Dockerfile. Сам код хранится в Github. Для продакшена мы собираем образы через Ansible на отдельном сервере. Билд занимает значительное время, 20-60 минут в зависимости от условий, поэтому вариант «по-быстрому пофиксим продакшен» невозможен. Но оказалось это не проблема, наоборот – дисциплинирует. Когда что-то идет не так при деплое на продакшен, мы просто убиваем один контейнер и  предыдущий. Наша база растет только горизонтально (что типично для проектов с, кхм-кхм, хорошей архитектурой), что позволяет использовать базу с разными версиями кода и не получать конфликтов. Поэтому откат это почти всегда простая замена версии кода.

    В первое время для деплоя мы использования Capistrano, но в итоге отказались от нее в пользу Ansible. Немного не привычно, но Ansible просто доставляет конфиги на удаленный сервер и запускает upstart, а тот в свою очередь уже обновляет образы. В такой схеме нам не нужно устанавливать на сервера ничего специального, для Ansible нужен только ssh-доступ. Для версионирования используются теги (v64, v65 и так далее), а деплой на стейджинг всегда использует самую последнюю версию (latest) кода.

    Кстати, мы так любим Ansible, что сделали по нему практический курс — «Ansible: Введение».



    Большой плюс — локально при разработке мы используем почти идентичные Ansible playbooks, что и для продакшена. Так что инфрастуктура обкатывается локально, насколько это возможно, что минимизирует ошибки типа «а на локалке работало». В итоге процесс деплоя выглядит так: новый коммит в Dockerfile в гитхабе -> запуск нового билда в docker registry -> запуск плейбука Ansible -> обновленные конфиги на сервере -> запуск upstart -> получение новых образов.

    Мы также используем амазоновский балансировщик, и в случае хабраэффекта за 10-20 минут можем поднять дополнительные машины. Важное условие такой схемы — конечные веб-серверы не хранят состояния (stateless), на них не сохраняется никаких данных. Это позволяет быстро масштабироваться.

    Амазон мы тоже любим, про Route53 (менеджмент доменов/DNS) и про балансировщик у нас есть уроки в цикле «Распределенные системы».


    Страница популярного урока.

    Суть проекта — позволять людям учиться в реальном окружении, для этого каждому юзеру мы поднимаем контейнер, в котором он выполняет практическое упражнение. Эти контейнеры поднимаются на специальном «eval»-сервере. На нем есть только Докер и обращаться к нему можно только из Shoryuken, асинхронно.

    В первых прототипах Хекслета система требовала от пользователей работать над практическими заданиями на своих компьютерах, но сейчас вся работа происходит в браузере, скачивать и устанавливать ничего не нужно. Для этого нам понадобилась браузерная среда разработки, которая позволила бы юзерам редактировать файлы и запускать программы. Существует много облачных IDE, и мы, как любой уважающий себя стартап, хотели по максимуму использовать готовые решения. Нашли классный IDE с кучей функций (даже с интеграцией с Git), но потом оценили стоимость поддержания чужого кода (полного изобретенных велосипедов) и решились писать свой простой IDE. Здесь нас спасла еще одна новая технология — ReactJS и концепция Flux. Пару недель назад вышла новая версия Hexlet IDE с кучей функциональных и визуальных улучшений.


    Новая версия Hexlet IDE в деле.

    В первые недели все метрики (как системные, вроде нагрузки на машины, так и бизнес-метрики, такие как регистрации и оплаты) мы отправляли в свою базу InfluxDB, и рендерили графики в Grafana. Но сейчас переходим на сторонние сервисы, например, Datadog. Он умеет интегрироваться с AWS, настраивать оповещения при возникновении инцидентов.

    Вся команда Хекслета сидит в Slack, там в специльном чате #operations мы видим все, что происходит на проекте: деплои, ошибки, билды и пр.



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

    Если вам это интересно — пишите на info@hexlet.io и вступайте в нашу группу для авторов на Фейсбуке.

    Спасибо!
    Hexlet
    64.81
    Практические уроки по программированию
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 19

      +5
      класс!
        +3
        Расскажите подробнее об опыте с InfluxDB?
          +2
          Да особо нечего рассказывать на самом деле. Поставили, потрекали метрики (слали напрямую и через statsd). Конечно удобно то, что к данным можно делать почти sql запросы. А дальше поняли что алерты вокруг этого не построишь, да и графана достаточно примитивна.
          +3
          Очень знакомая ситуация с првязкой к сервисам AWS. Сначала поднимаешь одни только EC2, а потом понимаешь, что весь проект в сервисах Amazon уже. Есть и обратная сторона злоупотребления их сервисами, сам столкнулся с тем, что на RDS они режут конкурентные соединения до определённого лимита в зависимости от типа инстанса (что явно не прописано в прайсах).

          Docker для каждого пользователя и реальная среда выполнения это круто — каким и должно быть обучение. Спасибо за обзор!
          • UFO just landed and posted this here
            +1
            Расскажите подробнее об опыте использование AWS. С какими столкнулись трудностями, почему именно AWS. Насколько сложно развернуть на AWS свой проект (обычный неприметный сайт). Нужны ли знание в области администрирования или все сводится к нажатием кнопочек через web-интерфейс. Какие преимущества AWS перед другими аналогичными сервисами. Если не сложно дайте пару ссылок на ресурсы где можно подробней почитать об AWS (гугл в помощь не предлагать -)). Буду признателен, если ответите в личку. Спасибо.
              +1
              Про AWS есть много на хабре и местами в блогах. В целом читать могу порекомендовать только официальную документацию, там все есть, но не скажу что это просто особенно по началу.

              > Нужны ли знание в области администрирования
              Это не зависит от амазона и кнопочек. Если есть сервера, значит их нужно администрировать. Без администрирования это вам в paas, например, heroku.

              У AWS есть бесплатные ресурсы, и достаточно много aws.amazon.com/free/.

              Что касается «развернуть». С нуля не просто, я потратил достаточно много времени чтобы разобраться в хитросплетении сервисов и конфигурациях. Для простого сайта это будет перебор. С другой стороны aws это хороший способ прокачаться и понять, а как можно делать инфраструктуру чтобы было хорошо.
              +1
              > Это не зависит от амазона и кнопочек. Если есть сервера, значит их нужно администрировать.
              Вы сами администрируете или есть штатный админ? Если сами, расскажите какие познания нужны для администрирования и поможет ли в этом оффдокументация?

              Спасибо
                +1
                Мы стартап, у нас три с половиной человека которые делают вообще все). А вообще мы приверженцы devops и управляем инфраструктурой как кодом. Очень рекомендую ознакомиться.

                Официальная документация не поможет. Есть пара хороших книг, которые переводят программистов на пару уровней вверх:

                www.ozon.ru/context/detail/id/2419365/ Операционная система UNIX
                www.ozon.ru/context/detail/id/7607778/ администрирование linux
                  +2
                  > Мы стартап, у нас три с половиной человека которые делают вообще все).
                  Да, в курсе, читал все ваши статьи. Очень интересно наблюдать как развивается проект. Даже один из ваших курсов проходил. Спасибо вам за ваши труды. Удачи в этом нелегком деле.

                  Отдельное спасибо за ответы и ссылки
                    +1
                    Спасибо! Вам удачи в освоении серверного края)
                      +2
                      Спасибо!
                +2
                Очень здорово! Вы большие молодцы! Надеюсь ваш проект ожидает большое будущее.
                  0
                  а как связаться с поддержкой?:)
                  На сайте нашел только идеи и предложения, на почту вашу гугол не хочет слать письма. Оплатил подписку, нокак-то она не активировалась, а учиться-то хочется!
                    +1
                    На сайте в правом нижнем углу иконка с вопросительным знаком – можно использовать ее или написать напрямую на info@hexlet.io
                    Разберемся быстро ;-)
                      0
                      не вижу иконки :(
                      а письма не ходят
                        0
                        Написал вам на почту.
                        А иконка: может, у вас стоит какой-нибудь adblock? Иконка выглядит так: cl.ly/image/0O01443J1j1V
                          0
                          Да, Ghostery блокировал!
                            0
                            Проблема решена, в ближайшее время все оплаты будут применены.
                            Еще раз прошу прощения за неудобства.

                    Only users with full accounts can post comments. Log in, please.