Богдан Стефанюк: дописи з тегом cloud

Где захостить свое приложение?

Wed, 15 Dec 2021 04:34:45 -0400

Как и многие другие разработчики я часто делаю разные небольшие приложения или пет-проекты. И очень часто возникает вопрос: где захостить приложение и его компоненты и как это сделать максимально дешево?

Я старался подобрать сервисы, которые позволяют максимально просто и дешёво запускать все необходимые для работы приложения ресурсы. В основном большинство приложений состоит из бекенда (в моем случае .NET), фронтенда и базы данных. Поэтому рассмотрим варианты развертывания каждого компонента.

Типы сервисов

Для начала стоит кратко пройтись по моделям предоставления сервисов в облаке. Эти модели описывают зоны ответственности пользователя и облачного провайдера. В разрезе данной статьи нас интересуют следующие модели:

IaaS (Infrastructure as a Service) — облачный провайдер предоставляет минимально необходимую инфраструктуру в виде виртуальных машин, сети и хранилища, а также отвечает за работоспособность. Дальнейшая настройка, в том числе и ОС, лежит на стороне пользователя. По сути это основные строительные блоки в облаке с помощью которых можно сделать все что захотим.
PaaS (Platform as a Service) представляет из себя готовую инфраструктуру для разработки и запуска приложений. При такой модели мы не думаем про настройку и управление серверами, операционными системами и т. д. Примером такого сервиса являются управляемые БД (managed databases). Облачный провайдер сам отвечает за правильную настройку сервера, ОС, сохранность данных, бекапах и бесперебойную работу. В основном пользователь только платит деньги и пользуется сервисом.
Serverless, самая свежая модель, которая очень похожа на PaaS. Только при такой модели облако само выделяет ресурсы на основании текущей нагрузки. Все настройки и планирование ресурсов скрыто от пользователя. Ему остается только загрузить свой код, а все остальное сделает облако. Также в serverless мире обычно оперируют понятием облачная функция это код, который умеет обрабатывать только одни конкретный запрос.

Наглядный пример зон ответственности в разных моделях предоставления сервисов.

Где захостить .NET бекенд?

AWS/Azure/GCP

Три самых крупных облачных провайдера, очень похожи между собой и предоставляют во многом одни и те же сервисы. Так в каждом из них можно арендовать виртуальные машины, создать управляемую БД или работать с облачными функциями. Мне больше всего нравиться AWS, но для .NET приложения Azure будет более интересным, потому что это родная для дотнета среда.

Больше всего нас интересую сервисы:

AWS EC2 (IaaS) обычные виртуальные машины. Есть маркетплейс на котором можно найти огромное множество готовых AMI образов с предустановленным софтом и нужными настройками. Например можно в один клик развернуть виртуалку с Wordpress и всем необходимым.
Azure App Service (PaaS) самый простой и нативный способ захостить .NET приложения. App Service сам разворачивает приложение из репозитория, настраивает все необходимое для работы и предоставляет полезные метрики.
AWS Lightsail (IaaS/PaaS) упрощенная версия AWS для тех кто с ним не знаком. Можно очень дешево арендовать виртуальную машину, поднять докер контейнер, развернуть БД и хранилище для файлов. Все это делается буквально в пару кликов мышкой. Первые три месяца бесплатные.
AWS Elastic Beanstalk (PaaS) умеет поднимать необходимые для работы приложения компоненты в AWS. По сути мы можем все это сделать руками, но Beanstalk автоматизирует всю рутину. Под капотом он представляет из себя набор разных CloudFormation скриптов, которые поднимают необходимые сервисы и настраивают их.

DigitalOcean

Самый простой в использовании сервис. Раньше в DO можно было арендовать только виртуальные машины, сейчас же можно создавать управляемы БД, балансировщики и т. д. На текущий момент почти все мои проекты крутяться в DigitalOcean.

Нам интересны следующие сервисы:

Droplets — виртуальная машина, есть много готовых образов на маркетплейсе под любой рантайм.
App Platform — позволяет нативно запускать приложения написанные на Python, Nodejs, Go, php или любое другое приложение в виде контейнера.

Heroku

