преза

Август 22, 2022

Содержание

2. Целевая идея Необходимость компаний держать у себя сервис, через который проходит большое количество клиентов и их
3. Облачные провайдеры Google Cloud. Microsoft Azure. AWS. Yandex Cloud. MTS Cloud
4. Анализ laaS провайдеров На данный момент большинство провайдеров дают следующие возможности: Снижение капитальных затрат Сокращение обслуживания
5. Биллинг Данные сравнения ведут к тому, что самым дешёвым решением является Yandex Cloud, а самым дорогим
6. Ценовая политика В Google Cloud финансы можно отследить в биллинг аккаунте. Для оценки затрат на будущий
7. О виртуализации и контейнерах Виртуальные машины Compute Engine работают на физическом узле с защищенным гипервизором Google
8. Gcloud x Terraform Особенность работы с Terraform в Google Cloud, заключается в более емком итоговом коде,
9. Анализ CML 2 Виртуальная машина с демоном Cisco Modeling Lab, является лицензионным продуктом, который требует от
10. Репликация CML 2 Для успешной репликации требуется: Образ копируемой виртуальной машины Уникальный публичный адрес. Уникальный приватный
11. Выбор конфигурации Как уже говорилось ранее, для CML требуется минимум 2 ядра процессора, 8 гб ОЗУ
12. Поддержка сценариев использования Для успешного запуска и поддержки скрипта, необходим ключ аккаунта, который позволит Terraform взаимодействовать
13. Сетевая связность При написании скрипта развёртывания виртуальных машин не обойтись без сетевой связности, в Google Cloud
14. Структура манифеста Выбор облачного провайдера Анализ написания Terraform у выбранного провайдера Изучение требований образа CML Расчет
15. Развертывание инфраструктуры После написания кода встаёт вопрос, а что дальше? Первым делом стоит загрузить необходимые для
16. Базовое состояние развернутого образа После успешного развертывания виртуальных машин, они имеют следующее: Внешний и внутренний ip
17. Уничтожение инфраструктуры В некоторых случаях даже после проверки кода командой, ошибки остаются, в момент остановки скрипта,
19. Скачать презентацию

Слайд 2

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

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

Слайд 3

Облачные провайдеры
Google Cloud.
Microsoft Azure.
AWS.
Yandex Cloud.
MTS Cloud

Слайд 4

Анализ laaS провайдеров
На данный момент большинство провайдеров дают следующие возможности:
Снижение капитальных

затрат
Сокращение обслуживания инфраструктуры
Повышенная доступность
Масштабируемость
Инструменты для разработки и автоматизации процессов

AWS предоставляет такие услуги, как IaaS, PaaS, SaaS и др. Предлагает более 70 ресурсов с расширенной зоной покрытия в четырнадцати регионах мира.
В Azure в настоящее время доступно около 60 сервисов.
Google Cloud предлагает множество услуг, включая IaaS, PaaS и Serverless, а также поддерживает Big data и IoT. В распоряжении провайдера более 50 ресурсов.
Yandex Cloud поддерживает контейнеризацию, машинное обучение, базы данных и отечественный софт, например 1С.
MTS Cloud имеет 25 облачных сервисов и решений, системы мониторинга, защита от атак и различные варианты VDI.

Слайд 5

Биллинг
Данные сравнения ведут к тому, что самым дешёвым решением является Yandex

Cloud, а самым дорогим Microsoft Azure, в плане цены можно колебаться между Google Cloud, AWS и Yandex Cloud.
В способах оплаты, самыми удобными будут отечественные провайдеры, тогда как иностранные представители облачных решений зачастую не всегда требуют рабочие в РФ сервисы по оплате их услуг.

Слайд 6

Ценовая политика
В Google Cloud финансы можно отследить в биллинг аккаунте.
Для оценки

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

Слайд 7

О виртуализации и контейнерах
Виртуальные машины Compute Engine работают на физическом узле

с защищенным гипервизором Google на базе KVM.
Для поддержки вложенной виртуализации Compute Engine добавляет к виртуальным машинам инструкции Intel VT-x , поэтому при создании виртуальной машины гипервизор, уже установленный на этой виртуальной машине, может запускать дополнительные виртуальные машины.
Так же в Google Cloud есть простор для контейнеризации, с помощью встроенной API Kubernetes Engine имеется возможность оркестрации докер контейнеров.

Слайд 8

Gcloud x Terraform
Особенность работы с Terraform в Google Cloud, заключается в

более емком итоговом коде, поскольку задействуется меньше модулей для создания одной виртуальной машины.
В среднем код Terraform для создания простой виртуальной машины в Google Cloud выходит в ~40 строк, когда например в том же Microsoft Azure ~100, AWS ~150, Yandex Cloud ~60.
Меньшее количество строк совсем не сказывается на функциональных возможностях кода в Google Cloud.

Microsoft Azure

Google Cloud

Слайд 9

Анализ CML 2
Виртуальная машина с демоном Cisco Modeling Lab, является лицензионным

продуктом, который требует от хоста подключение к интернету и значительные вычислительные мощности.
В качестве операционной системы стоит Ubuntu 20.04 LTS.
Требуется минимум 2 ядра процессора, 8 гб ОЗУ и 32 гб ПЗУ.
Активация лицензии осуществляется через web интерфейс CML, путём отправки ключей на сервер лицензирования Cisco.

