Amazon Web Services *

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

День добрый, дорогие Хабра-пользователи!

Сегодня хотелось бы поговорить об активно набирающей обороты технологии в мире ИТ — об одной из облачных технологий, а именно – о бессерверной архитектуре приложений (БСА – Serverless). В последнее время облачные технологии набирают все большую популярность. Это происходит по простой причине – лёгкой доступности, относительной дешевизны и отсутствию начального капитала – как знаний для поддержания и развёртывания инфраструктуры, так и денежного характера.

Технология Serverless становится все более и более популярна, но почему-то очень мало освещается в ИТ индустрии, в отличие от других облачных технологий, таких как IaaS, DBaaS, PaaS.

Мир не идеален. В любой момент что-то может пойти не так. К счастью, большинство из нас не запускает ракеты в космос и не строит самолеты.

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

В первой части этой серии статей вы узнали о данных и о том, как можно использовать компьютеры чтобы добывать смысловое значение из крупных блоков таких данных. Вы даже видели что-то похожее на большие данные у Amazon.com середины девяностых, когда компания запустила технологию для наблюдения и записи в реальном времени всего, что многотысячная аудитория клиентов одновременно делала на их сайте. Довольно впечатляюще, но назвать это большими данными можно с натяжкой, пухлые данные — больше подойдёт. Организации вроде Агентства национальной безопасности США (NSA) и Центра правительственной связи Великобритании (GCHQ) уже собирали большие данные в то время в рамках шпионских операций, записывая цифровые сообщения, хотя у них и не было простого способа расшифровать их и найти в них смысл. Библиотеки правительственных записей были переполнены наборами бессвязных данных.

То, что сделал Amazon.com, было проще. Уровень удовлетворённости их клиентов мог быть легко определен, даже если он охватывал все десятки тысяч продуктов и миллионы потребителей. Действий, которые клиент может совершить в магазине, реальный он или виртуальный, не так уж много. Клиент может посмотреть что в доступе, запросить дополнительную информацию, сравнить продукты, положить что-то в корзину, купить или уйти. Всё это было в пределах возможностей реляционных баз данных, где отношения между всеми видами действий возможно задать заранее. И они должны быть заданы заранее, с чем у реляционных баз данных проблема — они не так легко расширяемы.

Заранее знать структуру такой базы данных — как составить список всех потенциальных друзей вашего неродившегося ребенка… на всю жизнь. В нём должны быть перечислены все неродившиеся друзья, потому что как только список будет составлен, любое добавление новой позиции потребует серьезного хирургического вмешательства.

В этой статье я планирую описать процесс создания и деплоя в AWS лямбда-функции, которая будет вызывать нативный код из С++ аддона. Как вы сможете увидеть, этот процесс не сильно отличается от создания обычной AWS Lambda функции на Node.js — вам лишь нужно настроить своё окружение в соответствии с требованиями AWS.

Что такое AWS Lambda?

Цитируя документацию:

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

• Как событийно-ориентированный вычислительный сервис, когда AWS Lambda запускает ваш код при возникновении некоторых событий, таких как изменение данных в Amazon S3 или таблице Amazon DynamoDB.
• Как вычислительный сервис, который будет запускать ваш код в ответ на HTTP-запрос к Amazon API Gateway или запросам от AWS SDK.

AWS Lambda — очень крутая платформа, но поддерживает всего несколько языков: Java, Node.js и Python. Что же делать, если мы хотим выполнить некоторый код на С++? Ну, вы определённо можете слинковать код на С++ с Java-кодом, да и Python умеет это делать. Но мы посмотрим, как это сделать на Node.js. В мире Node.js интеграция с кодом на С++ традиционно происходит через аддоны. Аддон на С++ к Node.js представляет собой скомпилированный (нативный) модуль Node.js, который может быть вызван из JavaScript или любого другого Node.js-модуля.

Amazon Web Services позволяют очень быстро производить прототипирование простых веб-приложений, и написать API, допустим, для простого мобильного приложения можно за считанные минуты. Мы будем использовать связку DynamoDB и API Gateway (без Lambda-функций!) для настройки GET и POST запросов к базе с возможностью чтения, записи и изменения данных в ней.

