Мда, судя по всему, с такими успехами, придётся делать посты к заметкам. :)
DR - общеупотребительное сокращение для Disaster Recovery, что в контексте AWS обозначает возможность развернуть проект в другом его регионе. Например, работает в Oregon-e
RPO (Recovery Point Objective) - время от последнего бэкапа до катастрофы.
RTO (Recovery Time Objective) - время от катастрофы до восстановления работоспособности.
Если тема DR интересна (она важная с переходом в принциальная, но предполагает высокий уровень понимания) и вы почему-то про неё ещё не читали и смотрели (например, вот хорошее видео с позапрошлого реинвента 2017 про говорящую Алексу, плохо, но таки запускающую CloudFormation стэки DR восстановления) - жмите подробности, про неё я могу писать долго, много и ещё раз долго.
#DR
DR - общеупотребительное сокращение для Disaster Recovery, что в контексте AWS обозначает возможность развернуть проект в другом его регионе. Например, работает в Oregon-e
us-west-2, а DR plan (тоже устойчивый термин - план восстановления работоспособности) предусматривает подъём в Калифорнии us-west-1, Виржинии us-east-1 или даже на другом континенте (обычно Ирландия eu-west-1), если приложение такое подразумевает.RPO (Recovery Point Objective) - время от последнего бэкапа до катастрофы.
RTO (Recovery Time Objective) - время от катастрофы до восстановления работоспособности.
Если тема DR интересна (она важная с переходом в принциальная, но предполагает высокий уровень понимания) и вы почему-то про неё ещё не читали и смотрели (например, вот хорошее видео с позапрошлого реинвента 2017 про говорящую Алексу, плохо, но таки запускающую CloudFormation стэки DR восстановления) - жмите подробности, про неё я могу писать долго, много и ещё раз долго.
#DR
Последовательность блоков в #CloudFormation #templates можно менять (сначала ресурсы или даже вывод, остальное ниже):
Outputs: ecrRepository: Value: !Ref ecrRepositoryResources: ecrRepository: Type: AWS::ECR::Repository Properties: RepositoryName: !Ref RepositoryNameParameters: RepositoryName: Type: String Description: Name of ECR repository Default: some-repoDescription: ECR repositoryS3 и кодировка файлов
При сохранении в S3 не происходит никакая "перекодировка" файла и возможность задать
Пример. Имеем файл
file -i 1.csv
Сохраняем его на S3 и указываем "нужную" кодировку, наприме,
aws s3api put-object --content-type="application/csv;charset=UTF-16" --bucket my-bucket --key u16.csv --body 1.csv
Файл сохранится и в метаданных будет указанное значение (см. картинку).
Однако S3 не имеет отношения к тому, что в реальности внутри, это лишь метадата и потому, когда мы скачаем файл:
aws s3api get-object --bucket my-bucket --key u16.csv u16.csv
Кодировка останется той же:
file -i u16.csv
Чтобы реально поменять кодировку, нужно изменить содержимое файла, который указывается в
# iconv --from-code=us-ascii --to-code=
# file -i 16.csv
И теперь всё будет корректно.
Отдельно стоит добавить, что "конвертировать"
#s3
При сохранении в S3 не происходит никакая "перекодировка" файла и возможность задать
Content Type в этом не поможет.Пример. Имеем файл
1.csv:file -i 1.csv
1.csv: text/plain; charset=us-asciiСохраняем его на S3 и указываем "нужную" кодировку, наприме,
UTF-16:aws s3api put-object --content-type="application/csv;charset=UTF-16" --bucket my-bucket --key u16.csv --body 1.csv
Файл сохранится и в метаданных будет указанное значение (см. картинку).
Однако S3 не имеет отношения к тому, что в реальности внутри, это лишь метадата и потому, когда мы скачаем файл:
aws s3api get-object --bucket my-bucket --key u16.csv u16.csv
Кодировка останется той же:
file -i u16.csv
u16.csv: text/plain; charset=us-asciiЧтобы реально поменять кодировку, нужно изменить содержимое файла, который указывается в
--body. В Linux для этого есть команда iconv:# iconv --from-code=us-ascii --to-code=
utf-16 1.csv --output=16.csv# file -i 16.csv
16.csv: text/plain; charset=utf-16leИ теперь всё будет корректно.
Отдельно стоит добавить, что "конвертировать"
US-ASCII в UTF-8 не получится (незачем) и в результате будет всегда показываться кодировка как us-ascii, т.к. она "включена" (является подвидом, совпадает по битам) кодировки UTF-8. #s3
Тэгирование есть документирование вашей системы.
Дайте шанс самому себе же через год и добавьте временно поднимаемой виртуалке тэг
Дайте шанс самому себе же через год и добавьте временно поднимаемой виртуалке тэг
description со значением can be deleted at any time, чтобы после не расспрашивать всех, что за враг что-то создал и не убрал за собой, а просто тихонечко удалить.Forwarded from Человек и машина
Дорогие читатели, запись моего доклада для Highload++ 2019 - https://youtu.be/BEZKub1BYCE
YouTube
Нормально делай - нормально будет / Карен Товмасян (Newmotion)
Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: https://vk.cc/cuyIqx
--------
--------
При поддержке AvitoTech мы впервые публикуем все видео с HighLoad++ 2019…
Программа, подробности и билеты по ссылке: https://vk.cc/cuyIqx
--------
--------
При поддержке AvitoTech мы впервые публикуем все видео с HighLoad++ 2019…
Таймкоды к видео Нормально делай - нормально будет:
0:17 - Кому хорошо спится по ночам
2:36 - Зачем нанимают амазонщиков
3:07 - Least Privilege Principle (LPP)
4:40 - Метод обезьянки для борьбы с LPP
5:54 - В любой непонятной ситуации берите M-тип виртуалок
6:34 - Горизонтальное масштабирование против вертикального
8:08 - Только Spot, только хардкор!
9:13 - Проблема next-next-next-finish.
9:50 - Идентификатор зоны доступности и его отличие от имени зоны доступности
11:50 - Не используйте AWS Console вообще! (штоа?!?)
12:25 - Infrastructure As Code и экстремалы из Ansible
14:53 - cfn-lint (линтер, который не валидатор)
16:54 - AWS Trusted Advisor - сервис-советчик
17:54 - AWS Config - история изменения ресурсов с проверкой Compliance
18:51 - RDK (Rule Development Kit) для AWS Config Custom Rules
21:15 - Well-Architected Framework
22:08 - Well-Architected Tool
24:20 - Multi-Account Strategy
28:50 - Расчёт оценки решения
30:51 - Эксплуатационные издержки
32:42 - Делайте нормально и спите хорошо!
Вопросы:
33:36 - Как вы относитесь к Фаргейту (спойлер - очень положительно)
34:37 - Когда будут реализованы
35:07 - Когда Карен напишет книжку «Стандарты разработки Serverless приложений» (спойлер - в раздумьях)
36:30 - В каких случаях стоит использовать Serverless (спойлер - отталкивайтесь от проблемы)
38:05 - Serverless - это не лямбда, а подход (ответ из зала)
39:17 - Преобразование одного аккаунта с продом в мультиаккаунт схему (без спойлера)
40:32 - Terrafom
44:23 - Подводные камни у Route53 (спойлер - не поддерживает DNSSEC)
п.с. Удалось дважды попасть в кадр на 10:12 и 24:25.
0:17 - Кому хорошо спится по ночам
2:36 - Зачем нанимают амазонщиков
3:07 - Least Privilege Principle (LPP)
4:40 - Метод обезьянки для борьбы с LPP
5:54 - В любой непонятной ситуации берите M-тип виртуалок
6:34 - Горизонтальное масштабирование против вертикального
8:08 - Только Spot, только хардкор!
9:13 - Проблема next-next-next-finish.
9:50 - Идентификатор зоны доступности и его отличие от имени зоны доступности
11:50 - Не используйте AWS Console вообще! (штоа?!?)
12:25 - Infrastructure As Code и экстремалы из Ansible
14:53 - cfn-lint (линтер, который не валидатор)
16:54 - AWS Trusted Advisor - сервис-советчик
17:54 - AWS Config - история изменения ресурсов с проверкой Compliance
18:51 - RDK (Rule Development Kit) для AWS Config Custom Rules
21:15 - Well-Architected Framework
22:08 - Well-Architected Tool
24:20 - Multi-Account Strategy
28:50 - Расчёт оценки решения
30:51 - Эксплуатационные издержки
32:42 - Делайте нормально и спите хорошо!
Вопросы:
33:36 - Как вы относитесь к Фаргейту (спойлер - очень положительно)
34:37 - Когда будут реализованы
persistent volumes для Фаргейта (спойлер - следующий вопрос)35:07 - Когда Карен напишет книжку «Стандарты разработки Serverless приложений» (спойлер - в раздумьях)
36:30 - В каких случаях стоит использовать Serverless (спойлер - отталкивайтесь от проблемы)
38:05 - Serverless - это не лямбда, а подход (ответ из зала)
39:17 - Преобразование одного аккаунта с продом в мультиаккаунт схему (без спойлера)
40:32 - Terrafom
vs CloudFormation (спойлер - CloudFormation более надёжный)44:23 - Подводные камни у Route53 (спойлер - не поддерживает DNSSEC)
п.с. Удалось дважды попасть в кадр на 10:12 и 24:25.
YouTube
Нормально делай - нормально будет / Карен Товмасян (Newmotion)
Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: https://vk.cc/cuyIqx
--------
--------
При поддержке AvitoTech мы впервые публикуем все видео с HighLoad++ 2019…
Программа, подробности и билеты по ссылке: https://vk.cc/cuyIqx
--------
--------
При поддержке AvitoTech мы впервые публикуем все видео с HighLoad++ 2019…
В̵с̵помнить всё
Поучительное совпадение - буквально пару дней назад записал себе в заметки (на картинке - простые гуглошиты, просто копирую себе полезное из обсуждений, каждый месяц меняю название, т.к. много слишком много страниц набегает :) ) из AWS-чатов в слэке, где общаются настоящие гуру, что кто-то отвечая на вопрос не знал какой-то вещи. При этом сомневаться в профессионализме не приходилось и т.к. до этого не раз такое замечал, решил законспектировал конкретный факт, чтобы после написать о такой проблеме.
И вот сегодня примерно-показательно выяснилось, что и сам такой же. Кому лень читать лог чата, то коротко - посоветовал вариант решения, предполагая, что Access Control по тэгам объектов в S3 невозможен, а потому нужно использовать другой подход, в то время, как это давно реализовано.
То есть вот писал про тэги тут сто раз, понимая и рассказывая их важность, а не знал вещей 2013-го года розлива.
Задумался, как же так. После потужился и вспомнил, таки читал в документации, но не встречая реальных примеров использования-обсуждения таких проблем и это ушло на задний план. А после, видимо, было окончательно отторгнуто логикой "это ж ведь расходы какие на каждый запрос к объекту - вряд ли значит так может быть".
Выводы я для себя ещё сделаю, но один из них - граждане, спрашивайте и вам ответят. Сила коллективного разума, однако.
Другой: делайте внешний аудит ваших решений, какие бы профи у вас не работали (в том числе вы лично или я).
Ну и третий - проходите сертификацию, сдавайте на сертификаты. Писал, что не получал сертификатов за ненадобностью, как считал. И на выходе, вот, прорехи в обороне. Надеюсь, что сдача на сертификат позволит структурировать знания и закрыть такие бреши.
#учиться #учиться #учиться
Поучительное совпадение - буквально пару дней назад записал себе в заметки (на картинке - простые гуглошиты, просто копирую себе полезное из обсуждений, каждый месяц меняю название, т.к. много слишком много страниц набегает :) ) из AWS-чатов в слэке, где общаются настоящие гуру, что кто-то отвечая на вопрос не знал какой-то вещи. При этом сомневаться в профессионализме не приходилось и т.к. до этого не раз такое замечал, решил законспектировал конкретный факт, чтобы после написать о такой проблеме.
И вот сегодня примерно-показательно выяснилось, что и сам такой же. Кому лень читать лог чата, то коротко - посоветовал вариант решения, предполагая, что Access Control по тэгам объектов в S3 невозможен, а потому нужно использовать другой подход, в то время, как это давно реализовано.
То есть вот писал про тэги тут сто раз, понимая и рассказывая их важность, а не знал вещей 2013-го года розлива.
Задумался, как же так. После потужился и вспомнил, таки читал в документации, но не встречая реальных примеров использования-обсуждения таких проблем и это ушло на задний план. А после, видимо, было окончательно отторгнуто логикой "это ж ведь расходы какие на каждый запрос к объекту - вряд ли значит так может быть".
Выводы я для себя ещё сделаю, но один из них - граждане, спрашивайте и вам ответят. Сила коллективного разума, однако.
Другой: делайте внешний аудит ваших решений, какие бы профи у вас не работали (в том числе вы лично или я).
Ну и третий - проходите сертификацию, сдавайте на сертификаты. Писал, что не получал сертификатов за ненадобностью, как считал. И на выходе, вот, прорехи в обороне. Надеюсь, что сдача на сертификат позволит структурировать знания и закрыть такие бреши.
#учиться #учиться #учиться
Инструменты для получения минимальных прав (Least Privilege Principle), что требуются приложению с помощью CloudTrail:
https://medium.com/netflix-techblog/introducing-aardvark-and-repokid-53b081bf3a7e
https://github.com/duo-labs/cloudtracker
Это в дополнение к видео выше.
https://medium.com/netflix-techblog/introducing-aardvark-and-repokid-53b081bf3a7e
https://github.com/duo-labs/cloudtracker
Это в дополнение к видео выше.
Medium
Introducing Aardvark and Repokid
AWS Least Privilege for Distributed, High-Velocity Development
Где задать вопрос по AWS
Официальный форум:
https://forums.aws.amazon.com/
Официальный, англоязычный, требуется аккаунт в AWS.
Reddit:
https://www.reddit.com/r/aws/
Большой и популярный англоязычный форум, короче - Reddit.
Slack
#ecs и другие) - требуется инвайт.
Инвайт можно получить на https://og-aws-slack.lexikon.io/ , большое количество каналов по Амазону, известные AWS-гуру обитают тут, потому вопросы предполагают какой-то достаточный уровень. Задавать вопросы сразу в нескольких каналах не принято. Если не знаете точно темы - задавайте в #questions. Англоязычный.
Slack
Инвайт можно получить на https://signup.hangops.com/ , живенький AWS-чат, вопросы предполагают некоторый уровень, англоязычный.
Телеграм:
AWS_ru
AWS Minsk Community
AWS@NSK
AWS User group Kazakhstan
Чат AWS_ru - самый большой и самый популярный русскоязычный чат по AWS.
Его преимущества - очень много народу, можно получить с большой вероятностью качественный комментарий, т.к. его читают и в нём отвечают представители AWS. Задать вопрос можно любого уровня и при этом не побьют.
Его минусы - когда много народу спрашивает, лента бежит быстро и на ваш вопрос могут так и не ответить, даже если кто-то мог и хотел.
Поэтому, если вы из Минска-Новосибирска-Казахстана-поблизости - старайтесь задавать вопрос в своих сообществах. Везде есть профи, только местные точно увидят ваш вопрос и с удовольствие ответят. Кроме того представители AWS мониторят и эти каналы, потому также смогут прокомментировать.
Facebook:
https://www.facebook.com/groups/aws.notes/
Юзер-группа канала aws_notes, требуется аккаунт в Facebook. Народу нет совсем, но если кто спросит - я точно отвечу. :) Копирую туда новости из этого канала для тех, кому удобней читать и комментировать в Фейсбуке.
#info
Официальный форум:
https://forums.aws.amazon.com/
Официальный, англоязычный, требуется аккаунт в AWS.
Reddit:
https://www.reddit.com/r/aws/
Большой и популярный англоязычный форум, короче - Reddit.
Slack
og-aws (каналы #questions #cloudformation#ecs и другие) - требуется инвайт.
Инвайт можно получить на https://og-aws-slack.lexikon.io/ , большое количество каналов по Амазону, известные AWS-гуру обитают тут, потому вопросы предполагают какой-то достаточный уровень. Задавать вопросы сразу в нескольких каналах не принято. Если не знаете точно темы - задавайте в #questions. Англоязычный.
Slack
hangops (канал #aws) - требуется инвайт.Инвайт можно получить на https://signup.hangops.com/ , живенький AWS-чат, вопросы предполагают некоторый уровень, англоязычный.
Телеграм:
AWS_ru
AWS Minsk Community
AWS@NSK
AWS User group Kazakhstan
Чат AWS_ru - самый большой и самый популярный русскоязычный чат по AWS.
Его преимущества - очень много народу, можно получить с большой вероятностью качественный комментарий, т.к. его читают и в нём отвечают представители AWS. Задать вопрос можно любого уровня и при этом не побьют.
Его минусы - когда много народу спрашивает, лента бежит быстро и на ваш вопрос могут так и не ответить, даже если кто-то мог и хотел.
Поэтому, если вы из Минска-Новосибирска-Казахстана-поблизости - старайтесь задавать вопрос в своих сообществах. Везде есть профи, только местные точно увидят ваш вопрос и с удовольствие ответят. Кроме того представители AWS мониторят и эти каналы, потому также смогут прокомментировать.
Facebook:
https://www.facebook.com/groups/aws.notes/
Юзер-группа канала aws_notes, требуется аккаунт в Facebook. Народу нет совсем, но если кто спросит - я точно отвечу. :) Копирую туда новости из этого канала для тех, кому удобней читать и комментировать в Фейсбуке.
#info
Из правил техподдержки AWS.
Неправильно говорить «Нет, к сожалению, у нас нет такого сервиса», правильно «Вы можете сделать это сами на Лямбде!»
#правильное
Неправильно говорить «Нет, к сожалению, у нас нет такого сервиса», правильно «Вы можете сделать это сами на Лямбде!»
#правильное
Из правил отдела маркетинга AWS.
Неправильно говорить «Мы придумали новую фичу», правильно «Почти все фичи сделаны по просьбам наших клиентов».
Если фича понравилась — мы заботимся о вас.
Если нет — мы тут ни при чём, это ж клиенты.
#правильное
Неправильно говорить «Мы придумали новую фичу», правильно «Почти все фичи сделаны по просьбам наших клиентов».
Если фича понравилась — мы заботимся о вас.
Если нет — мы тут ни при чём, это ж клиенты.
#правильное
Из правил работы пресс-службы AWS.
Если за день не было новостей, то обратитесь в отдел по развёртыванию текущих сервисов в любом регионе или просто печатайте результаты очередного спринта команды CloudFormation.
#правильное
Если за день не было новостей, то обратитесь в отдел по развёртыванию текущих сервисов в любом регионе или просто печатайте результаты очередного спринта команды CloudFormation.
#правильное
Из правил технического отдела EC2.
Название для нового типа инстансов формируется по первому потопленному однопалубному кораблю.
#правильное
Название для нового типа инстансов формируется по первому потопленному однопалубному кораблю.
#правильное
CloudFormation - главные фичи 2019
• Появился Roadmap
• Импорт существующих ресурсов в стэки
• Реестр для сторонних ресурсов + cfn (CloudFormation Command Line Interface)
#итоги
• Появился Roadmap
• Импорт существующих ресурсов в стэки
• Реестр для сторонних ресурсов + cfn (CloudFormation Command Line Interface)
#итоги
S3 - главные фичи 2019
• S3 Batch Operations
• S3 Path Deprecation Plan до 2020.09.30
• SigV2 Deprecation Period до 2020.06.24
• Same-Region Replication
• S3 Replication Time Control (SLA для Cross-Region Replication)
• S3 Access Points
#итоги
• S3 Batch Operations
• S3 Path Deprecation Plan до 2020.09.30
• SigV2 Deprecation Period до 2020.06.24
• Same-Region Replication
• S3 Replication Time Control (SLA для Cross-Region Replication)
• S3 Access Points
#итоги
Новые фичи коротко:
• Асимметричное шифрование (публичный+приватный ключ) в AWS KMS
• Least Outstanding Requests (LOR) для ALB
• CloudWatch метрики для VPC Traffic Mirroring
• Политики тэгирования в AWS Organizations
• NLB поддерживает подсети из Shared VPC
• Amazon QuickSight API
• Managed Rules для AWS WAF
• External Identity Provider для AWS SSO
• Поддержка своих ключей (KMS Customer-Provided Keys) в Kinesis и DynamoDB
• Поддержка LDAPS в AWS Managed Microsoft AD
• Пользовательские функции в Amazon Athena
• Параллельная Лямбда под Kinesis
• Spot инстансы в Elastic Beanstalk
• Materialized Views в Amazon Redshift
@aws_update
• Асимметричное шифрование (публичный+приватный ключ) в AWS KMS
• Least Outstanding Requests (LOR) для ALB
• CloudWatch метрики для VPC Traffic Mirroring
• Политики тэгирования в AWS Organizations
• NLB поддерживает подсети из Shared VPC
• Amazon QuickSight API
• Managed Rules для AWS WAF
• External Identity Provider для AWS SSO
• Поддержка своих ключей (KMS Customer-Provided Keys) в Kinesis и DynamoDB
• Поддержка LDAPS в AWS Managed Microsoft AD
• Пользовательские функции в Amazon Athena
• Параллельная Лямбда под Kinesis
• Spot инстансы в Elastic Beanstalk
• Materialized Views в Amazon Redshift
@aws_update
Новое на AWS:
EC2 Image Builder - сервис для создания и сопровождения системных образов для Windows Server и Amazon Linux 2
AWS DeepComposer - сервис для сочинения музыки.
DeepRacer Evo - новая машинка с двумя камерами и LIDAR-ом.
Amazon Transcribe Medical - сервис перевода в текст речи врачей.
Amazon EventBridge Schema Registry
AWS End-of-Support Migration Program (EMP) for Windows Server - позволяет запускать не имеющие уже поддержки Windows приложения, рассчитанные на Windows Server 2003/2008/2008R2 и новей без их изменения.
#reInvent
EC2 Image Builder - сервис для создания и сопровождения системных образов для Windows Server и Amazon Linux 2
AWS DeepComposer - сервис для сочинения музыки.
DeepRacer Evo - новая машинка с двумя камерами и LIDAR-ом.
Amazon Transcribe Medical - сервис перевода в текст речи врачей.
Amazon EventBridge Schema Registry
Preview - с поддержкой в JetBrains IntelliJ, PyCharm и Microsoft Visual Studio Code.AWS End-of-Support Migration Program (EMP) for Windows Server - позволяет запускать не имеющие уже поддержки Windows приложения, рассчитанные на Windows Server 2003/2008/2008R2 и новей без их изменения.
#reInvent