Использование T2/T3 инстансов в проде

Можно ли использовать T2/T3 для #EC2, #RDS и прочих сервисов в продовских окружениях? Запросто. Нужно лишь помнить и учитывать моменты, которые отличают их от "полноценных" инстансов. Это baseline (нагрузка) и сеть (задержки).

Baseline (нагрузка)

Если у вас постоянная/долговременная нагрузка на проде выше #baseline (правая колонка):

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

То он будет тормозить. Что плохо, точней, обычно недопустимо, потому ставим "полные" c4/c5/m4/m5 и т.д.

Если у вас нагрузка никогда (обычно, редко и очень ненадолго - чтобы хватило накопленных кредитов) не достигает baseline - запросто можно использовать эти полезные и более дешёвые инстансы (не только для виртуалок, но и для RDS, ES и др.).

Сеть (задержки)

Если с первым (загрузкой) более-менее всем понятно, то вот второй фактор многие не учитывают - скорость сети у T2/T3 инстансов не только ниже, а временами хромает, ковыляет, страдает и даже просто, бывает, лежит. Дипломатично в документации это называется "не гарантирована".

Для каких-то сервисов это может быть не столь критично, а вот лаги RDS на T2/T3 могут стать неприятным откровением. В таком случае активно используйте кэширование, мониторинг и здравый смысл.

Реальную скорость сетевого интерфейса и её катастрофу, когда кончаются бурсты - можно посмотреть по следующей полезной ссылке:

https://cloudonaut.io/ec2-network-performance-cheat-sheet/

Итого

Не умеешь - не обгоняй. Боишься, деньги казёные или лень разбираться - ставь "полные версии".

Хочешь (нужно) сэкономить, протестировано, мониторинг, кэширование и прочий фарш помноженный на рассудок - смело используем T2/T3, в том числе на проде.

#t2 #t3 #prod

⁠SSM Session Manager + SSH

Вслед за недавно появившимся EC2 Instance Connect, прокачался идеологически правильный способ коннекта к виртуалке - через #Session_Manager. Теперь он умеет туннелировать SSH и SCP.

Настройка SSH Session Manager Sessions (отличное название, чуваки, снимаю шляпу) по официальной ссылке:

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html

У кого уже стоит Session Manager plugin - нужно обновить до версии 1.1.23.0 или более новой.

⁠SSH туннелирование через SSM Sessions Manager

Куда

На виртуалке, куда мы хотим коннектиться должен быть установлен SSM агент. Правильные пацаны юзают Amazon Linux 2, где он стоит по умолчанию на новых версиях. Однако даже на только что поднятых из консоли виртуалках стоит не самая последняя версия (фу, Амазон), потому запускаем стандартный установочный однострочник:

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

Для неудачников на своих Убунтах и прочих некошерных линуксах - двигаем по ссылке первоисточника.

Присоединяем к виртуалке нужные #IAM права (было тут и тут), без которых она не имеет права зарегистрироваться в #SSM и вы не сможете использовать #Session_Manager для подключения к ней.

Для всех (т.е. 0.0.0.0/0 - обязательно) открываем порт 22 (укоряюще смотрит на всех безопасников Амазона).

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

Откуда

На виртуалке (компьютере), откуда будем коннектиться на подготовленную ранее виртуалку, требуется #aws_cli (само собой разумеется) и должен быть установлен Session Manager Plugin.

Правим файл SSH-конфига (который в домашнем каталоге ~/.ssh/config), добавляя для хостов, куда хотим коннектиться запуск ProxyCommand - см. официальную ссылку.

Всё, должно работать:

ssh -i /root/.ssh/ttt19 ec2-user@i-016de9a622dfd5430

(см. картинку)

===

#multi_account_strategy

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

Для примера, вот полная версия реального файла /root/.ssh/config:

# CodeCommit
Host git-codecommit.*.amazonaws.com
 User ADDAJA5W7IDY5CHX3YKK
 IdentityFile ~/.ssh/codecommit_devops-user

# SSH over Session Manager
host i-* mi-*
 ## single account
 #ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

 ## multi account (stage account)
 ProxyCommand sh -c "aws --profile=stage ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

