Size: a a a

2020 September 02

VS

Vladimir Sennikov in AWS_RU
NB
Вопрос, с экзамена DevOps Pro. В ответах написано ответ C, я выбрал B. На кой ляд здесь SNS? И что не правильного в B?
в первом случае взаимодействие
S3 <-> App <-> DynamoDB
во втором
S3 <-> SNS <-> DynamoDB

мне кажется это просто AWS-way (использовать больше сервисов AWS)
ну еще там было в вопросе про cost-effective, тут уже не знаю
источник

AG

Alexey Gravanov in AWS_RU
NB
Вопрос, с экзамена DevOps Pro. В ответах написано ответ C, я выбрал B. На кой ляд здесь SNS? И что не правильного в B?
B тоже технически рабочий вариант. нужно, чтобы клиент писал данные и в S3 и в динаму и потом апдейтить кеш, что не всегда возможно. например signed url для аплоада файлов и подобные случаи. Если клиент не будет писать в динаму, то нужно будет делать full table scan (ну или как-то фильтровать объекты) и апдейтить динаму -> большое кол-во GET запросов, которые мы и стараемся избежать.

если настроить нотификации, то динама будет сама посылать нотификации при загрузке объектов. читаем эту нотификацию, пишем инфу в динаму - GET запросов нет вообще. и заодно из нотификаций апдейтим кеш аппликухи.
источник

N

NB in AWS_RU
Vladimir Sennikov
в первом случае взаимодействие
S3 <-> App <-> DynamoDB
во втором
S3 <-> SNS <-> DynamoDB

мне кажется это просто AWS-way (использовать больше сервисов AWS)
ну еще там было в вопросе про cost-effective, тут уже не знаю
Разве нельзя как в б написано, просто триггать на put -> lambda и обновлять dynamodb
источник

AG

Alexey Gravanov in AWS_RU
основная проблема в SA pro / DevOps pro экзаменах - не найти рабочее решение, в каждом вопросе будет несколько вариантов, которые будут рабочими с технической точки зрения. проблема найти наиболее эффективное с точки зрения сложности, времени, поддержки или цены решение.
источник

N

NB in AWS_RU
Alexey Gravanov
B тоже технически рабочий вариант. нужно, чтобы клиент писал данные и в S3 и в динаму и потом апдейтить кеш, что не всегда возможно. например signed url для аплоада файлов и подобные случаи. Если клиент не будет писать в динаму, то нужно будет делать full table scan (ну или как-то фильтровать объекты) и апдейтить динаму -> большое кол-во GET запросов, которые мы и стараемся избежать.

если настроить нотификации, то динама будет сама посылать нотификации при загрузке объектов. читаем эту нотификацию, пишем инфу в динаму - GET запросов нет вообще. и заодно из нотификаций апдейтим кеш аппликухи.
Не понимаю зачем кленту писать в динаму. Делаем динаму с ключем файл или файлхэш. При записи в с3 тригаем лямбду - обновляем по ключу метадату.
источник

AG

Alexey Gravanov in AWS_RU
NB
Не понимаю зачем кленту писать в динаму. Делаем динаму с ключем файл или файлхэш. При записи в с3 тригаем лямбду - обновляем по ключу метадату.
в ответе нет ничего про лямбду, поэтому, мне кажется, не надо додумывать "а что бы там еще могло быть сбоку прикручено".
источник

N

NB in AWS_RU
Alexey Gravanov
в ответе нет ничего про лямбду, поэтому, мне кажется, не надо додумывать "а что бы там еще могло быть сбоку прикручено".
а разве SNS может сам писать в динаму? Там тоже придется сбоку докручивать и лямбду и полиси, разве нет?
источник

AG

Alexey Gravanov in AWS_RU
NB
а разве SNS может сам писать в динаму? Там тоже придется сбоку докручивать и лямбду и полиси, разве нет?
ну там по крайней мере написано "... that automatically updates ...."

черт знает, я бы сам выбрал Ц, хотя я согласен, формулировки там так себе.
источник

BG

Boris Gorbuntsov in AWS_RU
Vladimir Sennikov
в первом случае взаимодействие
S3 <-> App <-> DynamoDB
во втором
S3 <-> SNS <-> DynamoDB

