Конкретно мы в своей команде используем vim, но это вопрос личных предпочтений. Главное что мы используем в локальной разработке это vagrant, а докер только для сервисов, таких как, база данных. Вести непосредственно разработку внутри докера теоретически можно, но я не уверен что это вам что то даст, особенно если вы только в начале пути.
Стейджинг это autobuild репозиторий на докер хаба. На тот момент когда мы это делали, нельзя было одновременно с ним работать как с обычным репозиторием и autobuild. Поэтому у нас два разных репозитория. В будущем мы конечно уйдем от автосборки прямо на хабе, пустив все это дело через нормальное cd.
«обновить ядро» — в случае облаков это часто невозможно, а на самом деле не нужно. У нас машины живут около месяца, и в процессе постоянно меняются. В принципе такая же история с жесткими дисками.
В общем случае, для веб серверов, эта проблема (zero downtime) решается тем что бекенд отключается от балансера, а потом снова подключается (после всех нужных изменений), либо подключается новый.
Мы начинали наши исследования с coreos, kubernetes и многих других модных штук. Они клевые, но для нас не несут никакого бизнес value. А вот непрерывное развертывания влияет и несет добро.
Мы стартап, у нас три с половиной человека которые делают вообще все). А вообще мы приверженцы devops и управляем инфраструктурой как кодом. Очень рекомендую ознакомиться.
Официальная документация не поможет. Есть пара хороших книг, которые переводят программистов на пару уровней вверх:
Про AWS есть много на хабре и местами в блогах. В целом читать могу порекомендовать только официальную документацию, там все есть, но не скажу что это просто особенно по началу.
> Нужны ли знание в области администрирования
Это не зависит от амазона и кнопочек. Если есть сервера, значит их нужно администрировать. Без администрирования это вам в paas, например, heroku.
Что касается «развернуть». С нуля не просто, я потратил достаточно много времени чтобы разобраться в хитросплетении сервисов и конфигурациях. Для простого сайта это будет перебор. С другой стороны aws это хороший способ прокачаться и понять, а как можно делать инфраструктуру чтобы было хорошо.
Да особо нечего рассказывать на самом деле. Поставили, потрекали метрики (слали напрямую и через statsd). Конечно удобно то, что к данным можно делать почти sql запросы. А дальше поняли что алерты вокруг этого не построишь, да и графана достаточно примитивна.
Я не очень понимаю когда говорят «не фулстек», вот мы на нем делаем сложные приложения и фактически ничего дополнительного не используем. Только бекенд дописываем, но в таком случае ни ангуляр ни кнокаут тоже не фулстек, потому что у них тоже нет бекенда ;), в отличие от, скажем meteor.
Единственное это роутер, в реакте он идет не из коробки пока, но есть очень клевое популярное решение. И насколько я понял разработчики фейсбука уже общаются с теми кто делает этот роутер и возможно его включат.
Если по простому, то в реакте приложение генерируется полностью заного на каждое изменение. Основной смысл каждого компонента вернуть новый virtual dom. Дальше реакт делает diff с предыдущим состоянием и очень хитро производит изменения в реальном доме, таким образом чтобы сократить количество обращений до минимума. Эта техника приводит к очень серьезному ускорению, потому что virtual dom это всего лишь структуры данных на js которые работают чертовски быстро, а обращения к реальному дому это самое медленнное в работе js фреймворков. Так вот реакт не просто быстр, он фантастически быстр и еще он совсем другой. Его нельзя оценивать через призму обычных подходов, потому что его подходы революционны, а не эволюционны.
Как я уже говорил, реакт это совершенно другая идеология. JSX это не верстка, это всего лишь обертка для более простого визуального восприятия. На самом деле оно компилируется в js код, если уж так хочется то можно сразу в js коде писать. Все дело в том что реакт работает с виртуальным домом, и вот это не просто прекрасно это революция в вебе. Посмотрите вот эту статью habrahabr.ru/post/217295/
Так react же (в начале поста ссылка на такой же обзор про реакт). Его многие недооценивают и самое главное не понимают. Он работает принципиально не так как остальные фреймворки. Вместо 2-way data binding (без которого многие не представляют как вообще можно работать), reaсt предлагает 1-way data flow. Этот подход надо прочувствовать. Вот тут все рассказано github.com/facebook/flux.
Я уже выше писал в комментариях, у нас в hexlet.io на react/flux написана облачная IDE и простым это приложение не назовешь. Можно посмотреть: github.com/Hexlet/hexlet-ide.
Вот мы делаем редактор hexlet-ide, он полностью построен на reactjs/flux и мы довольны как слоны). Кстати, atom гитхаба, насколько мне известно, тоже мигрирует на reactjs.
Ну и конечно обязательно 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 это хороший способ прокачаться и понять, а как можно делать инфраструктуру чтобы было хорошо.
Единственное это роутер, в реакте он идет не из коробки пока, но есть очень клевое популярное решение. И насколько я понял разработчики фейсбука уже общаются с теми кто делает этот роутер и возможно его включат.
Я уже выше писал в комментариях, у нас в hexlet.io на react/flux написана облачная IDE и простым это приложение не назовешь. Можно посмотреть: github.com/Hexlet/hexlet-ide.