Бесплатный tier у облачных провайдеров обычно похож на пробник в магазине: чуть-чуть ресурсов на год, потом плати. У Oracle Cloud история другая: в Always Free давно лежат ARM-инстансы Ampere A1 с суммарными 4 vCPU и 24 ГБ памяти плюс 200 ГБ дискового пространства, и это не на год, а постоянно. Для домашней лаборатории это почти неслыханная щедрость: на таком объёме крутятся Kubernetes-кластер, CI-раннеры, медиасервер и десяток pet-проектов одновременно. В статье разбираем, как реально получить и удержать эти ресурсы, что на них удобно запускать и где спрятаны подводные камни с регионами и доступностью capacity.
Что именно входит в Always Free и как это получить
Перечень Always Free у Oracle заметно шире, чем у конкурентов. Основное блюдо: compute на архитектуре ARM Ampere A1.Flex, где можно суммарно использовать до 4 OCPU (Oracle считает OCPU как целое физическое ядро с двумя потоками, то есть в терминах vCPU это до 8 виртуальных потоков) и до 24 ГБ RAM, распределённых на 1-4 инстанса. Дополнительно: 200 ГБ block volume суммарно, 10 ТБ исходящего трафика в месяц (щедрость, которой нет даже у Hetzner), два инстанса Micro на x86 с 1/8 OCPU и 1 ГБ RAM для мелочи, плюс managed-сервисы в миниатюре: Autonomous Database на 20 ГБ, Object Storage на 10 ГБ стандартного класса и ещё по мелочи мониторинг и балансировщик.
Регистрация требует банковской карты, и это первый фильтр: карта должна принимать зарубежные платежи, списывается и возвращается проверочный доллар. Домашний регион выбирается один раз при создании аккаунта и не меняется никогда. Это критично для ARM: capacity под Always Free выделяется из общего пула региона, и в популярных регионах (Frankfurt, Amsterdam, Ashburn) свободные ARM-ядра под бесплатные инстансы кончаются надолго. Создавая инстанс, вы можете неделями видеть ошибку Out of capacity for shape VM.Standard.A1.Flex. Поэтому домашний регион выбирают головой, а не географией: смотрят, где реально есть capacity для A1, а не где ближе к дому.
Проверить capacity можно из CLI: oci compute shape list или проще - попытаться создать инстанс в консоли и посмотреть, не ругается ли Availability Domain. Есть и народные скрипты-мониторы, которые крутят oci compute instance launch в цикле с retry и бьют вам в мессенджер, когда освободилось место. Это автоматизация официального API, она не противоречит правилам, но создавать её стоит аккуратно с паузами, чтобы не упереться в rate limits.
Реальная установка и первичная настройка ARM-инстанса
Создание через консоль занимает пять минут: выбирается образ (Oracle Linux 9, Ubuntu 22.04/24.04 aarch64 или Debian), shape VM.Standard.A1.Flex, задаются OCPU и память, прикладывается SSH-ключ. Разумное распределение 4 OCPU и 24 ГБ: один инстанс на всё (проще, один SSH-ключ, один firewall) или два инстанса по 2 OCPU и 12 ГБ (изоляция экспериментов от основного контура). Для Kubernetes-лаборатории типичная разбивка: control plane на 1 OCPU и 6 ГБ, worker на 3 OCPU и 18 ГБ.
После запуска ждёт особенность Oracle: у VCN (виртуальной сети) по умолчанию закрыты почти все порты в Security List, и правила добавляются руками. Для веба открывают 80 и 443 для 0.0.0.0/0, SSH оставляют только на свой IP. Внутри инстанса поверх этого работает iptables или firewalld самой ОС, так что правило надо продублировать внутри: в Oracle Linux это firewall-cmd --add-port=443/tcp --permanent и firewall-cmd --reload. Классическая ситуация новичка: сервис слушает порт, Security List открыт, а снаружи таймаут - потому что забыт firewalld внутри гостя.
Диски: boot volume по умолчанию 47-50 ГБ, остаток из 200 ГБ раздаётся дополнительными block volumes. Их создают через консоль или CLI (oci bv volume create --availability-domain ... --size-in-gbs 100), пристёгивают к инстансу и размечают внутри: lsblk покажет /dev/sdb, дальше mkfs.ext4 и запись в /etc/fstab по UUID. Важно: пристёгивать тома можно только в тот же Availability Domain, где живёт инстанс, поэтому AD выбирают один раз и не скачут между ними.
Что реально запускают на free tier ARM
Практических сценариев хватает. Первый - домашний Kubernetes: k3s отлично работает на aarch64, и кластер из двух нод на 4 ядра суммарно это полноценная учебная и даже боевая среда для pet-проектов. Второй - круглосуточные сервисы дома: Nextcloud, Vaultwarden для паролей, Home Assistant в контейнере, Uptime Kuma для мониторинга домашней сети, Pi-hole как DNS-фильтр. Третий - CI-раннеры: GitHub Actions self-hosted runner под ARM экономит минуты в платных тарифах, а заодно тестирует, что ваши контейнеры собираются под aarch64.
Четвёртый сценарий - личный выходной шлюз и междусерверная связность: инстанс в облаке с чистым публичным IP удобен как точка входа для self-hosted сервисов, живущих дома за NAT провайдера. Трафик в 10 ТБ включён, поэтому даже тяжёлые сценарии не пробьют лимит. Пятый - постоянные микросервисы: telegram-боты, RSS-агрегаторы, парсеры, cron-задачи для автоматизации. Всё это стабильно живёт на ARM, если контейнеры собраны multi-arch; современные образы redis, postgres, nginx имеют aarch64-сборки, а вот старые образы с Docker Hub иногда существуют только под x86, и это надо проверять до переноса.
Производительность Ampere Altra достойная: одно ядро уступает топовым x86 в однопотоке, но SoC держит стабильную частоту без троттлинга, и для типичных веб-задач, баз и контейнеров разницы вы не заметите. Заметить её можно на задачах с AVX-512 или специфичных x86-инструкциях - там ARM просто не умеет таких команд.
Подводные камни, регионы, capacity и правила игры
Главный камень уже упомянут: домашний регион неизменяем, а ARM capacity под free tier выделяется из общего пула. В перегруженных регионах новые A1-инстансы не запускаются неделями. Выходы такие: выбирать при регистрации менее популярный регион; ловить окна retry-скриптом; разбивать требование на части (инстанс на 4 OCPU не поднялся - пробуют 2x2, потому что мелкие куски находятся чаще); держать инстанс включённым, потому что после удаления освобождённые ядра может забрать кто-то другой.
Второй камень - правило idle для Always Free. Oracle может запросить подтверждение активности аккаунта, а неиспользуемые ресурсы (по их метрикам) подлежат отключению после уведомления. На практике это редко цепляет реально работающие инстансы, но брошенный инстанс с нулевой нагрузкой лучше не держать: поставьте на него хотя бы что-то полезное или удалите. Третий камень - деньги: однажды выбранный Always Free не защищает от случайного создания платных ресурсов, поэтому в консоли полезно настроить budget alert на 1 доллар, чтобы поймать любое списание в зародыше.
Четвёртый камень - сеть: приватные подсети, bastion и штатные механизмы доступа работают как в любом облаке, но Oracle имеет свою терминологию (VCN, subnet, route table, internet gateway, service gateway), и маппинг её на привычную AWS-шную модель занимает первый вечер знакомства. Пятый - поддержка: на бесплатном тарифе опираться на техподдержку не стоит, разбираться придётся по документации и форумам; зато документация у OCI подробная, а сообщество вокруг free tier разрослось настолько, что типовые ошибки гуглятся с готовыми решениями.
Итог для домашней лаборатории
Oracle Cloud free tier это редкий случай, когда бесплатное облако не игрушка, а полноценное железо: четыре ARM-ядра, 24 гигабайта памяти и 200 гигабайт дисков домашней лаборатории хватит с запасом. Чтобы воспользоваться этим без боли, нужно сделать три вещи: выбрать домашний регион с живым capacity под ARM, подготовиться к тому, что инстанс может не запуститься с первой попытки, и сразу настроить бюджетный алерт. Дальше всё как в любом Linux-облаке: cloud-init для bootstrap, контейнеры для сервисов, бэкапы наружу, и лаборатория работает круглый год, не прося ни копейки.
Бесплатные managed-кусочки, о которых забывают
Помимо compute, в Always Free лежат вещи, которые заметно упрощают лабораторию. Autonomous Database на 20 ГБ - это полностью управляемая база (варианты: Transaction Processing, Data Warehouse, JSON Database и APEX для low-code). Для pet-проекта удобен именно JSON Database или ATP: не надо самому крутить PostgreSQL, бэкапы и патчи включены, клиент подключается по wallet-файлу, который скачивается из консоли и раскладывается по каталогу с настройкой sqlnet.ora. Строка подключения указывает на сервис из tnsnames.ora внутри wallet, и после этого обычный клиент Python или Node подключается как к локальной базе.
Object Storage на 10 ГБ стандартного класса и ещё 10 ГБ infrequent access работает по S3-подобному API (есть совместимый endpoint), что позволяет держать там бэкапы лаборатории через rclone: rclone config с типом s3, endpoint региона Oracle, ключи из user settings - и nightly rsync критичных данных уходит в облако без настройки сервера бэкапов. Дополняет картину бесплатный Load Balancer на 10 Мбит/с: его хватает, чтобы сгруппировать несколько мелких сервисов за одним публичным IP с TLS-терминацией.
Мониторинг тоже есть: базовые метрики инстансов, алармы и notifications до 500 email в месяц - всё без оплаты. Минимальный набор для лаборатории: алерт на CPU выше 90% за 15 минут, на дисковое заполнение через кастомную метрику агента (Oracle Cloud Agent ставится одной командой и шлёт метрики гостевой ОС) и на живость самого инстанса. После этого лаборатория перестаёт быть чёрным ящиком.
Организация доступа и бэкап стратегия
Доступ к лаборатории разумно организовать сразу по-взрослому. SSH-ключи только, пароль отключён; отдельный пользователь вместо opc/ubuntu для повседневной работы; sudo без пароля только для автоматизированных задач. Для доступа из дома без открытия лишних портов годится встроенный bastion-сервис OCI: он создаёт управляемую точку входа с ограниченным временем жизни сессии, и домашний IP вообще не светится в Security List.
Бэкапы уровня дисков делаются политиками: backup policy на boot volume и block volumes по расписанию, но учтите - снапшоты занимают место в лимите 200 ГБ, и наглец-бэкап может его съесть. Поэтому для важных данных делают двухъярусную схему: локальные снапшоты для быстрого отката плюс выгрузку критичного наружу через rclone в Object Storage или на домашний NAS. Раз в пару месяцев полезно реально восстановить файл из бэкапа, чтобы убедиться, что схема рабочая, а не декоративная.
И финальный совет из практики: ведите небольшой журнал того, что живёт на лаборатории - какие контейнеры, на каких портах, где лежат данные. Когда через полгода вы вернётесь к инстансу, чтобы добавить ещё один сервис, этот файлик сэкономит вечер воспоминаний. Домашняя лаборатория хороша тем, что учит дисциплине без риска для чужих данных: практики, наработанные на бесплатных ARM-ядрах, потом спокойно переносятся в продакшен любой серьёзности.
Проверка совместимости софта перед переносом на ARM
Прежде чем тащить любимый сервис на Ampere, стоит потратить десять минут на проверку. Для контейнеров: docker manifest inspect имя:тег покажет список архитектур в образе - ищите linux/arm64. Для бинарников: file ./program скажет, под что собран исполняемый файл. Для языков с нативными зависимостями (Python с C-расширениями, Node с native modules) проверяется наличие wheel под aarch64 или готовность собираться из исходников, что иногда тянет за собой gcc и десяток dev-пакетов.
Сюрпризы обычно приходят со старым self-hosted софтом, который авторы собирали только под x86, и с закрытыми бинарниками без ARM-сборок. Решение бывает разное: найти поддерживаемый форк, заменить сервис альтернативой, или в крайнем случае держать эту конкретную программу на бесплатном x86 Micro-инстансе рядом - на то он и есть в Always Free, чтобы закрывать хвосты, которые не переваривают ARM. Такая гибридная схема в лаборатории вполне жизнеспособна: тяжёлое на ARM, экзотика на Micro, и оба бесплатны.