мне кажется это просто AWS-way (использовать больше сервисов AWS)
ну еще там было в вопросе про cost-effective, тут уже не знаю
Слышал такую тему.
Это для МС экзаменов тоже было релевантно когда-то.
А по философии AWS, кмк, тиражное решение костэффективнее авторского. Его надо поддерживать, хостить и всё прочее, что дороже в целом.
Наверное так
источник

N

NB in AWS_RU
Boris Gorbuntsov
Слышал такую тему.
Это для МС экзаменов тоже было релевантно когда-то.
А по философии AWS, кмк, тиражное решение костэффективнее авторского. Его надо поддерживать, хостить и всё прочее, что дороже в целом.
Наверное так
ИМХО они оба авторские, SNS не сможет писать в динаму без трансфорамции под структуру таблицы.
источник

AT

Al T in AWS_RU
просто в варианте B не описан механизм получения информации о том что файл загружен на S3, а в С описан и рекомендован к использованию AWS, если почитать всякие white papers/well architected то там будет навярняка упомянута связка S3+SNS
источник

R

Roman 🇲🇪 in AWS_RU
Парни подскажите, появился ли какой то легкий способ узнавать имена EBS дисков при запуске EC2 инстанса на Ubuntu? У меня прекрасно работал мой однострочный костыль с lsblk, пока не пришлось добавлять несколько дисков.
источник

VM

Viktor Mikalayeu in AWS_RU
Roman 🇲🇪
Парни подскажите, появился ли какой то легкий способ узнавать имена EBS дисков при запуске EC2 инстанса на Ubuntu? У меня прекрасно работал мой однострочный костыль с lsblk, пока не пришлось добавлять несколько дисков.
можно при запуске ec2 указавать на какое имя маунтить , а уже потом использовать это имя




resource "aws_ebs_volume" "server_data" {
 provider = aws.work
 availability_zone = data.aws_subnet.default.availability_zone
 size = var.data_storage_size
 type = var.data_storage_type
 tags = {
   Name = "sisense-single-data-${var.aws}-${var.prefix}"
        }
}





resource "aws_volume_attachment" "data" {
 provider = aws.work
 device_name = var.data_volume_name
 instance_id = aws_instance.server.id
 volume_id = aws_ebs_volume.server_data.id
}
источник

JM

Jeison Mortyre in AWS_RU
скажите, а можно как то в ECR настроить политику удаления, что б он не трогал билды, помеченные доп тегом. т.е. у меня билды в зависимости от енва имеют тег dev, dev2, dev3  и тд, вот я хочу чтоб он удалял все, кроме этих
источник

VM

Viktor Mikalayeu in AWS_RU
#ECR-репозиторий имеет ограничение в 1000 образов максимум. Когда у вас активный процесс разработки, то этот кажущийся большим лимит очень даже быстро достигается и вы получаете много удовольствия от упражнений по изучению логов под названием "ну вчера же работало".

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

Светлая мысль "с этим что-то нужно делать" помноженная на гугление в попытках что-то найти и отсортировать в AWS консоли по работе с ECR докер-образами — очень скоро приведёт вас в уныние. Не расстраивайтесь, это не вы верблюд - там действительно не работает пэйджер (фильтры применяются лишь к одной странице). Пусть вас успокаивает факт, что они страдают точно также.

В общем смысл следующий - нужно настроить ECR LifecyclePolicy. Пишем правила, какие тэги сколько живут и добавляем каждому репозиторию, в результате порядок будет поддерживаться автоматически.

Если репозиторий один, то можно и потыкать ручками, однако если десятки? Тогда используем для этого секретную менюшку Edit JSON (на картинке внизу), откуда можно скопировать натыканное и размножить для других репозиториев.

Тяжело разбираться без примеров, потому вот реально используемый вариант #LifecyclePolicy:

{
"rules": [
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "develop"
      ]
    },
    "description": "clean 'develop*' after 180 days",
    "rulePriority": 10
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "feature"
      ]
    },
    "description": "clean 'feature*' after 180 days",
    "rulePriority": 20
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "hotfix"
      ]
    },
    "description": "clean 'hotfix*' after 180 days",
    "rulePriority": 30
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 1,
      "tagStatus": "untagged"
    },
    "description": "clean Untagged after 1 day",
    "rulePriority": 40
  }
]
}
источник

РР

Роман Рахманин... in AWS_RU
Viktor Mikalayeu
#ECR-репозиторий имеет ограничение в 1000 образов максимум. Когда у вас активный процесс разработки, то этот кажущийся большим лимит очень даже быстро достигается и вы получаете много удовольствия от упражнений по изучению логов под названием "ну вчера же работало".

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

