Місія 1: «Ізоляційна Капсула»

Рівень 1 (оцінка 3) — Першокурсник

Перед стартом: спорядження ранера

Перш ніж будувати капсулу, підготуй майстерню — це кілька хвилин, зате далі все піде гладко.

Твоє середовище. Працюємо в GitHub Codespaces — це вже готовий Linux зі встановленим Docker Engine, локально відкривати нічого не треба. Якщо Codespaces недоступний, підійде будь-яка машина з Docker (Linux, WSL2 або Docker Desktop). Перевір одразу, що Диспетчер узагалі готовий будувати брами:

docker version

Якщо бачиш блоки Client: і Server: без помилок — капсула чекає на будівництво.

🎲 Твій варіант. Порахуй свій номер у списку групи N і обчисли N % 4. Це визначає, з яким проброшеним портом і суфіксом імені контейнера ти працюєш на розвідці руками й на рівнях 2–3 (значення підстав у свій deploy.sh у vtfk-sid через змінну середовища, а не хардкодь):

Це не заради бюрократії: у групі десятки людей, і однакові звіти з однаковими портами й іменами контейнерів — перше, що впадає в очі на перевірці. Вкажи свій варіант і його розрахунок на початку REPORT.md.

⚠️ Варіант не стосується капсули, яку ти здаєш. Ті devbox-<суфікс> — твої чернетки: підняти, подивитися, прибрати. А капсула, по яку приходить перевірка, у всіх одна й та сама — vtfk-lab01, і порт їй не потрібен узагалі. Перевірка шукає контейнер за точним іменем; devbox-bravo вона просто не побачить.

📡 С.І.Д.: «Позивний вигадуй собі який хочеш, ранере. Але двері, у які стукає кур'єр, мають один номер на все місто — інакше він стукає в порожнечу.»

📦 Де житиме капсула. У тебе буде два репозиторії, і в кожного одна робота.

цей репозиторій        ← кожна ЛР має свій; сюди рівень 1 і REPORT.md
vtfk-sid/              ← створюєш СЬОГОДНІ, один на весь семестр
  core/capsule/          сюди кладеш капсулу — і вона житиме тут до ЛР10

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

Другий створюєш сама, сьогодні, і більше не створюєш ніколи: vtfk-sid — це ядро С.І.Д., яке росте. Наступної ночі ти будеш худнути саму цю капсулу, а не абстрактну програму; у ЛР3 вона стане одним із двох контейнерів; у ЛР10 у ній збереться фінальне ядро. Рівні 2 і 3 усіх десяти місій живуть тут — і показуються на захисті, не автотестами.

Як його створити — рівно чотири кроки, один раз за семестр:

1. відкрий github.com/alex-ordynski/vtfk-sid — це шаблон із порожньою картою тек;

2. зелена кнопка «Use this template» → «Create a new repository»;

3. ім'я — vtfk-sid (саме так, без префіксів), власник — ти сама, видимість — public, створити;

4. забери його до себе:

   git clone https://github.com/<твій-логін>/vtfk-sid.git
   

   https://, а не git@github.com:. Друге — це SSH, і воно вимагає ключа, якого в Codespaces немає: звідти Git ходить по HTTPS вбудованим токеном. На сторінці репозиторію це вкладка HTTPS під зеленою кнопкою Code. Побачиш Permission denied (publickey) — значить, скопіювавла не ту вкладку, а не втративла доступ.

Це шаблон, а не форк: історія починається з твого першого коміту, і ядро — твоє. Якщо кнопки «Use this template» не видно — не тисни «Fork», скажи викладачеві: значить, у шаблона знята галочка, і це проблема не твоя.

🏷️ Як здаси. Рівень 1 — тегом submit/lab01 у репозиторії завдання. vtfk-sid не здається тегом узагалі: його ти показуєш на занятті. Детальніше — у блоці «Здача» наприкінці. А поки — до діла.