Честно говоря я им ни разу не пользовался, но друзья очень часто советуют. Из коробки не поддерживает .NET приложения, но вроде как есть кастомные билд паки. В основном хероку позволяет развернуть приложения на Nodejs, Go, Python и т. д. Из приятных фишек: достаточно запушить код в репозиторий, все остальное сделает Heroku.

Есть бесплатный тариф, в нем приложение останавливается после пол часа без активности. Так что первые запросы к приложению могут отрабатывать немного дольше.

Где захостить фронтенд?

С фронтендом дела обстоят намного проще, есть огромное количество сервисов, которые позволяют бесплатно захостить фронт.

Мой личный фаворит — Vercel. Бесплатный план включает такие фишки как HTTPS, автоматически деплой с репозитория, собственный домен. Также он умеет разворачивать приложение под каждый PR, что позволяет протестировать изменения до того как влить код в основную ветку.

Самым же популярным сервисом является Github Pages. В нем очень просто поднять статический сайт прямо из репозитория. Бесплатный и работает сразу из коробки. В основном используется для хостинга документации к коду, блогов или резюме.

App Platform от Digital Ocean я уже упоминал выше. Можно поднять три статических сайта бесплатно, последующие за 3$ в месяц. Есть автоматический деплой, бесплатный HTTPS, возможность подключения своего домена. Сейчас в нем крутиться мое онлайн резюме. Сервис прикольный тем что в нем можно запустить и бек и фронт.

Последним хочу отметить AWS S3. По сути это объектное хранилище (хранилище для файлов) в котором есть встроенная поддержка сайтов. Для этого нужно загрузить HTML/CSS/JS файлы и включить соответствующую опцию в настройках бакета. Часто встречает в продакшене связку CloudFront + S3.

Где развернуть базу данных?

С базами данных ситуация сложнее, в основном предлагают развернуть БД за большие деньги. Такой вариант не подходит если мы хотим захостить небольшое приложение или просто его потестировать без установки БД локально. Вот несколько из вариантов:

ElephantSQL, можно развернуть PostreSQL базу данных любого размера. Бесплатный план дает базу с 20 Мб и 5 параллельными подключениями.
Mongo Atlas подойдет если нужно развернуть кластер MongoDB. Есть достаточно жирный бесплатный план.
В DigitalOcean и AWS Lightsail начиная с 15 долларов в месяц можно развернуть достаточно неплохой сервер БД, который не нужно настраивать и работает из коробки. В Lightsail первые 3 месяца бесплатно.

Полезные ссылки

Веб аналитика на коленке с помощью AWS

Wed, 04 Aug 2021 03:58:43 -0400

Время от времени нам с друзьями приходят идеи различных проектов, которые было бы круто запустить. Но чтобы убедиться в жизнеспособности идеи нужно ее как-то проверить. Обычно для этого создаётся лендинг, на который нагоняется трафик и потом в аналитике смотрим, как ведут себя пользователи.

В один из таких дней мы решили проверить очередную идею. Но в этот раз пользователь мог сделать много разных действий на сайте и их нужно было как-то отследить и проанализировать.

Это не какая-то уникальная проблема, обычно для таких задач берут Google Tag Manager. Но никто из нас не умел им пользоваться да и желания изучать особо не было.

И тут внезапно пришла идея как это сделать. Можно взять AWS Lambda, набросать на коленке пару строк кода, которые будут получать событие и куда-то их складывать для дальнейшего анализа. Для места хранения метрик выбрал CloudWatch. Он как раз умеет анализировать разные метрики/логи и строить красивые дашборды.

Также хотелось получать письма на почту с информацией про самые важные события. Для этого взяли SNS.

В итоге пользователь заходит на сайт, делает какое-то действие, оно летит в лямбду, которая просто кладет информацию в логи и отправляет сообщение в SNS. Дальше идем в CloudWatch и смотрим на дашборды и анализируем полученную информацию.

Актуальная аналитика

В итоге получилась относительно простая и даже гибкая аналитика, которую можно использовать сразу на нескольких проектах. Сейчас она обходиться в 0$, нам хватает одного миллиона бесплатных вызовов лямбды в месяц.

Но я все же советую изучить и использовать готовые инструменты вместо того чтобы сидеть и делать свои велосипеды. Ведь это очень скользкий путь, в какой-то момент можно забыть для чего это делалось и бесконечно улучшать и допиливать, вместо того чтобы решать задачу.

