Завдання

Відповідно до номера свого варіанта виконайте завдання обраного рівня складності.

Варіанти

Варіант 1. Сервіс замовлень кав’ярні

1. Початковий рівень. Створити вебсервіс ASP.NET Core, який приймає замовлення кави (POST /orders з назвою напою) і повертає номер замовлення; написати багатоетапний Dockerfile, зібрати образ, запустити контейнер з публікацією порту й перевірити сервіс запитом curl.

2. Базовий рівень. Створити стенд Docker Compose із сервісу замовлень, брокера RabbitMQ і робітника-бариста: сервіс публікує замовлення в чергу, робітник «готує» напій 1–3 с і записує статус; брокер має healthcheck, сервіси запускаються після його готовності, запит GET /orders/{id} повертає статус замовлення.

3. Високий рівень. Створити стенд Docker Compose кав’ярні (вебсервіс замовлень ASP.NET Core, RabbitMQ, робітники-бариста «готують» напій 1–3 с і записують статус) і консольну програму coffee-load з опціями --orders N, --url і --help, яка надсилає N замовлень і чекає їх виконання. Виміряти час для 1, 2, 4 і 8 робітників (docker compose up --scale), вивести таблицю «робітників – час – замовлень/с – прискорення», перевірити зупинку робітника посеред роботи на втрату й дублювання замовлень; помилки – у потік помилок, коди 0/1/2.

Варіант 2. Обробка фото

1. Початковий рівень. Створити консольну програму-робітника, яка зменшує вхідне зображення (або імітує обробку обчисленням контрольної суми файла) і виводить час; зібрати образ на runtime:10.0-noble-chiseled, надіслати його в локальний реєстр localhost:5001 і запустити в кластері kind як Deployment з однією реплікою.

2. Базовий рівень. Створити в кластері kind Deployment вебсервісу обробки «фото» (імітація: обчислення згортки над масивом пікселів заданого розміру), Service типу NodePort і HorizontalPodAutoscaler від 1 до 6 реплік за процесором; перевірити за допомогою kubectl get hpa -w, що під навантаженням кількість подів зростає.

3. Високий рівень. Розгорнути в kind вебсервіс обробки «фото» (імітація: згортка над масивом пікселів заданого розміру) з HorizontalPodAutoscaler за процесором і створити навантажувальний клієнт photo-load з опціями --tasks, --seconds, --size, --help, який викликає сервіс і кожні 10 с виводить пропускну здатність, затримку й кількість подів, що відповіли. Провести експерименти з цілями HPA 50 % і 80 % та різними limits.cpu, звести результати в таблицю й CSV для графіка.

Варіант 3. Розподілений Монте-Карло

1. Початковий рівень. Створити консольну програму, яка методом Монте-Карло обчислює частину інтеграла ${\int }_0^1\frac{4}{1+x^2}dx$ для номера частини з аргументу, зібрати її образ і запустити контейнер тричі з різними номерами частин.

2. Базовий рівень. Запустити як індексоване завдання Kubernetes (completionMode: Indexed, completions: 8) контейнер консольної програми, яка методом Монте-Карло обчислює частину інтеграла ${\int }_0^1\frac{4}{1+x^2}dx$ за номером частини (JOB_COMPLETION_INDEX); зібрати результати частин з журналів подів командою kubectl logs і вивести підсумкове значення $\pi$ та похибку.

3. Високий рівень. Створити програму mc-runner з опціями --parts, --parallelism, --points, --help, яка генерує маніфест індексованого Job Kubernetes для контейнера, що методом Монте-Карло обчислює частину інтеграла ${\int }_0^1\frac{4}{1+x^2}dx$ за номером частини, застосовує його через kubectl, чекає завершення, збирає результати з журналів і виводить значення $\pi$ та таблицю «parallelism – час – прискорення» для 1, 2, 4, 8 подів (медіана трьох запусків) з поясненням накладних витрат запуску подів.

Варіант 4. Банківські рахунки Orleans

1. Початковий рівень. Створити силос Orleans із зерном банківського рахунку та вебендпоінтом GET /accounts/{id}, зібрати образ і запустити його в контейнері Docker з публікацією порту.

2. Базовий рівень. Створити стенд Docker Compose із двох силосів Orleans із зерном банківського рахунку (вебендпоінт GET /accounts/{id}), кластеризованих через Redis, і Redis для стану зерен; перевірити, що після зупинки одного контейнера силосу баланси рахунків доступні через інший силос.

