AWS Notes

Классы хранилищ объектов – Amazon S3

Бэкапимся сразу на S3

PostgreSQL

Чтобы забэкапиться без сохранения локально, что безопасно (не сохраняется копия важной информации) и часто удобней:

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz

Дампы читаются редко, а весят много, потому добавим сохранение на STANDARD_IA:

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz --storage-class STANDARD_IA

И шифрование:

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz --storage-class STANDARD_IA --sse aws:kms

MySQL

Аналогичный вариант для MySQL с paranoid_mode=on опцией (используется shred, чтобы врагам ничего досталось):

https://github.com/sparkcodeuk/kb/tree/master/mysql/mysqldump_to_s3

#backup #s3

Amazon

649 views16:42

👍интересно 30

⁠Выбор типа EBS

Полезная статья по выбору #EBS:

https://aws.amazon.com/blogs/storage/maximizing-microsoft-sql-server-performance-with-amazon-ebs/

#EC2

624 views06:38

👍интересно 25

⁠Сервисы по типу в различных облаках и on-prem

Картинка начала 2019-го года, полезна для поиска аналогичных сервисов в разных облаках.

Для тех, кто работает лишь с AWS и считает его безусловным лидером (что так и есть) может быть откровением, что набор сервисов в Azure больше (что так и есть).

#AWS #Azure #GCP #Oracle #IBM #Alibaba #info

842 views09:26

👍интересно 31

4. Lifecycle operations. 3

Билет 3
===
Как можно сохранить файл с его правами 755 на S3?

1. Это невозможно.
2. Можно через S3 API.
3. Можно только сохранив в архиве.
4. Можно с помощью Lifecycle в AWS Console.

#AWS_Certification #training

486 views12:31

1. Никак. 19

2. S3 API 19

3. Только в архиве. 54

⁠Ответы на Билет 3 по S3

S3 - объектное хранилище, а не файловая система, потому прикрепить информацию о правах файла невозможно (ведь в #s3 хранятся объекты, а не файлы - как и следует из названия). Потому ответы 2 и 4 отпадают.

Однака аттрибуты файла можно сохранить в архиве:

tar czf my_file.tar.gz my_file

Который уже сохранить на S3 (в виде объекта). Потому правильный ответ - 3.

===

Цель вопросов по Билет 3 - запомнить, что S3 - это про объекты, а не файлы. Несмотря на то, что там хранятся файлы, все говорят про него как "файловое хранилище", используют термин "путь к файлу", а в консоли даже можно создать "папки" (create folder).

#AWS_Certification #training #answers

499 views15:31

Специалист AWS по базам данных

Добавилась шестая специализация в сертификатах AWS - специалист по БД:

https://d1.awsstatic.com/training-and-certification/docs-database-specialty/AWS%20Certified%20Database%20-%20Specialty%20Exam%20Guide_v1.0_08-23-2019_FINAL.pdf

#AWS_Certification

648 views06:58

👍интересно 25

неинтересно👎 2

Automating AWS Account Deletion – One Cloud Please

Автоматизация удаления аккаунта в AWS Organization

На данный момент удалить аккаунт в организации - больная боль. Удалив ресурсы вы всего лишь закрываете аккаунт и он продолжает оставаться в вашей организации месяцами (в статусе closed).

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

А пока предлагаю почитать детектив на тему автоматизации удаления аккаунтов. Спойлер - не делайте так, это опасно. Однако всегда интересно посмотреть на извращения настоящего профессионала.

https://onecloudplease.com/blog/automating-aws-account-deletion

#Organization

Onecloudplease

This week Control Tower was released publicly, a managed service that replicates and iterates on the AWS Landing Zone solution previously released. It has an in-built capability of an

518 views12:22

⁠Просто и со вкусом или --query в aws-cli

Очередная текущая задача, где в терминале нужно было быстро найти нужный VPC ID по известному диапазону адресов для неё (CIDR block).

Выполняем очевидную команду для этого:

aws ec2 describe-vpcs

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

Для этого многие ставят jq, который сделает что угодно с json выводом. Однако не нужно забывать про флажок --query, который из коробки есть в любой #aws_cli.

Итак, смотрим верхние строчки результата работы:

{
   "Vpcs": [
       {
           "VpcId": "vpc-04bec1a347f431036",
...
           "CidrBlock": "10.11.0.0/16",
...

Нас интересуют элементы VpcId и CidrBlock, для этого перебираем все выведенные Vpcs, получается следующая конструкция:

aws ec2 describe-vpcs --query Vpcs[*].[VpcId,CidrBlock]

[
   [
       "vpc-04bec1a347f431036",
       "10.11.0.0/16"
   ],
   [
       "vpc-6b9b1111",
       "172.31.0.0/16"
   ]
]

Уже хорошо, лишь то, что нужно, можно довольствоваться. А можно сделать ещё и красиво:

aws ec2 describe-vpcs --query Vpcs[*].[VpcId,CidrBlock] --output table

#query

553 views12:20

👍интересно 49

⁠Какие AWS сервисы используют Security groups?

Решили расчистить заброшенный аккаунт от ненужного и обнаружили сотню-другую неизвестно чьих и используемых ли security groups?

Зачистка

Самый простой способ почистить ненужные-неиспользуемые #sg - просто взять и удалить. Вот так просто выделить все и удалить.

Эту операцию особо приятно проделывать на проде, быстренько нажав подтверждение Yes в присутствии кого-нибудь важного. Вы-то знаете, что все хоть как-то задействованные sg-группы останутся и удалятся лишь бесхозные, не прикреплённые ни к какому сервису и на которые никто не ссылается. А лицезрящий ваш самоубиственный поступок руководитель - нет.

Прополка

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

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

Сервисы

Когда инстансы прошерстили и всё равно не удаляется - вспоминаем, что sg используется не только в EC2, но и в RDS! Точно, находим таким образом забытые сто лет жрущие деньги никому не нужные базы данных, гасим, гордимся собой за сэкономленным в будущем казёные деньги и снова удаляем.

Часть удалилось, но часть нет. Какие же сервисы ещё используют security groups? Напрягаем логику и вспоминаем про Лямбду (умеющую ходить в VPC) и что у нас бесхозный Redis в углу завалялся из ElastiCache, который тоже имеет security group. StackOverflow подсказывает, что sg ещё есть у EMR и Redshift. Всё?

А вот и не всё. Вот полный список сервисов, использующих security groups:

AppStream
Batch
CodeBuild
DAX
DMS
DocDB
EC2 (AutoScaling, ELB, ALB, NLB)
ECS
EFS
EKS
ElastiCache
Elasticsearch
EMR
Events
FSx
Glue
Lambda
MediaLive
MSK
Neptune
OpsWorks
RDS
Redshift
Route53 (Route53Resolver)
SageMaker

Удачной борьбы с сорняками!

#security_groups

582 views14:38

👍интересно 45

неинтересно👎 1

⁠Поиск по IAM политикам

Для этого есть очень хороший секретный ресурс:

https://iam.cloudonaut.io/reference

Здесь находится список всех #IAM политик на текущий момент с возможностью разнообразного поиска.

Например, для поиска tag-supported сервисов в поле Conditions задаём ResourceTag и получаем актуальный список для такой манипуляции.

#info

751 views15:39

Расходы на прод против остальных

Интересные цифры: в AWS проектах обычно на prod-окружения уходит около 80% денег, на dev/stg/test/etc — 10-20%.

А как у вас? Сколько уходит на non-prod окружения? Примерно.

#опрос #расходы #статистика

494 views15:38

Для внутренних адресов можно выбрать несколько регионов, описанных в RFC1918:

10.0.0.0    - 10.255.255.255  (10.0.0.0/8     prefix)
172.16.0.0  - 172.31.255.255  (172.16.0.0/12  prefix)
192.168.0.0 - 192.168.255.255 (192.168.0.0/16 prefix)

и RFC6598:

100.64.0.0  - 100.127.255.255 (100.64.0.0/10  prefix)

Из четырёх "удобными" являются лишь два - 10.0.0.0/8 и 192.168.0.0/16. Их подсети описываются очевидной схемой 10.х.х.х и 192.168.х.х, хорошо запоминаются и потому вероятность ошибиться минимальна, не путая локальные адреса с публичными.

Кроме того, Docker использует по умолчанию регион 172.17.0.0/16 - пересечение с ним обеспечит незабываемые ощущения при отладке. Равно как и дефолтная подсеть VPC в Амазоне это 172.31.0.0/16, что сделает проблемным возможный пиринг при использовании такого же региона.

Потому в общем случае не стоит мудрить и использовать для CIDR block подсети из 10.х.х.х (10.0.0.0/8) — много адресов и обычно они банально короче (меньше кнопок жать).

#VPC #CIDR

613 viewsedited 12:21

👍интересно 34

неинтересно👎 2

⁠Disallow Actions as a Root User

Полгода назад я добавил тэг #paranoid к посту про защиту от работы из-под рута, а теперь это в официальной документации:

https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-guardrails.html#disallow-root-auser-actions

507 views10:19

👍интересно 14

Amazon S3 | Amazon Web Services

S3 history

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

Нужно - понимать. А чтобы как раз понимать - нужно знать как оно было и почему стало как сейчас.

Итак, отметим лишь точку отсчёта:

https://aws.amazon.com/blogs/aws/amazon_s3/

В общем - #S3 вместе с #SQS и #EC2 ведут свой отсчёт с 2006-го года.

Это время расцвета VPS-хостингов со всей болью, помноженной на стоимость и ненадёжность при существенных нагрузках. Айфон лишь рождался, а крупным потребителям вычислительных мощностей всё приходилось делать самим. Потому с появлением первого крупного игрока, обещавшего SLA 99,99%, огромное количество будущих крупных клиентов Амазона бросились изучать возможности и стабильность его сервисов, в первую очередь S3.

Цена в 15 центов за гигабайт на то время была вполне себе конкурентной, потому основными в тестах была надёжность и стабильность доступа на протяжении длительного времени. Одними из первых крупных интересантов выступили штатовские универы, которые хотели избавиться от расходов на железо и перекинуть всё своё хозяйство в Амазон.

Через годик, убедившись в достаточной надёжности, они стали активно переходить туда.

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

#s3_history #history

Amazon

Earlier today we rolled out Amazon S3, our reliable, highly scalable, low-latency data storage service. Using SOAP and REST interfaces, developers can easily store any number of blocks of data in S3. Each block can be up to 5 GB in length, and is associated…

527 views11:38

👍интересно 42

неинтересно👎 1

⁠S3 нулевых

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

Забегая вперёд, скажу, что тема с Амазоном не выгорела, т.к. даже спустя четыре года с момента открытия он держал планку в 15 центов за гигабайт, что в 2010-м году уже не выглядело конкурентным ни разу и потому выбор пал на покупку своих dedicated servers. Руководству сложно и в наше время понять, зачем это вот всё дорогущее и ненужное, когда вот они, свои железяки и специально обученные админы в комплекте. А что уж говорить про десять лет тому.

Но не об этом. Хотя ещё чуть-чуть о нём. Через два года стартапный бэкап так не взлетел и на Амазон таки мы переехали. Денег было потрачено столько, что навсегда хватит, чтобы понимать, насколько удобен Амазон для стартапов.

Как же работали с S3 десять лет назад? Консоль - это же очевидно? Вот и я так думал.

Зарегистрировался на AWS, скачал Access Key ID и Secret Access Key. Зашёл в AWS Management Console, однако там всё лишь для управления виртуалками, вкладки с S3 нет. Как быть?

Оказалось, что для управления S3 через веб нужно было ставить сторонние утилиты, одним из самых популярных (бесплатных) был плагин под Firefox с незамысловатым названием S3Fox (полное название The FireFox S3 Organizer). Его же рекомендовали и пользовались сами амазоновцы.

Это было удивительно. Я знал Амазон как главного лидера в облакостроении, а чтобы пользоваться его сервисом, даже спустя четыре года после старта #S3 — нужно было ставить чужие плагинчики или шпилить в неудобную командную строку из-под жавы.

Только много-долго после я понял и осознал всю мощу такого подхода. Когда другие пилят пока не допилят, Амазон уже не один год эксплуатирует и продаёт, доделывая по ходу.

Так, я отвлёкся. S3Fox просто настраивался, имел FTP-подобный интерфейс, действительно просто позволял работать с бакетами. Однако эта схожесть с обычным файлохранилищем, но при этом отсутствие хоть какой-то возможности разграничить доступ - особо разочаровывала.

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

Кто ещё не понял - да, тогда ещё не было #Bucket_polices и #IAM. Их завезли позже в 2010-м и это очень важно запомнить. Почему важно - станет ясно потом.

Итого запишем главный результат лирического отступления - первобытные девопсы амазонили на S3 без всяческих политик. Юзали всевозможные плагины, рубились в руби командной строкой и дотошно логировали все проблемы доступности S3, покрывая жалобами девелоперский форум.

#s3_history #history

541 views07:01

👍интересно 42

неинтересно👎 1

полная версия (с картинками)

⁠S3 invention

Разбираясь с исторической точки зрения, нельзя не упомянуть про ещё один полезный подход, который очень эффективен для того, чтобы понять и разобраться, а не только запомнить. Это когда пытаешься сам изобрести, создать, придумать и настроить ту штуку, которая интересует. В данном случае - Amazon S3.

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

1. Нужно иметь возможность закидывать файлы в будущее хранилище (а также, понятно, удалять и др. стандартные операции для файлов).
2. Нужна возможность делать эти файлы как приватными, так и доступными из интернета.

Вопросы доступности, устойчивости к нагрузками и прочие надёжности нас здесь не интересуют — нас интересует, как бы мы сделали, так сказать, "админку" или, по-правильному, какое API бы использовали для этого.

Имея представление о привычной файловой системе в линукс с её ACL расширением - логично использовать что-то типа, только с поправкой на будущее объектное хранилище.
Если кто не в курсе, что в линуксе кроме привычной схемы user:group можно использовать и ACL - погуглите по getfacl и setfacl.

---

Итак, у нас будут клиенты, они будут к нам логиниться в свои аккаунты и авторизоваться через апи - это будут типа юзеры из линукса.

У нас будут бакеты, которые создают юзеры и в которые они могут писать свои файлы - это будут типа папки из линукса.

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

Аналогично для объектов, потому как и бакету, добавим каждому объекту свой ACL.

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

===

Вроде всё. Просто, без замудренностей и должно работать - ведь работает в линуксе, верно?

Только что, в нескольких абзацах, мы заново изобрели #S3. Оно, действительно, работает. И, что важно, оно, дейстительно, работает так. Или точней и ещё более важней - так работало.

#s3_history #history

489 views14:54

👍интересно 16

👉нужны_подробности👈 6