Отличное видео про основы Docker

Sat, 09 Jan 2021 17:11:26 -0400

Настройка новой виртуальной машины

Sat, 26 Dec 2020 14:54:46 -0400

Время от времени поднимаю виртуальные машины на убунту для своих проектов или экспериментов. Первое что я настраиваю — безопасность. Раньше у меня не было единого чек-листа и приходилось каждый раз гуглить. Поэтому решил сделать такой список и оставить у себя в блоге, чтобы обращаться к нему по мере необходимости.

Чеклист

Создать нового пользователя вместо root.
Настроить доступ по ssh ключам.
Отключить доступ по паролю для ssh.
Отключить доступ для root через ssh.
Заблокировать все порты в ufw, кроме 80, 22 и 443.
(необязательно) Поменять ssh порт с 22 любой другой

Terminal

# Создаем нового пользователя и добавляем в группу sudo.
adduser bstefaniuk
usermod -aG sudo bstefaniuk

# Копируем свой публичный ключ для нового пользователя.
ssh-copy-id bstefaniuk@vps-ip

# Отключаем доступ по паролю и root для ssh.
nano /etc/ssh/sshd_config
## Установить значения:
PasswordAuthentication no
PermitRootLogin no
## Перезапустить службу
systemctl restart ssh

# Настройка ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80
ufw allow 433
ufw enable
## Проверяем что все ОК
ufw status

В будущем хочу написать ansible-playbook скрипт, который будет все настраивать сам.

Хороший мануал по ufw
Генератор конфигураций nginx
Deployment: настраиваем пользователей

GCP: Databases

Wed, 14 Oct 2020 16:24:00 -0400

Google Cloud Platform предоставляет большой выбор разных способов хранить данные. Некоторые из них построены на базе существующих продуктов, другие — собственная разработка гугла.

Для начала нужно понять, что такое managed databases. Это услуга по настройке и администрированию баз данных. Облачный провайдер сам отвечает за работу сервера, установку патчей безопасности, доступность сервиса. Для того чтобы достичь такого же результата с помощью self hosted, нужно иметь в штате специалиста, который умеет администрировать сервера, закупить железо и подготовить инфраструктуру. В случае с managed databases платишь только за то количество ресурсов, которое используешь.

Cloud SQL

Cloud SQL это классический managed database сервис. Он позволяет развернуть 3 самые популярные базы данных. Такие как:

MySQL (5.6, 5.7 и 8.0)
PostgreSQL (9.6, 10, 11, 12)
MS SQL Server 2017

Также гугл гарантирует доступность базы данных на уровне 99,95%. Дополнительно получаем автоматическую репликацию и бекапы.

Ограничения

30 Tb хранилища
60,000 IOPS
624 Gb RAM
Реплики БД только для чтения

Cloud Spanner

Spanner — реляционная база данных, разработка Google. Spanner позиционирует себя как горизонтально масштабируемая база данных, способна хранить петабайты информации, гарантирует строгую согласованность данных. А также доступность 99.999%.

По своей природе Cloud Spanner это распределённая база данных с автоматическим шардированием и репликацией, которые скрыты под капотом. Чтобы создать БД, нужно выбрать локацию (region или multi-region) и количество нод. Количество нод влияет на размер данных, которые кластер способен хранить и его доступность. Каждая нода может обслуживать до 2 Тб данных.

Пример кластера, который состоит из 4 нод. Каждая зона содержит полную копию базы данных и 4 процесса, которые обслуживают эти данные.

Гугл советует иметь минимум 3 ноды для прода. Но есть один нюанс — цена. Cloud Spanner очень дорогое решение, созданное для работы с огромным количеством данных. За 1 петабайт данных прийдется отдать ......... 1 645 568 $ ......... в месяц.

Cloud Big Table

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

Основная фича — наличие интерфейса HBase и нативная поддержка Hadoop. Это позволяет перенести данные с собственного кластера в Big Table без каких либо изменений. Big Table идеально подойдёт для очень быстрой записи и чтения, а также хранения данных типа ключ/значения, размер которых не превышает 10 Мб.

Данные внутри базы данных лежат в огромных таблицах. Грубо говоря, таблица в HBase представлена в виде огромного словаря словарей. Таблица состоит из строк, каждая из которых обычно описывает одну сущность, и столбцов, которые содержат отдельные значения для каждой строки. Каждая строка индексируется одним ключом, а столбцы, которые связаны друг с другом, обычно группируются в семейство столбцов.

Для более глубокого ознакомления советую прочитать главу «HBase» из книги «7 баз данных за 7 недель». Также советую ознакомится с официальной документацией.

Cloud Firestore

Cloud Firestore — это полностью управляемая,документоориентированная serverless база данных, предназначена для разработки serverless приложений. Структура данных сильно напоминает такую в MongoDB.

Firestore поддерживает офлайн режим и живую синхронизацию. С помощью этих фич удобно строить приложения, которые предназначены для совместного использования, например, Google Docs или другие похожие варианты.

А также она пришла на замену предыдущего сервиса — Cloud Datastore. В 2021 году гугл обещает автоматически всех мигрировать с Datastore на Firestore. Это возможно благодаря обратной совместировать с Datastore API.

Firestore имеет два режива работы:

Datastore mode, создан для серверных приложений, совместим с Cloud Datastore. Поддерживает согласованность в конечном счёте.
Native mode, создан для веб и мобильных платформ. Поддерживает строгую согласованость и все основные фичи Firestore.

Детальнее с режимами можно ознакомится в официальной документации.

Cloud Memorystore

Управляемый in-memory сервис, построенный на базе Redis и memcached.

Сравнение

GCP: Cloud Storage

Sun, 11 Oct 2020 04:33:42 -0400

Cloud Storage — сервис хранения неструктурированных данных. Внутри можно хранить все что захотим, но в основном используется как файловое хранилище. Каждый файл представлен в виде объекта, сами же объекты лежал в бакетах.

Бакет avatars содержит аватары пользователей, music — песни.

В Cloud Storage нету ограничений на количество и размер файлов. Мы платим только за то что используем.

Основные понятия

Бакеты
Бакет это коллекция объектов, все файлы должны лежать внутри. Также бакет является центральным местом управления жизненным циклом объектов и доступа к ним. Каждый бакет имеет свое глобально уникальное имя, регион и класс хранения данных. Для работы с бакетом используют конструкцию:

gs://название-бакета

Объекты
Технически Cloud Storage не является файловым хранилищем или файловой системой, это объектное хранилище. Поэтому каждый файл представляет из себя объект, который состоит из двух частей: сам файл и метаданные. Метаданные описывают характеристики объекта в виде ключ-значение.

Иммутабельность
Все объекты иммутабельные, их можно только перезаписать или удалить. При перезаписи предыдущая версия файла будет доступна пока новая успешно не запишется на диск.

Классы хранения

Классы хранения отвечают за доступность и цену хранения объектов.

Standard Storage
Лучший выбор для данных, которые активно используются (горячие данные) и хранятся непродолжительное время.

В свою очередь standard класс можно поделить еще на 3 подкласса: multi-regional, dual-region, single region. Они влияют на доступность файлов и скорость доступа к ним, особенно если пользователи разбросаны по миру. При использовании multi-regional класса автоматически выберется регион, который ближе к пользователю.

Nearline
Для этого и всех что ниже классов появляется стоимость за извлечение данных. Но хранение файлов дешевле.

Такое хранилище отлично подходит для данных, которые редко используются, обычно раз в месяц. Например, бэкапы или архивные данные. Если файлы нужны реже, чем один раз в квартал, лучше использовать Coldline или Archive классы.

Coldline
Используется для данных, которые нужны раз в квартал.

Archive
Самый дорогой в плане доступа к данным, но самый дешёвый для хранения. Файлы в нём должны храниться минимум 365 дней. Подходит для бэкапов и для аварийного восстановления. Но этот класс не имеет SLA для доступности.

gsutil

Для Cloud Storage есть своя консольная утилита. Большенство команд похожи на те что есть в Linux для работы с файловой системой.

С помощью gsutil можно:

Создать и удалить бакет
Загружать, скачивать, удалять объекты
Отображать список объектов
Перемещать, копировать и переименовывать объекты
Редактировать ACLs
Управлять версионированием