3. Високий рівень. Розгорнути в Kubernetes кластер силосів Orleans із зернами банківських рахунків (Deployment на 3 репліки, Redis для кластеризації й стану, Service) і написати клієнт bank-check з опціями --accounts, --seconds, --help, який безперервно виконує перекази між рахунками й перевіряє незмінність загальної суми; видалити под силосу й вивести тривалість помилок, кількість невдалих операцій і підсумкову суму.

Варіант 5. Прогноз погоди gRPC

1. Початковий рівень. Створити gRPC-сервіс прогнозу погоди (унарний виклик за назвою міста) і багатоетапний Dockerfile для нього; запустити контейнер і перевірити сервіс консольним клієнтом.

2. Базовий рівень. Зібрати образи gRPC-сервісу прогнозу погоди (унарний виклик за назвою міста) на aspnet:10.0, aspnet:10.0-noble-chiseled і aspnet:10.0-alpine, порівняти розміри (docker images), розгорнути chiseled-варіант у kind з пробами readinessProbe і livenessProbe та службою NodePort.

3. Високий рівень. Розгорнути в kind gRPC-сервіс прогнозу погоди (унарний виклик за назвою міста, відповідь містить версію) і виконати його поступове оновлення з версії 1.0 на 1.1 (maxSurge: 1, maxUnavailable: 0). Клієнтом weather-poll з опціями --interval, --seconds, --help безперервно викликати сервіс і вивести кількість відповідей кожної версії та помилок; порівняти результати з preStop і без нього, виконати rollout undo.

Варіант 6. Бібліотечний каталог

1. Початковий рівень. Створити рішення Aspire (AppHost і ServiceDefaults) з вебсервісом каталогу книг, який повертає список книг із пам’яті, запустити його командою aspire run і показати ресурс у дашборді.

2. Базовий рівень. Створити рішення Aspire (AppHost і ServiceDefaults) з вебсервісом каталогу книг і ресурсом PostgreSQL (AddPostgres): рядок підключення передається через WithReference і WaitFor, книги зберігаються в базі даних, сервіс реалізує пошук за автором. Перевірити в дашборді трасування запитів разом зі спанами бази даних.

