Ну так это просто бага, которую мы поправим. Главная идея батла была именно в том чтобы видеть код, это в первую очередь обучающая игра с элементами фана.
Основная идея в том что vim это слепой десятипальцевый способ редактирования текста и его мощь именно в командном режиме. Попытка смотреть на него как на IDE уводит от сути и всегда плагины вима будут недотягивать до автоматизации, которая есть практически в любой иде. Но это вторично по отношению к тому за что его по настоящему любят и пользуются им.
Она «начать учиться» только в одном из a/b тестов. Скоро там останется только один вариант, который как раз «посмотреть список курсов», т.к. он победил). По поводу регистрации да спасибо, это ценно и совсем не очевидно. У нас в слаке больше 600 пользователей и никто не обращал наше внимание на это.
Конкретно мы в своей команде используем vim, но это вопрос личных предпочтений. Главное что мы используем в локальной разработке это vagrant, а докер только для сервисов, таких как, база данных. Вести непосредственно разработку внутри докера теоретически можно, но я не уверен что это вам что то даст, особенно если вы только в начале пути.
Стейджинг это autobuild репозиторий на докер хаба. На тот момент когда мы это делали, нельзя было одновременно с ним работать как с обычным репозиторием и autobuild. Поэтому у нас два разных репозитория. В будущем мы конечно уйдем от автосборки прямо на хабе, пустив все это дело через нормальное cd.
«обновить ядро» — в случае облаков это часто невозможно, а на самом деле не нужно. У нас машины живут около месяца, и в процессе постоянно меняются. В принципе такая же история с жесткими дисками.
В общем случае, для веб серверов, эта проблема (zero downtime) решается тем что бекенд отключается от балансера, а потом снова подключается (после всех нужных изменений), либо подключается новый.
Мы начинали наши исследования с coreos, kubernetes и многих других модных штук. Они клевые, но для нас не несут никакого бизнес value. А вот непрерывное развертывания влияет и несет добро.
Мы стартап, у нас три с половиной человека которые делают вообще все). А вообще мы приверженцы devops и управляем инфраструктурой как кодом. Очень рекомендую ознакомиться.
Официальная документация не поможет. Есть пара хороших книг, которые переводят программистов на пару уровней вверх:
Про AWS есть много на хабре и местами в блогах. В целом читать могу порекомендовать только официальную документацию, там все есть, но не скажу что это просто особенно по началу.
> Нужны ли знание в области администрирования
Это не зависит от амазона и кнопочек. Если есть сервера, значит их нужно администрировать. Без администрирования это вам в paas, например, heroku.
Что касается «развернуть». С нуля не просто, я потратил достаточно много времени чтобы разобраться в хитросплетении сервисов и конфигурациях. Для простого сайта это будет перебор. С другой стороны aws это хороший способ прокачаться и понять, а как можно делать инфраструктуру чтобы было хорошо.
Да особо нечего рассказывать на самом деле. Поставили, потрекали метрики (слали напрямую и через statsd). Конечно удобно то, что к данным можно делать почти sql запросы. А дальше поняли что алерты вокруг этого не построишь, да и графана достаточно примитивна.
Основная идея в том что vim это слепой десятипальцевый способ редактирования текста и его мощь именно в командном режиме. Попытка смотреть на него как на IDE уводит от сути и всегда плагины вима будут недотягивать до автоматизации, которая есть практически в любой иде. Но это вторично по отношению к тому за что его по настоящему любят и пользуются им.
Ну и конечно обязательно ansible.
Стейджинг это autobuild репозиторий на докер хаба. На тот момент когда мы это делали, нельзя было одновременно с ним работать как с обычным репозиторием и autobuild. Поэтому у нас два разных репозитория. В будущем мы конечно уйдем от автосборки прямо на хабе, пустив все это дело через нормальное cd.
В разделе «Разворачивание инфраструктуры» я подробно ответил на этот вопрос.
Посмотрите содержимое upstart скрипта, там видно и остановка и старт.
В общем случае, для веб серверов, эта проблема (zero downtime) решается тем что бекенд отключается от балансера, а потом снова подключается (после всех нужных изменений), либо подключается новый.
Официальная документация не поможет. Есть пара хороших книг, которые переводят программистов на пару уровней вверх:
www.ozon.ru/context/detail/id/2419365/ Операционная система UNIX
www.ozon.ru/context/detail/id/7607778/ администрирование linux
> Нужны ли знание в области администрирования
Это не зависит от амазона и кнопочек. Если есть сервера, значит их нужно администрировать. Без администрирования это вам в paas, например, heroku.
У AWS есть бесплатные ресурсы, и достаточно много aws.amazon.com/free/.
Что касается «развернуть». С нуля не просто, я потратил достаточно много времени чтобы разобраться в хитросплетении сервисов и конфигурациях. Для простого сайта это будет перебор. С другой стороны aws это хороший способ прокачаться и понять, а как можно делать инфраструктуру чтобы было хорошо.