Пример команды, которая отобразит список объектов в бакете.

gsutil ls gs://some-bucket

Копирование файлов

gsutil cp -r <source> <target>

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

Cloud Storage поддерживает два механизма обеспечения безопасности: IAM и ACL.

IAM
Про IAM я рассказывал в предыдущей статье. По умолчанию есть 3 типа ролей, они распространяются на проект или бакет. Для тонкой настройки лучше использовать ACL.

Примитивные роли (owner/editor/viewer)
Standard Storage Roles — работают независимо от ACL
Legacy Roles — эквивалентны ACL разрешениям

ACLs
ACL приходят на помощь, когда нам нужно организовать атомарный доступ к отдельным объектам. Каждый элемент ACL состоит из разрешения и пользователя, кому эти разрешения выданы.

Что выбрать?
Первое что нужно понимать — IAM и ACL независимы и не влияют друг на друга. Если использовать оба механизма, можно выстрелить себе в колено. Убрав права на уровне IAM не забудь убрать из ACL.

Гугл советует использовать uniform подход, в котором используется только IAM. При таком подходе мы создаем бакет для конкретной группы пользователей.

Также у IAM есть система аудита, которая фиксирует все действия. Их можно проанализировать с помощью Big Query.

Signed URL
Иногда нужно дать доступ к файлу для пользователя, у которого нет гугл аккаунта. Тут на помощь приходит Signed URL. Он работает также как и ссылки в гугл документах. Единственное отличие в том что все ссылки имеют срок жизни, который мы указываем при создании.

С помощью этого механизма можем дать доступ на чтение, загрузку и удаление. Поэтому следите за тем кому даёте ссылку и с какими правами.

Шифрование

Google Storage всегда шифрует данные на сервере, перед тем как они будут записаны на диск. По умолчанию гугл использует собственные ключи шифрования. Но можно использовать собственные ключи или сгенерировать их с помощью Cloud Key Management Service.

Версионирование

Cloud Storage поддерживает версионирование объектов. Каждое изменение или удаление на самом деле не удаляет файл, а архивирует его. По умолчанию версионирование отключено, но его можно включить с помощью gsutil

$ gsutil versioning set on gs://bucket-name

Объекты для которых есть несколько версий имеют одно имя, но разные идентификаторы.

$ gsutil ls -a gs://my-files
gs://my-files/sample.txt#1602324272958747
gs://my-files/sample.txt#1602324615090803

Количество версий не ограничено из-за чего данные могут разрастись и сжигать больше денег. Для решения этой проблемы существует механизм управления жизненным циклом.

Также нужно помнить что архивные файлы имеют свои ACL, которые могут отличатся от актуальных!

Жизненный цикл

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

Общий вид правил:

В качестве условий можно использовать:

Возраст — время жизни в днях (TTL)
CreatedBefore — объекты созданные до даты (например до 1 апреля 2020)
IsLive — использовать актуальные или архивные файлы
MatchesStorageClass — текущий класс хранения
NumberOfNewerVersions — количество версий

Действия:

Удаление
SetStorageClass — поменять класс хранения

А вот так правила выглядят в жизни:

GCP: Identity and Access Management

Wed, 07 Oct 2020 12:35:52 -0400

Я уже кратко описывал работу прав внутри облака в статье “Google Cloud Platform”. Сегодня расскажу как устроен IAM.

Полики IAM содержат роль, пользователя или группу пользователей. Каждая роль содержит в себе список разрешений.

Модель доступа состоит из трех основных частей:

Участники (members). Любые учетные записи Google, сервисные аккаунты, Google Groups, Cloud Identity или GSuit домен.
Роль (role). Набор разрешений, определяют какие операции можно выполнять с указанным ресурсом.
Политика (policy). Объеденение роли и участников.

Также в качестве участника можно установить два специальных значения:

allUsers — любой пользователь в интернете
allAuthenticatedUsers — любой пользователь, авторизированный с помощью гугл аккаунта, даже если это личный аккаунт

Отдельно нужно упомянуть иерархию ресурсов. Она позволяет группировать ресурсы и централизованно управлять доступами используя систему наследования прав. Политики установленные на уровне папки будут распространятся на все проекты и подпапки.

Основные концепты

Ресурсы
Компоненты, которые выполняют работу. В основном права выдаются на уровне проекта. Но для некоторых ресурсов можно атомарно настроить права. Например выдать права администратора на конкретный экземпляр виртуальной машины.

Разрешения
Разрешения описывают операции, которые можно выполнять с ресурсами. Имеют следующий вид — service.resource.verb.

В большинстве случаев, разрешения соотносятся одним к одному с методами REST API. То есть, каждая служба Google Cloud содержит соответствующий набор разрешений для каждого метода REST API, который она предоставляет.

Роли
Роли — набор разрешений. Несколько разрешений желательно собирать в отдельную роль, которую назначать группе пользователей, вместо того чтобы раздавать разрешения напрямую пользователям.

Роли делятся на три типа:

Примитивная роль (Primitive) — самая простая и общая. Указывает какие действия можно выполнить со всеми ресурсами. Всего есть 4 примитивных роли: owner, editor, viewer и billing administrator.
Предустановленные роли (Predefined). Ими можно тонко настроить права. Указывают кто и какое действие разрешено выполнять с определенным ресурсов. Каждый ресурс в GCP содержит готовый набор predefined ролей.
Кастомные роли позволяют указать любой набор разрешений и предоставить их любому пользователю или группе.

Сервисные аккаунты

Сервисные аккаунты предназначены для взаимодействия ресурсов и сервисов друг с другом. Каждый аккаунт имеет уникальный email. Для того чтобы ресурс смог достучатся к другому, сначала нужно получить токен с помощью Google API и уже с ним идти в другой ресурс. Это происходит автоматически.

Отличия сервисных аккаунтов от обычных

Сервисный аккаунт не имеет пароля. Мы не сможем залогиниться через браузер.
Сервисный аккаунт содержит публичный и приватный ключ с помощью которого он авторизуется в облаке.
Разрешение serviceAccountUser позволяет выдавать пользователя за сервисный аккаунт.

Типы сервисных аккаунтов

Пользовательские, можно создать до 100 аккаунтов, количество можно увеличить, поменяв квоту. Такие аккаунты создаются со следующим электронным адресом: service-account-name@project-id.iam.gserviceaccount.com

Дефолтные — для каждого проекта автоматически создаются два аккаунта, каждый имеет права Editor. Один используется для взаимодействия с App Engine (project-id@appspot.gserviceaccount.com), а второй для Compute Engine (project-number-compute@developer.gserviceaccount.com).

Аккаунты Google API — создаются и управляются на стороне Google, обеспечивают взаимодействие с сервисами гугла.

GCP: виртуальные машины

Wed, 23 Sep 2020 12:46:16 -0400

Compute Engine

В основе почти всех ресурсов в Google Cloud лежат виртуальные машины, которые принадлежат сервису Compute Engine. Впервые они были представлены в 2012 году и отлично подойдут для любых запросов. По сути это обычные компьютеры с Linux или Windows на борту.

Создание виртуалок состоит из нескольких шагов:

Выбрать регион и зону
Определится с типом машины
Выбрать образ
Подключить дополнительные диски
Настроить сеть

Типы VM

Перед созданием виртуальной машины нам нужно определиться с ее типом. Гугл уже насоздавал множество готовых конфигураций и объединил их в 6 групп:

Standard
High-memory
High-CPU
Memory-optimized
Compute-optimized
Shared-core

Если недостаточно представленных ресурсов, можно создать свою конфигурацию, выбрав нужное количество CPU или памяти. В зависимости от типа аппаратной платформы доступно до 96 vCPU, до 768 Гб памяти и диски до 257 терабайт. Каждая конфигурация основывается на соотношении CPU до памяти.

Кроме готовых конфигураций есть еще и аппаратная платформа, всего 4 варианта:

E2 машины имеют оптимизированный расход и содержат до 32 vCPU и максимум 8 Гб памяти на один vCPU. Также у них предопределена платформа процессора, работают на процессорах Intel, либо на AMD EPYC Rome второго поколения.
N2 расширяются до 80 vCPU и до 8 Гб памяти на один vCPU. Работают на процессорах Intel Cascade Lake.
N2D самые мощные в плане количества ядер машины, могут иметь до 224 vCPU, 8 Гб памяти на процессор и работают на базе AMD EPYC Rome.
Машины N1 предлагают до 96 процессоров, 6.5 ГБ памяти на один процессор, и доступны на платформах Intel Sandy Bridge, Ivy Bridge, Haswell, Broadwell и Skylake.

