Бесплатный ARM-сервер на постоянной основе звучит как маркетинговое обещание, но у Oracle Cloud оно оформлено документально: Always Free ресурсы доступны всю жизнь аккаунта, и среди них есть настоящие вычислительные машины на чипах Ampere. Для домашней лаборатории это редкий шанс получить круглосуточный узел с двенадцатью гигабайтами памяти без ежемесячных платежей. Разберём, что именно достаётся бесплатно, как выбрать регион и какие ловушки расставлены по пути.
Что именно достаётся бесплатно и на каких условиях
Always Free ресурсы создаются в домашнем регионе аккаунта и живут без срока давности. По вычислениям даётся две микро-машины VM.Standard.E2.1.Micro на AMD с одним ядром и гигабайтом памяти каждая, плюс ARM-линейка VM.Standard.A1.Flex: первые 1 500 OCPU-часов и 9 000 ГБ-часов памяти в месяц бесплатно, что эквивалентно двум ядрам и 12 ГБ на одной машине. Минимальный размер загрузочного тома 47 ГБ, всего на аккаунт выделяется 200 ГБ блочного хранилища, и лимит делится между всеми машинами. Загрузочные тома тоже растут из этого пакета: двухсот гигабайт хватает на пару корневых разделов по шестьдесят-восемьдесят с запасом под данные, а скромное распределение места по таблице в конце статьи помогает не упереться в потолок через полгода. В консоли у бесплатных ресурсов стоит метка Always Free-eligible, перепутать сложно. Имя аккаунта и права администратора фиксируются при создании, и многофакторная защита входа включается сразу: аккаунт с бесплатными машинами тоже ценность, которую жалко потерять. Математика квоты получается впритык: два ядра, работающие все 744 часа месяца, съедают 1 488 из 1 500 часов, а 12 ГБ дают 8 928 из 9 000 ГБ-часов. Круглосуточная работа одной двухъядерной машины влезает ровно, вариант с двумя машинами по одному ядру тоже. Остановленная машина часы не расходует, поэтому вторую машину удобно держать выключенной и включать для экспериментов, и такой режим полностью вписывается в бесплатный пакет. Заранее посчитанная схема из главного узла и запасной машины не оставляет квоте шансов удивить в конце месяца.
Рядом с вычислениями в бесплатный пакет входят приватная сеть, пара свободных адресов, балансировщик с небольшой полосой, мониторинг и уведомления, и этой обвязки хватает на полноценную схему без доплат. Коробку бесплатных лимитов стоит проверить в консоли перед проектированием: состав пакета периодически расширяется, и новые позиции тоже помечены бесплатной меткой.
Хватает ли ARM-двухъядерника на лабораторию
Два ядра Ampere и 12 ГБ памяти закрывают на удивление много задач. На такой машине спокойно живут обратный шлюз, git-сервер, раннер CI, связка Prometheus с Grafana, собственный DNS и закрытый туннель WireGuard для доступа к домашним сервисам издалека. Контейнерный стек работает штатно, но образы нужны мультиархитектурные: большинство популярных картинок собраны и под arm64, а редкие бинарники без ARM-сборки выручаются эмуляцией или заменой аналогом. Go, Node, Python и PostgreSQL ставятся без сюрпризов, сборка собственных образов ведётся прямо на машине.
Бюджет памяти прикидывается заранее и ложится комфортно: обратному шлюзу хватает десятков мегабайт, связке мониторинга по двести-пятьсот, небольшой базе до полугигабайта, и даже с раннером сборок остаётся запас на пики. Ощущение дефицита возникает только при сборке крупного проекта на самой машине, и эту задачу лучше выносить на включаемый по надобности второй узел. Исходящего трафика даётся 10 ТБ в месяц, для лаборатории это огромный запас, который не израсходовать честной работой сервисов. Рядом в бесплатном пакете лежат объектное хранилище на 20 ГБ под бэкапы конфигураций и пара автономных баз данных для мелких сервисов, так что небольшой сайт или служебный API размещается без единой дополнительной строки в счёте.
По скорости одно ядро Ampere уступает свежим топовым x86, но для веб-сервисов, шлюзов и мониторинга разница незаметна, зато по соотношению производительность на доллар ARM-линейка обгоняет всё, что обычно достаётся бесплатным тарифам. Отдельный плюс схемы: облачная машина принимает входящие соединения напрямую, и домашний интернет остаётся за пределами схемы публикации сервисов. Трафик в десять терабайт покрывает службу со средним профилем с многократным запасом, а раздача тяжёлых файлов широкой публике подводит к мысли о платном тарифе заранее.
Регион выбирается один раз и навсегда
Домашний регион фиксируется при регистрации аккаунта и не меняется, а все Always Free ресурсы создаются только в нём. Ошибка выбора бьёт дважды. Во-первых, задержка от вашего города до машины закрепляется навсегда: интерактивные сервисы на дальнем регионе заметно тормозят. Во-вторых, регион с дефицитом бесплатной ёмкости превратит создание ARM-машин в долгую охоту за свободными слотами. Выбирают регион по двум критериям: географической близости и опыту сообщества о доступности ёмкости в конкретной локации. Список локаций с зонами доступности виден на публичной странице облака ещё до регистрации, и таблицы задержек от пользователей обновляются чаще официальных данных. Есть и внутренний нюанс: A1-машины можно создавать в любой зоне доступности региона, кроме одной южнокорейской, а микро-машины на AMD живут только в одной конкретной зоне. Задержку до регионов можно померить заранее: у облака есть публичные адреса сервисов в каждой локации, и обычный ping до них за вечер обрисовывает картину. Свежие отзывы по регионам стоит перечитать перед регистрацией: карта доступности меняется, и вчерашний пустой регион через полгода может стать переполненным. Задержка влияет не только на людей: репликации между машинами и между домом и облаком тоже зависят от расстояния, и лаборатория с частыми синхронизациями выигрывает от ближнего региона.
Сама регистрация проходит спокойнее без спешки: понадобится карта для подтверждения, почта и пара минут на выбор домашнего региона, и торопиться здесь вредно, потому что поле выбора региона не редактируется потом. Заранее стоит определиться и с именем аккаунта: оно фигурирует в интерфейсах и скриптах, а переименование позже не предусмотрено.
Борьба за ёмкость и апгрейд до Pay As You Go
Частая история при создании ARM-машины: ошибка out of host capacity, свободной ёмкости нет. Рабочие приёмы известны: пробовать разные зоны доступности, повторять в разное время суток, автоматизировать перебор параметров скриптом через API, который стучится каждые несколько минут:
oci compute instance launch \
--availability-domain "$AD" --compartment-id "$COMP" \
--shape "VM.Standard.A1.Flex" \
--shape-config '{"ocpus": 2, "memoryInGBs": 12}' \
--image-id "$IMG" --subnet-id "$SUB" \
--assign-public-ip true --user-data-file cloud-init.yamlКардинальное решение: сменить тариф аккаунта на Pay As You Go. Бесплатные ресурсы остаются бесплатными, платёж идёт только за превышение лимитов, а очередь на выделение ёмкости для платных аккаунтов короче, и машина создаётся с первой попытки. Привязанная карта и контроль лимитов снимают риск нежданного счёта: в консоли настраиваются алерты на бюджет, и превышение бесплатных часов видно заранее. Для серьёзной лаборатории апгрейд аккаунта стоит рассматривать как рабочий приём, а не как трату, потому что бесплатный пакет после него не уменьшается ни на гигабайт.
Сценарий борьбы за машину готовится заранее: сначала пробуют заявку на две единицы OCPU, при отказе снижают до одной, а удачную конфигурацию сразу описывают в Terraform, чтобы повторный запуск сводился к одной команде. По опыту владельцев таких лабораторий, удачные попытки чаще случаются в утренние часы по времени региона, и серия из десятков попыток считается обычным делом. Чем скромнее запрос, тем выше шанс получить машину с первой попытки, а конфигурацию позже можно поднять без пересоздания узла. Пока машина не создана, борьба идёт за квоту, а после создания начинается нормальная жизнь, и дальнейшие шаги уже не зависят от удачи.
Правила простоя и как не отдать машину обратно
Бесплатные машины при простое могут изъять. Критерии платформы конкретны: за семидневное окно загрузка процессора на 95-м перцентиле ниже 20%, сетевой трафик ниже 20%, а для ARM-машин и память ниже 20%. Рецепт прост: машина должна честно работать. Регулярные задания держат утилизацию на нужном уровне естественно: ночные обновления, бэкапы в объектное хранилище, сбор метрик, прогон тестов, синхронизация репозиториев. Уровень загрузки измеряется стандартными средствами: экспортер метрик отдаёт процессор, память и сеть в систему мониторинга, а контроль порога строится на простом запросе 95-го перцентиля за неделю.
quantile_over_time(0.95, rate(node_cpu_seconds_total{mode!="idle"}[7d]))Лаборатория с живыми сервисами обычно не проваливает ограничения, а вот машина, созданная ради галочки и забытая на месяц, попадает под изъятие вместе с содержимым диска. Полезно раз в неделю смотреть на перцентили: если машина простаивает, ей добавляют настоящую работу, ведь задачи в лаборатории всегда найдутся. Типовые роли для такого узла легко назвать: собственный реестр контейнерных образов, синхронизатор конфигураций, служба уведомлений, учебный одноузловой Kubernetes. Каждая из них приносит пользу сама по себе и заодно держит машину занятой. Сразу после создания машины стоит закрыть базовые шаги гигиены: обновления безопасности по расписанию, отказ входа по паролю, ограничение входящих портов списками безопасности и регулярный просмотр журналов. Бесплатная машина видна всему интернету, и сканеры находят новорождённые узлы за считаные часы.
Практичная компоновка домашней лаборатории
Рабочая схема стартует с разведения ролей. Главный ARM-узел с двумя ядрами и 12 ГБ получает контейнерный стек и загрузочный том на 100 ГБ, микро-машина на AMD берёт краевую роль: обратный шлюз, входящие соединения, лёгкая автоматика. Конфигурации всех сервисов лежат в git, создание машин описывается Terraform или cloud-init, и пересоздание узла занимает минуты, а не вечер. Бэкапы конфигураций и данных уходят в бесплатное объектное хранилище по ночам, ключи шифрования лежат отдельно от копий. За живостью машины следит внешний наблюдатель, который проверяет доступность сервисов и шлёт уведомление при пропадании: когда бесплатная площадка молчит, узнать об этом нужно раньше посетителей. Раз в квартал стоит пересоздавать машины из описаний: так лаборатория остаётся воспроизводимой, а не превращается в снежный ком ручных правок, и переезд на любую другую площадку остаётся делом одного вечера.
Прямая отправка почты из облака по умолчанию закрыта, поэтому уведомления и алерты идут через внешние сервисы рассылки, и это учитывается в схеме мониторинга с первого дня. Маршрутизация сервисов строится на поддоменах и бесплатных сертификатах, обновляемых автоматически, и каждый новый сервис добавляется строчкой в конфигурацию шлюза, а не новой машиной. Стек описывается одним файлом композиции, где соседствуют обратный шлюз, мониторинг и служебные контейнеры, и такой файл живёт в репозитории рядом с Terraform-описанием машин.
Чек-лист до регистрации аккаунта
Подготовка до первого входа в консоль экономит недели:
- регион выбран по задержке и опыту сообщества о доступности ёмкости, потому что смена его невозможна;
- план распределения 200 ГБ нарисован заранее, с запасом под рост томов;
- роли машин разведены: основной узел работает всегда, запасной включается под эксперименты;
- список сервисов проверен на наличие arm64-сборок, замены для несовместимых найдены;
- заготовлен cloud-init или Terraform-конфиг для воспроизводимого создания машин;
- составлен план загрузки: фоновые задания держат утилизацию выше порогов простоя, а их расписание проверяется раз в месяц.
Бесплатный ARM-узел не заменит боевой кластер, но для домашней лаборатории это оптимальный старт: настоящие два ARM-ядра, 12 ГБ памяти и приличный канал за ноль в месяц. При дисциплине описания инфраструктуры такая лаборатория годами живёт без единого платежа и остаётся переносимой на любую площадку, когда проект перерастёт бесплатный тариф. Начинается всё с одного файла конфигурации и одного репозитория, и бесплатная машина отплатит за эту дисциплину годами стабильной работы.