Светлая мысль "с этим что-то нужно делать" помноженная на гугление в попытках что-то найти и отсортировать в AWS консоли по работе с ECR докер-образами — очень скоро приведёт вас в уныние. Не расстраивайтесь, это не вы верблюд - там действительно не работает пэйджер (фильтры применяются лишь к одной странице). Пусть вас успокаивает факт, что они страдают точно также.

В общем смысл следующий - нужно настроить ECR LifecyclePolicy. Пишем правила, какие тэги сколько живут и добавляем каждому репозиторию, в результате порядок будет поддерживаться автоматически.

Если репозиторий один, то можно и потыкать ручками, однако если десятки? Тогда используем для этого секретную менюшку Edit JSON (на картинке внизу), откуда можно скопировать натыканное и размножить для других репозиториев.

Тяжело разбираться без примеров, потому вот реально используемый вариант #LifecyclePolicy:

{
"rules": [
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "develop"
      ]
    },
    "description": "clean 'develop*' after 180 days",
    "rulePriority": 10
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "feature"
      ]
    },
    "description": "clean 'feature*' after 180 days",
    "rulePriority": 20
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "hotfix"
      ]
    },
    "description": "clean 'hotfix*' after 180 days",
    "rulePriority": 30
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 1,
      "tagStatus": "untagged"
    },
    "description": "clean Untagged after 1 day",
    "rulePriority": 40
  }
]
}
Что в данном случае образ? Так то на образ там 10тыс ограничение, прямо в статье по ссылке
источник

VM

Viktor Mikalayeu in AWS_RU
Роман Рахманин
Что в данном случае образ? Так то на образ там 10тыс ограничение, прямо в статье по ссылке
Статья не новая, смотри документацию
источник

JM

Jeison Mortyre in AWS_RU
Viktor Mikalayeu
#ECR-репозиторий имеет ограничение в 1000 образов максимум. Когда у вас активный процесс разработки, то этот кажущийся большим лимит очень даже быстро достигается и вы получаете много удовольствия от упражнений по изучению логов под названием "ну вчера же работало".

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

Светлая мысль "с этим что-то нужно делать" помноженная на гугление в попытках что-то найти и отсортировать в AWS консоли по работе с ECR докер-образами — очень скоро приведёт вас в уныние. Не расстраивайтесь, это не вы верблюд - там действительно не работает пэйджер (фильтры применяются лишь к одной странице). Пусть вас успокаивает факт, что они страдают точно также.

В общем смысл следующий - нужно настроить ECR LifecyclePolicy. Пишем правила, какие тэги сколько живут и добавляем каждому репозиторию, в результате порядок будет поддерживаться автоматически.

Если репозиторий один, то можно и потыкать ручками, однако если десятки? Тогда используем для этого секретную менюшку Edit JSON (на картинке внизу), откуда можно скопировать натыканное и размножить для других репозиториев.

Тяжело разбираться без примеров, потому вот реально используемый вариант #LifecyclePolicy:

{
"rules": [
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "develop"
      ]
    },
    "description": "clean 'develop*' after 180 days",
    "rulePriority": 10
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "feature"
      ]
    },
    "description": "clean 'feature*' after 180 days",
    "rulePriority": 20
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 180,
      "tagStatus": "tagged",
      "tagPrefixList": [
        "hotfix"
      ]
    },
    "description": "clean 'hotfix*' after 180 days",
    "rulePriority": 30
  },
  {
    "action": {
      "type": "expire"
    },
    "selection": {
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 1,
      "tagStatus": "untagged"
    },
    "description": "clean Untagged after 1 day",
    "rulePriority": 40
  }
]
}
да, я видел эту статью. но она не отвечает на вопрос как не удалить билды, которые имеют тег dev. т.е. все билды имеют тег version-1.0.100 version-1.0.101 version-1.0.102 и тд. а последнии собранные билды имеют еще доп тег dev, dev2, dev3 и вот мне надо что б те, что имеют доп тег не удалилсь ни при каких обстоятельствах
источник

AS

Alexey Stekov in AWS_RU
Amazon опубликовал Bottlerocket 1.0.0, Linux-дистрибутив на базе изолированных контейнеров
https://www.opennet.ru/opennews/art.shtml?num=53648
источник

AS

Alexey Stekov in AWS_RU
источник