Що саме приймає перевірка

С.І.Д.: «Одне уточнення, перш ніж ти візьмешся за клавіатуру. Переказ на словах — «усе піднялося, усе було гарно» — бункера не будує. Мені потрібен протокол: файл, який щоразу зводить капсулу однаково, хоч о третій ночі, хоч без тебе. Я його запущу й перевірю сам — не на слово, а руками.»

Здається один файл — level1.sh, у корені цього репозиторію. Його пишеш ти; у шаблоні його немає навмисно. Контракт:

1. Шапка #!/usr/bin/env bash і set -euo pipefail. Запускається без аргументів.

2. Піднімає контейнер з іменем vtfk-lab01 з образу ubuntu:24.04 — і лишає його працювати після того, як скрипт закінчився.

3. Записує значення змінної оточення $VTFK_NONCE у файл /tmp/vtfk-nonce всередині контейнера. Змінну підкладає перевірка, і щоразу вона інша.

4. Друкує рівно такі три рядки (порядок вільний, будь-який інший вивід дозволено):

   CONTAINER_PID=<PID головного процесу всередині контейнера>
   CONTAINER_PROCS=<скільки процесів видно всередині>
   HOST_PROCS=<скільки процесів видно на хості>
   

5. Завершується кодом 0, нічого не питає й не падає при повторному запуску — ідемпотентність тут не прикраса: перевірка запускає скрипт на репозиторії, де капсула могла лишитися з попередньої спроби.

Що саме дивиться грейдер

Зараховується, коли пройшли всі шість:

⚠️ Не прибирай капсулу в кінці скрипту. Звичка «за собою прибирати» тут коштує трьох перевірок із шести: перевірки 3, 4 і 5 стукають у контейнер docker inspect і docker exec уже після того, як level1.sh відпрацював. Якщо останнім рядком стоїть docker rm -f vtfk-lab01 — стукати буде нікуди, і виглядатиме це так, ніби зламався грейдер. Прибирання — його турбота, не твоя.

📡 С.І.Д.: «Бункер лишають відчиненим для свого. Ти будуєш мені дах, а не розбираєш його назад того ж вечора — я ж збираюся там жити.»

Числа в рядках мають бути виміряні, а не вгадані: перевірка рахує процеси сама й звіряє з твоїми. І nonce — той самий гачок, який неможливо обійти друком: його значення щоразу нове, і прочитати його можна лише з файлу в справді піднятій капсулі.

Крок за кроком — чотири етапи

Тут не потрібна творчість. Веду тебе за руку: три етапи ти робиш руками, щоб побачити ізоляцію на власні очі, а на четвертому перекладаєш побачене у level1.sh — той самий протокол із контракту вище. Вивід кожної команди дорогою складай у REPORT.md: перевірка його не читає, зате читає викладач на захисті рівнів 2–3.

Етапи йдуть по одному: зробив — постав «вийшло» — і ранер перекине тебе на наступний. Стрілки ← → на клавіатурі, свайп на телефоні, «усі» — щоб побачити всі чотири одразу. Місце запам'ятовується: закриєш ноутбук — повернешся туди ж.

Рівень 2 (оцінка 4, захист) — Магістр

Тут я вже не диктую кожен рядок. Формулюю мету й контракт — далі твоя голова.

Ланцюг починається тут. ЛР1 — перша місія, тому в неї немає «попереднього артефакту»: обидві версії умови збігаються. З ЛР2 у кожного завдання рівнів 2–3 буде два входи — «на своєму ядрі» і «на референсі», якщо своє ядро з якоїсь причини відсутнє. Твоя справа сьогодні — щоб ядро з'явилося.

Мета. Довести, що ти не просто скопіювавла команди, а розумієш, чому без явних дій капсула залишається «німою» для зовнішнього світу, і вмієш пробити крізь NET-браму контрольований канал назовні.

Контракт рівня:

1. Підніми нову капсулу з проброшеним портом (значення HOST_PORT — зі свого варіанта в таблиці). Орієнтир для команди:

   docker run -it -p <HOST_PORT>:80 --name devbox2-<суфікс> ubuntu:24.04 bash
   

2. Усередині капсули підніми найпростіший HTTP-сервер на порту 80 (наприклад, python3 -m http.server 80, доти встановивши python3).
3. З іншого терміналу на хості доведи, що канал працює: curl -i http://localhost:<HOST_PORT>/ має повернути HTTP-відповідь 200 OK зі списком файлів контейнера.
4. Доведи зворотне: підніми таку саму капсулу без прапорця -p (під іншим іменем) і покажи, що той самий curl падає з помилкою з'єднання. Це і є доказ, що проброс — свідома дія, а не побічний ефект запуску контейнера.

На захисті будь готовийа: усно пояснити, чим мережевий простір капсули відрізняється від мережевого простору хоста і як саме -p перетворюється на NAT-правило, та наживо продемонструвати робочий проброшений порт — з будь-яким значенням HOST_PORT, яке попросить викладач, не обов'язково твоїм із таблиці. Завчений результат тут не врятує; рятує розуміння.

Рівень 3 (оцінка 5, розширення) — Легенда Коледжу

С.І.Д. дивиться на тебе інакше, коли ти доходиш сюди. «Ручна праця — для першокурсників, — каже він. — Легенда не набирає команди. Легенда пише протокол, який щоразу піднімає бункер однаково, хоч серед ночі, хоч під сканерами.» Мета — перетворити всі ручні кроки на один надійний, ідемпотентний протокол розгортання.

Контракт. Напиши core/capsule/deploy.sh за такими вимогами:

• Шапка #!/usr/bin/env bash і set -euo pipefail.
• Без аргументів піднімає капсулу «з нуля»: базовий образ ubuntu:24.04, встановлює curl git procps iproute2, пробиває порт (значення бери зі змінної середовища HOST_PORT, за замовчуванням — значення твого варіанта з таблиці варіантів на початку рівня 1).
• Головна вимога рівня 3 — ідемпотентність. Повторний запуск скрипту без ручного прибирання не повинен падати з помилкою «name already in use». Скрипт має або перевіряти наявність контейнера з таким іменем і перевикористовувати/перезапускати його, або прибирати старий перед створенням нового (docker rm -f "$NAME" 2>/dev/null || true).
• Код завершення 0 при успіху; ненульовий, якщо Docker недоступний або контейнер не піднявся.
• Без інтерактивних запитань «yes/no» — усе має відпрацьовувати без втручання людини (прапорці на кшталт -y для apt-get, детач-режим для довготривалих процесів).
• Контейнер має лишатися запущеним після відпрацювання скрипта (детач-режим із довготривалим процесом, напр. sleep infinity), інакше на захисті не буде куди зайти через docker exec і показати встановлені в ньому утиліти. Та сама вимога, що й на рівні 1: скрипт будує бункер, а не розбирає його назад. Типовий кістяк: docker rm -f "$NAME" 2>/dev/null || true; docker run -d --name "$NAME" -p "$HOST_PORT":80 ubuntu:24.04 sleep infinity, а потім установлення утиліт усередині через docker exec "$NAME" bash -c 'apt-get update && apt-get install -y curl git procps iproute2'.

Приклад запуску:

# з кореня свого vtfk-sid
HOST_PORT=8081 ./core/capsule/deploy.sh
HOST_PORT=8081 ./core/capsule/deploy.sh   # другий запуск — не повинен впасти

На захисті викладач запустить скрипт двічі поспіль і перевірить через docker exec, що всі чотири перелічені вище утиліти (curl, git, procps, iproute2) справді стоять у кінцевому контейнері. Машина сюди не дістає: vtfk-sid — твій репозиторій, автогрейдер його не бачить.