По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих статьях мы познакомились как управлять ресурсами AWS с помощью Terraform, в данной статье мы посмотрим, как создавать работающий web-сервер с помощью Terraform. Для развертывания настоящего боевого Web сервера, нам понадобится создать с помощью Terraform два ресурса. Инстанс EC2 и группу безопасности для того, чтобы открыть порт 80 во внешний мир. Для начала создадим новую директорию Lesson-2 и файл WebServer.tr. Вспоминаем именно данный файл с данным расширением является основным для написания кода и управления.
Напоминаю, что это обычный текстовый файл, который редактируется с помощью любого текстового редактора в нашем случае мы будем использовать текстовый редактор nano.
Mkdir Lesson-2
cd Lesson-2
nano WebServer.tr
Сразу будем привыкать к оформлению кода и добавим в код комментарии, комментарии добавляются следующим образом. Ставим знак решетки # и за ней пишем комментарий.
#-----------------------------------------------
# Terraform
#
#Build WebServer during BootStrap
#--------------------------------------------------
Для начала пишем, кто провайдер и регион для размещения наших ресурсов.
provider "aws" {
region = "eu-central-1"
}
Кстати, есть интересный сайт awsregion.info на котором можно посмотреть название регионов и место размещение. Сайт на момент написания статьи обновляется и поддерживается в актуальном состоянии.
Так первый ресурс это инстанс EC2. Resource служебное слово, далее название ресурса в кавычках и имя, которое мы ему даем в кавычках, далее открываются и закрываются фигурные скобки. Именно между ними мы и будем описывать наш ресурс.
Далее добавляем ami – который показывает, какой образ мы будем использовать.
Instance_type – тип и размер ресурса, который мы будем использовать.
В итоге смотрим, что у нас получилось в первой итерации кода:
resource "aws_instance" "WebServer_my" {
ami = "ami-0767046d1677be5a0" #Amazon Linux ami
instance_type = "t2.micro"
}
В результате исполнения данной части у нас будет создан инстанс EC2.
Далее создадим 2-й ресурс aws_security_group, фактически это правило сети для брандмауэра.
Так же описание начинаем со служебного слова resource, далее название ресурса и имя ресурса в кавычках, а в конце открывающаяся и закрывающаяся скобка в которой пойдет описание ресурса. Указываем параметр name - этот параметр обязательный для корректного отображения, description – параметр не обязательный, но можем указать, vpc_id мы не указываем т.к используем ресурс vpc по умолчанию. Далее идет описание правил сетевых на языке Terraform. Служебный параметр ingress для входящего трафика с фигурными скобками где мы вставим порты и другие параметры данного параметра. И второй служебный параметр engress для исходящего трафика с фигурными скобками. Cidr_blocks = [“подсеть”], указывают откуда или куда разрешен данный поток трафика т.е подсеть 0.0.0.0/0 означает весь интернет или все подсети.
Обратите внимание:
Мы разрешили входящий трафик на 80 порт, тот порт на котором будет работать наш веб сервер.
Мы разрешили входящий трафик на 22 порт, тот порт, который может принимать соединение для подключения по SSH протоколу.
Мы разрешили ICMP трафик до нашего сервера, чтобы можно было из интернета проверить его доступность.
Мы разрешили трафик на 443 порт, если мы в будущем захотим сделать защищенное HTTPS соединение.
И мы разрешили весь исходящий трафик с сервера указав protocol “-1”
В такой конфигурации кода Terraform мы получим два отдельных ресурса Инстанс EC2 и группу безопасности, но нас такой вариант не устроит. Нам необходимо, чтобы данная группа безопасности была автоматически присоединена к нашему серверу. Это можно сделать с помощью нового параметра, который мы добавим в первую часть кода, где мы описывали aws_instance. Данный параметр называется vpc_security_group_id, с помощью данного параметра можно сразу присоединить несколько групп безопасности, через знак равенства и скобки “= [“номер группы безопасности”]”. Например, номер группы безопасности можно взять той, что создается по умолчанию.
Все остальные указываются, через запятую. Но в нашем случае данный вариант не подойдет, потому что у нас должно все подключиться автоматически, т.е присоединить ту группу безопасности, которая создастся и которую мы описали ниже. А делается это достаточно просто после знака = в квадратных скобках без кавычек вставляем aws_security_group – то что это группа безопасности, затем . – разделитель, затем вставляем имя группы безопасности, которую мы создали mywebserver, опять разделитель символ точки ., и мы ходим взять id. В итоге получается следующий параметр и его значение:
vpc_security_group_ids = [aws_security_group.mywebserver.id]
Этой самой строчкой мы привязали группу безопасности к нашему создаваемому инстансу. И как следствие возникла зависимость инстанса от группы безопасности. Следовательно, Terraform создаст сначала группу безопасности, а затем уже создаст инстанс.
Код Terraform не выполняется сверху вниз, зачастую он исполняется в зависимости от зависимостей или вообще одновременно, когда многие части зависят друг от друга. Следовательно, вот в таком коде мы создали зависимость. По коду вы можете заметить, что если необходимо еще дополнительный порт открыть, например, в группе безопасности, то необходимо скопировать часть кода, отвечающую за открытие порта и добавить необходимые настройки, порт и протокол, подправить cidr_blocks. После корректировки вставить в правильное место, как параметр.
И для того, чтобы завершить настройку нашего Web сервера, нам необходимо написать параметр user_data. В амазоне это называется bootstrapping, т.е начальная загрузка.
User_data = <<EOF
Скрипт
EOF
Как вы видите сам скрипт будет находится между EOF, а знак << говорит о том, что скрипт мы подаем на ввод.
Далее, как любой скрипт в Linux системе мы пишем сначала интерпретатор или shell который будет исполнять и на языке понятном для bash. Поэтому в скрипте не должно быть никаких отступов! Это важно, даже если плагин текстового редактора пытается поправить.
Теперь сам скрипт:
user_data = <<EOF
#!/bin/bash
apt -y update
apt -y install apache2
myip=`curl http://169.254.169.254/latest/meta-data/local-ipv4`
echo "<h2>WebServer with IP: $myip</h2><br> Build by Terraform!" > /var/www/html /index.html
sudo service httpd start
chkconfig httpd on
EOF
Сначала обновляем систему apt –y update, далее команда apt –y install apache2 устанавливаем apache веб сервер непосредственно. Следующая строка присваиваем значение переменной myip, с помощью получения данных из самого амазона curl http://169.254.169.254/latest/meta-data/local-ipv4. Далее просто добавляем в индексную страницу по умолчанию вывод того что мы получили с подстановкой IP. Следующая строка стартует сервис, и последняя строка проверяет конфигурацию апача.
Таким образом, мы получаем полностью готовый скрипт. Нам остается его сохранить в файле и инициализировать Terraform, командой terraform init и даем команду на применение terraform apply.
В результате команды мы видим, что будет создано 2 ресурса, все, как и планировалось. Инстанс и группа безопасности.
Как мы видим сначала, из-за зависимости создается группа безопасности. А затем поднимается инстанс, к которому и будет привязана данная группа. Спустя пару минут мы можем видеть, что у нас веб сервер поднялся.
IP-адрес можно найти в консоли.
Далее, если нам более данный Web сервер не нужен, то мы его можем уничтожить простой командой terraform destroy. И мы увидим, что из-за зависимостей ресурсы будут уничтожаться в обратном порядке тому, в котором они запускались. Сначала инстанс, потом группа безопасности.
Скрипт вы можете легко модифицировать и добавить более сложные детали установки и настройки веб сервера – это полностью рабочая конфигурация.
Функция Call Waiting при настройке в Asterisk или через FreePBX позволяет внутреннему номера принимать второй параллельный вызов, во время текущего разговора. Основной проблемой Call Waiting является то, что звонящий занятому абоненту слышит стандартный КПВ (Контроль посылки вызова, или просто гудок) в телефонной трубке, что создает ложное ощущение игнорирования.
Звонящий думает, что вызываемый абонент не взял трубку по причине обеда, перекура, невнимательности или похищения пришельцами.
Нас такой вариант не устраивает и мы предлагаем решение: звуковое уведомление звонящего о том, что вызываемый абонент сейчас разговаривает и не может принять вызов. Предложим звонящему подождать или позвонить попозже. Приступаем к реализации.
Настройка extensions_custom.conf
Как можно понять по названию заголовка, настройку мы будем производить в одноименном файле extensions_custom.conf, который находится в директории /etc/asterisk/:. Открываем для редактирования:
vim /etc/asterisk/extensions_custom.conf
После чего, добавляем в файл следующую конфигурацию:
[from-internal-custom]
include => macro-dialout-one-predial-hook
[macro-dialout-one-predial-hook]
exten => s,1,Noop(HINT STATUS - ${EXTENSION_STATE(${DEXTEN})})
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "INUSE"]?Playback(/var/lib/asterisk/sounds/ru/custom/busytest))
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "INUSE"]?Set(D_OPTIONS=Ttm))
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "RINGINUSE"]?Playback(/var/lib/asterisk/sounds/ru/custom/busytest))
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "RINGINUSE"]?Set(D_OPTIONS=Ttm))
Разберемся с каждой строчкой контекста macro-dialout-one-predial-hook:
exten => s,1,Noop(HINT STATUS - ${EXTENSION_STATE(${DEXTEN})}) - выводим в консоль сервера состояние хинта. Здесь может быть : UNKNOWN, NOT_INUSE, INUSE, BUSY, UNAVAILABLE, RINGING, RINGINUSE, HOLDINUSE, ONHOLD
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "INUSE"]?Playback(/var/lib/asterisk/sounds/ru/custom/busytest)) - проверяем статус хинта: если он равен INUSE (находится в разговоре), то проигрываем для него заранее записанный файл (/var/lib/asterisk/sounds/ru/custom/busytest, где сообщаем звонящему о занятости и просим подождать;
exten => s,n,ExecIf($["${EXTENSION_STATE(${DEXTEN})}" = "INUSE"]?Set(D_OPTIONS=Ttm)) - сразу после озвучивания нашего аудио, играем MoH (Music On Hold) звонящему;
Аналогичным способом, как показано выше, мы проводим проверку для состояния хинта равному RINGINUSE. Готово. Перегружаем диалплан командой:
asterisk -rx "dialplan reload"
Не работает с Follow Me
Если вы столкнулись с проблемой того, что данный функционал не работает на внутренних номерах, в настройках которых включена опция Follow Me, то сделайте следующие действия:
Откройте графический интерфейс FreePBX. Перейдите в раздел Settings → Advanced Settings;
Найдите опцию Default Follow Me Ring Strategy в разделе Follow Me Module и выставьте ее как ringallv2;
Повторите подобную итерацию для каждого экстеншена в разделе Follow Me;
Дайте команду asterisk -rx "dialplan reload" в консоль вашего сервера;
Неисправности
Вы не можете запустить виртуальную машину и получаете сообщения об ошибках зависимости диска и отсутствии файла.
В случае отсутствия файлов вы видите такие ошибки, как:
Cannot open the disk '/vmfs/volumes/volume/vm/vm-000002.vmdk' or one of the snapshot disks it depends on.
Cannot open disk "/vmfs/volumes/volume/vm/vm-000002.vmdk": The parent virtual disk has been modified since the child was created (18).
В случае отсутствия файлов, в файле vmware.log виртуальной машины есть сообщения, похожие на:
vmx| DISKLIB-LINK : "myvm.vmdk" : failed to open (The system cannot find the file specified).
vmx| DISKLIB-CHAIN : "myvm.vmdk" : failed to open (The system cannot find the file specified).
В случае сбоя зависимости снимка диска, в файле vmware.log виртуальной машины не будет ошибки «Невозможно найти указанный файл» (cannot find the file specified), но Вы увидите сообщения о том, что родительский виртуальный диск был изменён:
Cannot open the disk '/vmfs/volumes/4a365b5d-eceda119-439b-000cfc0086f3/examplevm/examplevm-000002.vmdk' or one of the snapshot disks it depends on.
The parent virtual disk has been modified since the child was created.
Эти ошибки могут возникать, если дескриптор диска виртуальной машины (VMDK) или файл данных отсутствуют или цепочка снимков стала несовместимой.
Решение
Это решение разбито на 2 части, в зависимости от проблемы:
Вы не можете запустить виртуальную машину из-за ошибки system cannot find the file specified (Система не может найти указанный файл) или других ошибок, например - file not found(Файл не найден).
Вы не можете запустить виртуальную машину из-за того, что the parent virtual disk has been modified since the child was created (Родительский виртуальный диск был изменён с момента создания дочернего диска).
System cannot find the file specified
Вы должны убедиться, что файлы диска виртуальной машины представлены должным образом.
Для каждого диска, включая снимок диска, должен быть файл дескриптора в виде vmName.vmdk
Кроме того, для базового диска также должен существовать файл с расширением flat.vmdk или separse.vmdk в виде vmName-flat.vmdk или vmName-separse.vmdk.
Для снимка диска, должен быть файл с разрешением delta.vdmk или sesparse.vmdk в виде vmName-######-delta.vmdk или vmName-######-separse.vmdk.
Если файлы дескриптора отсутствуют, то Вам необходимо создать их заново.
Если файлы данных (-flat, -delta или –sparse) отсутствуют, возможно, потребуется восстановить виртуальную машину из резервной копии.
The parent virtual disk has been modified since the child was created
Эта проблема обычно возникает из-за несоответствия идентификатора содержимого (CID). Чтобы устранить несоответствие CID, необходимо отредактировать файлы дескрипторов VMDK, чтобы обеспечить согласованность цепочки снимков.
Дополнительная информация
Для дисков RDM не будет файла –flat или –sesparse для базового диска. Физический режим RDM будет иметь файл в виде vmName-rdmp.vmdk. Виртуальный режим RDM будет иметь файл в виде vmName-rdm.vmdk.
Если дескриптор RDMA отсутствует, его также можно создать заново.