Лично для меня Amazon Web Services всегда ассоциировался с Infrastructure as a Service (IaaS), на базе которого каждый строил свои сервисы и приложения. Но есть и претендующие на роль платформы в виде сервиса, например, Elastic Beanstalk и OpsWorks. Хотя, по моему мнению, их с натяжкой можно считать PaaS, так как остается доступ к инфраструктуре, и вместе с тем головная боль по её администрированию.

Вся прелесть PaaS — это нулевые затраты на администрирование, простота использования и, как следствие, возможность сфокусироваться на коде приложения, забыв о том, как его разворачивать, интегрировать и поддерживать.

Итак, по словам представителей AWS, Lambda позволит забыть об инфраструктуре и запускать приложения в облаке, при этом получая интеграцию с другими сервисами Amazon, масштабируемость, низкую цену использования вычислительных ресурсов. Все, что нужно для старта, — написать функцию, ассоциировать её с событиями. После этого амазон автоматически выполнит функцию при каждом новом событии. О масштабировании и высокой доступности можно не думать: наша функция сможет обработать десятки тысяч запросов в час без каких-либо усилий с нашей стороны, без бекенда в традиционном его понимании.

Скорее всего, передовой облачный провайдер Amazon Web Services в первую очередь ассоциируется с EC2 (виртуальные инстансы) и ELB (балансировщик). Типичная схема разворачивания web-сервиса — EC2 инстансы за балансировщиком (Elastic Load Balancer).Преимуществ у такого подхода очень много, в частности, у нас «из коробки» есть проверка состояния нод, мониторинг (количество запросов, логи), легко настраивамое авто-масштабирование и т.д. Но далеко не всегда ELB — лучший выбор для распределения нагрузки, а иногда и вовсе не подходящий инструмент.

Под катом я покажу два примера использования Route 53 вместо Elastic Load Balancer-а: первый — из опыта компании Loggly, воторой — из моего личного.

Предисловие от переводчика

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

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

Статья будет полезна как для видавших виды «поваров», так и для новичков.

Вступление (лирическое)

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

Для меня, автоматизатора-линуксоида, использвание Windows на основной рабочей станции первое время было просто болью и страданием. Но с этим я ничего поделать не мог: корпоративные стандарты и софт, кторый работает только на Windows. В попытке найти золотую середину, я прошёл три стадии. Сначала я только изредка переключался на винду по необходимости. Затем виртуалка на virtualbox-е с X-server-ом. После этого захотелось хоть чуть-чуть того консольного комфорта, который был на линуксе (я использовал Terminator в качестве основного терминала).

После яростного гугления и установки всех эмуляторов терминала под Windows, которые только удалось найти, оказалось, что нет ни одного хоть немного подходящего мне. А хотелось, чтобы вёл себя терминал максимально приближенно к линуксовым вариантам. Например, естественно нужны табы, сплит, выделение текста с прокруткой (когда нужно выделить больше чем один экран), копирование текста в буфер сразу при выделении и т.д.

В итоге я получил «комбайн» как на скриншоте ниже. О том, как это настроить, можно узнать, заглянув под кат.

Что такое Continuous Delivery многие уже, наверное, слышали неоднократно. Одним из ключевых моментов этого процесса является постороение Build Pipeline («трубопровод» от исполнителя к заказчику). А для этого нужно автоматизировать такие процессы как сборка проекта, его разворачивание на инфраструктуре, тестирование и т.д. Отличным инструментом для таких задач является Jenkins.

Для автоматизации разворачивания приложения простейшим вариантом может быть запуск скриптов Jenkins-ом на хостах инфраструктуры по ssh. А что, если в парк из Linux-инстансов затесался один (или несколько) с Windows? Как деплоить на «вражеский» хост — смотри под катом.

Как известно, в облаке Amazon виртуальные инстансы запускаются на основе образов (так называемые AMI). Amazon предоставляет большое их количество, также можно использовать публичные образы, подготовленные сторонними организациями, за которые облачный провайдер, естественно, никакой ответственности не несёт. Но иногда нужен образ чистой системы с нужными параметрами, которого нет в списке образов. Тогда единственный выход — сделать свой AMI.

В официальной документации описан способ создания «instance store-backed AMI». Минус такого подхода заключается в том, что готовый образ нужно будет ещё и сконвертировать в «EBS-backed AMI»

О том, как создать свой EBS-backed AMI в облаке Amazon без промежуточных шагов, пойдёт речь в этой статье.

Доброго времени суток!

Вряд ли сейчас можно найти IT-ишника, который не слышал о системе управления версиями Git и популярном хостинге GitHub. Многие активно её используют как в продакшене, так и для хранения личных наработок и велосипедов. Совсем недавно в их блоге была опубликована статистика за 2012 год.

В последнее время веб-приложения генерируют и потребляют постоянно возрастающие объёмы данных. Для примера: в онлайн-игру на старте могут играть всего пара тысяч пользователей, нагрузки на БД небольшие, и с ними справляется один сервер. Но, с ростом популярности игры, количество пользователей может быстро увеличиться до миллионов, а нагрузка на БД — до десятков, сотен тысяч операций чтения и записи в секунду. В такой ситуации остро встаёт вопрос о масштабировании системы хранения данных.

В январе 2012 Amazon запустил в своём облаке сервис Dynamo DB. Это NoSQL база данных, которая позволяет решить проблемы масштабирования и производительности. Теперь этот сервис доступен и в Южно-Американском регионе.

Всем привет!

Скорее всего все слышали о Memcached — open source распределённой системе кеширования объектов в оперативной памяти. Но, чтобы её использовать, Вам нужно иметь свой сервер, на который нужно установить Memcached, настроить и затем поддерживать в рабочем состоянии.

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

Сегодня стало известно о том, что появилось 4 новых типа инстансов ElastiCache.

Доброго времени суток!


Сегодня стала известна ещё одна хорошая новость от Amazon Web Services: теперь каждый EBS-диск обеспечивает производительность в 2000 IOPS (это в два раза больше предыдущего лимита в 1000 IOPS).



Если производительности диска в 2000 IOPS Вам мало, то EBS-диски можно объединить в RAID-массив, получив тем самым необходимое количество операций ввода/вывода.

Здравствуйте!

В этой статье я хочу рассказать об автоконфигурации в облаке. Для примера запустим ec2-инстанс, на котором «приготовится» WordPress.

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