Инфраструктура платформ облачных веб-сервисов
Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.
Одной из задач администрирования облачной инфраструктуры является мониторинг её компонентов: важно знать о неправильной работе облака, вовремя выявлять и исправлять ошибки конфигурации. Управлять облаком 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 для уже существующей инфраструктуры.
В нашем мире мобильных гаджетов, сфокусированных на приложениях, уже не принято говорить о веб-сайтах. Классические веб-сайты служат в основном для информационных целей, а для работы с целевой аудиторией бизнес нуждается в веб-приложениях. И тут неизбежно встает вопрос о том, где эти веб-приложения могут работать максимально надежно, быстро и эффективно с точки зрения затрат. Выбор возможных решений достаточно велик и мы рассмотрим достоинства и недостатки некоторых из них ниже. Но все же, забегая вперед, можно с уверенностью сказать, что облачные решения в настоящее время являются наиболее оптимальными.
Пошаговая инструкция по созданию и деплою статического сайта в облако, прикрутке к нему сертификата 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 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 и делится своей историей.
Простая мотивирующая история с полезными ссылками.