Amazon Web Services

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

Мой рабочий компьютер - Macbook Air 2020 (Intel), и его вполне хватает для написания кода и прочих задач. Однако, когда потребовалось смонтировать небольшой видеоролик, выяснилось что мощи моего ноута катастрофически не хватает, и я стал искать варианты.

Облачные провайдеры — это реактор, где вместо обогащённого урана используется твой кошелёк. В позапрошлом году наша компания начала активно применять облака и мы в полной мере ощутили это на себе: несколько команд разрабатывали отдельные продукты, и для большинства тестов запускались виртуальные мощности в AWS. Мы с коллегами получили сертификаты от Amazon, и это, вместе с наглядностью происходящего, Free Tier и Soft Limit’ами, создавало ложное чувство спокойствия за свой бюджет. А когда этому чувству поддаёшься, получаешь локальный Чернобыль. Под катом я расскажу, как решил эту проблему c помощью serverless-функций.

Мое приложение на 100% serverless, и я всегда умещался в уровень бесплатного использования, так что просто игнорировал затраты. Но затем мне пришел счет на 62$.

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

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

Проблематика

Без каких-либо процессов автоматизации управления инфраструктурой вы неизбежно столкнетесь с известными ограничениями: невозможно быстро пересоздать инфраструктуру; нет истории изменений, произведенных в инфраструктуре; нет контроля используемых версий ПО…

Без API не обходится ни одно веб-приложение. Для их разработки используются разные методы. Сейчас, например, набирает популярность бессерверный подход — он экономичный, масштабируемый и относительно простой. Как ведущий провайдер бессерверных вычислений Amazon Web Services (AWS) вносит огромный вклад в бессерверную разработку. Здесь мы обсудим общие концепции реализации API с помощью AWS Lambda и других сервисов AWS.

Terraformer — консольный инструмент для генерации кода и стейта в форматах HCL и json для уже существующей инфраструктуры.

Облачные вычисления так популярны по нескольким причинам: они гибкие, относительно дешевые по сравнению с поддержкой внутренней инфраструктуры и позволяют отлично автоматизировать распределение ресурсов (и тут тоже экономия). Когда объем обрабатываемых данных растет из года в год, нельзя полагаться на вертикальную масштабируемость, покупая все более и более дорогие серверы. Данные должны быть распределены по нескольким более дешевым системам (кластерам), где могут надежно храниться, обрабатываться и возвращаться к пользователю при необходимости. Создание таких систем — непростая задача, но, к счастью, есть решения, которые отлично вписываются в облачную архитектуру. Я говорю об Apache Ignite.

Подготовка среды

Я собираюсь использовать AWS-облако для развертывания кластера Ignite. Для целей обучения нам хватит бесплатных машин базового уровня (AWS free tier). Я выбрал образ Ubuntu 18.04, но в целом это неважно. Перед развертыванием первых машин нам надо настроить группу безопасности (Security Group). В ней должны быть определены сетевые правила для портов, необходимых для узлов Ignite.


Рисунок 1 – Конфигурация Security Group

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

Пошаговая инструкция по созданию и деплою статического сайта в облако, прикрутке к нему сертификата Let’s Encrypt, домена второго уровня и настройки API-шлюза.

В этой статье поговорим о нюансах использования Terraform от HashiCorp, в частности о том, как использовать Terraform при управлении несколькими аккаунтами Amazon Web Services (так делают все чаще — из-за размера организации или предпочтений команды DevOps). По сути, AWS сами намекают клиентам, что неплохо было бы использовать несколько аккаунтов, и недавно даже выпустили для этого несколько сервисов.

«Мы прогнозируем, что использование serverless будет стремительно расти. Мы также прогнозируем, что локальные гибридные облачные приложения со временем будут сокращаться, хотя некоторые развертывания могут сохраняться из-за нормативных ограничений и правил управления данными.

Бессерверные вычисления станут стандартной вычислительной парадигмой в эпоху облаков, в значительной степени, заменив серверные вычисления и тем самым закрыв эру клиент-сервер."

Cloud Programming Simplified: A Berkeley View on Serverless Computing, February 10, 2019

С публичного релиза AWS Lambda прошло ни много ни мало 6 с лишним лет. Реактивные функции, реагирующие на события, не только позволили по-другому смотреть на архитектуру систем и приложений, но и породили новый buzzword Serverless.

Мотивом к написанию этой статьи служит пост в блоге Netflix. Прочитав его, а так же комментарии русскоязычной аудитории, я прихожу к выводу, что направление "бессерверных вычислений" еще не обкатано вдоль и поперек (как и в англоязычной тусовке, чего греха таить), и неплохо бы проитерироваться по этой теме еще раз.