Cloudwatch Log это сервис AWS в который приложения или Bash скрипты могут отправлять данные в виде строк или JSON, потом их можно найти или построить различные графики средствами того же AWS.

Как то раз у меня возникло желание получить данные из AWS Cloudwatch Log, обработать их особым образом и красиво представить в виде графика. Google Spreadsheet хорошо справляется с визуализацией данных, и ранее для подобных задач я загружал в него данные используя Ruby. Но тот же ruby скрипт нужно где-то хостить и периодически запускать, а все что он будет делать это запрашивать данные из одного API (AWS) и ложить их в другой (Spreadsheet). Хорошо бы, если бы Spreadsheet сам мог бы запрашивать данные, и оказывается он может, используя Google Script. Удивительно, сколько всего на самом деле умеют гугл доки.

Google Script позволяет не только создавать пользовательские функции и макросы используя JavaScript, но и обращаться к внешнему API.
У AWS есть SDK под JavaScript, так что я не ожидал никаких сложностей, но не тут то было. Оказалось, что этот SDK будучи импортированным в проект GS не может найти объект «window» и не работает.

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

С февраля месяца 2016 года сервис AWS Lambda получил возможность доступа к ресурсам внутри Virtual Private Cloud, но по умолчанию все лямбды работают вне VPC. Поскольку эта возможность появилась относительно недавно и статей, как это реализовать, не так много, мы хотели бы поделиться с вами своим опытом.

Официальная документация Laravel достаточно подробно описывает установку веб-приложения и сопутствующих процессов-работников, но что если я хочу развернуть продукт в среде AWS Elastic Beanstalk?

Как оказалось, об этом практически нет статей в Интернете, нет готовых пакетов на Packagist, нет упоминания в документации.

Эта статья не только покажет как можно легко и просто запустить планировщик и обработчик очередей в AWS, но также в очередной раз докажет, что Laravel очень легко расширяется.

Сразу после своего 10-летнего юбилея компания AWS провела в ИТ-парке AWSome Day – наш технопарк оказался в числе тех счастливчиков, где прошел бесплатный учебный курс по облачным технологиям AWS. Воспользовавшись случаем, мы взяли интервью у Сергея Раковского, менеджера AWS по работе с клиентами в России и СНГ.

Управление виртуальным хостингом — это сложная, но интересная в реализации задача, которая постоянно сопряжена с различными трудностями.

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

Поэтому я хотел бы поделиться историей успеха одного из наших клиентов, демонстрирующей, как можно использовать Amazon Route 53 в виртуальном хостинге.

Если Вам не очень повезло, и на работе нет n-ядерного монстра, которого можно загрузить своими скриптами, то эта статья для Вас. Также если Вы привыкли запускать скрипты на всю ночь (и утром читать, что где-то забыли скобочку, и 6 часов вычислений пропали) — у Вас есть шанс наконец познакомиться с Amazon Web Services.



В этой статье я расскажу, как начать работать с сервисом EC2. По сути это пошаговая инструкция по полуавтоматической аренде спотового инстанса AWS для работы с Jupyter-блокнотами и сборкой библиотек Anaconda. Будет полезно, например, тем, кто в соревнованиях Kaggle все еще пользуется своим игрушечным маком.

Под конец прошлого года компания Amazon выпустила (наконец-то!) C++ SDK для своей платформы AWS. Непонятно, почему так долго тянули — есть масса приложений, написанных на С++, из которых давно хотелось удобно пользоваться AWS. Не джавой же единой, в самом деле.

Всегда интересно посмотреть на что-то, написанное на С++ в наши дни с нуля, без груза обратной совместимости и странных архитектурных решений, присущих некоторым разработкам прошлого. Я не буду тут пересказывать документацию, но остановлюсь на ключевых моментах, определяющих всё поведение SDK.

