В этой статье мы рассмотрим из чего состоит Terraform, а также поэтапно запустим собственную инфраструктуру в облаке с VMware подготовим три VM для разных целей: прокси, файловое хранилище и CMS.
Обо всем подробно и в три этапа:
Terraform это IaC (Infrastructure-as-Code) инструмент для построения и управления виртуальной инфраструктурой с помощью кода .
В работе с инструментом мы отметили несколько преимуществ:
Скорость развертывания новых тенантов (пользовательских виртуальных сред). Обычно, чем больше новых клиентов, тем больше "кликов" требуется сделать сотрудникам технической поддержки для публикации новых ресурсов. С Terraform пользователи могут изменять параметры виртуальных машин (например, автоматически выключать ОС и увеличивать раздел виртуального диска ) без участия технической поддержки и выключения самой машины.
Моментальная проверка плана активации нового теннанта. С помощью описания кода инфраструктуры мы можем сразу же проверить, что и в каком порядке будет добавлено, а также в каком конечном состоянии будет та или иная виртуальная машина или виртуальная сеть с подключениями к виртуальным машинам.
Возможность описывать большинство популярных облачных платформ. Вы можете использовать инструмент от Amazon и Google Cloud, до частных платформ на базе VMware vCloud Director, предлагающих услуги в рамках IaaS, SaaS и PaaS решений.
Управлять несколькими облачными провайдерами и распространять инфраструктуру между ними для повышения отказоустойчивости, используя одну конфигурацию для создания, диагностики и управления облачными ресурсами.
Удобное использование для создания демо-стендов под тестирование и отладку программного обеспечения. Вы можете создавать и передавать стенды для отдела тестирования, параллельно проверять ПО в разных средах, а также моментально изменять и удалять ресурсы, создав всего лишь один план построения ресурсов
Кратко рассказали про преимущества инструмента, теперь разберем его на составляющие
Providers (провайдеры).
В Terraform практически любой тип инфраструктуры можно представить в качестве ресурса. Связь между ресурсами и платформой API обеспечивается providers модулями, которые позволяют создавать ресурсы в рамках определённой платформы, например, Azure или VMware vCloud Director.
В рамках проекта вы можете взаимодействовать с разными провайдерами на разных платформах.
Resources (описание ресурсов).
Описание ресурсов позволяет управлять компонентами платформы, например виртуальными машинами или сетями.
Вы можете самостоятельно создать описание ресурсов для провайдера VMware vCloud Director и использовать это описание для создания ресурсов у любого хостинг-провайдера, который использует vCloud Director. Вам потребуется лишь заменить параметры аутентификации и параметры сетевого подключения к необходимому хостинг-провайдеру
Provisioners.
Эта составляющая дает возможность выполнять операции по первоначальной установке и обслуживанию операционной системы после создания виртуальных машин. После того, как вы создали ресурс виртуальной машины, с помощью provisioners вы можете настроить и подключиться по SSH, выполнить обновление операционной системы, а также загрузить и выполнить скрипт.
Переменные Input и Output.
Input переменные входные переменные для любых типов блоков.
Output переменные позволяют сохранить значения после создания ресурсов и могут быть использованы, как входные переменные в других модулях, например в блоке Provisioners.
States (состояния).
States-файлы хранят информацию о конфигурации ресурсов платформы провайдера. При первом создании платформы никаких сведений о ресурсах нет и перед любой операцией Terraform обновляет состояние с реальной инфраструктурой уже описанных ресурсов.
Основная цель состояний, это сохранение связки объектов уже созданных ресурсов для сравнение конфигурации добавляемых ресурсов и объектов, чтобы избежать повторного создания и изменений платформы.
Информация о состоянии по умолчанию хранится в локальном файле terraform.tfstate, но при необходимости есть возможность использовать удаленное хранение для работы в команде.
Также вы можете импортировать текущие ресурсы платформы в состояние, чтобы далее взаимодействовать с другими ресурсами, которые в свою очередь были созданы без помощи Terraform.
Составляющие разобрали, теперь с помощью Terraform мы поэтапно создадим инфраструктуру с тремя виртуальными машинами. Первая с установленным прокси-сервером nginx, вторая с файловым хранилищем на базе Nextcloud и третья с CMS Bitrix.
Писать код и исполнять его мы будем на примере нашего облака на VMware vCloud Director. У нас пользователи получают учётную запись правами Organization Administrator, если вы используете учетную запись с теми же правами в другом облаке VMware, то сможете воспроизвести код из наших примеров. Поехали!
Сначала создадим для нашего нового проекта директорию, в которой будут размещены файлы с описанием инфраструктуры.
mkdir project01
Затем опишем компоненты инфраструктуры. Terraform создаёт связи и обрабатывает файлы на основании описания в файлах. Сами файлы можно именовать исходя из целевого назначения описываемых блоков, например, network.tf - описывает сетевые параметры для инфраструктуры.
Для описания компонентов нашей инфраструктуры, мы создали следующие файлы:
Список файлов.main.tf - описание параметров для виртуальной среды - виртуальные машины, виртуальные контейнеры;
network.tf - описание параметров виртуальной сети и правил NAT, Firewall;
variables.tf - список переменных, которые используем;
vcd.tfvars - значения переменных проекта для модуля VMware vCloud Director.
Язык конфигурации в Terraform является декларативным и порядок блоков не имеет значения, кроме блоков provisioner, т.к. в этом блоке мы описываем команды для выполнения при подготовке инфраструктуры и они будут выполнятся по порядку.
Структура блоков.<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK
LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> #
Argument
}
Для описания блоков используется собственный язык программирования HCL (HashiCorp Configuration Language), возможно описывать инфраструктуру и с помощью JSON. Подробнее о синтаксисе можно прочитать на сайте разработчика.
Сначала создадим два файла, которые описывают список всех используемых переменных и их значений для модуля VMware vCloud Director. Первым создадим файл variables.tf.
Cодержимое файла variables.tf.variable "vcdorguser" {
description = "vCD Tenant User"
}
variable "vcdorgpassword" {
description = "vCD Tenant Password"
}
variable "vcdorg" {
description = "vCD Tenant Org"
}
variable "vcdorgvdc" {
description = "vCD Tenant VDC"
}
variable "vcdorg_url" {
description = "vCD Tenant URL"
}
variable "vcdorgmaxretrytimeout" {
default = "60"
}
variable "vcdorgallowunverifiedssl" {
default = "true"
}
variable "vcdorgedgename" {
description = "vCD edge name"
}
variable "vcdorgcatalog" {
description = "vCD public catalog"
}
variable "vcdtemplateoscentos7" {
description = "OS CentOS 7"
default = "CentOS7"
}
variable "vcdorgssdsp" {
description = "Storage Policies"
default = "Gold Storage Policy"
}
variable "vcdorghddsp" {
description = "Storage Policies"
default = "Bronze Storage Policy"
}
variable "vcdedgelocalsubnet" {
description = "Organization Network Subnet"
}
variable "vcdedgeexternalip" {
description = "External public IP"
}
variable "vcdedgelocalipnginx" {}
variable "vcdedgelocalipbitrix" {}
variable "vcdedgelocalC11Cnextcloud" {}
variable "vcdC12Cexternal_network" {}
vcd_org_user - имя пользователя с правами Organization Administrator,
vcd_org_password - пароль пользователя,
vcd_org - название организации,
vcd_org_vdc - название виртуального дата-центра,
vcd_org_url - API URL,
vcd_org_edge_name - название виртуального маршрутизатора,
vcd_org_catalog - название каталога с шаблонами виртуальных машин,
vcd_edge_external_ip - публичный IP-адрес,
vcd_edge_external_network - название внешней сети,
vcd_org_hdd_sp - название политики хранения HDD,
vcd_org_ssd_sp - название политики хранения SSD.
И вводим свои переменные:
vcdedgelocalipnginx - IP-адрес виртуальной машины с NGINX,
vcdedgelocalipbitrix - IP-адрес виртуальной машины с 1С: Битрикс,
vcdedgelocalipnextcloud - IP-адрес виртуальной машины с Nextcloud.
Вторым файлом создаем и указываем переменные для модуля VMware vCloud Director в файле vcd.tfvars: Напомним, что в нашем примере мы используем собственное облако mClouds, если вы работаете с другим провайдером уточните значения у него.
Содержимое файла vcd.tfvars.vcdorgurl = "https://vcloud.mclouds.ru/api"
vcdorguser = "orgadmin"
vcdorgpassword = "*"
vcd = "org"
vcdorgvdc = "orgvdc"
vcdorgmaxretrytimeout = 60
vcdorgallowunverifiedssl = true
vcdorgcatalog = "Templates"
vcdtemplateos_centos7 = "CentOS7"
vcdorgssdsp = "Gold Storage Policy"
vcdorghddsp = "Bronze Storage Policy"
vcdorgedgename = "MCLOUDS-EDGE"
vcdedgeexternalip = "185.17.66.1"
vcdedgelocalsubnet = "192.168.110.0/24"
vcdedgelocalipnginx = "192.168.110.1"
vcdedgelocalipbitrix = "192.168.110.10"
vcdedgelocalipnextcloud = "192.168.110.11"
vcdedgeexternal_network = "NET-185-17-66-0"
Переменные окружения заданы, теперь настроим схему подключения виртуальных машин к каждой виртуальной машине назначим приватный IP-адрес и с помощью Destination NAT "пробрасываем" порты во внешнюю сеть. Для ограничения доступа к портам управления установим доступ только для нашего IP-адреса.
Схема сети для создаваемой Terraform платформыСоздаем виртуальную организационную сеть с названием net_lan01, шлюзом по умолчанию: 192.168.110.254, а также с адресным пространством: 192.168.110.0/24.
Описываем виртуальную сеть.resource "vcdnetworkrouted" "net" {
name = "netlan01"
edgegateway = var.vcdorgedgename
gateway = "192.168.110.254"
dns1 = "1.1.1.1"
dns2 = "8.8.8.8"
staticippool {
startaddress = "192.168.110.1"
end_address = "192.168.110.253"
}
}
Создадим правила для межсетевого экрана, которое позволяет предоставить виртуальным машинам доступ в сеть Интернет. В рамках этого блока все виртуальные ресурсы в облаке будут иметь доступ в сеть Интернет:
Описываем правила для доступа VM в интернет.resource "vcdnsxvfirewallrule" "fwinternetaccess"
{
edgegateway = var.vcdorgedgename
name = "Internet Access"
source {
gatewayinterfaces = ["internal"]
}
destination {
gatewayinterfaces = ["external"]
}
service {
protocol = "any"
}
dependson = [vcdnetworkrouted.net]
}
Установив зависимость, что после обработки блока vcdnetworkrouted.net мы приступаем к конфигурации блока vcdnsxvfirewallrule, с помощью dependson. Используем эту опцию, так как некоторые зависимости могут быть распознаны неявно в конфигурации.
Далее создадим правила разрешающее доступ к портам из внешней сети и указываем наш IP-адрес для подключения по SSH к серверам. Любой пользователь сети Интернет имеет доступ к портам 80 и 443 на веб-сервере и пользователь с IP-адресом 90.1.15.1 имеет доступ к портам SSH виртуальных серверов.
Разрешаем доступ к портам из внешней сети.resource "vcdnsxvfirewallrule" "fwnatports" {
edgegateway = var.vcdorgedgename
name = "HTTPs Access"
source {
gatewayinterfaces = ["external"]
}
destination {
gateway_interfaces = ["internal"]
}
service {
protocol = "tcp"
port = "80"
}
service {
protocol = "tcp"
port = "443"
}
dependson = [vcdnetworkrouted.net]
}
resource "vcdnsxvfirewallrule" "fwnatadminports"
{
edgegateway = var.vcdorgedgename
name = "Admin Access"
source {
ipaddresses = [ "90.1.15.1" ]
}
destination {
gatewayinterfaces = ["internal"]
}
service {
protocol = "tcp"
port = "58301"
}
service {
protocol = "tcp"
port = "58302"
}
service {
protocol = "tcp"
port = "58303"
}
depends_on = [vcdnetworkrouted.net]
}
Создаём правила Source NAT для доступа в сеть Интернет из облачной локальной сети:
Описываем правила Source NAT.resource "vcdnsxvsnat" "snatlocal" {
edgegateway = var.vcdorgedgename
networktype = "ext"
networkname = var.vcdedgeexternalnetwork
originaladdress = var.vcdedgelocalsubnet
translatedaddress = var.vcdedgeexternalip
dependson = [vcdnetwork_routed.net]
}
И в завершении конфигурации сетевого блока добавляем правила Destination NAT для доступа к сервисам из внешней сети:
Добавляем правила Destination NAT.resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTPs"
original_address = var.vcd_edge_external_ip
original_port = 443
translated_address = var.vcd_edge_local_ip_nginx
translated_port= 443
protocol = "tcp"
depends_on =
[vcd_network_routed.net]
}
resource
"vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway =
var.vcd_org_edge_name
network_name =
var.vcd_edge_external_network
network_type =
"ext"
description = "NGINX HTTP"
original_address = var.vcd_edge_external_ip
original_port = 80
translated_address = var.vcd_edge_local_ip_nginx
translated_port= 80
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH NGINX"
original_address = var.vcd_edge_external_ip
original_port = 58301
translated_address = var.vcd_edge_local_ip_nginx
translated_port= 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Bitrix"
original_address = var.vcd_edge_external_ip
original_port = 58302
translated_address = var.vcd_edge_local_ip_bitrix
translated_port= 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Nextcloud"
original_address = var.vcd_edge_external_ip
original_port = 58303
translated_address =
var.vcd_edge_local_ip_nextcloud
translated_port=
22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Как мы и планировали в начале статьи, создадим три виртуальные машины. Они будут подготовлены с помощью "Guest Customization". Сетевые параметры пропишем согласно указанным нами настройками, а пароль от пользователя генерируется автоматически.
Опишем vApp в котором будут находится виртуальные машины и их конфигурацию.
Конфигурация виртуальных машинСоздадим контейнер vApp. Чтобы мы могли сразу же подключить vApp и ВМ к виртуальной сети также добавляем параметр depends_on:
Создаем контейнерresource "vcd_vapp" "vapp" {
name =
"web"
power_on = "true"
depends_on =
[vcd_network_routed.net]
}
resource "vcd_vapp_vm" "nginx" {
vapp_name = vcd_vapp.vapp.name
name = "nginx"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nginx
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Основные параметры в описании VM:
name - имя виртуальной машины,
vappname - название vApp в который добавить новую ВМ,
catalogname / templatename - название каталога и название шаблона виртуальной машины,
storageprofile - политика хранения по умолчанию.
Параметры блока network:
type - тип подключаемой сети,
name - к какой виртуальной сети подключить ВМ,
isprimary - основной сетевой адаптер,
ipallocation_mode - режим выделения адреса MANUAL / DHCP / POOL,
ip - IP-адрес для виртуальной машины, укажем вручную.
Блок override_template_disk:
sizeinmb - размер boot-диска для виртуальной машины
storage_profile - политика хранения для диска
resource "vcd_vapp_vm" "nextcloud" {
vapp_name = vcd_vapp.vapp.name
name = "nextcloud"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nextcloud
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
resource "vcd_vm_internal_disk" "disk1" {
vapp_name = vcd_vapp.vapp.name
vm_name = "nextcloud"
bus_type = "paravirtual"
size_in_mb = "102400"
bus_number = 0
unit_number = 1
storage_profile = var.vcd_org_hdd_sp
allow_vm_reboot = true
depends_on = [ vcd_vapp_vm.nextcloud ]
}
В секции vcdvminternal_disk опишем новый виртуальный диск, который подключается к виртуальной машине.
Пояснения по блоку vcdvminternaldisk:
bustype - тип дискового контроллера
sizeinmb - размер диска
busnumber / unitnumber - место подключения в адаптере
storage_profile - политика хранения для диска
resource "vcd_vapp_vm" "bitrix" {
vapp_name = vcd_vapp.vapp.name
name = "bitrix"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_bitrix
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "81920"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Сеть подготовлена, виртуальные машины описаны. Перед импортом нашей инфраструктуры мы можем заранее провести первоначальный провижининг с помощью provisioners блоков и без использования Ansible.
Рассмотрим как обновить ОС и запустить установочный скрипт CMS Bitrix с помощью provisioner блока.
Сначала выполним установку пакетов обновления CentOS.resource "null_resource" "nginx_update_install"
{
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password =
vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip
zip" ]
}
}
}
Обозначение составляющих:
provisioner "remote-exec" - подключаем блок удаленного "провижининга"
В блоке connection описываем тип и параметры для подключения:
type - протокол, в нашем случае SSH;
user - имя пользователя;
password - пароль пользователя. В нашем случае указываем на параметр vcdvappvm.nginx.customization[0].admin_password, который хранит сгенерированный пароль от пользователя системы.
host - внешний IP-адрес для подключения;
port - порт для подключения, который ранее указывали в настройках DNAT;
inline - перечисляем список команд, которые будут вводится. Команды будут введены по порядку, как и указано в этой секции.
Как пример, дополнительно выполним скрипт установки 1С-Битрикс. Вывод результата выполнения скрипта будет доступен во время выполнения плана. Для установки скрипта, сначала опишем блок:
Опишем установку 1С-Битрикс.provisioner "file" {
source = "prepare.sh"
destination = "/tmp/prepare.sh"
connection {
type = "ssh"
user = "root"
password =
vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
}
provisioner "remote-exec" {
inline = [
"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"
]
}
И сразу же опишем обновление Битрикс.
Пример провижининга 1С-Битрикс.resource "null_resource" "install_update_bitrix"
{
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password =
vcd_vapp_vm.bitrix.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58302"
timeout = "60s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip
zip",
"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O
/tmp/bitrix-env.sh",
"chmod +x /tmp/bitrix-env.sh",
"/tmp/bitrix-env.sh"
]
}
}
Важно! Скрипт может не сработать, если не отключить заранее SELinux! Если вам требуется подробная статья по установке и настройке CMS 1С-Битрикс с помощью bitrix-env.sh, оо вы можете воспользоваться нашей статьей в блоге на сайте.
Для работы мы используем простой джентельменский набор: лэптоп с
ОС Windows 10 и дистрибутив с официального сайта terraform.io. Распакуем и
проинициализируем с помощью команды: terraform.exe
init
После описания вычислительной и сетевой инфраструктуры, мы запускаем планирование для проверки нашей конфигурации, где мы можем увидеть, что будет создано и как между собой связано.
Выполняем команду - terraform plan
-var-file=vcd.tfvars
.
Получаем результат - Plan: 16 to add, 0 to change, 0 to
destroy.
То есть по этому плану будет создано 16
ресурсов.
Запускаем план по команде - terraform.exe apply
-var-file=vcd.tfvars
.
Виртуальные машины будут созданы, а затем выполняются перечисленные нами пакеты в рамках секции provisioner ОС будет обновлена и установится CMS Bitrix.
После выполнения плана мы хотим получить в текстовом виде данные для подключения к серверам, для этого оформим секцию output следующим образом:
output "nginxpassword" {
value =
vcdvappvm.nginx.customization[0].adminpassword
}
И следующий вывод сообщает нам пароль от созданной виртуальной машины:
Outputs: nginx_password = F#4u8!!N
В итоге мы получаем доступ к виртуальным машинам с обновлённой операционной системой и предустановленными пакетами для нашей дальнейшей работы. Все готово!
Но что если у вас уже есть существующая инфраструктура?
Всё просто, вы можете импортировать текущие виртуальные машины и их vApp контейнеры с помощью команды import.
Опишем ресурс vAPP и виртуальную машину.resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
Следующий шаг, это выполнить импорт свойств ресурсов vApp в
формате vcdvapp.<vApp>
<org>.<orgvdc>.<vApp>
, где:
vApp - имя vApp;
org - название организации;
org_vdc - название виртуального дата-центра.
Выполним импорт свойств ресурсов VM в формате:
vcdvappvm.<VM>
<org>.<orgvdc>.<vApp>.<VM>
,
в котором:
VM - имя VM;
vApp - имя vApp;
org - название организации;
orgvdc - название виртуального дата-центра.
C:\Users\Mikhail\Desktop\terraform>terraform import
vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importing from ID
"mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Import prepared!
Prepared vcd_vapp_vm for import
vcd_vapp_vm.Zabbix: Refreshing state...
[id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Import successful!
The resources that were imported are shown above. These
resources are now inyour Terraform state and will henceforth be
managed by Terraform.
Теперь мы можем посмотреть на новый импортированный ресурс:
Импортированный ресурс> terraform show
...
# vcd_vapp.Monitoring:
resource "vcd_vapp" "Monitoring" {
guest_properties = {}
href =
"https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"
id =
"urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"
ip = "allocated"
metadata = {}
name = "Monitoring"
org = "mClouds"
status = 4
status_text = "POWERED_ON"
vdc = "mClouds"
}
# vcd_vapp_vm.Zabbix:
resource "vcd_vapp_vm" "Zabbix" {
computer_name = "Zabbix"
cpu_cores = 1
cpus = 2
expose_hardware_virtualization = false
guest_properties = {}
hardware_version = "vmx-14"
href =
"https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
id =
"urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
internal_disk = [
{
bus_number = 0
bus_type = "paravirtual"
disk_id = "2000"
iops = 0
size_in_mb = 122880
storage_profile = "Gold Storage Policy"
thin_provisioned = true
unit_number = 0
},
]
memory = 8192
metadata = {}
name = "Zabbix"
org = "mClouds"
os_type = "centos8_64Guest"
storage_profile = "Gold Storage Policy"
vapp_name = "Monitoring"
vdc = "mClouds"
customization {
allow_local_admin_password = true
auto_generate_password = true
change_sid = false
enabled = false
force = false
join_domain = false
join_org_domain = false
must_change_password_on_first_login = false
number_of_auto_logons = 0
}
network {
adapter_type = "VMXNET3"
ip_allocation_mode = "DHCP"
is_primary = true
mac = "00:50:56:07:01:b1"
name = "MCLOUDS-LAN01"
type = "org"
}
}
Теперь точно готово - мы закончили с последним моментом (импорт в существующую инфраструктуру) ирассмотрели все основные моменты работы с Terraform.
Инструмент оказался очень удобным и позволяет описать вашу инфраструктуру как код, начиная от виртуальных машин одного облачного провайдера до описания ресурсов сетевых компонентов.
При этом независимость от окружения дает возможность работать с локальными, облачными ресурсами, так и, заканчивая управлением платформой. А при отсутствии поддерживаемой платформы и желании добавления нового, можно написать свой провайдер и использовать его.
Какая версия прошивки самая правильная и рабочая? Если СХД гарантирует отказоустойчивость на 99,9999%, то значит ли, что и работать она будет бесперебойно даже без обновления ПО? Или наоборот для получения максимальной отказоустойчивости нужно всегда ставить самую последнюю прошивку? Постараемся ответить на эти вопросы, опираясь на наш опыт.
Все мы понимаем, что в каждой версии программного обеспечения, будь то операционная система или драйвер для какого-то устройства, зачастую содержатся недоработки/баги и прочие особенности, которые могут, как не "проявиться" до конца службы оборудования, так и вскрыться только при определенных условиях. Количество и значимость таких нюансов зависит от сложности (функциональности) ПО и от качества тестирования при его разработке.
Зачастую пользователи остаются на прошивке с завода (знаменитое "работает, значит не лезь") или всегда ставят самую последнюю версию (в их понимании последняя значит самая рабочая). Мы же используем другой подход смотрим релиз ноты для всего используемого в облаке mClouds оборудования и внимательно выбираем подходящую прошивку для каждой единицы оборудования.
К такому выводу мы пришли, что называется, с опытом. На своем примере эксплуатации расскажем, почему обещанные 99,9999 % надежности СХД ничего не значат, если вы не будете своевременно следить за обновлением и описанием ПО. Наш кейс подойдет для пользователей СХД любого вендора, так как подобная ситуация может произойти с железом любого производителя.
В конце прошлого года, к нашей инфраструктуре добавилась интересная система хранения данных: младшая модель из линейки IBM FlashSystem 5000, которая на момент приобретения именовалась Storwize V5010e. Сейчас она продается под названием FlashSystem 5010, но фактически это та же аппаратная база с тем же самым Spectrum Virtualize внутри.
Наличие единой системы управления - это, кстати, и есть основное отличие IBM FlashSystem. У моделей младшей серииона практически не отличается от моделей более производительных. Выбор определённой модели лишь даёт соответствующую аппаратную базу, характеристики которой дают возможность использовать тот или иной функционал или обеспечить более высокий уровень масштабируемости. ПО при этом идентифицирует аппаратную часть и предоставляет необходимый и достаточный функционал для этой платформы.
IBM FlashSystem 5010Кратко про нашу модель 5010. Это двухконтроллерная блочная система хранения данных начального уровня. Она умеет размещать в себе диски NLSAS, SAS, SSD. Размещение NVMe в ней недоступно,так как эта модель СХД позиционируется для решения задач, которым не требуется производительность NVMe дисков.
СХД приобреталась для размещения архивной информации или данных, к которым не происходит частого обращения. Поэтому нам было достаточно стандартного набора её функционала: тиринг (Easy Tier), Thin Provision. Производительность на NLSAS дисках на уровне 1000-2000 IOPS нас тоже вполне устраивала.
Теперь собственно про само обновление ПО. На момент приобретения система имела уже немного устаревшую версию ПО Spectrum Virtualize, а именно, 8.2.1.3.
Мы изучили описание прошивок изапланировали обновление до 8.2.1.9. Если бы мы были чуть расторопнее, то этой статьи бы не было на более свежей прошивке баг бы не произошел. Однако, по определённым причинам обновление этой системы было отложено.
В результате небольшая задержка обновления привела к крайне неприятной картине, как в описании по ссылке: https://www.ibm.com/support/pages/node/6172341.
Да, в прошивке той версии как раз был актуален так называемый APAR (Authorized Program Analysis Report) HU02104. Проявляется он следующим образом. Под нагрузкой при определённых обстоятельствах начинает переполняться кэш, далее система уходит в защитный режим, в котором отключает ввод-вывод для пула (Pool). В нашем случае выглядело как отключение 3-х дисков для RAID-группы в режиме RAID 6. Отключение происходит на 6 минут. Далее, доступ к Томам в Пуле восстанавливается.
Если кто не знаком со структурой и именованием логических сущностей в контексте IBM Spectrum Virtualize, я сейчас кратко расскажу.
Структура логических элементов СХДДиски собираются в группы, которые называются MDisk (Managed Disk). MDisk может представлять собой классический RAID (0,1,10,5,6) или виртуализованный DRAID (Distributed RAID). Использование DRAID позволяет увеличить производительность массива, т.к. будут использоваться все диски группы, и уменьшить время ребилда, благодаря тому, что нужно будет восстанавливать только определённые блоки, а не все данные с вышедшего из строя диска.
Распределение блоков данных по дискам при использовании Distributed RAID (DRAID) в режиме RAID-5.А эта схема показывает логику работы ребилда DRAID в случае выхода из строя одного диска:
Логика работы ребилда DRAID при выходе из строя одного дискаДалее, один или несколько MDisk образуют так называемый Pool. В пределах одного пула не рекомендуется использовать MDisk с разным уровнем RAID/DRAID на дисках одного типа. Не будем в это сильно углубляться, т.к. мы планируем рассказать это в рамках одной из следующих статей. Ну и, собственно, Pool делится на Тома (Volumes), которые презентуются по тому или иному протоколу блочного доступа в сторону хостов.
Так вот, у нас, в результате возникновения ситуации, описанной в APAR HU02104, из-за логического отказа трёх дисков, перестал быть работоспособным MDisk, который, в свою очередь, повлёк отказ в работе Pool и соответствующих Томов.
Так как эти системы довольно умные, их можно подключить к облачной системе мониторинга IBM Storage Insights, которая автоматически, при возникновении неисправности, отправляет запрос на обслуживание в службу поддержки IBM. Создаётся заявка и специалисты IBM в удалённом режиме проводят диагностику и связываются с пользователем системы.
Благодаря этому вопрос решился довольно оперативно и от службы поддержки была получена оперативная рекомендация по обновлению нашей системы на уже ранее выбранную нами прошивку 8.2.1.9, в которой на тот момент этот момент был уже исправлен. Это подтверждает соответствующий Release Note.
Как говорится: "хорошо то, что хорошо заканчивается". Баг в прошивке не обернулся серьезными проблемами работа серверов была восстановлена в кратчайшие сроки и без потери данных. У некоторых клиентов пришлось перезапускать виртуальные машины, но в целом мы были готовы к более негативным последствиям, так как ежедневно делаем резервные копии всех элементов инфраструктуры и клиентских машин.
Мы получили подтверждение, что даже надежные системы с 99,9999% обещанной доступности требуют внимания и своевременного обслуживания. Исходя из ситуации мы сделали для себя ряд выводов и делимся нашими рекомендациями:
Нужно обязательно следить за выходом обновлений, изучать Release
Notes на предмет исправления потенциально критичных моментов и
своевременно выполнять запланированные обновления.
Это организационный и даже довольно очевидный момент, на котором,
казалось бы, не стоит заострять внимание. Однако, на этом ровном
месте можно довольно легко споткнуться. Собственно, именно этот
момент и добавил описанные выше неприятности. Относитесь к
составлению регламента обновления очень внимательно и не менее
внимательно следите за его соблюдением. Этот пункт больше относится
к понятию дисциплина.
Всегда лучше держать систему с актуальной версией ПО. Причём, актуальная не та, которая имеет большее числовое обозначение, а именно с более поздней датой выхода.
Например, IBM для своих систем хранения данных держит в актуальном состоянии как минимум два релиза ПО. На момент написания этой статьи это 8.2 и 8.3. Обновления для 8.2 выходят раньше. Следом с небольшой задержкой обычно выходит аналогичное обновление для 8.3.
Релиз 8.3 имеет ряд функциональных преимуществ, например, возможность расширения MDisk (в режиме DRAID) добавлением одного или более новых дисков (такая возможность появилась начиная с версии 8.3.1). Это довольно базовый функционал, но в 8.2 такой возможности, к сожалению, нет.
Если обновиться по каким-либо причинам нет возможности, то для версий ПО Spectrum Virtualize, предшествующих версиям 8.2.1.9 и 8.3.1.0 (где описанный выше баг актуален), для снижения риска его появления техническая поддержка IBM рекомендует ограничить производительность системы на уровне пула, как это показано на рисунке ниже (снимок сделан в русифицированном варианте GUI). Значение 10000 IOPS показано для примера и подбирается согласно характеристикам вашей системы.
Необходимо правильно рассчитывать нагрузку на системы хранения и не допускать перегрузки. Для этого можно воспользоваться либо сайзером IBM (если есть к нему доступ), либо помощью партнеров, либо сторонними ресурсами. Обязательно при этом понимать профиль нагрузки на систему хранения, т.к. производительность в МБ/с и IOPS сильно разнится в зависимости как минимум от следующих параметров:
тип операции: чтение или запись,
размер блока операции,
процентное соотношение операций чтения и записи в общем потоке ввода-вывода.
Также, на скорость выполнения операций влияет как считываются блоки данных: последовательно или в случайном порядке. При выполнении нескольких операций доступа к данным на стороне приложения есть понятие зависимых операций. Это тоже желательно учитывать. Всё это может помочь увидеть совокупность данных со счётчиков производительности ОС, системы хранения, серверов/гипервизоров, а также понимание особенностей работы приложений, СУБД и прочих "потребителей" дисковых ресурсов.
И напоследок, обязательно иметь резервные копии в актуальном и рабочем состоянии. Расписание резервного копирования нужно настраивать исходя из приемлемых для бизнеса значений RPO и периодически обязательно проверять целостность резервных копий (довольно много производителей ПО для резервного копирования реализовали в своих продуктах автоматизированную проверку) для обеспечения приемлемого значения RTO.
Благодарим, что дочитали до конца.
Готовы ответить на ваши вопросы и замечания в комментариях. Также
приглашаем
подписаться на наш телеграмм-канал, в котором мы проводим
регулярные акции (скидки на IaaS и розыгрыши промокодов до 100% на
VPS), пишем интересные новости и анонсируем новые статьи в блоге
Хабра.
sysbench 1.0.20 (using bundled
LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 40
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 47238.17
General statistics:
total time: 10.0009s
total number of events: 472487
Latency (ms):
min: 0.68
avg: 0.85
max: 1.46
95th percentile: 0.99
sum: 399892.63
Threads fairness:
events (avg/stddev): 11812.1750/824.36
execution time (avg/stddev): 9.9973/0.00
sysbench 1.0.20 (using bundled
LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 40
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 46474.85
General statistics:
total time: 10.0009s
total number of events: 464850
Latency (ms):
min: 0.74
avg: 0.86
max: 53.87
95th percentile: 1.01
sum: 398802.05
Threads fairness:
events (avg/stddev): 11621.2500/1156.95
execution time (avg/stddev): 9.9701/0.02
Параметр | Сервер | ВМ | Разница |
---|---|---|---|
Events per second | 47238.17 | 46474.85 | -1.62% |
Latency (avg) | 0.85 ms | 0.86 ms | +1.2% |
7-Zip (a) [64] 16.02 : Copyright
(c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64
bits,80 CPUs Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz
(50657),ASM,AES-NI)
Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz (50657)
CPU Freq: - - - - - - - - -
RAM size: 772271 MB, # CPU hardware threads: 80
RAM usage: 17650 MB, # Benchmark threads: 80
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 219383 7214 2959 213417 | 2433655 7750 2678 207532
23: 207598 7028 3010 211518 | 2418901 7873 2660 209301
24: 204763 7174 3069 220162 | 2364952 7826 2652 207568
25: 198526 7168 3162 226669 | 2384016 7909 2682 212138
---------------------------------- |
------------------------------
Avr: 7146 3050 217941 | 7839 2668 209135
Tot: 7493 2859 213538
7-Zip (a) [64] 16.02 : Copyright
(c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64
bits,80 CPUs Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz
(50657),ASM,AES-NI)
Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz (50657)
CPU Freq: 3769 3775 3772 3772 3773 3771 3772 3772 3772
RAM size: 64134 MB, # CPU hardware threads: 80
RAM usage: 17650 MB, # Benchmark threads: 80
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 190208 6089 3039 185035 | 2001333 6449 2646 170665
23: 179252 5785 3157 182637 | 2077835 6995 2570 179789
24: 184889 6251 3181 198793 | 2069792 7037 2582 181662
25: 192625 6794 3237 219932 | 2157590 7441 2580 191990
---------------------------------- |
------------------------------
Avr: 6230 3154 196599 | 6981 2595 181027
Tot: 6605 2874 188813
Параметр | Сервер | ВМ | Разница |
---|---|---|---|
Total CPU usage % | 7493 | 6605 | -11.8% |
Total R/U MIPS (normalized 100% CPU usage) | 2859 | 2874 | +0.5% |
Total MIPS | 213538 | 188813 | -11.6% |
Параметр | Сервер | ВМ | Разница |
---|---|---|---|
Single-Core Score | 1186 | 1052 | -11.3% |
Multi-Core Score | 31093 | 28872 | -7.1% |
Flash - это неотъемлемая часть в истории развития Интернета. Начиная с графического редактора, до размещения Flash-контента на 50% всех сайтов в сети Интернет, заканчивая дальнейшей борьбой с размещенным Flash-контентом и эксплуатированием уязвимостей в браузере - со всем этим столкнулся Flash. А как мир пришёл к этой технологии?
1993 год.
Концепция Flash берёт своё начало с 1993 года - момент основания компании FutureWave Software, работы над графическим редактором SmartSketch для компьютеров со стилусом на PenPoint OS и дальнейшим запоздалым портированием на операционные системы Microsoft Windows и Macintosh.
1995 год.
Низкие продажи и бурное развитие веб-технологий подтолкнули разработчиков к переработке SmartSketch в инструмент для создания анимированный векторной графики CelAnimator.
PC Computing Magazine Volume 9 Issue 9 / archive.orgБета-тестеры использовали CelAnimator для создания навигационных панелей, технических иллюстраций и рекламных баннеров.
1996 год.
Для отражения нового позиционирования программа была переименована в FutureSplash Animator. Весь созданный контент с помощью FutureSplash назывался movies.
archive.orgВсего через несколько месяцев после выпуска своего плеера FutureSplash, Netscape добавила его в свой список рекомендуемых расширений.
В конце 1996 года Macromedia, пытаясь добиться широкого распространения своего собственного веб-плеера Shockwave, купила FutureSplash. В надежде сделать название более запоминающимся, они его сократили и выпустили Macromedia Flash (FuturespLASH).
1997 год.
Выпустив вторую версию Flash и добавив возможность размещение кнопок, подключение библиотек и звуков, наряду с улучшенной интеграцией с растровыми изображениями и анимацией: Flash становится мощным инструментом для создания маркетингового материала с анимацией, звуками и базовыми кнопками - Stop и GoTo.
1998 год.
С третьей версии было положен старт - movie clip (видеоклип), который стал мощным инструментом для создания инструкций для учебных пособий, справочных документов и обзора программного обеспечения, так как он включал в себя собственную шкалу времени, что позволяло пользователям Flash вводить более сложную интерактивность по сравнению с той, что была доступна ранее.
С помощью видеоклипов пользователи могли организовывать взаимодействия между несколькими временными шкалами, которые следовали разным инструкциям и взаимодействовали друг с другом; это сделало возможным создание сайтов полностью на Flash.
По мере развития программного обеспечения в него были включены более сложные возможности программирования, но была сохранена базовая парадигма временной шкалы, разработанная для создания анимации.
1999 год.
К середине года Flash стал плеером по умолчанию в Microsoft Internet Explorer.
webdesignmuseum.org2000 год.
В августе в 5 версию был добавлен ActionScript. Разработчики стали комбинировать ActionScript с кнопками и смогли создавать больше, чем просто анимацию, они могли создавать целые интерактивные веб-сайты. Некоторые использовали эту технологию для добавления короткого вступления или небольшого виджета, другие создавали целые сайты с нуля, используя только Flash, поэтому единственным HTML на странице был встроенный проигрыватель.
webdesignmuseum.orgКонечно, были и недостатки. Поисковые системы не могли читать контент, который был заблокирован внутри файла Flash, поэтому поисковая оптимизация исчезла, а вместе с ним и доступность. А поскольку все нужно было загружать заранее, Flash-сайты работали немного медленнее. Но они по-прежнему привлекали дизайнеров, которые хотели сделать с веб-сайтом больше, чем позволяли все еще ранние технологии HTML и CSS. Таким образом, Flash открыл новое поколение веб-дизайна.
2002 год.
6 версия Flash и поддержка видео, Flash MX. Программное обеспечение было существенно переработано с использованием Flash MX и опубликовано в марте 2002 года и версия Flash MX Professional в сентябре 2003 года.
webdesignmuseum.org2004 год.
В марте 2004 г. была представлена новая среда программирования под названием Macromedia Flex для разработки того, что Macromedia описывает как многофункциональные интернет-приложения (или RIA) на платформе Flash.
Одна из культовых игр, Yetisports: YlympicsНекоторые из новых сайтов, построенных на платформе Flash, например Flickr, привлекали значительное внимание. Вскоре эти сайты стали одними из образцов совершенно нового видения Интернета, наполненного пользовательским контентом.
2005 год.
Первая уязвимость в линейке Macromedia MX 2004: Captivate, Contribute 2 и 3 - которая позволяла локальному пользователю выполнить произвольный код и получить повышенные привилегии.
2006 год.
В этом году Google купил YouTube, и его популярность с нарастающей скоростью только укрепила повсеместное распространение Flash.
webdesignmuseum.orgAdobe купила компанию в рамках приобретения Macromedia, что дало начало новой линейке - Adobe Macromedia.
Было зафиксировано пять CVE бюллетеней с различными уязвимостями.
2007 год.
Выпуск первого iPhone и отказ Apple от использования Flash, даже в облегченном виде в своей операционной системе.
2008 год.
Начало проекта Open Screen Project, цель которого - создание единого программного интерфейса для персонального компьютера, мобильных устройств и бытовой техники.
Появление и использование уязвимостей в Adobe Flash с помощью платных наборов эксплойтов.
2009 год.
Компанией Adobe были сняты ограничения на использование спецификаций SWF, FLV/F4V.
2010 год.
Стив Джобс публикует открытое письмо, где объясняет, почему Flash не появится на мобильных устройствах Apple никогда.
Lewis Wallace /cultofmac.com2017 год.
Компания Adobe в блоге опубликовала запись - Flash & the Future of Interactive Content. По мере того, как стандарты HTML5, WebGL и WebAssembly стали распространены в веб сильнее, и с началом уменьшения аудитории Flash, компания приняло решение о прекращении разработки Flash Player с конца 2020 года и призвали создателей контента к миграции на новые открытые форматы.
2020 год.
На текущий момент в базе уязвимостей было опубликовано 1078 уязвимостей.
Количество уязвимостей в разрезе - год публикации и по типу / cvedetails.com27 октября компания Microsoft выпустила обновление, которое удаляет Flash Player. В начале 2021 года обновление будет распространено через WSUS и центр обновления Windows. К концу года из Chrome будет удален плагин Flash Player.
История интернета помнит много разных изменений, но с Flash сталкивались наверняка все: как в профессиональной деятельности, так и при работе с обычными браузерами. 31.12.2020 переходим на следующую страницу, эпоха технологии Flash уходит в прошлое.
На этом заканчиваем наш экскурс в основные вехи по технологии Flash. Надеемся тем, кто давно в ИТ, было интересно вспомнить, а тем, кто не застал все этапы, как минимум, полезно.
Основной источник изображений, спасибо вам за историю: webdesignmuseum.org