Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
Пости з тегом #AWS
30.08.2022
AWS Parameter Store - сервіс для зберігання налаштувань і секретів
🛠️📦☁️ Сьогодні повідаю про мало відомий, але дуже корисний сервіс
AWS Parameter Store. Якщо ви мешкаєте у AWS-і, то це найзручніший спосіб зберігати налаштування та секрети до вашого
коду. Ось кілька фактів про нього:
- У технічному сенсі Parameter Store це key-value база даних, у якій дані - це рядки, а ключі
організовані у ієрархію на кшталт файлової системи (або кращий приклад - S3).
- Для рядків до 4 КБ він абсолютно безкоштовний. Рядки від 4 КБ до 8 КБ трошки коштують (у нас з
таких тільки TLS-сертифікати.) 8 КБ - це максімум.
- Керування доступом здійснюється засобами IAM та спирається на ієрархію. Тобто, можна надати доступ
до якогось під-дерева. Саме так ми й робимо - у кожного сервісу свій префікс до свого дерева
конфігурації.
- Окрім обмеження доступу, дані також можна шифрувати ключами KMS, що ми робимо для всіляких
секретів.
- Само собою, параметри можна створювати за допомогою Terraform, як ми й робимо для параметрів, що
походять з інфраструктури та "склеюють" сервіси, наприклад, їхніх адрес.
- Звісно, параметри можна отримати через API, але ще AWS ECS може передавати їх у змінні оточення
(зручно це чи ні - залежить від обставин проєкту.).
- AWS веде облік версій параметрів, з датою та автором зміни. Інколи це дуже корисно.
Ми Parameter Strore широко використовуємо, тому наші
rubygem та
go package
вміють завантажувати параметри у вкладену структуру JSON. Тож і вам раджу.
10.12.2024
Дев-адвент 10: редагування тегів... та AWS Lambda
Сьогодні не те щоб найцікавіші функції, яких в кожному проєкті вистачає. (Хоча гарно, що простий CRUD на Swift UI робиться без зайвих перешкод.) Тому розкажу про іншу цікаву знахідку.
На вихідних одна AWSLambda накрилася та почала замість 15 секунд тривати 15 хвилин, тобто вилітати за браком часу. Лямбда ця запускається за розкладом та перекачує дані з Kafka ще кудись. Ніяких підстав бути такою повільною в неї не було.
В Кафки особливий підхід до споживачів, а саме: щоб уникнути повторної обробки даних, споживачі в групі ділять між собою потік задач. (Саме для того потоки — теми - topic діляться на розділи - partition.) А це своєю чергою значить, що коли споживач уходить, або зʼявляється новий, Кафка негайно виконує перебалансування групи. А якщо споживач просто відвалився, то щоб переконатися в його відсутності потрібний ще й тайм-аут. (Тому важливо завжди виходити з групи ввічливо.)
(До речі, це значить, що лямбди — не краще поєднання з Кафкою; сталий сервіс однозначно природніше. Втім, в моєму випадку на цілий сервіс задач було мало.)
Що, гадаю вийшло: в якийсь момент чергова лямбда “спіткнулася” - можливо, в Кафці йшли роботи, які самі викликають перебалансування — та зависла. Після того її наздогнала наступна лямбда, та вони почали ділити між собою групу в Кафці. Далі почався каскадний ефект: поки старі лямбди запускалися наново, зʼявлялися ще й нові та викликали нове перебалансування, причому кожна з них мала необмежену кількість спроб, тому вони нікуди не зникали, та проблема тривала аж до ручного втручання.
Виявилося, що запуск лямбд за розкладом — не така тривіальна справа. 1)тайм-аут лямбди повинен бути менше за інтервал розкладу - це, думаю, очевидно. 2) в налаштуваннях рівночасності треба вказати 1 рівночасне виконання, щоб уникнути набігання. 3) в налаштуваннях надійності вказати 0 повторних спроб, бо лямбда все одно запуститься за наступним розкладом. 4) там же ж вказати мінімальний вік подій, бо знов-таки немає сенсу обробляти старий розклад, коли завжди буде новий.
24.05.2025
Google Workload Identity Federation... на ECS
Понад рік тому я писав про авторизацію з AWS до GCP. ЇЇ не так важко налаштувати та працює вона відмінно. Без жодного секрету, тільки з правильним файлом credentials.json. Але нещодавно дізнався, що є нюанс: не у всіх середовищах.
Всередині клієнту Google потрібні ключі доступу до AWS. (Щоб побудувати підпис — далі вони не йдуть.) В простому випадку код авторизації (ось на Go) шукає ключі в змінних оточення.
Якщо мовити про виконання в AWS, то ключі в оточенні знайдеш тільки в AWS Lambda. Тому що ключі ці завжди тимчасові. Та тільки Lambda теж настільки ефемерна, що її час існування не перебільшує терміну дії ключів.
А в інших місцях — на EC2 та на Fargate - є спеціальні HTTP API для отримання тимчасових ключів. Різні. Та клієнт Google вміє читати ключі тільки з EC2 Metadata API. Буквально — в їхній реалізації немає згадки про Fargate.
(До речі: намагався знайти офіційне посилання на документацію по цьому Fargate API, та знайшов тільки згадку в документації по SDK. Тобто технічно цей API… незадокументований? Таємний? Це багато пояснює.)
(Взагалі, а чому вони не використовують для цього AWS SDK, в якому вже реалізовані універсальні методи отримання ключів? Включаючи, звісно, читання з цього самого API? Політика?)
Отже, як вийти з цих обставин? Ну я знайшов дикий, але дієвий та універсальний спосіб: підробити EC2 Metadata API, а точніше, його частину, до якої звертається клієнт Google. На щастя, в credentials.json є посилання на той API, отже, його можна підмінити на наш власний. А власному залишається просто читати тимчасові ключі з Fargate API та віддавати за EC2 API - суть авторизації абсолютно не змінюється. Класичний патерн адаптера. (Але це не точно).