9 февраля компания Amazon представила и выложила в открытый доступ бета-версию своего 3D-движка Lumberyard.

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Разработчик и системный архитектор Михаель Виттиг (Michael Wittig) написал в блоге Cloudonout интересный материал о наиболее распространенных ошибках при работе с сервисом AWS (Amazon Web Services). Мы представляем вашему вниманию основные тезисы этой заметки.

Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV), использующих облако Microsoft Azure. В этом выпуске мы продолжим рассказ про платформу компании Jelastic темой автоматической миграции контейнеров между ЦОДами. Предыдущие статьи цикла вы всегда можете найти по ссылке #isvcloudstory. — Владимир Юнев

Умное управление Jelastic позволяет унифицировать и агрегировать различные комплекты оборудования от разных ЦОДов в рамках единой установки облачной платформы. Такие ДЦ, представленные в виде отдельных регионов окружений, могут быть выбраны в качестве местоположения для окружающей среды при его создании.

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

Автономия – вы избавитесь от необходимости обслуживания у одного лишь поставщика и повысите эффективность использования ЦОДов, обеспечивая низкую задержка в обработке данных для конечных клиентов через обширную сеть гео-распределения;

Гибридность – унификация частных и общедоступных облаков обеспечивает эффективность нагрузок, позволяя получить более высокую производительность с меньшими затратами;

HA и DR – приобретение повышенной отказоустойчивости и исключение рисков, связанных с простоем сервисов.

Указываем в скрипте путь на книгу в txt — на выходе получаем папку с озвучкой хорошим синтезом.

Всем привет.
Наступил новый 2016 год, а значит пора обновить инструменты для упрощения скучной механической работы. Отделы аналитики, маркетинга, продаж часто сталкиваются со следующими трудностями при обновлении отчетности:
1. Данные приходится собирать воедино из нескольких источников.
2. Отчеты составляются в Excel, что накладывает значительные ограничения на объем обрабатываемых данных.
3. Внесение изменений в заранее настроенные разработчиками выгрузки дело как правило не самое быстрое.

Если отчеты нужно обновлять еженедельно или даже ежедневно, то эта процедура становится весьма напряжной даже для самых терпеливых. С помощью надстройки Excel Power Query и записи данных в MySQL можно свести обновление большинства отчетов до простого нажатия кнопки «Обновить»:
1. Данные из любого количества источников импортируются через SQL-запросы в обычные таблицы Excel.
2. Даже из большой базы можно записывать в Excel только небольшую часть данных (например, итоговые суммы за нужный диапазон дат с группировкой только по нужным столбцам).
3. Изменения в отчет можно вносить просто поменяв SQL-запрос. Далее формируем нужный отчет стандартными средствами Excel.

В этой статье я покажу как настраивать и автоматически заполнять простые базы данных MySQL (на примере выгрузки статистики всех ключевых слов из Яндекс Метрики), а потом одной кнопкой обновлять отчеты в Excel, используя надстройку Power Query. Power Query имеет весьма странные особенности работы при составлении SQL-запросов (особенно динамических), которые мы разберем во второй части статьи.

При работе с облаком Amazon, часто приходится выполнять много рутинных операций через Web консоль. Но хочется их автоматизировать.
AWS CLI, интерфейс командной строки, хорошо для этого подходит. Конечно, можно написать и приложение на Scala, но в повседневных задачах лучше обойться без «тяжелой артиллерии».
Команды AWS умеют возвращать данные в разных форматах, в том числе и в json. Можно воспользоваться bash и jq, но последнего нет в репозитарии cygwin, а руками устанавливать лень. Между тем в PowerShell есть прекрасная поддержка json! Правда оказалось, что воспользоваться этим не совсем просто.

Независимый специалист по безопасности Уэсли Вайнберг (Wesley Wineberg) подвергся серьёзному давлению со стороны компании Facebook. Она не заплатила за найденные уязвимости на сервере Instagram, да ещё угрожает судебным иском.

Уэсли обнаружил уязвимость в инфраструктуре Instagram, с помощью которой нашёл (и, возможно, скачал) практически всё ценное, что есть на серверах Instagram: исходный код последней версии, SSL-сертификаты и приватные ключи для Instagram.com, ключи для подписи куков аутентификации, учётные данные от почтового сервера и ключи для некоторых других продуктов, в том числе для подписи мобильных приложений под iOS и Android.