Слайд 10

Репликация CML 2
Для успешной репликации требуется:
Образ копируемой виртуальной машины
Уникальный публичный адрес.
Уникальный

приватный адрес.
Уникальный диск под хранение данных.
Открытие портов, требуемых для доступа к необходимым данным.
Переменные для эффективного создания копий.
Файловый ресурс с переносимыми данными.
Могут возникнуть проблемы, если заливать образ не указав в качестве системы Ubuntu 20.04, в противном случае образ не запустится.

Слайд 11

Выбор конфигурации
Как уже говорилось ранее, для CML требуется минимум 2 ядра

процессора, 8 гб ОЗУ и 32 гб ПЗУ.
В Google Cloud данным характеристикам соответствует тип виртуальной машины e2-standart-2, такой вариант с 35 гб ПЗУ будет стоить $52.42, или же 3191,06 р.
Если планируется загружать CML по максимуму, можно выбрать тип виртуальной машины с 4 vCPU и 16 гб ОЗУ, такой вариант с 35 гб ПЗУ будет уже стоить $101.34, или же 6169,06 р.
Выбор конфигурации состоит в том, чтобы выбрать тип виртуальной машины, количество ПЗУ, сеть, образ системы или диск.
Произвольно выбрать параметры виртуальной машине нельзя.

Слайд 12

Поддержка сценариев использования
Для успешного запуска и поддержки скрипта, необходим ключ аккаунта,

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

Слайд 13

Сетевая связность
При написании скрипта развёртывания виртуальных машин не обойтись без сетевой

связности, в Google Cloud получения адреса является задачей в “три строки”.
Получить адрес это хорошо, но что на счёт доступности?
В Google Cloud как и во многих других облачных системах, есть внутренний файрволл, который с помощью правил и тегов разрешает или запрещает проход определенного трафика.
Для CML требуется открыть порты:
443 – Веб консоль CML.
9090 – Веб консоль Ubuntu.
22 – Для доступа к CML без графики.

Слайд 14

Структура манифеста
Выбор облачного провайдера
Анализ написания Terraform у выбранного провайдера
Изучение требований образа

CML
Расчет биллинга
Загрузка образа в облако
Написание Terraform скрипта
Отладка кода
Применение кода в продакшене

Cml-1

Cml-0

SSH

ADMIN

CLIENT-1

CLIENT-0

terraform apply

Слайд 15

Развертывание инфраструктуры
После написания кода встаёт вопрос, а что дальше?
Первым делом стоит

загрузить необходимые для Terraform данные, относительно нашего кода (Рисунок 1).
Если в коде были ошибки, то они проявятся уже на этом этапе, но нам всё равно стоит проверить валидность кода (Рисунок 2).
Подготовительный этап был закончен.
Теперь следует запустить наш скрипт и подтвердить план конфигурации, написав yes (Рисунок 3).

Рисунок 1

Рисунок 2

Рисунок 3

Слайд 16

Базовое состояние развернутого образа
После успешного развертывания виртуальных машин, они имеют следующее:
Внешний

и внутренний ip
Открытые порты 443, 9090, 22, icmp
Рабочие веб интерфейсы по https и порту 9090
Доступ в интернет

Слайд 17

Уничтожение инфраструктуры
В некоторых случаях даже после проверки кода командой, ошибки остаются,

в момент остановки скрипта, до ошибки могли создаться какие-либо ресурсы, для их очистки следует уничтожить недостроенную инфраструктуру (Рисунок 1).
Так же эту команду используют, когда от развернутых виртуальных машин уже ничего не требуется и они просто тратят финансы, после ввода команды, так же как и при развертывании требуется подтвердить намериния написав yes.

Рисунок 1

преза

Содержание

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

Облачные провайдерыGoogle Cloud.Microsoft Azure.AWS.Yandex Cloud.MTS Cloud

Анализ laaS провайдеровНа данный момент большинство провайдеров дают следующие возможности:Снижение капитальных

БиллингДанные сравнения ведут к тому, что самым дешёвым решением является Yandex

Ценовая политикаВ Google Cloud финансы можно отследить в биллинг аккаунте.Для оценки

О виртуализации и контейнерахВиртуальные машины Compute Engine работают на физическом узле

Gcloud x TerraformОсобенность работы с Terraform в Google Cloud, заключается в

Анализ CML 2Виртуальная машина с демоном Cisco Modeling Lab, является лицензионным

Репликация CML 2Для успешной репликации требуется:Образ копируемой виртуальной машиныУникальный публичный адрес.Уникальный

Выбор конфигурацииКак уже говорилось ранее, для CML требуется минимум 2 ядра

Поддержка сценариев использованияДля успешного запуска и поддержки скрипта, необходим ключ аккаунта,

Сетевая связностьПри написании скрипта развёртывания виртуальных машин не обойтись без сетевой

Структура манифестаВыбор облачного провайдераАнализ написания Terraform у выбранного провайдераИзучение требований образа

Развертывание инфраструктурыПосле написания кода встаёт вопрос, а что дальше?Первым делом стоит

Базовое состояние развернутого образаПосле успешного развертывания виртуальных машин, они имеют следующее:Внешний

Уничтожение инфраструктурыВ некоторых случаях даже после проверки кода командой, ошибки остаются,

Похожие презентации