#tutorial

Deployless - быстрей, чем vim на проде

Только пытаетесь освоить #serverless? Забудьте, это же прошлый век! Нонче на острие прогресса #deployless — все ваши изменения на проде быстрей, чем вы поняли, что прочитали! Или написали.

https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671

Всего за две сотни в месяц можно мгновенно покрывать всё ваше стадо продов, а за штуку - ещё и всех соседей.

#пятничное

Кому интересны подробности по #deployless, то их есть тут:
• https://waterbear.cloud/2019/07/06/waterbear-cloud-goes-open-source
• https://waterbear.cloud/2019/06/07/the-semantic-cloud-a-new-vision-for-infrastructure-as-code-projects
• https://www.reddit.com/r/aws/comments/cblkgx/new_semantic_declarative_infrastructureascode
• https://news.ycombinator.com/item?id=20395228

⁠Amazon CloudFront announces new Edge location.

⁠Увеличение EC2 диска

Просто увеличить размер диска (#EBS #Volume) через AWS Console не составляет труда. Для пущей безопасности в любом случае лучше сделать перед этим снэпшот.

Главное не забыть, что кроме увеличения диска, после требуется ещё и увеличение раздела, иначе доступное пространство не изменится.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

Это простая, частая и обычно хорошо запоминающаяся ошибка — будет более полезно новичкам, но также и напоминание тем, у кого в очередной раз «всё забилось логами».

Кому удобней читать (и комментировать) в Facebook - есть такая страничка:

https://www.facebook.com/aws.notes

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

Пока там ещё не всё, но, возможно кто-то подключился недавно и будет интересно почитать предыдущее (по мере наполнения).

Подписывайтесь или просто поставьте лайк странице. :)

#facebook

Transit Gateway vs VPC Peering

AWS Transit Gateway действительно удобный способ объединения VPC и он рекомендован как современный подход к реализации VPC peering.

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

https://aws.amazon.com/transit-gateway/pricing/

Если присмотреться, то по сравнению с #VPC_peering, где вы платите лишь за трафик по стандартному ценнику $0.02/GB, добавляется ещё и часовая составляющая — по 5 центов с носа каждой #VPC. При этом VPC минимум две, а значит $0.1 в час или условная m5.large виртуалочка, что для многих может оказаться роскошью.

А когда у вас аккаунтов (а значит и VPC) больше, то сумма за #Transit_Gateway будет кратно более ощутимой. Понятно, что для крупной организации это не те расходы. Однако стоит про них знать, учитывать и ещё крепче любить старый добрый VPC peering.

#pricing

Цены на трафик в Амазоне

Дополняя предыдущий пост по стоимости трафика - расширенная картинка где, чего и сколько стоит.

#pricing

Вертикальное масштабирование EC2

#Вертикальное_масштабирование EC2 - это изменение типа виртуалки, а не количества виртуалок в autoscaling group (что есть горизонтальное масштабирование).

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

Можно делать это руками - останавливая, докидывая мощи и самому стартуя виртуалку, например, придя на работу.

А можно это доверить готовому решению AWS Ops Automator. Как его приготовить под такую задачу, есть тут:

https://aws.amazon.com/ru/blogs/architecture/aws-ops-automator-v2-features-vertical-scaling-preview/

#AWS_Solutions #Ops_Automator

⁠Сертификаты-требования-стандарты — Compliance