Публикуем сессию вопросов и ответов о работе с AWS и другими cloud-провайдерами. Сессия прошла в рамках вебинара «Создание эффективной инфраструктуры при помощи облачных решений». На Youtube есть запись вебинара, а в блоге мы уже размещали текстовую расшифровку доклада.

Спикер вебинара Александр Волочнев (Developer Advocate в DataStax Inc.) и Всеволод Севастьянов (TechLead в vene.io) ответили на вопросы о прайсе и правах в AWS, рассказали, как защитить данные и в каких ситуациях лучше выбрать российских облачных провайдеров.

Архитекторы и проектировщики решений, а также все, кто желает ими стать! Нам («Сетевой Академии ЛАНИТ») нужна ваша помощь. Мы в поиске новых направлений для развития, и один из вариантов – авторизованные курсы по облачным технологиям Amazon. Расскажите, будет ли вам интересно такое обучение.


Architecting on AWS – это курс об основах создания ИТ‑инфраструктуры на платформе AWS. В ходе обучения вы научитесь оптимизировать облако AWS, проектировать оптимальные ИТ-решения на AWS и создавать различные инфраструктуры. Будем рады пожеланиям и предложениям в комментариях. Давайте обсудим.

Публичные облака появились как ответ на мучения компаний, которые поддерживали парк собственных серверов. Слишком много проблем возникало с заказом оборудования, его настройкой и поддержкой, поэтому облачные вычисления быстро стали востребованными — так считает Александр Волочнев, Developer Advocate в DataStax и автор видеокурса по AWS в «Слёрме». 

Боли сисадминов и бизнеса, а также возможности, которые принесли им облака, Александр Волочнев подробно описал на вебинаре «Создание эффективной инфраструктуры при помощи облачных решений». Запись вебинара есть на YouTube, здесь публикуем краткую выжимку.

Эта небольшая история — живое свидетельство того, как самые простые решения (иногда) могут оказаться очень эффективными. В одном из проектов руководство взяло курс на оптимизацию бюджета на инфраструктуру. В результате анализа всех статей расходов стало очевидным, что заметно выдаются счета за сетевой трафик из Amazon S3-бакета, где хранится публичная статика веб-приложения. Так появилась задача найти и реализовать максимально недорогой и решающий бизнес-задачу способ.

Если вы используете в облачных провайдерах managed-инсталляции серверных служб вроде RDS или ElastiCache от AWS, то несомненно задавались темой мониторинга инфраструктуры, а главное — оповещений по произошедшим инцидентам. При реализации возникают понятные вопросы: Как можно настроить сбор данных с endpoint’ов в систему мониторинга? Если использовать Prometheus, то какие экспортеры использовать и где их можно запускать? Какие есть варианты готовых алертов для покрытия основных причин аварий/частичной недоступности?

Эта статья в большей степени рассчитана на начинающих инженеров: на примере Prometheus и CloudWatch мы рассмотрим одно из самых простых и понятных решений с помощью cloudwatch_exporter и prometheus_aws_cost_exporter в AWS, напишем для них Helm-чарт и задеплоим его в Kubernetes. (K8s будет выступать удобной площадкой для разворачивания экспортеров.) А также посмотрим, как можно мониторить текущие и ежедневные затраты всей вашей инфраструктуры.

Айдар присоединился к EPAM Anywhere в качестве DevOps-инженера полтора года назад, и за это время прошел несколько программ сертификации, какое-то время был на бенче, сменил два проекта, а сейчас работает в двух проектных группах.

Айдар стремится стать экспертом по облачным технологиям, поэтому он посвящает много времени изучению сервисов AWS, Azure и GCP. Теперь Айдар уже является одним из самых сертифицированных профессионалов EPAM и делится своей историей.

Простая мотивирующая история с полезными ссылками.

Translation of this article written by John Armstrong on Jan 20, 2021

Вступая в новый год, самое время поразмышлять о достижениях компании Tigera и о том, насколько  Calico Enterprise изменилась за последний год и как она стала ведущим решением в сфере безопасности и мониторинга сетей и микросервисов Kubernetes. Опыт работы с пользователями корпоративного класса помог Tigera определить наиболее важные требования пользователей для успешного развертывания кластеров Kubernetes и успешного перехода от пилотных проектов к промышленным проектам. Эти знания помогли Tigera создать систему Calico Enterprise, архитектура которой и представлена ниже. Давайте рассмотрим этот многофункциональный слоёный пирог, снизу вверх.

Архитектура корпоративных решений Calico: