Инженер облачных сервисов Yandex

Памятка на основе прохождения курса Инженер облачных сервисов (Сертификат)

• Виртуальные машины
• Disk
• VPC
• Группы WM
• Managed DB
• Object storage
• MySql
• PostgreSql
• MongoDB
• Clickhouse
• YDB
• Hadoop (Dataproc)
• Datalens
• DevOPS
• YC Cli
• Packer
• Terraform
• Docker
• Kubernetes
• Отказоустойчивость
• Мониторинг
• Serverless
• Cloud Functions
• Api gateway
• YDB
• Queue
• Безопасность
• IAM
• Сетевая безопасность
• Шифрование данных
• Оптимизация затрат

Виртуальные машины

Основа, на которой строятся все остальные сервисы.
- Генерация ключа:

ssh-keygen -t ed25519 

ключи будут в ~/.ssh
открытый вставляется в вм, закрытый испольлзуется для авториазции

ssh -i /home/pihel/.ssh/id_ed25519 pihel@158.160.8.190

- после первого подключения лушче обновить ОС:

sudo apt-get update
sudo apt-get upgrade

- пернос вм между фолдерами: yc compute instance move
- можно автоматически выполнить команду из startup.sh после создания вм:

yc compute instance create \ 
--name demo-1 \ 
--metadata-from-file user-data=startup.sh \ 

- можно включить передачу метрик в Ya Monitoring (по умолчанию выключено)
- после 1 входа лучше задать пароль пользователю, чтобы в случае ЧП можно было активировать серийную консоль и сделать отладку в веб интерфейсе:

sudo passwd pihel

- метаданные о ВМ можно получить через HTTP или yc cli

curl \ 
  --header Metadata-Flavor:Google \
  169.254.169.254/computeMetadata/v1/instance/id 

- сэкономить можно, если зарезревировать % cpu или сделать вм прерываемой (как минимум раз в 22-24 часа, поднимать нужно самим)

Disk

- скорость дисков network-ssd-nonreplicated (без репликации) = network-ssd-io-m3 ( с репликацией в рамках 1 зоны)
данные дисков хранятся блочно: SSD=32ГБ, HDD=256ГБ, по этому у ссд лучше скорость чтения по сети. Чем больше блоков, тем выше скорость
- снимок диска вм = поблочный бэкап.

yc compute snapshot create --help

Безопасно заморозить перед бэкапом или выключить ВМ:

#остановить приложение 
sync #скинуть на диск кэш ОС 
sudo fsfreeze --freeze /mnt/abc #заморозить фс
sudo fsfreeze --unfreeze #разморозить

- снимок реплицируется во все зоны доступности
загрузочный диск можно восстановить только пересозданием вм
образы дисков - для распространения или переноса с локальной вм (загружать нужно в s3)

VPC

- ip для подсетей: 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16
диапазон от /16-/28 - 2 ip заняты под шлюз и днс
- NAT - сопоставление внутреннего адреса внешнему
- создание сети - создает подсети в каждой зоне доступности + можно создавать свои
- Таблицы маршрутизации: отказоустойчивость, весь трафик через один машрут, выход в инет через шлюз
- группы безопасности (фаервол): если есть правила только для исх. тарфика, то входящий ответ все равно примется (облако запоминает источник)
по умолчанию не заблокировать: сервер метаданных (169.254.169.254) и днс сервер *.2

- Балансировщик
целевая группа - список вм для балансировки
тут же задается правила проверки состояния (жив/мертв вм)
обработчик - переправление порта с-на

Группы VM

Группы вм - создание нескольких вм по общему шаблону
с авторасширение и удалением (можно разрешить немного превышать и уменьшать целевую группу, если ктото вышел из строя)
- Авто масштабирование:
масштабирование от цпу: стабилизация (сколько не может быть уменьшена группа после расширения), разогрев (время игнора метрик после разворачивания), частота измерения. Вообще можно использовать любые метрики из мониторинга

Managed DB

Object storage

- по апи совместимо с s3
- нет редактирования
- имя бакета уникальное на весь яндекс
- идентификатор объекта - полный путь с файлом, т.е. структура плоская (сгруппированы в бакеты)
- хранение делится на горячесть, чем холоднее, тем дешевле хранить, но дороже обращаться
у ледяного мин. срок хранения = 12мес. Класс задается для бакета
- метаданные над объектами: дата, изменение, хэш + пользовательские (x-amz-meta-) - все в нижнем регистре
- доступы:
IAM: storage.viewer=viewer, storage.uploader+editor+предыдущее=editor, storage.configurer+admin+предыдущее=admin
ACL - доступ к объектам S3 для группы пользователей
Политика доступа - ограничения на действия (лист, открыть, загрузить и т.д.) с определенным условием (реферер, ип, префикс с3, юзер)
ACl - точечные правила, для большого числа однотипного лучше Политика доступа
- через жизенный цикл можно настроить правила для файлов по маске (перенос в холодное)
- установка параметров файла

s3cmd modify \ 
--add-header=x-amz-meta-patient:ivanov \ 
--add-header=x-amz-meta-status:ok \ 
s3://pihel/image01.dat \ 
s3://pihel/image02.dat

просмотр метаданных

s3cmd info \
s3://pihel/image01.dat \ 
s3://pihel/image02.dat

- файл из с3 можно пошарить на короткий промежуток времени через "получить ссылку"
- бэкапирование через - изменение проверяется через проверку хэш суммы
s3cmd sync s3://
так же можно бэкапить через winscp
winscp.exe /ini=nul /script=backup.bat
- для всего бакета можно включить версионирование, к файлу добавляется номер версии и хранятся все предыдущие (отключить нельзя, только приостановить. вычищать вручную. Версия у новых объектов = null)

MySql

- классы дисков: стандартные сетевые + локальный ссд, но только в конфигурации из 3 серверов
- при остановке кластера с local-ssd ресурсы не высвобождаются и плата все равно зымается
- размер можно поменять, а тип нельзя
- бэкап не оплачивается, если его размер+бд меньше зарезервированного (скорость восстановления 10МБ/с на 1 ядро)
- на создание есть квоты, но их можно увеличивать через сд
- есть резевирование ресурсов на долгий период со скидкой
- оплачивается только исходящий внешний трафик (входящий и внутри - бесплатно)
- есть авто обновление ПО ОС и самой БД
- получение сертификата яндекса:

wget "https://storage.yandexcloud.net/cloud-certs/CA.pem" -O ~/.mysql/root.crt 
chmod 0600 ~/.mysql/root.crt 

- в логах в консоли можно сразу посмотреть медленные запросы (MYSQL_SLOW_QUERY)
- при восстановлении из бэкапа создается копия кластера

PostgreSql

- репликация - поддерживается только синхронная, реплики RO (снижает производительность записи на 30%)
- есть физическая и логическая репликация. Логическая репликация может быть каскадная и работает по pub-sub (нужна роль mdb.admin)
Перенос бд в облако
- источник
/etc/postgresql/10/main/postgresql.conf
-- включаем SSL (шифрование + сжатие)
-- включаем логический wal: wal_level=logical
-- в /etc/postgresql/10/main/pg_hba.conf добавляем хосты облака (куда переносим)

hostssl    all            all             <адрес хоста>      md5 
hostssl    replication    all             <адрес хоста>      md5 

-- открыть фаервол в источнике (если есть)
-- дампим только схему бд

pg_dump -h <адрес сервера СУБД> \ 
    -U <имя пользователя> \
    -p <порт> \ 
    --schema-only \ 
    --no-privileges \
    --no-subscriptions \

-- создаем публикацию всех таблиц

CREATE PUBLICATION p_data_migration FOR ALL TABLES;