Детальнее в документации: https://cloud.google.com/compute/docs/machine-types

Образы

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

Документация: https://cloud.google.com/compute/docs/images

Диски

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

После удаления вуртуалки вместе с ней удаляется загрузочный диск. Для того чтобы выключить эту опцию нужно отключить опцию “Delete boot disk when instance is deleted”. Кроме того все диски автоматически шифруются ключами, которыми управляет гугл, но у можно использовать собственные ключи.

Для хранения данных есть постоянные диски. Они живут отдельной жизнью и подключаются к виртуальной машине по сети, что не так быстро как физически подключенные диски. Выбрать можем HDD или SSD. Первый дешевле, но медленнее чем SSD. Чтобы изменить размер диска не надо выключать виртуалку. В качестве бекапа выступают инкрементальные снапшоты.

Local SSD
Отдельный тип дисков, которые физически присоединены к виртуалке. Они производительнее чем постоянные диски и имеют меньшие задержки. Каждый диск расширяется до 375 Гб, что в сумме дает до 3 Тб на одну машину. Local ssd нельзя использовать для длительного хранения данных, так как стираются после выключения виртуальной машины, переживают только перезапуск.

Дока: https://cloud.google.com/compute/docs/disks

Жизненный цикл

Каждая виртуальная машины имеет свою жизненный цикл где каждая стадия отвечает за определенный набор действий. Всего есть пять состояний: Provisioning, Staging, Running, Stopping, Terminated.

Provisioning
Происходит после выбора всех необходимых настроек и нажатия на кнопку «создать VM». На этом этапе выделяется процессор, память и резервируются диски, но сама машина еще не работает.

Staging
На этом этапе происходит выделение внешнего и внутреннего IP адреса, загружается системный образ и стартует ОС.

Running
Сначала выполняются установленные start-up скрипты и включается удаленный доступ через SSH или RDP. Здесь выполняется вся возложенная на машину работа. На этом шаге можно мигрировать нашу виртуалку в другую зону без перезапуска, создавать снапшоты дисков или экспортировать системный образ.

Stopping и Terminated
Некоторые действия требуют остановки виртуальной машины, например добавление CPU или памяти. Когда машина переходит в это состояние выполняются установленные shutdown скрипты и VM переходит в terminated статус.

После этого мы можем ее удалить, мигрировать, добавлять и удалять IP адреса, теги, менять тип машины, добавлять новые диски.

Когда машина отключена мы платим только за выделенные IP и за диски. Главное что надо помнить, на выполнения shutdown скриптов есть всего 90 секунд, а если это preemptible машина, то 30 секунд.

Доступ к виртуальной машины

Linux манишь предоставляю доступ через SSH, а Windows — через RDP. В обоих случаях в брандмауэре должен быть открыт 22 порт для SSH и 3389 для RDP.

Специальные опции

Preemptible VMs
Временные и очень дешевые виртуальные машины. Обычно их используют для непродолжительной обработки больших массивов данных или расчетов. Например обработать больше количество картинок или подсчитать какие-то метрики. В свою очередь такие машины накладывают следующие ограничения:

Они могут быть выключены в любой момент, поэтому приложение должно быть fault-tolerant.
Google останавливает их после 24 часов работы.
Не всегда доступны для создания
Не предоставляют SLA

Sole-tolerant node
Если вы обрабатываете очень чувствительные данные, можно использовать sole-tolerant ноды, которые представляют физические сервера, которые изолированы от других проектов и клиентов.

GCP: Virtual Private Cloud (VPC)

Mon, 14 Sep 2020 15:46:06 -0400

Virtual Private Cloud (VPC) сеть — это виртуальная версия физической сети, которая работает внутри облака. С помощью сетей можно организовать общение между ресурсами в облаке или изолировать их друг от друга.

Общий вид проекта с одной сетью и двумя подсетями.

Составляющие компоненты VPC

Регионы
Зоны
Проекты
Сети
Подсети
IP адреса
Маршрутизаторы
Фаерволы

