Amazon Web Services *

В одном из проектов встала следующая задача: пользователь загружает пачку файлов через клиента (CloudBerry Explorer, к примеру) в S3 бакет, мы копируем эти файлы в архив и шлем SNS уведомление о том, что все сделано. Перекладывать файлы в архив нужно начинать только тогда, когда пользователь загрузит все, что хотел. Пользователей мало и загружают батчи они довольно редко. Но файлов может быть много.

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

<batch_name>/done.trigger
<batch_name>/files/<file_key_1>
<batch_name>/files/<file_key_2>
...
<batch_name>/files/<file_key_n>

Как видим, для каждой пачки создается свой каталог <batch_name> с подкаталогом files, в который и заливаются уже пользовательские файлы с каталогами и именами, которые он хочет. Триггер-файл загружается в <batch_name> и по ключу этого  файла можно понять какие конкретно файлы нужно отправить в архив. Но здесь есть один нюанс, мы хотим при копировании в архив вырезать каталог files. Т.е. файл <batch_name>/files/<file_key_1> скопировать в <batch_name>/<file_key_1>.

К счастью, S3 позволяет отслеживать загрузку файлов с определенным суффиксом и отправлять уведомления при наструплении этого события. В качестве получаетеля этих уведомлений можно указать аж 3 сервиса: SNS, SQS и Lambda-функцию. Но тут не без нюансов. Так, первые 2 типа поддерживают только стандартные очереди и SNS, а FIFO не поддерживают, увы.

Всем привет!

Сегодня я хотел бы поделиться опытом настройки AWS Auto Scaling Group (ASG) на основе использования оперативной памяти (RAM).

Всё началось с того, что на одном из проектов нам понадобилось настроить масштабирование EC2-инстансов по использованию памяти, а стандартный ASG Target Tracking Scaling Policy позволяет создавать политики только на основе следующих метрик: среднее использование ЦПУ, средний входящий или исходящий сетевой траффик и количество запросов на цель ALB...

Всем привет!

 Теперь настал черед поделиться с информацией о том, как я готовился и сдавал экзамен AWS Certified DevOps Engineer – Professional, это мой третий сертификат по AWS, о том, как я готовился и сдавал экзамен Solutions Architect – Associate можете прочитать тут, а о Security Specialty более подробно тут.

Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным инструментам, в том числе и к базам данных. Создатели находят этим инструментам применение в распределённых приложениях и микросервисах, где важна скорость разработки и возможность масштабирования. 

Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.

Всем привет!

Сегодня я бы хотел поделиться с вами информацией о том, как я готовился и сдавал экзамен AWS Certified Security – Specialty. Это мой второй сертификат, о том, как я готовился и сдавал экзамен AWS Certified Solutions Architect – Associate можете прочитать тут.

Начну с того, почему я выбрал именно эту сертификацию.

Миграция платежной системы в облако: Зачем и стоит ли?

Привет! Наша компания занимается разработкой платформы для процессинга электронных платежей. Платформа предоставляется в аренду по White-label модели другим компаниям, которые хотят начать бизнес в области процессинга электронных платежей, при этом получив ряд “плюшек”:

- быстрый запуск;

- готовая PCI DSS ready инфраструктура;

- дополнительная поддержка, в том числе при прохождении аудита PCI DSS;

- брендирование;

- гибкая цена.

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

Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.

Данная статья будет полезна тем, кто хочет начать работать с очередями сообщений или хочет перевести работающий проект с зарубежных облачных сервисов, либо с сервисов обслуживаемых собственными силами. В данной статье не будут затронуты вопросы: "Что такое очереди сообщений?", "Для чего нужны очереди сообщений?" и прочие вопросы, ответов на которые очень много на хабре и других ресурсах причем на различных языках. Зато в этой статье вы найдете демо-проекты позволяющие быстро попробовать минимальный функционал, информацию о работе с облачными российскими сервисами очередей с помощью популярных библиотек, ну и описание проблем, которые у меня возникли.

Всем привет!

 Меня зовут Сергей Яворский. Я работаю в EPAM Systems около 5 лет. Я хотел бы поделиться своим опытом в получении сертификатов AWS. На данный момент у меня их три, в этом посте я хочу рассказать о своем процессе участия в программе сертификации AWS Solution Architect Associate SAA-C02 в рамках AWS Global Certification Program от EPAM.

 Сначала хотел бы немного пояснить, зачем мне это понадобилось. У меня было две цели:

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

Я расскажу, как мы в Plesk сократили расходы на AWS-инфраструктуру одного из наших сервисов без применения уличной магии.

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

Изображения играют важную роль в продаже авторских туров. Когда стартап в сфере туризма, маркетплейс авторских туров YouTravel.me начал обрабатывать 2,5 млн запросов на картинки и отдавать 50 GB в сутки, команда разработки задумалась, как хранить изображения, чтобы они не теряли качество, и при этом не тратить космические бюджеты.

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

Сами по себе экзамены и сертификаты не несут в себе ничего отрицательного, негативные моменты будут рассмотрены ниже, начнем с позитивных и очевидных:

Привет, Хабр! Сегодня мы поговорим немного о DevOps и самоорганизации.

Мы начнем с фразы, с которой не соглашается добрая половина разработчиков в индустрии: "каждый разработчик должен быть сам себе DevOps". Кто-то считает, что этим должен заниматься отдельно выделенный человек, чтобы у разработчика оставалась забота только о качестве кода. Мы считаем, что в современных реалиях рынка и избытке инструментов/знаний разработчик должен уметь настроить и обслуживать конвейер быстрой и предсказуемой доставки артефакта в нужную ему среду.

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

В этой статье я представлю вам маленькую историю зарождения DevOps в на примере frontend проекта. Эта история применима как к разработчику-одиночке, так и к большой команде.

Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.

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

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

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

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

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

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

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

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