Ідентифікація робочого навантаження, без ключів
BYOC у Google Cloud
Програми запуску у вашому проекті GCP із ідентифікацією робочого навантаження, локальним SSD і кешуванням реєстру артефактів.
Ідентичність робочого навантаження
Об’єднана автентифікація без ключів службового облікового запису для ротації чи витоку.
Локальний SSD
Приєднайте локальний NVMe до профілю диска, який використовують розміщені програми.
Реєстр артефактів
Наскрізне кешування зберігає зображення у вашому проекті.
Часті запитання
- Чи потрібні мені ключі сервісного облікового запису?
- Ні. Замість цього використовується об’єднання ідентифікаційних даних робочого навантаження, тому немає довгострокових облікових даних JSON, які потрібно ротувати або витікати. Використовуйте умову довіри для власника сховища як мінімум.
- Чи має значення локальний SSD?
- Значно. Кроки CI, які містять велику кількість файлів, прив’язані до диска, а локальний NVMe — це те, що надає запускачам BYOC той самий профіль, що й розміщений продукт. Це також обмежує, які сімейства машин ви можете використовувати, тому спочатку виберіть диск.
- Чи підтримуються програми запуску Windows на GCP?
- Підтримка більш обмежена, ніж на AWS і Azure. Перевірте сторінку обмежень Azure, щоб дізнатися про поточну матрицю можливостей постачальників.
Ваш наступний білд може бути вдвічі швидшим і вдвічі дешевшим
Почніть безкоштовно. Піти — це той самий один рядок, і цей diff ми теж публікуємо.