Ок, идем в клауд.реп, открываем исх. код и видим, что действительно все запушилось ок, т.е. изменения есть
но деплоя нет )))

... а в ответ тишина, тогда еще один вопросик )))
есть пайплайн на пап/сабе, в основном он из гугл-функций,
но один из шагов нужно сделать на VM instance
ок, пишем функции старт и стоп для инстанса
НО:
- инстанс стратует оч. долго - десятки секунд
- на инстансе нужно поднятый сервис, который тоже стартует достаточно долго после старта ОС на инстансе
- и хотелось бы вызвать этот сервис с параметром, например имя файла, который должен быть чем-то вроде параметра при запуске инстанса

Внимание, вопросы )))
1. Есть ли способ (кроме куберн.) запустить инстанс с сохраненым состоянием (т.е. с уже поднятыми сервисами)?
(что-то типа как в Винде выход ОС из спячки/заморозки)
2. Как лучше передать инстансу "параметры" извне? Через переменные ОС? ... ?

Уточнение:
Вернее нужно, чтобы поднималось одновременно несколько репликаций этого инстанса с сохраненным состоянием, т.к. пайп-лайны выполняются асинхронно по событиям
Да, про кубер все понятно, но хотелось бы сэкономить и сделать более "изящно"

почему "но один из шагов нужно сделать на VM instance"? Откуда такое ограничение?

сервис, который нужно использовать, поднимается только под определенными ОС и обладает рядом требований

в контейнере не сможет?

вступление:
инстансы - предположены быть нужными несколько часов как минимум. чтобы старт/стоп в несколько минут был незначительным.

как же быть?
а. можно "нагревать" инстанс раньше, чем сервис нужен.
б. можно просто обзавестись терпением

хранение состояния:
1. в ведре, app specific impl.
2. хранить диск приложения

во всех случаях надо следить за синхронизацией.

кстати preemptible так и используют: запускается старт скрипт либо шатдаун скрипт

вообще передавать данные удобно через ведро.

> а. можно "нагревать" инстанс раньше, чем сервис нужен.
до этого додумался, да такое возможно заранее в пайп-лайне + чтобы иметь отдельные раликации, можно их создавать - это понятно как сделать в гугл-функции

> 1. в ведре, app specific impl.
плз, расшифровку )))

> 2. хранить диск приложения
это можно для сокращения времени установки, но не сокращает врем старта и ресурсы на это
Хотелось бы, чтобы восстанавливалось именно "замороженное" состояние ОС

имхо, заморозка системы - это специально опущено, "потому что кубернет".
ибо system migration изначально очень дорогое удовольствие.

насчет ведра:
application specific state implementation: т.е. реализуй заморозку состояния сервиса сам

т.е. нужно делать (не зарекаюсь) какое-то периодическое сохранение состояния (типа snapshotting).

"дешевле" - но труднее, сохранять дифф состояния.

да, похоже что кубер продвигают

вот это то, что нужно наполовину )))

ессно чем объемнее твой батч данных, и нагрузка на память, тем больше взрослых дикобразов придется родить.

наполовину, потому что не задача сохранять состояние сервиса поднятого под ОС через снепшоты
задача - сократить время на старт этого сервиса - оч. долго разворачивается

приготовься, покупай много ниток и иголок, штопать будешь много.

мне кажется тебе стоит посчитать что стоит дороже - убитые часы разработки, или же плата за compute+store.

В user data при запуске можно передать параметр. Если нужно что-то тригернуть из виртуалки - http и пабсаб везде доступны