Региональные и зональные ресурсы

Я уже писал в предыдущей статье, что ресурсы в облаке разделяются по географии. К таким ресурсам относятся сети и их компоненты. Так к глобальным ресурсам относятся: VCP сети, firewall, маршрутизаторы. А к региональным статические внешние IP адреса и подсети.

Сети и подсети

Центральная единица в GCP — проект, объединяет набор ресурсов и сервисов в единую организационную единицу. Каждый проект содержат до 5 сетей, но это количество можно изменить, поменяв соответствующие квоты.

VPC сеть представляет из себя топологию с набором разных ресурсов, таких как подсети, роутеры, DNS и другие. Сами по себе сети не содержат никаких диапазонов IP адресов.

Сети разделяются на 3 типа: default, auto mode, custom.

Про диапазоны IP адресов можно почитать в Википедии.

Default сети
Они же auto mode сети, создаются автоматически при создании проекта. Каждая сеть содержит по одной подсети на каждый регион и имеет преднастроенный брандмауэр. Эти подсети по умолчанию содержат фиксированное количество адресов (/20) с возможностью расширения до /16.

Custom сети
Создаются вручную. По умолчанию не содержат подсетей, их нужно создавать самим, по мере необходимости. При этом у нас появляется полный контроль над IP адресами и диапазонами, главное чтобы они соответствовали RFC 1918 и не превышали размер /16. После создания подсети, количество адресов можно увеличить, но не уменьшить. Такие сети лучше всего подходят для продакшена.

Несколько VPC сетей могут взаимодействовать друг с другом с помощью внешних адресов или используя VPC Network Peering, который позволяет взаимодействовать с помощью приватных IP адресов, но работает только с custom сетями.

Двум виртуальным машинам нужно коммуницировать через внешний IP несмотря на то что они находятся в одном регионе.

Детальнее можно ознакомится в документации.

IP адреса

Каждая виртуальная машина в GCP может иметь два IP адреса: внутренний и внешний.

Внутренние IP используются для коммуникации между ресурсами в одной сети. Их устанавливает DHCP и они являются эфемерными. Кроме IP адреса мы можем использовать имя вииртуальной машины, GCP автоматически прописывает его в DNS.

Внешние IP адреса используются для коммуникации с интернетом или между сетями. По умолчанию внешние IP являются эфемерными, но мы можем зарезервировать статический адрес, правда это уже стоит денег.

Если же статический IP адрес не закреплён ни за каким ресурсов, его цена будет выше, чем адреса, которые используются.

Можно настроить диапазон IP адресов для конкретного экземпляра VM. Это удобно, когда на одной машине крутится несколько сервисов и мы хотим, чтобы каждый имел свой IP.

Firewall

Каждая сеть имеет фаервол, в нём можно настроить правила для входящего(ingress) и исходящего(egress) трафика. По умолчанию весь ingress трафик запрещён, а egress разрешён. Поэтому для входящего трафика мы можем создать только разрешающие правила.

Сами правила можно применять для конкретного IP адреса, множества или для тегов. Например, создать правило, которое разрешает HTTP трафик для экземпляров с тегом «allow-http».

Все эти правила работают не на одной железке или роутере, а применяется для каждого экземпляра и обрабатываются на их уровне.

Богдан Стефанюк: дописи з тегом cloud

Где захостить свое приложение?

Типы сервисов

Где захостить .NET бекенд?

Где захостить фронтенд?

Где развернуть базу данных?

Полезные ссылки

Веб аналитика на коленке с помощью AWS

Отличное видео про основы Docker

Настройка новой виртуальной машины

GCP: Databases

Cloud SQL

Cloud Spanner

Cloud Big Table

Cloud Firestore

Cloud Memorystore

Сравнение

GCP: Cloud Storage

Основные понятия

Классы хранения

gsutil

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

Шифрование

Версионирование

Жизненный цикл

GCP: Identity and Access Management

Основные концепты

Сервисные аккаунты

Рекомендации

GCP: виртуальные машины

Типы VM

Образы

Диски

Жизненный цикл

Доступ к виртуальной машины

Специальные опции

GCP: Virtual Private Cloud (VPC)

Региональные и зональные ресурсы

Сети и подсети

IP адреса

Firewall