#AWS

🛠️📦☁️ Сьогодні повідаю про мало відомий, але дуже корисний сервіс 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. Тож і вам раджу.

Сьогодні не те щоб найцікавіші функції, яких в кожному проєкті вистачає. (Хоча гарно, що простий CRUD на Swift UI робиться без зайвих перешкод.) Тому розкажу про іншу цікаву знахідку.

На вихідних одна AWSLambda накрилася та почала замість 15 секунд тривати 15 хвилин, тобто вилітати за браком часу. Лямбда ця запускається за розкладом та перекачує дані з Kafka ще кудись. Ніяких підстав бути такою повільною в неї не було.

В Кафки особливий підхід до споживачів, а саме: щоб уникнути повторної обробки даних, споживачі в групі ділять між собою потік задач. (Саме для того потоки — теми - topic діляться на розділи - partition.) А це своєю чергою значить, що коли споживач уходить, або зʼявляється новий, Кафка негайно виконує перебалансування групи. А якщо споживач просто відвалився, то щоб переконатися в його відсутності потрібний ще й тайм-аут. (Тому важливо завжди виходити з групи ввічливо.)

(До речі, це значить, що лямбди — не краще поєднання з Кафкою; сталий сервіс однозначно природніше. Втім, в моєму випадку на цілий сервіс задач було мало.)

Що, гадаю вийшло: в якийсь момент чергова лямбда “спіткнулася” - можливо, в Кафці йшли роботи, які самі викликають перебалансування — та зависла. Після того її наздогнала наступна лямбда, та вони почали ділити між собою групу в Кафці. Далі почався каскадний ефект: поки старі лямбди запускалися наново, зʼявлялися ще й нові та викликали нове перебалансування, причому кожна з них мала необмежену кількість спроб, тому вони нікуди не зникали, та проблема тривала аж до ручного втручання.

Виявилося, що запуск лямбд за розкладом — не така тривіальна справа. 1)тайм-аут лямбди повинен бути менше за інтервал розкладу - це, думаю, очевидно. 2) в налаштуваннях рівночасності треба вказати 1 рівночасне виконання, щоб уникнути набігання. 3) в налаштуваннях надійності вказати 0 повторних спроб, бо лямбда все одно запуститься за наступним розкладом. 4) там же ж вказати мінімальний вік подій, бо знов-таки немає сенсу обробляти старий розклад, коли завжди буде новий.

Понад рік тому я писав про авторизацію з 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 - суть авторизації абсолютно не змінюється. Класичний патерн адаптера. (Але це не точно).

Трапляється що треба дізнатися повний перелік запущених копій сервісу. Зазвичай щоб встановити між ними синхронізацію чи кворум. На AWS в такому випадку можна не вигадувати педальників, а скористатися готовим сервісом AWS Cloud Map.

Воно звучить страшно, але насправді технічно досить простий сервіс — це лише приватний (або навіть публічний) сервер DNS, з автоматичною реєстрацією копій сервісу. От в цій автоматичній реєстрації вся суть.

Тобто можна у сервісі ECS вказати область імен AWS Cloud Map, та він буде там реєструвати кожну нову задачу. А взагалі AWS Cloud Map підтримує практично всі різновиди сервісів в AWS - від EC2 до Lambda.

На виході отримуємо локальне імʼя вузла (myservice.local), яке можна через локальний DNS розвʼязати у список активних копій. Ну є ще API DiscoverInstances, але мені ним не доводилося користатися.

Бо виявлення копій через DNS це доволі типовий сценарій, тоді достатньо вказати в конфігурації то локальне імʼя та решту сервіс робить самостійно. І не треба ніяких редісів, куди ми пишемо під час запуску, а потім ще й переклик робимо, щоб не було зомбі.

Все це трохи нагадує домашній mDNS, але не дуже. Бо хоч Cloud Map так само надає можливість перелічити сервіси, та відбувається це через центральний сервіс. Інакше в хмарі складно було б уявити.