1.1.Создать виртуальную сеть и 2 подсети, 1 публичная другая приватная
1.2 Nat для приватной
1.3 Security Groups
1.4 Instance - Создание сервера в публичной и приватной сетях
1.5 подключение к instance через Session Manager
1.5.1 Создадим IAM роль
1.5.2 подключение к private instance через Session Manager используя endpoint
2.хранилище S3 доступ до которого только из приватной сети
3.Auto scaling group - горизонтальное масштабирование
3.1 Target Groups
3.2 Load Balancer
3.3 Launch Templates
3.4 Autoscaling Group
1.1 Создаём 2 подсети
для начала создадим виртуальную сеть в которой будем создавать наши подсети:
создаём 2 подсети
10.5.1.0/24. - будет публичной
10.5.2.0/24. - будет приватной
пока создаём подсети в одной зоне доступности:
подсети мы создали но доступа в интернет у них нету, чтоб появился надо создать internet-gateway
Теперь надо присоединить его к нашему VPC
Теперь настроим автоматическую выдачу публичных айпи-адресов тем серверам, которые будут запущены в публичной подсети. Выберем первую публичную подсеть в списке подсетей
Теперь настроим таблицы маршрутизации - без соответствующих маршрутов наш интернет-шлюз всё равно останется недоступен
там уже автоматически создан route table проассоциируем его с нашей публичной подсеткой:
подредактируем маршруты, новый должен идти ПОСЛЕ локального и захватывать все адреса назначения (0.0.0.0/0). Точкой назначения выберите наш новый интернет-шлюз. Затем сохраните маршруты.
выбираем наш созданный IGW
1.2 Nat для приватной
Для публичной сети мы настроили выход в интернет, теперь настроим выход в интернет для приватной подсети и настроим NAT
Отмечу что NAT gateway создаётся в публичной подсети:
создание NAT занимает время, как только он создастся можно создавать маршрутизацию route table
Отредактируем таблицу маршрутизации
новый маршрут: идея точно такая же, весь трафик (0.0.0.0/0), который не попадает в local, должен идти в NAT Gateway этой подсети
теперь привяжем эту таблицу к соответствующей приватной подсети
1.3 Security Groups
Прежде чем добавлять сервера, придётся добавить группы безопасности
Создаём Security Groups для публичной сети
Правила будут следующие HTTP откуда угодно, также добавим SSH и ICMP
создаём ещё одну группу для приватной подсети:
доступ по 22 разрешаем только с Security Groups публичной подсети
Создаём kep pair, формата - pem, если его ещё нет. Используйте его при создании инстансов.
после его создания, он будет автоматически скачан в формате pem на ваш комп.
1.4 Создание сервера в публичной и приватной сетях
добавляем User data это грубо говоря скрипт который будет запускать при запуске инстанса, в моём случае я ставлю nginx
1 2 3 4 |
#!/bin/bash amazon-linux-extras install -y nginx1 systemctl start nginx echo "Hello from `curl http://169.254.169.254/latest/meta-data/public-ipv4`" > /usr/share/nginx/html/index.html |
а строкой
echo "Hello from `curl http://169.254.169.254/latest/meta-data/public-ipv4`" > /usr/share/nginx/html/index.html
я дёргаю meta data внутренний айпишник
далее если надо добавляем жёсткий диск или выбираем его тип:
добавляем тэги если надо
назначаем Security Group который мы создали для публичной подсети
запускаем:
выбираем наш ключ:
как видим всё нормально создалось, пробуем подключиться:
проверяем в браузере что по публичному айпишнику отдаются наши данные:
всё ОК теперь запускаем наш второй инстанс в приватной сети:
всё тоже самое кроме момента выбора подсети:
User data так же добавляем чтоб проверить что доступ в интернет есть:
выбираем в security groups нашу приватную :
остальное всё также.
как видим наш инстанс запустился и у него есть только приватный айпишник из нашей подсети:
пробуем подключиться и у нас ничего не должно получиться так как публичного айпишника нету:
но мы можем подключиться с публичного инстанса, так как оттуда у нас есть доступ согласно настроенной security group
Подключаемся к публичному инстансу:
проверяем что до приватного есть доступ по 22 порту:
[ec2-user@ip-10-5-1-78 ~]$ telnet 10.5.2.127 22
Trying 10.5.2.127…
Connected to 10.5.2.127.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4
^]
telnet> quit
Connection closed.
копируем ключ на публичный инстанс
[root@centos7 ~]# scp -i andr-key-pair.pem andr-key-pair.pem ec2-user@3.135.198.211:~/
и подключаемся с помощью него на приватный:
ssh -i andr-key-pair.pem 10.5.2.127
как видим мы подключились и nginx установлен, следовательно у нас есть доступ интернету через наш NAT Gateway
1.5 подключение к instance через Session Manager
для работы session manage необходимо чтобы был доступ в интернет, настроим подключение к публичному instance и приватному как через NAT gateway так и через endpoint
1.5.1 Создадим IAM роль
теперь рассмотрим Security Groups, для работы ssm необходим как минимум доступ по 443 порту из 0.0.0.0/0
а теперь добавляем нашему инстансу IAM роль:
всё ок.
1.5.2 подключение к private instance через Session Manager используя endpoint
а теперь подключимся к нашему приватному инстансу используя endpoint но предварительно удалим NAT
удалим subnet associations у Route tables
удаляем айпишник
Всё у приватной подсети доступа в мир нету теперь можем настроить ENDPOINT
но нам ещё надо включить Edit DNS hostnames для нашего VPC
Всё теперь нужно добавить 3 endpoint ssm ssmmessages ec2messages
точно так же добавляем для ssmmessages и ec2messages, после создания какое то время всё висит в статусе pending
после чего надо проверить что подсети внутренние:
ну всё ок 3 эндпоинта созданы:
теперь создаём IAM роли, но мы её уже создали ранее, когда настраивали доступ для публичного инстанса:
вот этот пункт: 1.5.1 Создадим IAM роль
но нам необходимо добавить к нашей роли политику AmazonSSMManagedInstanceCore
теперь можно назначать IAM роль для нашего private instance
Помимо доступа из нашей публичной сети, для работы ssm необходим как минимум доступ по 443 порту из 0.0.0.0/0
поэтому правим нашу private Security Groups
всё можно подключаться:
как видим всё нормально подключилось и доступа в мир у нас нету:
2.хранилище S3 доступ до которого только из приватной сети
Simple Storage Service с создания контейнера для файлов - так называемого бакета. В рамках этого задания мы должны создать бакет, куда мы сможем загружать файлы, доступные для скачивания кому угодно, то есть публичное хранилище.
Для начала перейдём в службу S3 и нажмём на Create Bucket. В первом шаге надо ввести уникальное имя и выбрать регион:
создаём политику на удаление:
Теперь надо создать роль IAM.
Вернёмся к списку инстансов, выберем наш и изменим IAM роль: Actions -> Security -> Modify IAM Role.
подключаемся и проверяем доступность S3 бакета
[ec2-user@ip-10-5-1-78 ~]$ aws s3 ls s3://and-bucket
[ec2-user@ip-10-5-1-78 ~]$
Готово, там пусто. Теперь загрузим любой файл при помощи команды copy и проверим его наличие предыдущей командой.
[ec2-user@ip-10-5-1-78 ~]$ touch test-file
[ec2-user@ip-10-5-1-78 ~]$ aws s3 cp test-file s3://and-bucket/
upload: ./test-file to s3://and-bucket/test-file
[ec2-user@ip-10-5-1-78 ~]$ aws s3 ls s3://and-bucket
2021-09-19 13:57:47 0 test-file
как видим всё ок:
3.Auto scaling group - горизонтальное масштабирование
3.1 Target Groups
Чтобы освоить балансировку нагрузки и масштабирование, создадим и настроим группу серверов для простого веб-приложения.
Для начала, создадим Target Group - целевую группу. Сделать это можно в разделе Load Balancing сервиса EC2
задаём имя группы
далее не забываем указать нашу VPC
Группа готова, но совершенно пуста. Перейдём во вкладку Instances и запустим Launch Wizard, нажав на “Launch”/
Создаём инстанс как указано в данной инструкции:
1.4 Instance - Создание сервера в публичной и приватной сетях
используем следующие данные:
- AMI: Amazon Linux 2
- Type: t2.micro
- Number of Instances: 2
- Subnet: pubclic
- User Data:
1 2 3 4 5 6 |
#!/bin/bash yum update -y amazon-linux-extras install -y nginx1 systemctl start nginx echo "Hello from `hostname`" > /usr/share/nginx/html/index.html |
создайте ещё сервер с такими же настройками, но уже в другой Availability Zone. Ваши подсети могут отличаться - это неважно, но важно, чтобы сервера были в разных подсетях одного региона.
Сервера созданы, но не добавлены в группу, давайте сделаем это. Перейдите в Target Groups и выберите нашу группу.
Нажмите на “Register targets“, выберите созданные сервера и добавьте их, нажав на “Include as pending below”. Завершите регистрацию целей кнопкой “Register pending targets”.
После того как группа сформирована, необходимо подключить балансировщик. Перейдём во вкладку “Load Balancers” и создадим новый
3.2 Load Balancer
Укажите любое подходящее название для балансировщика. Нам потребуется “Internet-facing” балансировщик с поддержкой IPv4 Для Application Load Balancer будет автоматически создан listener на порт 80. Этого достаточно, здесь нечего менять
Далее необходимо выбрать зоны доступности, минимум две. Выбор зон осуществляется через выбор подсетей, поскольку каждая подсеть относится к конкретной
В разделе Security Groups создадим новую группу специально для этого балансировщика. Пока что просто разрешим все входящие соединения по порту 80.
сохраняем, переходим на предыдущую вкладку и выбираем на security group
В следующем шаге нам нужно указать целевую группу. Выбираем “Exisistring Target Group” и указываем нашу группу
как видим всё ок, теперь проверим по нашему доменному имени которое выдал Load balancer
http://andr-lb-1512071376.us-east-2.elb.amazonaws.com/
как видим если обновить то выдаются данные с разных инстансов(с разных зон доступности)
Так как ранее мы настроили Security group для наших серверов с публичным доступом то наши instans доступны и по своим публичным IP адресам:
Настроим доступ ТОЛЬКО с Load balancer
Создадим security group с доступом по 80 порту ТОЛЬКО с security group нашего баллансировщика
далее удалим текущую security group
и добавим созданную from-load-ballance-to-instance
для второго сервера делаем тоже самое.
всё теперь по публичному айпишнику наши instance недоступны
доступны только по доменному имени:
http://andr-lb-1512071376.us-east-2.elb.amazonaws.com/
3.3 Launch Templates
Для настройки автоматизированного масштабирования инфраструктуры нам понадобится шаблон запуска
Перейдём в Instances -> Launch Templates (Обратите внимание, не Configurations, а именно Templates - Configurations считаются устаревшими и вытеснены шаблонами)
В качестве AMI укажем Amazon Linux 2, а тип инстанса - t2.micro (помните, что это единственный тип, подходящий под условия Free Tier.) Добавьте KeyPair, если планируете использовать SSH, но в рамках этого модуля нам подойдёт и EC2 Connect.
В настройках сети выберите VPC - это более продвинутый способ, замещающий устаревший EC2 Classic. Важно: в Security Groups добавьте группу, которую мы будем использовать для настройки доступа балансировщика к инстансам целевой группы.
Очень важная настройка в Advanced Details: добавьте уже знакомый скрипт в User Data.
готово
3.4 Autoscaling Group
В следующем шаге мы можем выбрать варианты используемых инстансов: применять выбор из шаблона или комбинировать он-деманд и спот инстансы. выберем более простой вариант, поэтому выбираем “Adhere to launch template”.
далее можно создать load ballancer или использовать существующий, я выберу использовать уже существующий:
указываем параметры:
и сохраняем:
готово.
как ниже можно увидеть мы наш auto scaling group поднял 3 instance и максимум сможет их увеличивать до 9 штук
на скриншоте ниже мы можем увидеть 5 instances это 2 наших поднятых вручную и 3 поднятых с помощью auto scaling group
Чтобы убедиться, что всё работает
Сломаем пару серверов, два способа на выбор:
- cat /dev/random > /dev/null (увеличим нагрузку на CPU и будет скейл до 9)
- sudo systemctl stop nginx (останавливаем службу. При этом поднимется новый, а текущий удалится и scale останется на 3-ёх)
как видим новые тачки поднимаются:
Убираем нагрузку на CPU, чтобы scale упал до 3-ёх. Ждём около 10 минут. Чтобы scale сработал быстрее нужно подключить платный сервис - CloudWatch.
Не забываем подчищать за собой. Удаление абстракции - auto scaling group, удаляет автоматически созданные им инстансы.