Когда вам вдруг потребовалось разобраться с вашим приложением на Амазоне и его соответствия каким-то сертификатам/требованиям/стандартам (в русском языке нет простого и точного соответствия, потому лучше использовать #compliance), то прежде, чем гуглить и википедить, стоит пройти по официальной ссылочке:

https://aws.amazon.com/compliance/programs/

К примеру, если заказчик вдруг поинтересовался, сможет ли он выйти с вашим приложением на американский рынок медицинских услуг, а вам нужно хоть что-то быстро ответить — берите HIPAA и смотрите, какие из используемых вами AWS сервисов, на которых строится ваше приложение, сертифицировано #HIPAA (список сервисов пополняется):

https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

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

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

#аудит_своими_руками

Проверочная опция --dryrun при работе с S3

Если вы боитесь или не уверены в том, что произойдёт с вашим #s3 бакетом после запуска команды aws s3 sync или aws s3 cp, то не забывайте про иногда спасительный ключик --dryrun, добавив который, увидите, как бы вы всё поломали, если бы его не добавили:

aws s3 sync --dryrun ./my-folder s3://my-bucket/some-path
(dryrun) upload: my-folder/my-cert.crt to s3://my-bucket/some-path/my-cert.crt
(dryrun) upload: my-folder/my-cert.key to s3://my-bucket/some-path/my-cert.key

В строчках добавлено (dryrun), обозначающее, что команда бы сделала без этого ключика. А так ничего не происходит.

Опция --dryrun покажет проблемы #IAM доступа (правильно ли прописаны #bucket_policy), т.е. даст такую же ошибку как и с "нормальной" командой.

Особенно --dryrun помогает, когда вы хотите залить большой объём данных в "пересекающиеся" директории важного объёмного бакета, которые после упаритесь вылавливать-исправлять (или не сможете совсем). Тут можно было бы посоветовать скопировать данные в другой бакет, но часто это многие гигабайты или просто невозможно.

В общем, --dryrun сэкономит ваши нервы и время. Даже если у бакета включено #versioning.

Защита root-аккаунта или тысяча первое китайское предупреждение

Спички детям не игрушка, мойте руки перед едой, используйте двухфакторную авторизацию и не давайте #root-доступ в #root-аккаунт:

https://medium.com/@victoryteam/nightmare-scenario-employee-deletes-aws-root-account-29e28af15436

p.s. Обсуждение на реддите:

https://www.reddit.com/r/aws/comments/cgty96/nightmare_scenario_employee_deletes_aws_root/

#плач_Ярославны

⁠Проблемы NLB + TCP Health Checks

Когда требуется реализовать end-to-end шифрование, то логично выбирать #NLB для подобной задачи. Т.е. это когда не подходит терминация #SSL трафика на ALB, а вы хотите прямиком доставить ваш #TLS до каждого инстанса.

При реализации такой очевидной схемы с NLB можно наткнуться на нестабильную работу TCP Health Check - у вас точно открыты порты, а Health Check не прокатывает, совершенно случайные ошибки, лаги с ответами и прочие странности.

В таком случае не забывайте про ELB (Classic Elastic LoadBalancer). Он прекрасно умеет TCP forwarding и пока его окончательно не списали с большой долей вероятности решит ваш вопрос. С ним не будет никакой магии с HealthCheck-ами.

Рекомендация использовать #ELB вместо #NLB является крайней мерой и просто отражает тот факт, что некоторые сервисы даже спустя годы могут быть не самыми стабильными. А также их стабильность может зависеть от региона.

В любом случае помните, что большинство задач на Амазоне всегда можно решить несколькими способами и решить хорошо.

AWS Secrets Manager secrets - вставляем в окружение и сохраняем на диск

Достойные "напосмотреть" утилитки для работы с секретами — одна позволяет инжектировать их в окружение:

https://github.com/sgreben/aws-secretsmanager-env

А другая — в файлы:

https://github.com/sgreben/aws-secretsmanager-files

Нет возможности работы в мульти-аккаунте - вещь свежая, наверняка допилят. Кто любит #Go - может понравиться.

#Secrets

#serverless #пятничное

Интересно наблюдать, как количество #нужны_поднобности сначала увеличивается, а потом уменьшается (увеличивая #интересно). Как говорится - человек "догнал".

Для тех, кому всё-таки подробности нужны - следующая идея для стартапа.

Берёте сервер заказчика, переименовываете его в #serverless. После рапортуете о внедрении модной технологии на проекте, а для потверждения скидываете скриншот. Профит.

Универсальная таблица оценки задач

изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч

первоисточник

#agile #субботничное

[​​](https://telegra.ph/file/b7ccedaea5085a104cd05.jpg)Будь наготове

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

Деньги-то она может поедать, но вот жить (вечно) - вопрос (маловероятно). Например, случившаяся на эти выходные ситуация - на картинке снизу.

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

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

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

#ec2 #degradation #retirement #issue