25 октомври 2026 г. · Разказ от първо лице
Можехме да започнем с Terraform и след няколко команди да имаме куп ресурси, чиито имена едва помним. Този път избрахме да минем през уеб конзолата. Исках да видя къде живее всяко нещо, как се връзва с останалите и кои настройки всъщност имат значение. За малък проект това се оказа чудесен начин да си изясня картината.
Проектът се казва Cloud VM Docker Starter. Той още не е приложение, което обслужва потребители. Той е подготвената сцена: публичен HTTPS вход, Docker среда, постоянен диск за бъдещите данни, път за архивиране и наблюдение. Достатъчно реален, за да се счупи; достатъчно малък, за да разберем защо.
01 / Първите решения
Преди сървъра идва сметката
Започнахме от Google Cloud проект и billing account. Свързахме ги, но преди да натиснем „Create“ на каквато и да е машина, сложихме месечен бюджет с няколко прага за известяване. Сумата беше $26.50 — по-скоро ранно предупреждение, отколкото обещание за таван. Бюджетът не изключва услугите автоматично. Ако не гледаш сметката, облакът любезно продължава да работи.
После дойде калкулаторът. Там видяхме мистериозните 730 часа: това е приблизително пълен месец работа на една машина, не някакъв скрит бонус. Сравнихме няколко европейски региона и избрахме Белгия. Франкфурт излизаше малко по-скъп, а за този начален етап нямахме причина да плащаме разликата. Калкулацията беше ориентир, защото отделният диск, публичният адрес, архивите и трафикът също могат да участват във фактурата.
Имахме и първата малка загадка: защо при избор на e2-small калкулаторът показва половин vCPU? Защото това е споделен тип машина. Ако насила зададеш две ядра, вече избираш друг продукт — и цената се променя. Оставихме e2-small с 2 GB RAM и обикновен, а не прекъсваем режим на работа. За стартов gateway това е разумно начало, което ще измерим с истинско приложение.
02 / Кой може да влезе
Първо очертахме границите
Създадохме собствена VPC мрежа и subnet, вместо да стъпим върху готовата default мрежа. След това добавихме две ясни firewall правила. Едното допуска публичен HTTP и HTTPS трафик, защото искаме сайтът да се вижда. Другото допуска SSH само през Google Cloud IAP. Това е онзи специален диапазон на Google, който изглежда произволен, докато не разбереш, че тунелът към машината минава през него.
И двете правила сочат към tag, който поставихме на VM. Така правилото съществува в мрежата, но действа само върху машините с този tag. Затова не включвахме и допълнителните отметки „Allow HTTP traffic“ и „Allow HTTPS traffic“ при създаването на VM: те щяха да добавят още автоматични правила за същата задача.
Резервирахме и статичен външен IP адрес. Конзолата услужливо предупреди, че запазен адрес без машина струва повече. Свързахме го с VM, за да имаме постоянна цел за DNS записа. Във формата за мрежови интерфейси се появи още едно объркване: интерфейс към default плюс нов интерфейс към нашата мрежа. Оставихме само този към собствената VPC. Празното поле за alias IP не беше задача за решаване; просто не ни трябва допълнителен диапазон.
За административен вход включихме OS Login и използвахме IAP. Не отворихме SSH за целия интернет и не добавяхме ръчно ключове в настройките на VM. Това не прави машината магически защитена, но оставя достъпа разбираем: кой влиза се решава чрез Google Cloud права, а откъде идва трафикът — чрез мрежовото правило.
03 / Истинската машина
Един диск за системата, друг за данните
Създадохме Ubuntu VM с 20 GB boot disk и отделен 20 GB data disk. И двата са от типа Balanced persistent disk. За data disk избрахме да остане на място, ако някой ден изтрием или подменим VM. Това е важната разлика между „сървър“ и „данни“: контейнерът и машината могат да се пресъздадат, но базата на бъдещото приложение не бива да изчезне с тях.
После влязохме през Cloud Shell. Това беше полезна граница за научаване: Cloud Shell е терминал, предоставен от Google; след gcloud compute ssh вече сме вътре в нашата VM. Когато ключът поиска пасфраза, вече имахме и съвсем човешка част от инфраструктурата — да си я спомним. След рестарт SSH сесията действително прекъсна, после се върнахме и проверихме, че всичко е на мястото си.
На машината новият диск се виждаше отделно от системния. Форматирахме само празния data disk, монтирахме го по UUID и след рестарт проверихме, че продължава да стои на същия път. Това е по-важно от красивото име на диска в конзолата: Docker трябва да вижда реалния прикачен диск, когато записва постоянните си данни.
Инсталирахме Docker Engine и Compose, качихме проекта на VM и пуснахме един контейнер — Caddy. Засега няма Node или Java услуга, няма база с потребителски данни и няма излишни публични портове. Оставихме място за тях, когато има истинско приложение за разполагане.
04 / Първият публичен отговор
Един A запис, после HTTPS
Добавихме DNS A запис за api.tonymitsev.com, който сочи към постоянния адрес на VM. След като името започна да се разрешава правилно, Caddy пое HTTP и HTTPS трафика. Сертификатът се появи автоматично — без да купуваме файл, да го качваме ръчно или да пишем отделна процедура за подновяване. Постоянните данни на Caddy са върху отделния диск, така че пресъздаването на контейнера не започва всичко от нулата.
Първоначално началната страница връщаше 200 и текст „Cloud VM ready“. Това е приятно за първи тест, но се оказа лоша основа за сериозна проверка: непознатите адреси също връщаха 200. Как да симулираме грешка, ако всеки път ни отговарят „всичко е наред“?
Добавихме отделен /health, който връща 200 healthy, а непознатите пътища — 404. Така наблюдението има стабилен адрес. Когато бъдещото приложение се появи, ще запазим този публичен URL, но ще го свържем с реалната му проверка. Днес той проверява Caddy, а не все още несъществуващ backend.
05 / План Б, който пробвахме
Архивът има смисъл след възстановяване
Създадохме частен Cloud Storage bucket за бъдещите архиви. На VM дадохме право да създава обекти в него, но не и да чете или трие съдържанието му. Това е удобна граница: сървърът може да изпрати нов архив, без да получава пълен контрол над старите.
Точно тук получихме полезна грешка. Пробата с gcloud storage cp върна 403 за право на четене. Вместо да дадем по-широки права само за да замлъкне съобщението, качихме пробния файл през API операция за създаване на обект. След това направихме малка SQLite база, качихме и нея и я изтеглихме в отделен Cloud Shell с операторски достъп. PRAGMA integrity_check върна ok, а пробният запис се прочете. Това беше истинският момент „архивът работи“.
Добавихме и дневни disk snapshots. Те са втори път за възстановяване, различен от копието на SQLite файла. За бъдеща работеща база ще трябва периодично, съгласувано SQLite резервно копие, автоматично качване, известяване при провал и редовна проба за възстановяване. Днешният тест беше нарочно малък и ръчен; няма да го представяме като готова production backup система.
06 / Някой да ни събуди
Проверката проговори — и прати мейл
Настроихме Google Cloud Monitoring да отваря https://api.tonymitsev.com/health и да очаква едновременно успешен HTTP код и думата healthy. При проблем трябва да дойде имейл. Докато променяхме конфигурацията и пресъздавахме gateway контейнера, такъв имейл наистина пристигна. Малко досадно в момента, но точно това искахме да докажем: веригата от неуспешна проверка до пощата е жива.
На финала имаме работеща инфраструктурна основа. Има домейн с HTTPS, ограничен достъп, отделен постоянен диск, публичен gateway, частно място за архиви, пробно възстановяване и известяване. В хранилището оставихме и подробен човешки дневник на настройката, за да не се налага след месец да гадаем кое меню какво е създало.
Следващата глава е приложението. То ще трябва да влиза зад Caddy, да пази данните си на отделния диск, да има собствена проверка за здраве и автоматичен backup. Дотогава началната страница честно казва само това, което е вярно: облачната VM е готова.
Ако ти е интересно как изглежда малък облачен проект преди да стане продукт, кодът и документацията са в GitHub. Този разказ е за направеното досега; ще го продължим, когато на машината заживее истинското приложение.
Към останалите проекти
