AZ
а зачем для логов что-то костылять вместо захостить что-то своё или скормить какому-нибудь решению?
Size: a a a
2020 September 08
AZ
половина дата саентисов так делает))
осталось только понять, какое отношение имеют дата сатанисты к софтваре инженерам
DS
Al T
CSV + S3 не делает никто т.к. медленно и дорого
Но спасибо за замечание
AT
на кофейной гуще гадать, кто когда запускал?
не нужно гадать, кто у вас кнопку в дженкинсе нажал, того ключ и использовать. если нужно знать кто и когда что-то сделал, то если не использовать отдельных пользователей или ролей, то никогда и не получится узнать кто и когда что сделал...
AT
Но спасибо за замечание
загрузить файл полностью это ок, искать по нему - неоптимально потому что есть колоночные бинарные форматы для этого
AS
+
AP
Парни, привет, такой вопрос: как думаете, что лучш будет для хранения такой, долгосрочной инфы? типо логи, но будут представлены как колонки для бд. я вот думаю про rds, но пока не уверена. мб у кого еще какие предложения будут?
Логи в parquet и в s3. Дальше или родной s3 select или Athena
AP
Именно так сам AWS складывает логи с балансиров, cloudfront, Vpc flow logs и тд
A
мне кажется просто меня не поняли)
Ладно, попробую с другой стороны: вот смотри, есть условно скажем дженкинс, и есть условно скажем сервисный пользователь в авс, а есть разрабы, которые дергают сборки. и суть в том, что конфиг и трейл не смогут помочь, по причине того, что они в душе не гребут, кто там эту сборку дёргал)
Ладно, попробую с другой стороны: вот смотри, есть условно скажем дженкинс, и есть условно скажем сервисный пользователь в авс, а есть разрабы, которые дергают сборки. и суть в том, что конфиг и трейл не смогут помочь, по причине того, что они в душе не гребут, кто там эту сборку дёргал)
мне кажется для такого DynamoDb хорошо зайдет, особенно если вы не супер часто деплоите
AV
Al T
aws config это сделает за вас
Это каким образом тут Config что-то сделает? Config это Compliance, а не логи.
AT
Это каким образом тут Config что-то сделает? Config это Compliance, а не логи.
config покажет вам кто когда зачем с возможностью таймлайна по ресурсам. Он да, будет использовать для этого данные от cloudtrail, комплайенс в данном случае приятный бонус
2020 September 09
AV
Al T
config покажет вам кто когда зачем с возможностью таймлайна по ресурсам. Он да, будет использовать для этого данные от cloudtrail, комплайенс в данном случае приятный бонус
А, я понял. Если рассматривать с точки зрения API вызовов именных. Ручной деплой, по сути.
Если же CI/CD с вебхуками на коммит, то такой вариант не прокатит.
Если же CI/CD с вебхуками на коммит, то такой вариант не прокатит.
AT
А, я понял. Если рассматривать с точки зрения API вызовов именных. Ручной деплой, по сути.
Если же CI/CD с вебхуками на коммит, то такой вариант не прокатит.
Если же CI/CD с вебхуками на коммит, то такой вариант не прокатит.
нужно смотреть, но в клаудтрейл можно прокинуть commitID например который пушился. а по коммиту уже понятно кто пушил
AV
Al T
нужно смотреть, но в клаудтрейл можно прокинуть commitID например который пушился. а по коммиту уже понятно кто пушил
Эмм... Как это сделать в terraform/ansible?
AV
А почему не прокинуть автора сразу тогда?
AT
я предположил что CI/CD мы говорим про codepipeline... как это сделать в терраформ/ансибл - если этим занимаются разные люди и надо отлавливать кто именно, то как вариант в CI/CD пробрасывать разного IAM юзера/роль в зависимости от того кто запушил изменения... если изменения делать от одного пользователя, то тогда надо писать коммитИд в теги например.
AT
ну или автора или и то и другое
AT
lastDeployedBy = Petya, commitId = d32443de
AV
Не увидел там про CodePipeline.
В любом случае, делать всё это, для того чтобы через AWS Config посмотреть, кто делал изменения... Очень затейливо :)
В любом случае, делать всё это, для того чтобы через AWS Config посмотреть, кто делал изменения... Очень затейливо :)
AV
Практического применения такой сценарий, как мне видится, не имеет. Ведь можно в CI/CD просто смотреть кто запустил билд.