- бд приемник
-- восстанавливаем схему
pg_restore -Fd -v --single-transaction -s --no-privileges
-- подписываемся на бд источника

CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес сервера-источника> port=<порт> user=<имя пользователя> sslmode=verify-full dbname=<имя базы данных>' PUBLICATION p_data_migration;

-- следим за репликацией
pg_stat_subscription, если srsubstate=r , то репликация завершилась
- останавливаем работу БД источника и бэкапим сиквенсы

pg_dump -h <адрес сервера СУБД> \ 
    -U <имя пользователя> \ 
    -p <порт> -d <имя базы данных> \ 
    --data-only -t '*.*_seq' > /tmp/seq-data.sql 

- в бд приемника восстанавливаем последовательности

psql -h <адрес сервера СУБД> \ 
    -U <имя пользователя> -p 6432 \ 
    -d <имя базы данных> \ 
    < /tmp/seq 

- отключаем репликацию и переносим нагрузку

DROP SUBSCRIPTION s_data_migration;

- перенос так же можно сделать через datatransfer: может и копирование и репликация и вместе

MongoDB

- хранит JSON
- консольная утилита для доступа: mongodb-mongosh

db.createCollection("users")
db.users.insertOne({firstName: "Adam", lastName: "Smith", age: 37, email: "adam.smith@test.com"}); 
db.users.find() 
#поиск по json:
db.users.find({age: {$gt: 37}});

- шардирование: быстрота отклика, законы, надежность, скорость, масштабирование
шардирование автоматическое с версии 4: по хэшу или рэнжу ключа
данные с шардов дополнительно реплицируются на отдельные хосты
- для выбора мастера, лучше чтоб было нечетное число хостов
т.е. минимум для шардированной бд: 2 шарда + 2 реплики на каждый шард (=6)

Clickhouse

- в шардированном CH дополнительно нужно 3 хоста ZK - для распределния запросов, репликации и т.д.
- есть возможность гибридного хранения данных на сетевых дисках и на с3
- LTS версии поддерживаются год (выходят раз в пол года)- обновление происходит автоматом
- можно читать из s3

s3( 
'https://storage.yandexcloud.net/arhipov/weather_data.tsv', 
'TSV', 
'LocalDateTime DateTime, LocalDate Date, Month Int8, Day Int8, TempC Float32,Pressure Float32, RelHumidity Int32, WindSpeed10MinAvg Int32, VisibilityKm Float32, City String') 

- загрузка локального файла:

cat weather_data.tsv | clickhouse-client \ 
--host r**.mdb.yandexcloud.net \ 
--secure \ 
--user user1 \ 
--database db1 \ 
--port 9440 \
-q "INSERT INTO db1.Weather FORMAT TabSeparated" \ 
--ask-password 

загружать можно и по HTTP

- бэкапы хранятся целиком раз в 7 дней, потом инкремент подневый (резервируются только MergeTree)
- шардирование через шаред-насинк, запрос маршрутизируетс на конкретную ноду (2 не могут использоваться)
- есть словари в виде хэш массивов в памяти
- есть гео функции и МЛ (catboost)

YDB

newSQL = oltp + olap
- степень изоляции - serializeable, реляционная
можно ослабить: Online Read-Only - чтение грязных данных , Stale Read Only - отставание от актуальных
- режим развертывания:
--dedicated (сами управляем виртуалками и расширяем) - оплата за ресурсы
--serverless - облако управляет этим - оплата за операции (не подходит для большой нагрузки)
- язык YQL или Document API — HTTP API (как у DynamoDB)
- первичный ключ обязателен - данные упорядочены по ключу
- диапазон первичного ключа используется для шардирования (партицирования) - может быть автоматически, может на определенное число, может по диапазонам
- группа хранения - 9 дисков, по 3 в каждой зоне
- авторизация через сервисный аккаунт:

yc iam key create \ 
--service-account-name sa-ydb \ 
--output ~/.ydb/ydb.json  
export YDB_SERVICE_ACCOUNT_KEY_FILE_CREDENTIALS=~/.ydb/ydb.json 

- создание вторичного глобального индекса:

ALTER TABLE <имя таблицы> ADD INDEX <имя индекса> GLOBAL ON (<имя столбца>);

replace/upser - это вставка с заменой, если данные уже есть
insert - вставка с проверкой на уникальность
LEFT/RIGHT SEMI - exists
LEFT/RIGHT ONLY - not exists
- типы доступа к данным: FullScan/Scan - таблица, Lookup/MultiLookup - индекс
- есть системные вьюхи с основной информацией
- можно бэкапить на с3. Восстановление возможно в ту же бд, но в другую дирректорию

Hadoop (Dataproc)

- dataproc - рекомендуется 2 бакета: RO для исходных данных, RW для логов и результатов запроса
- для корректной работы датапрок нужен nat Для выхода в инет (описано как создавать тут https://yandex.cloud/ru/docs/vpc/operations/create-nat-gateway)
- нельзя назначить публичный ип, но можно зайти через виртуалку
- для масштабирования используется метрика yarn.cluster.containersPending (но можно и по CPU)

Datalens

- bi инструмент.
- Много коннекторов и визуализаторов (интеграция с я.сервисами) 1с
- есть RLS, есть кэш в CH
- датасет - источник данных: есть прямое подключение и материализация.
- есть возможность лукапа в связанный датасет (можно указать самим или свяжет сам по названию и типу данных)
- для таблиц показателей нужно указывать функцию агрегации
- если нужно использовать поле в измерении и показателе, то его лучше продублировать в датасете
- можно делать вычисляемое поле (как на уровне датасета, так и в чарте)

DevOPS

DevOPS - автоматизация, инрфа как кода, простота создания окружения, масштабирования, отказоустойчивость

YC Cli

- Шаблон вызова команды: yc сервис ресурс действие параметры
- параметры в linux разбиваются через \
- глобальные параметры: каталог
- с помощью профиля можно задать параметры поумолчанию:

yc config profile create project-1 
yc config set folder-name project-1 --profile project-1 
yc config profile activate project-1 
yc config list --profile project-1 

- флаг --help можно ставить для любой команды
- асинхронный запуск команды в ЯО: флаг --async , вернется ID, статус которого можно получить командой

yc operation get <идентификатор_операции>

Packer

создание образов вм, которые можно запускать в системах виртуализации и облаках (только в определенной)
- файл описания образа делается на hcl или json: build (настройки ОС в облаке) + build (софт и команды)

Terraform

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

variable "folder-id" {
  type = string
}
provider "yandex" {
  folder_id = var.folder-id 
} 

- этапы:
-- terraform init - выполнение provider
-- terraform plan - проверка ошибок и плана выполнения
-- terraform apply - запускает развертывание
- у terraform есть json стейт, где хранится что уже установлено, что ускоряет установку
- подключить стейт: terraform import , удалить terraform state rm , посмотреть terraform show

Docker

- использует ядро оборудования и ядро ОС от хостовой ос - легче, независимей
- образ создается с помощью инструкций. Пример:

FROM ubuntu:latest 
RUN apt-get update -y 
RUN apt-get install -y nginx 
ENTRYPOINT ["nginx", "-g", "daemon off;"] 

- билд:

docker image build -f my-dockerfile -t my-image .

- запись в хранилище образов, получение и запуск:

docker push my-image 
docker pull my-image 
docker run my-image

- Yandex Container Registry:
нет сетевого трафика вовне облака, приватно для компании, удаление старых образов (при наличии новых), работа через инструменты яо
- репозиторий - набор версий одного образа
- к образу нужно добавлять еще тег
cr.yandex/<реестр>/<имя образа>:<тег>
- если не указать тег, то он будет = latest
- для поиска можно использовать регулярные выражения:
cr.yandex/my-registry/my-app:test.*
- Имя для образа:
docker build . -t cr.yandex/<идентификатор_реестра>/ubuntu-nginx:latest
- Политики удаления по тегу и времени (expire_period), часть образов можно оставить (retained_top). Можно протестировать работу через тестовый запуск (dry-run)
- Container Optimized Image - обычная виртуальная машина, в которой предустановлен докер и можно указать образ при старте, который сразу будет запущен

Kubernetes

- под - логический хост, несколько подов - узел (node - физ. или логическая машина), группа узлов - кластер
- мастер - запускает поды, планирует ресурсы
- в 1 физическом кубере, может быть несколько логических (namespace)
- Можно ставить вспомогательные сервисы: веб интерфейс web-ui-dashboard, мониторинг ресурсов resource-usage-monitoring , днс dns-pod-service (обязательно)
что делает: развертывает, мониторит и балансирует, хранилище, перезапуск упавшего
- Yandex Managed Service for Kubernetes: ЯО сам ставит необходимые сервисы и обновляет их, автоматическое масштабирование, графический интерфейс, Yandex Container Registry для хранения образов, репликация мастера в зонах ЯО, добавление пользователей через идентификацию пользователя
- нужно 2 сервисных аккаунта: 1 для выделения машин, 2 для доступа к докер образам
- релизные каналы задают как обновлять софта в кластере (REGULAR)
- мастер - управление кластером: зональный (1), региональный (в каждой зоне)
- группы узлов - настройки как у группы ВМ
- управление кубером происходит через cubectl
настройка:

yc managed-kubernetes cluster get-credentials --id catjjatqj1vg75vg6ef5 --external 

подключение сохраняется в /home/pihel/.kube/config
просмотр подключения: kubectl config view
- приложение деплоится через yml (kind: Deployment) в spec основная конфигурация, template/selector определяют какие поды будут использоваться приложением, в containers указывается образ приложения
применение манифеста yml с новым приложением:
kubectl apply -f my-nginx.yaml
- список подов:

kubectl get pods -o wide

- полная информация о других частях кластера:

kubectl get pod,svc,hpa,nodes -o wide

- максимально подробная информация о приложении:

kubectl describe deployment/my-nginx-deployment

- увеличить число подов под приложение можно редактирование реплик в yml и выполнением apply или командой:

kubectl scale --replicas=3 deployment/my-nginx-deployment

- создание внешнего адреса для взаимодействия делается черзе load balancer (type: LoadBalancer: port: 80 -> targetPort: 80)
- автоматическое масштабирование:
Horizontal Pod Autoscaler: указывается limits (cpu/mem/etc) для приложения в поде и requests - сколько доступно в поде, чтоб в нем еще чтото можно было запустить
Cluster Autoscaler - оценивает потребности в подах от HPA и добавляет/убирает узлы
- пример спецификации на пол ядра и 256мб на приложение

spec: 
    containers: 
    - name: nginx-hpa 
        image: k8s.gcr.io/hpa-example 
        resources: 
        requests: 
            memory: "256Mi" 
            cpu: "500m" 
        limits: 
            memory: "500Mi" 
            cpu: "1" 

- Отказоустойчивость:
правильно распределять копии приложения по разным узлам (node anti-affinity / Pod Topology Spread Constraints)
Обновление кубера идет по нодам, минимальное число задается Pod Disruption Budget (minAvailable: 2, maxUnavailable: 1)
кэширование днс через NodeLocal DNSCache
- Основные роли:
-- devops
k8s.admin - создавать кластер, не включает vpc.publicAdmin - давать публичный кластер
k8s.cluster-api.cluster-admin - установка системных приложений
обновление приложения (помещение в реестр) - container-registry.admin
-- developer
k8s.cluster-api.editor - создание приложений
container-registry.images.pusher - добавление образов в реестр
k8s.viewer - просмотр статуса работы
-- узлам нужна роль container-registry.images.puller , чтобы скачивать образы
всему куберу k8s.cluster.agent , чтобы создавать объекты (кроме публичных ип)

Отказоустойчивость

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

Мониторинг

- хранение и визуализация метрик в реал.тайм
в ЯО любой сервис имеет набор преднастроенных метрик, отправляемых в мониторинг
- Yandex Unified Agent - агент поставки метрик в ЯО
- собранные системные метрики хранятся 30 дней (пользовательские не удаляются по умолчанию)
- отправка кастомных метрик через rest-api:
получаем токен авторизации
https://yandex.cloud/ru/docs/iam/operations/iam-token/create-for-sa (создавалось в разделе по terraform)

export IAM_TOKEN=$(yc iam create-token) 
 curl -X POST \ 
     -H "Content-Type: application/json" \ 
     -H "Authorization: Bearer ${IAM_TOKEN}" \ 
     -d '@<путь_к_файлу_my-metrics.json>' \ 
 'https://monitoring.api.cloud.yandex.net/monitoring/v2/data/write?folderId=<идентификатор_каталога>&service=custom' 

- отправка доп. метрик с linux хоста
ставим Yandex Unified Agent : https://yandex.cloud/ru/docs/monitoring/concepts/data-collection/unified-agent/installation
или ставим "Агент сбора метрик" при создании ВМ
- Prometheus - бд временных рядов , сама опрашивает источники. Можно поставить в докере подложив ему конфиг ЯО: https://yandex.cloud/ru/docs/monitoring/operations/metric/prometheusExport
по умолчанию метрики прометеуса можно сразу отображать в графане - авторизации нет.
- алерты: считается среднее за 5 минут, чтобы исключить пики
настраивается на тех же метриках, что на графиках в мониторинге
границы сразу видно на графике, разные типы уведомлений. Алерт приходит со скрином

Serverless

Cloud Functions

Cloud Functions - func as service (FaaS)
- представляет из себя пустой контейнер, чтобы запустить код в функции, нужно создать версию (поместить в нее код)
- запуск приложения на 1 из 8 языков (py,java,bash,php,...), платим только за число вызовов, время работы, потребление памяти и исходящий трафик
- Есть бесплатное число вызовов для тестов и ознакомления.
- Состав cloud function:
* набор виртуалок с предустановленными рантаймами на нужных языках
* логирование
* набор триггеров с/для внешних сервисов
* sdk для облегчения работы
- Ограничения:
* ограничение по времени (есть жесткий таймаут)
* нет возможности хранит стейт внутри функции или обмениваться между
- Можно загрузить архив своей программы. Нужно указать точку входа: <имя файла с функцией>.<имя обработчика вызова>
- После создания есть возможность сразу протестировать и посмотреть как выглядит json для вызова.
- Обновление кода функции через cli

yc serverless function version create \ 
    --function-name my-first-function \ 
    --memory 256m \ 
    --execution-timeout 5s \ 
    --runtime python37 \ 
    --entrypoint index.handler \
    --service-account-id $SERVICE_ACCOUNT_ID \ 
    --source-path index.py

- вызов функции по ID из yc

yc serverless function invoke <идентификатор_функции>

- функцию можно сделать публичной, тогда обращение к ней возможно по url извне облака
- Требования к коду:
* контекст - параметры запуска и состояния
* если запросы поступают быстрей, чем функция работает, то поднимается доп. экземпляр
* обновление кода происходит через создание версии и пометкой тэгом
последняя версия имеет тег $latest
- чтобы общаться к предыдущей версии, нужно ей задать тег вручную (можно задавать несколько тегов)

yc serverless function version set-tag \ 
  --id <идентификатор_версии> \ 
  --tag <тег>

- Функция может быть вызвана по триггеру от: queue, s3, container, logs, IOT
- но может вызываться и по расписанию
Пример создания триггера, который вызовет функцию на создание нового файла в бакете:

yc serverless trigger create object-storage \ 
  --name my-first-trigger \ 
  --bucket-id $BUCKET_NAME \ 
  --events 'create-object' \ 
  --invoke-function-name my-trigger-function \ 
  --invoke-function-service-account-id $SERVICE_ACCOUNT_ID 

при создании файла в бакете вызовется триггер функция, вызов будет видно в логах:

yc serverless function logs my-trigger-function 
2024-11-17 17:59:03       Starting function after trigger 

2024-11-17 17:59:03       {'messages': [{'event_metadata': {'event_id': '4898e0d1-3a75-4a95-89d9-ddc82b4df28d', 'event_type': 'yandex.cloud.events.storage.ObjectCreate', 
'created_at': '2024-11-17T17:59:00.637668971Z', ...}]}} 

- Если нужен доступ до бд, то нужно создать подключение в разделе cloud functins
В скрипте обращение к конекшену будет через переменную окружения , а пароль из контекста функции входа

def entry(event, context): 
    connection = psycopg2.connect( 
        database=os.getenv("CONNECTION_ID"), # Идентификатор подключения 
        user=DB_USER, # Пользователь БД 
        password=context.token["access_token"],

Вызов триггера по расписанию:

yc serverless trigger create timer \
  --name trigger-for-postgresql \
  --invoke-function-name function-for-postgresql \ 
  --invoke-function-service-account-id $SERVICE_ACCOUNT_ID \ 
  --cron-expression '* * * * ? *'  

Api gateway

- статический ответ в зависимости от параметров (type = dummy)
- вызов cloud function с параметрами (type = cloud-functions)

x-yc-apigateway-integration: 
  type: cloud-functions 
  function_id: <идентификатор функции>
  tag: <Тег функции>
  service_account: <идентификатор сервисного аккаунта>

- чтение s3 (type = object-storage)

x-yc-apigateway-integration: 
  type: object-storage 
  bucket: <Имя бакета> 
  object: <Имя объекта>
  presigned_redirect: <Генерация пре-подписанного url> 
  service_account: <идентификатор сервисного аккаунта, от имени которого идет обращение к Yandex Object Storage>

- пересылка по другому url и получение ответа (type = http)
- как у функций есть бесплатный лимит
- использует спецификацию open api 3
Шаблон openapi: 3.0.0:

info: 
  title: <Название API> 
  version: <Версия API> 
paths: 
  <Путь 1>: 
    <Метод>: 
      x-yc-apigateway-integration: 
        type: <Тип расширения> 

YDB

работа через ydb sdk, есть документное расширение совместимое с aws dynamo db
плата за размер, потребляемые ресурсы (можно ограничить лимитом сверху/с)
можно купить почасовой лимит в пределах (если лимит = почасовому пределу, то платим фикс за время)

Queue

для развязывания систем с разной интенсивностью
- fifo - для строгой последовательности доступа
- в стандартных последовательность не гарантируется
состав сообщения:
- тело, атрибуты, хэш тела, ID
- ReceiptHandle - подтверждение от принимающией стороны (признак для удаления из очереди)
отправитель и получатель сам обращается к очереди. Получатель может помечать сообщение в обработке, а после удалять
параметры очередей:
- время скрытие из очереди после прочтения получателем
- время хранения, пока сообщение не прочитает получатель
- макс. размер
- время задержки до появления сообщения в оререди
- макс. время ожидания нового сообщения, если сообщение не получилось, вернется пусто
- дед леттер - очередь необработанных или плохих сообщений
тарифицируется число сообщений и исходящий трафик
API совместимо с AWS sqs
запись в очередь:

import boto3
# Create client 
client = boto3.client( 
    service_name='sqs', 
    endpoint_url='https://message-queue.api.cloud.yandex.net', 
    region_name='ru-central1' 
)
QUEUE_URL="https://message-queue.api.cloud.yandex.net/***/my-first-queue" 
# Send message to Queue
client.send_message(
    QueueUrl=QUEUE_URL, 
    MessageBody='ssdfsdfsdf:123' 
) 

извлечение из очереди

messages = client.receive_message( 
    QueueUrl=QUEUE_URL, 
    MaxNumberOfMessages=1, 
    VisibilityTimeout=60, 
    WaitTimeSeconds=1 
).get('Messages') 
#удаление после прочтения 
client.delete_message( 
    QueueUrl=QUEUE_URL, 
    ReceiptHandle=msg.get('ReceiptHandle')
) 

Безопасность

- распределение ответственности: провайдер следит за железом и софтом, пользователь за настройками, правами и сетью (может чуть смещаться в зависимости от типа сервиса)
- данные пользователей шифруются в хранилище, передаваемые шифруются TLS
- изоляция машин происходит на уровне гипервизора и сетевых настроек
- сервисы ЯО: IAM для разграничения доступов, KMS - шифрование ключами, Lockbox - секреты, сетевая: VPN, DDOS, NAT

IAM

- Верхнеуровневая авторизация: Yandex ID (Oauth) , Федерация (ID пользователя берется из AD предприятия)
Верхнеуровневая кука или ответ AD обменивается на IAM токен и устанавливает куку на поддомен cloud.
- Сервисные аккаунты: под ними нельзя зайти в веб интерфейс, но можно выполнять действия через апи.
* открытый и закрытый ключ для получения IAM токена
* API ключи - упрощенный вариант авторизации для некоторых сервисов
* статический ключ - для aws совместимых сервисов (s3, queue)
- Выдача прав через роли. Роли могут входить в другие роли.
Т.е. если даны права на каталог, то они распронятся на все ресурсы каталога.
- Права ролей объединяются, но никогда не убавляются (т.е. уменьшить права дочерней ролью не получится)
- Примитивные роли: viewer/editor/admin можно использовать только для тестирования. Нужно давать роли продуктов, которые являются подмножествами примитивных.
resource-manager.clouds.member - обязательная роль для входа в облако.
resource-manager.clouds.owner - лучше дать нескольким человекам и настроить на них доп. проверки (а Yandex ID не использовать или использовать только в крайней ситуации)
billing.accounts.owner - не может подключен к федерации и испольлзует Yandex ID. После каждого использования менять пароль.
- Работу с деньгами лучше поместить в отдельное облако. Общие ресурсы (бакеты, сети), лучше хранить в одном фолдере.

Сетевая безопасность

- NAT - трансляция внутренних адреосов во внешние. Ограничивать порты или делать впн. Минимальные права для функционирования.
- Группы безопасности - фаервол (по умолчанию все запрещено, можно только разрешать)
-- self - общение внутри группы безопасности
- лучшие практики:
- виртуалка с группами безопасности и доступом по ссш для управления инфрой из инета

Шифрование данных

- TLS - сертификат шифрования подтвержденный удостоверяющим центром. (домен, юр. инфа, центр сертификации, срок действия, публичный ключ для шифрования)
- самый быстрый вариант шифрования - симметричный ключ. Он используется во всех частях системы, но чтобы его сложней было украсть, он шифруется ассимитрично (envelope). Т.е. для его использования нужно сначала расшифровать и если украдут ключи, то будет время их поменять, пока их расшифровывают. Расшифрованный ключ находится только в памяти во время работы.

Оптимизация затрат

- Sku - единица учета
- порог оплаты - допустимый минус (только если оплата картой)
- калькулятор для расчета стоимости https://yandex.cloud/ru/prices
- 4 уровня тех.поддержки (первый бесплатный)
- метками удобно разделять группы ресурсов (проекты, тесты и т.д.)
- уведомление о перерасходе можно настроить в бюджете (можно целиком для облака, а можно на конкретные сервисы), можно настроить уведомления на пороги
- можно получить значительную скидку, если зарезервировать ресурсы на длительный срок