Комментарии 7
Даже читать статью не хочу. Мы потратили несколько дней, выдавая доступы на Яндекс.Облако. Совсем тупые и неочевидные моменты в раздаче прав на консоль. Многие сдаются и просто отдают логин-пароль другим, чтобы не мучиться. К сожалению, в нашей православной нельзя пользоваться облаками здорового человека.
Работаю с YC уже некоторое время и меня смущает взаимодействие каталогов с некоторыми сервисами. Допустим, если приложение развернуто так, что каждое окружение (dev/stage/prod) в отдельном каталоге, то условный Container Registry (который по идее один на все окружения) хранить в отдельном каталоге?
хорошей практикой под такие штуки(сети,реджистри, днсы и etc) является отдельный каталог.
Как уже отметил коллега: в таком случае для общих сервисов лучше использовать каталог common/infra. И там разворачивать инфраструктурные сервисы, общие для остальных окружений: Сontainer Registry, хранилище метрик наподобие Victoria, Elastic для сбора логов и так далее.
Можно ли в Яндекс диске делать объекты ограниченого по токену доступа? Например, хочу подключить плеер к папке с музыкой, а общий логин-пароль не выдавать.
Недавно выполнял заказ по автоматизации развёртывания VM в Yandex Cloud с помощью Ansible и deploy приложения (тг бот на python + postgresql). Понимаю, что с помощью одного Ansible это делать не совсем правильно наверное, тот же terraform для развёртывания VM куда более удобен, но так пожелал заказчик. Так вот, по итогу заказчик был сильно удивлён тому, что ему предварительно нужно указать folder_id, image_id, subnet_id и т.д. Он хотел бы вбить логин и пароль и поехали. Надо бы эту статью ему скинуть).
Спасибо за комментарий! Рад, что статья полезна)
Для развертывания одной ВМ это может и не совсем удобно, но в облаке Yandex Cloud может быть развернута достаточно сложная инфраструктура с различными каталогами, сетями и разграничением доступа к ним. В этом случае как раз важно указывать, какой ресурс в каком каталоге и в какой подсети будет создаваться.
К тому же такого рода идентификаторы являются уникальными в рамках всего облака, и их явное указание поможет позволить избежать ошибочного создания ресурса из-под другого аккаунта в другом облаке, указав идентификационные данные аккаунта с доступом в другое облако.
С подсетями тоже есть такой момент, что могут быть созданы разные подсети, с доступом в Интернет и без него. В результате, указав идентификатор сети, мы можем выбрать, будет ли ВМ иметь доступ в Интернет или только к хостам в той же сети.
Сам себе DevOps: как разобраться с доступами в Yandex Cloud