3. Високий рівень. Створити рішення Aspire з вебсервісом каталогу книг (PostgreSQL) і сервісом видачі книг, який викликає каталог через виявлення сервісів (https+http://catalog) і має власну метрику кількості видач. Згенерувати aspire publish для Docker Compose, розгорнути стенд і написати звіт порівняння згенерованого docker-compose.yaml з написаним вручну.

Варіант 7. Телеметрія IoT

1. Початковий рівень. Створити консольний «датчик», який щосекунди виводить випадкову температуру, зібрати образ і запустити три контейнери з різними ідентифікаторами датчиків через змінну середовища.

2. Базовий рівень. Створити стенд Docker Compose: датчики (сервіс з --scale sensor=5) публікують показники в RabbitMQ, агрегатор обчислює середнє за хвилину й записує в Redis; дані брокера й Redis зберігаються в іменованих томах і переживають docker compose down та up.

3. Високий рівень. Створити стенд Docker Compose телеметрії IoT (датчики публікують випадкові температури в RabbitMQ, агрегатор обчислює середнє за хвилину й записує в Redis, іменовані томи) і сценарій перевірки відновлення (PowerShell або програма iot-chaos з опціями --kill, --seconds, --help), який періодично зупиняє випадковий контейнер агрегатора чи брокера. Звіт виводить кількість надісланих, оброблених і втрачених показників та час відновлення після кожного збою.

Варіант 8. Шкільний розклад

1. Початковий рівень. Створити вебсервіс розкладу уроків, який читає назву школи й кількість уроків зі змінних середовища, і запустити його в kind з ConfigMap, переданою через envFrom.

2. Базовий рівень. Створити вебсервіс розкладу уроків з ендпоінтом GET /schedule/{class} і розгорнути його в kind: розклад зберігається в ConfigMap як файл JSON, змонтований у под томом, а пароль адміністратора – у Secret. Перевірити, що після зміни ConfigMap і kubectl rollout restart сервіс віддає новий розклад.

3. Високий рівень. Створити вебсервіс розкладу уроків (GET /schedule/{class}), розгорнутий у kind з розкладом у ConfigMap, змонтованому як файл, який перезавантажує конфігурацію без перезапуску пода (reloadOnChange) і веде журнал змін. Створити програму schedule-check з опціями --url, --expect, --help, яка вимірює, через скільки секунд після kubectl apply сервіс починає віддавати новий розклад (5 вимірювань, середнє та максимум).

Варіант 9. Рендеринг фракталів

1. Початковий рівень. Створити консольну програму, яка обчислює фрагмент множини Мандельброта (прямокутник пікселів за номером тайла) і зберігає його у файл PGM; зібрати образ і запустити контейнер з томом для результату.

2. Базовий рівень. Запустити як індексоване завдання Kubernetes з parallelism: 4 контейнер програми, яка обчислює тайл множини Мандельброта за номером (16 тайлів) і записує його у файл PGM на спільний том PersistentVolumeClaim, а окремою програмою склеїти тайли в повне зображення.

3. Високий рівень. Створити програму fractal-job з опціями --width, --height, --tiles, --parallelism, --help, яка створює індексований Job Kubernetes, поди якого обчислюють тайли множини Мандельброта на спільний том, чекає завершення, збирає зображення й виводить таблицю часу для різної паралельності та розмірів тайлів з поясненням впливу нерівномірного навантаження тайлів.

Варіант 10. Чат-сервіс

1. Початковий рівень. Створити вебсервіс чату з ендпоінтами POST /messages і GET /messages, що зберігає повідомлення в пам’яті й повертає ім’я хоста; запустити його в Docker і перевірити кількома запитами.

2. Базовий рівень. Створити вебсервіс чату (POST /messages, GET /messages, відповідь містить ім’я хоста) і розгорнути його в kind на 3 репліки зі службою NodePort; показати, що повідомлення, надіслані різним подам, «губляться» при зберіганні в пам’яті, і перенести їх у Redis, щоб усі репліки бачили спільну історію.

3. Високий рівень. Розгорнути в kind вебсервіс чату (POST /messages, GET /messages, історія в Redis, відповідь з іменем хоста) на кілька реплік і створити клієнт chat-bots з опціями --bots, --messages, --help, який імітує одночасних користувачів, перевіряє порядок і повноту історії та виводить розподіл запитів між подами; порівняти результати з keep-alive з’єднаннями й без них і пояснити балансування служби.

Варіант 11. Аукціон

1. Початковий рівень. Створити рішення Aspire з вебсервісом аукціону (створення лота й ставки в пам’яті) і показати в дашборді ресурси, журнали й трасування запиту POST /bids.

2. Базовий рівень. Створити рішення Aspire з вебсервісом аукціону (лоти й ставки), Redis і RabbitMQ: ставки зберігаються в Redis, а подія «нова ставка» публікується в RabbitMQ і обробляється сервісом сповіщень; перевірити в дашборді розподілене трасування від ставки до сповіщення.

3. Високий рівень. Створити рішення Aspire з вебсервісом аукціону (лоти, ставки) з власними метриками через IMeterFactory (лічильник ставок, гістограма сум, кількість активних лотів) і навантажувальний клієнт auction-bots з опціями --bots, --seconds, --help. Скласти звіт зі значеннями метрик із дашборду та перевіркою, що виграшна ставка кожного лота максимальна.

Варіант 12. Кінотеатр

1. Початковий рівень. Створити вебсервіс розкладу сеансів кінотеатру з ендпоінтом GET /version, зібрати дві версії образу (1.0 і 2.0) з різними тегами й надіслати їх у локальний реєстр.

2. Базовий рівень. Реалізувати в kind синьо-зелене розгортання (blue-green) вебсервісу розкладу сеансів кінотеатру з ендпоінтом GET /version: два Deployment (blue з образом версії 1.0 і green з 2.0) і Service, селектор якого перемикається командою kubectl patch; перевірити миттєве перемикання й повернення.

3. Високий рівень. Розгорнути в kind вебсервіс кінотеатру з ендпоінтом GET /version у версіях 1.0 і 2.0 і створити програму switch-check з опціями --url, --seconds, --help, яка під час перемикання версій безперервно запитує сервіс і виводить кількість відповідей кожної версії й помилок. Порівняти синьо-зелене розгортання (перемикання селектора Service) з поступовим оновленням за часом перемикання, помилками й потрібними ресурсами.

Варіант 13. Сортування великих файлів

1. Початковий рівень. Створити консольну програму, яка сортує файл цілих чисел і записує результат; зібрати образ і запустити контейнер із теками вхідних і вихідних даних, підключеними як томи.

2. Базовий рівень. Реалізувати зовнішнє сортування файла цілих чисел у Kubernetes: індексоване завдання, поди якого сортують свої частини файла на томі PersistentVolumeClaim, і друге завдання, що зливає відсортовані частини; перевірити відсортованість результату.

3. Високий рівень. Створити програму sort-cluster з опціями --size, --parts, --parallelism, --help, яка генерує файл випадкових цілих чисел, запускає в Kubernetes індексоване завдання сортування частин на томі PersistentVolumeClaim і завдання злиття, перевіряє відсортованість результату й виводить таблицю часу етапів для різної кількості частин і паралельності.

Варіант 14. Моніторинг сайтів

1. Початковий рівень. Створити консольну програму, яка перевіряє доступність списку URL зі змінної середовища й виводить код відповіді та час; запустити її контейнером Docker.

2. Базовий рівень. Запустити в kind як CronJob (щохвилини) контейнер програми, яка перевіряє доступність списку сайтів (код відповіді й час), передаючи список через ConfigMap; переглянути результати командою kubectl logs для подів завдань і обмежити історію завершених завдань.

3. Високий рівень. Створити програму перевірки доступності сайтів, що запускається в kind як CronJob і зберігає результати (код, час відповіді) у Redis, вебсервіс звіту з ендпоінтом GET /report (доступність і середній час за годину для кожного сайту) і програму monitor-report з опціями --url, --format table|csv, --help, яка виводить звіт.

Варіант 15. Ігровий сервер

1. Початковий рівень. Створити вебсервіс ігрової кімнати, який зберігає рахунок гравців у файлі в теці /data, і запустити його контейнером з іменованим томом; перевірити збереження даних після перезапуску контейнера.

2. Базовий рівень. Створити вебсервіс ігрової кімнати, що зберігає рахунок гравців у файлі в теці /data, і розгорнути його в kind спочатку як Deployment, потім як StatefulSet з volumeClaimTemplates; показати, що після видалення пода StatefulSet зберігає ім’я пода й дані, а Deployment без тому – ні.

3. Високий рівень. Розгорнути в kind три ігрові кімнати (вебсервіс, що зберігає рахунок гравців у файлі на томі) як StatefulSet із headless-службою, створити клієнт game-bots з опціями --rooms, --players, --help, який звертається до кімнат за стабільними DNS-іменами подів, і скласти звіт про збереження стану після видалення подів і масштабування.

Варіант 16. Медична реєстратура

1. Початковий рівень. Створити рішення Aspire з двома вебсервісами: реєстратура і розклад лікарів, які викликають один одного через виявлення сервісів; показати виклики в дашборді.

2. Базовий рівень. Створити рішення Aspire медичної реєстратури: вебсервіс реєстратури публікує запис на прийом у RabbitMQ, робітник підтверджує запис і зберігає його в Redis; перевірити в дашборді розподілене трасування реєстратура → RabbitMQ → робітник.

3. Високий рівень. Створити рішення Aspire медичної реєстратури (вебсервіс реєстратури, RabbitMQ, робітник підтвердження записів з Redis) з власними спанами (ActivitySource) з атрибутами лікаря й пацієнта, навмисною затримкою в робітнику для частини записів і програмою clinic-load з опціями --requests, --help; за даними aspire otel визначити найповільніший етап і пояснити результат.

Варіант 17. Порівняння образів .NET

1. Початковий рівень. Створити мінімальний вебсервіс ASP.NET Core і зібрати його образи на aspnet:10.0 та aspnet:10.0-noble-chiseled; вивести їхні розміри командою docker images.

2. Базовий рівень. Зібрати образи мінімального вебсервісу ASP.NET Core чотирма способами: одноетапний на SDK, багатоетапний на aspnet:10.0, dotnet publish /t:PublishContainer з ContainerFamily=noble-chiseled і Native AOT на runtime-deps; порівняти розмір образу й кількість шарів.

3. Високий рівень. Створити програму image-bench з опціями --images, --runs, --help, яка для кожного заданого образу мінімального вебсервісу ASP.NET Core з ендпоінтом /health (наприклад, на aspnet:10.0, chiseled, Native AOT) вимірює час від docker run до першої успішної відповіді /health і споживання пам’яті (docker stats), виконує кілька запусків і виводить таблицю медіан.

Варіант 18. Обчислення простих чисел

1. Початковий рівень. Створити вебсервіс GET /primes?to=N, який рахує кількість простих чисел до N, і розгорнути його в kind з обмеженнями requests/limits для процесора.

2. Базовий рівень. Розгорнути в kind вебсервіс GET /primes?to=N (кількість простих чисел до N) з requests/limits процесора й HorizontalPodAutoscaler (від 1 до 8 реплік, ціль 60 % процесора), встановити metrics-server і перевірити масштабування під навантаженням консольним клієнтом із кількома паралельними задачами.

3. Високий рівень. Розгорнути в kind вебсервіс GET /primes?to=N з HorizontalPodAutoscaler і створити клієнт primes-load з опціями --tasks, --n, --seconds, --help, який кожні 10 с виводить запити/с, затримку й кількість подів; побудувати таблицю «час – репліки – пропускна здатність» і пояснити вплив stabilizationWindowSeconds на зменшення кількості подів.

Варіант 19. Логістика доставки

1. Початковий рівень. Створити compose.yaml зі службою обліку посилок і Redis, передати рядок підключення змінною середовища й перевірити збереження посилок.

2. Базовий рівень. Створити стенд Docker Compose служби обліку посилок з Redis і RabbitMQ з профілями dev і test: у dev публікуються порти Redis і вебконсолі RabbitMQ, у test – запускається контейнер з інтеграційними тестами; усі залежності мають healthcheck, а служби стартують за depends_on з умовою service_healthy.

3. Високий рівень. Створити стенд Docker Compose служби обліку посилок з Redis і тестову програму delivery-tests з опціями --url, --help, яка в профілі test перевіряє створення, пошук і зміну статусу посилок, повертає код завершення 0 або 1 і виводить таблицю пройдених тестів; стенд запускається командою docker compose --profile test up --abort-on-container-exit.

Варіант 20. Лічильник голосів

1. Початковий рівень. Створити вебсервіс голосування з ендпоінтами POST /vote/{option} і GET /results, ендпоінтами /health/live і /health/ready та зберіганням у Redis.

2. Базовий рівень. Розгорнути в kind на 3 репліки вебсервіс голосування (POST /vote/{option}, GET /results, зберігання в Redis) з пробами готовності (/health/ready, готовий лише при доступному Redis) і життєздатності (/health/live); показати, що при зупинці Redis поди виключаються зі служби, але не перезапускаються.

3. Високий рівень. Розгорнути в kind вебсервіс голосування з Redis і забезпечити нульовий простій при оновленні: коректне завершення за SIGTERM, preStop, стратегія maxUnavailable: 0. Створити програму vote-bots з опціями --rate, --seconds, --help, яка голосує під час оновлення, і звіт, що порівнює надіслані й зараховані голоси та кількість помилок.

Варіант 21. Поштові розсилки

1. Початковий рівень. Створити консольного робітника розсилок, який читає адреси з черги RabbitMQ і «надсилає» листи (виводить у журнал), зібрати образ і запустити його разом із брокером у Compose.

2. Базовий рівень. Розгорнути в kind з limits.memory: 64Mi робітника розсилок, який читає адреси з черги RabbitMQ і «надсилає» листи (виводить у журнал), з режимом накопичення листів у пам’яті; показати завершення контейнера з причиною OOMKilled у kubectl describe pod і підібрати ліміт, за якого робітник працює стабільно.

3. Високий рівень. Розгорнути в kind робітника розсилок (читає листи з черги RabbitMQ і «надсилає» їх у журнал) і створити програму mail-load з опціями --messages, --size, --help, яка публікує листи. Виміряти пропускну здатність робітника для різних limits.cpu (250m, 500m, 1) і limits.memory; вивести таблицю й рекомендовані значення requests/limits.

Варіант 22. Спортивна статистика

1. Початковий рівень. Створити рішення Aspire з вебсервісом статистики матчів і Redis для кешування, запустити його та показати ресурси в дашборді.

2. Базовий рівень. Створити рішення Aspire з вебсервісом статистики матчів і Redis для кешування та ціллю Kubernetes (AddKubernetesEnvironment з реєстром localhost:5001), виконати aspire publish і проаналізувати згенеровану діаграму Helm: які об’єкти створено для проєкту й Redis.

3. Високий рівень. Створити рішення Aspire з вебсервісом статистики матчів і Redis, розгорнути його в кластер kind командою aspire deploy (Helm 4.2 або новіший), перевірити роботу через kubectl port-forward, доповнити згенеровані маніфести пробами та ресурсами через PublishAsKubernetesService і скласти звіт про відмінності від маніфестів, написаних вручну.

Варіант 23. Файлообмінник

1. Початковий рівень. Створити вебсервіс завантаження й отримання файлів, що зберігає файли в теці /data, і запустити його контейнером з іменованим томом.

2. Базовий рівень. Запустити контейнером вебсервіс файлообмінника, що зберігає файли в теці /data на іменованому томі, і реалізувати резервне копіювання тому командою docker run --rm з тимчасовим контейнером, що архівує вміст тому в теку хоста, і відновлення тому з архіву; перевірити, що після видалення контейнера й тому файли відновлюються.

3. Високий рівень. Створити програму backup-tool з командами backup, restore, list, опціями --volume, --dir, --help, яка через тимчасові контейнери Docker архівує іменований том (наприклад, файлообмінника) у теку хоста й відновлює його, перевіряє контрольні суми SHA-256 файлів після відновлення й виводить звіт.

Варіант 24. Пошук текстів

1. Початковий рівень. Створити вебсервіс пошуку слова в наборі текстів, вбудованих в образ, що повертає кількість збігів та ім’я хоста.

2. Базовий рівень. Створити вебсервіс пошуку слова в наборі текстів, вбудованих в образ (відповідь – кількість збігів та ім’я хоста), розгорнути його в kind на 1, 2 і 4 репліки й показати розподіл запитів між подами службою ClusterIP за допомогою тимчасового пода-клієнта (kubectl run).

3. Високий рівень. Розгорнути в kind вебсервіс пошуку слова в текстах, вбудованих в образ, і створити клієнт search-bench з опціями --tasks, --seconds, --keepalive, --help; виміряти пропускну здатність та затримку для 1, 2, 4 реплік з постійними з’єднаннями й без них і пояснити, чому служба балансує з’єднання, а не запити.

Варіант 25. Розумна парковка

1. Початковий рівень. Створити вебсервіс стану паркувальних місць із назвою міста в змінній середовища й розгорнути його в kind у просторі імен dev.

2. Базовий рівень. Створити вебсервіс стану паркувальних місць, що читає кількість місць і тариф з конфігурації, і розгорнути той самий образ у простори імен dev і prod kind з окремими ConfigMap (кількість місць, тариф) і Secret; показати різну поведінку сервісу в двох середовищах.

3. Високий рівень. Розгорнути в kind вебсервіс паркувальних місць у просторах імен dev і prod з ResourceQuota і LimitRange, написати сценарій або програму parking-deploy з опціями --env, --replicas, --help, яка розгортає середовище з шаблону (Deployment, ConfigMap, Secret), і показати відмову створення подів при перевищенні квоти.

Варіант 26. Транспортний диспетчер

1. Початковий рівень. Створити робітника, який обробляє повідомлення про рух транспорту з черги RabbitMQ з ручним підтвердженням, і запустити його в Compose.

2. Базовий рівень. Створити робітника, який обробляє повідомлення про рух транспорту з черги RabbitMQ з ручним підтвердженням і коректно завершується за SIGTERM: припиняє отримання, дочікується поточного повідомлення, підтверджує його й закриває канал; запустити в Compose і перевірити командою docker stop відсутність втрат і дублів.

3. Високий рівень. Створити робітника обробки повідомлень про рух транспорту з черги RabbitMQ (ручні підтвердження, коректне завершення за SIGTERM) і програму dispatch-check з опціями --messages, --stops, --help, яка публікує пронумеровані повідомлення, під час обробки кілька разів зупиняє й запускає робітників (docker stop/docker kill) і виводить кількість втрачених і повторно оброблених повідомлень для коректного, аварійного завершення та версії без обробки SIGTERM.

Варіант 27. Криптокурси (імітація)

1. Початковий рівень. Створити рішення Aspire з вебсервісом, що генерує імітовані курси трьох криптовалют, і переглянути його журнали в дашборді.

2. Базовий рівень. Створити рішення Aspire з вебсервісом, що генерує імітовані курси трьох криптовалют, і власними метриками rates.value (поточний курс з міткою валюти) і rates.updates (кількість оновлень); переглянути їх у дашборді на сторінці Metrics.

3. Високий рівень. Створити рішення Aspire з вебсервісом імітованих курсів трьох криптовалют і сервісом сповіщень, що отримує курси через виявлення сервісів, фіксує перевищення порогів і має метрику кількості сповіщень, та програму rates-report з опціями --threshold, --help, яка за даними aspire otel або dotnet-counters виводить таблицю сповіщень.

Варіант 28. Кластер обчислень матриць

1. Початковий рівень. Створити консольну програму, яка множить блок матриць за номером блока з аргументу і виводить контрольну суму; зібрати образ і перевірити в Docker.

2. Базовий рівень. Запустити множення матриць 1024×1024 як індексоване завдання Kubernetes (16 блоків), де кожен под обчислює свій блок і записує його в Redis; окрема програма збирає результат і перевіряє його порівнянням із послідовним множенням.

3. Високий рівень. Створити програму matrix-job з опціями --size, --blocks, --parallelism, --help, яка генерує індексований Job Kubernetes, поди якого множать свій блок матриць і записують його в Redis, чекає завершення, збирає добуток, перевіряє його послідовним множенням і виводить таблицю часу й прискорення для різної кількості блоків і паралельності.

Варіант 29. Онлайн-курси

1. Початковий рівень. Створити compose.yaml для сервісу онлайн-курсів (вебсервіс і PostgreSQL) з томом для бази даних і перевірити роботу.

2. Базовий рівень. Розгорнути в kind сервіс онлайн-курсів (вебсервіс і PostgreSQL): Deployment і Service для вебсервісу, StatefulSet для PostgreSQL, ConfigMap і Secret для конфігурації; перевірити роботу через NodePort.

3. Високий рівень. Створити для сервісу онлайн-курсів (вебсервіс і PostgreSQL) compose.yaml, ручні маніфести Kubernetes і модель Aspire; скласти таблицю відповідності елементів compose.yaml об’єктам Kubernetes, порівняти ручні маніфести з результатом aspire publish і виміряти час розгортання кожного варіанта програмою deploy-timer з опцією --help.

Варіант 30. Навантажувальний тест платформи

1. Початковий рівень. Створити консольний навантажувальний клієнт, який N паралельними задачами викликає заданий URL протягом заданого часу й виводить кількість запитів за секунду.

2. Базовий рівень. Створити консольний навантажувальний клієнт, який N паралельними задачами викликає заданий URL протягом заданого часу й виводить кількість запитів за секунду, середню й 95-перцентильну затримку, кількість помилок і розподіл відповідей за іменами хостів; протестувати ним сервіс, розгорнутий у kind на 1, 2 і 4 репліки.

3. Високий рівень. Створити інструмент platform-load з опціями --url, --tasks, --ramp, --seconds, --csv, --help, який поступово збільшує навантаження, записує CSV із часом, запитами/с, затримками й кількістю подів (через kubectl get hpa) і виводить підсумкову таблицю масштабування.

Порядок виконання та захисту роботи

1. Опрацювати теоретичні відомості та приклади розв’язання завдань.
2. Перевірити інструменти: docker version, kubectl version --client, kind version, aspire --version; за потреби встановити kind (winget install Kubernetes.kind) і CLI Aspire (dotnet tool install -g Aspire.Cli).
3. Для свого варіанта скласти схему розгортання: сервіси, образи, порти, змінні середовища, томи, залежності; для Kubernetes – об’єкти (Deployment, Service, ConfigMap, Secret, Job, HPA) і їхні мітки.
4. Створити в JetBrains Rider рішення .NET 10, написати Dockerfile і .dockerignore, зібрати й перевірити образи локально (docker run), потім описати стенд у compose.yaml або маніфестах і розгорнути його (для Kubernetes – у кластері kind з реєстром localhost:5001).
5. Перевірити масштабування, відмову контейнера чи пода, оновлення версії та журнали; для Aspire – ресурси, трасування й метрики в дашборді; результати вимірювань звести в таблицю.
6. Після роботи звільнити ресурси: docker compose down -v, kind delete cluster --name pro16, aspire stop, docker image prune.
7. Продемонструвати роботу викладачеві, пояснити Dockerfile, маніфести й код і відповісти на контрольні питання.