#люди

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

Я закинул эту идею своей команде, мне посоветовали пообщаться с одним из Staff+, который собаку съел на хостинге и развертывании. Долго тянуть с этой историей не буду, скажу, что по итогам этого общения решил задачу вообще по-другому и вовсе без контейнеров.

Нередко приходиться обращаться к старшим коллегам или из соседних команд по какому-то специфическому вопросу, и в этот момент меньше всего хочется услышать встречный вопрос: "Какую проблему решаем?"

Однако задница горит только так, в путь. Вот представьте - сидите, долго корпите над ПРОБЛЕМОЙ, продумываете РЕШЕНИЕ, и задумываетесь о применении ИНСТРУМЕНТА. Идете к эксперту, а тот чем рассказать про этот инструмент, вместо этого сам задает встречные вопросы, да и вообще братишка, тут все по новой надо, и вообще не то делаешь. Скотина такая.

Я слышал этот вопрос очень часто, а со временем переметнулся в лагерь тех, кто его задает. Притом необязательно задавать прям в лоб, можно замучать наводящими "зачем" и "почему", но задача всегда в одном - докопаться до изначальной постановки проблемы, что вполне объяснимо.

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

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

В комментарии приглашаются все рассказать о своем опыте и как их контора способствует быстроте принятия инженерных решений.

#машины_aws

Опыт учит с опаской относиться к умным людям. Чем умнее люди, тем более страшную, прошу прощения, хуйню они делают.

Казалось бы, в AWS работают очень умные люди - и это не шутка - но от некоторых моментов волосы встают дыбом. Да, я снова о семействе Code*, на этот раз о CodeBuild.

Итак, гениальный момент №1: сборки выполняются из под root. Нет смысла объяснять почему это плохо, но к счастью в buildspec есть инструкция run-as, как для всей сборки, так и для конкретных шагов. Однако, откуда нам знать, под каким пользователем надо выполнять сборку если не под рутом? Такой пользователь есть, но его не найти в документации. Я нашел его на SO, и вот где он спрятан.

Гениальный момент №2: как вы догадались, у этого пользователя прописывается путь к домашней директории, но самой домашней директории у него нет! Прибавьте к этому пляски с доступом к ФС, а также сборку Maven’ом, и получается полный антигуманизм. Решается созданием нужной директории и присваиванием этих прав нужному пользователю.

Итоговый файл спецификации выглядит вот так:

version: 0.2
run-as: codebuild-user

phases:
install:
run-as: root
runtime-versions:
java: corretto8
commands:
- mkdir /home/codebuild-user
- aws s3 cp s3://b/settings.xml ~codebuild-user/.m2/settings.xml
- chown -R codebuild-user:codebuild-user ~codebuild-user

build:
commands:
- mvn build # …

Другой вариант: создание собственного образа.

Customer obsession’ом отдает за версту, поддержку уведомил.

#машины_aws

И раз у меня Пятница Горящих Жоп, я не могу пройти мимо этой прекрасно выверенной дезинформации.

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

Два момента:
1. Хваленый IMDSv2 защищает от подобного вектора атаки приблизительно никак. Достаточно сначала запросить токен, потом с этим токеном сходить в мету.
2. Кто вообще наделяет виртуалку в облаке правами администратора облака?

#машины_разное

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

Зачем? Ну затем, что у меня очень много AWS credit’ов. И еще больше свободного времени.

Шутки в сторону. Как обещал, ниже выборка того, что накидали мне читатели под вот этим постом, с моими комментариями к каждому пункту. Сразу оговорюсь, список не весь, так что пожалуйсте в верхний пост за добавкой.

Самостоятельные лабы:
1. Amazon EKS Workshop - хорошая мощная лаба по EKS с дополнительными внешними инструментами. Подойдет для тех, кто уже прикинул k8s к носу и хочет вертеть его на AWS. Не понравилось, что завязана на eksctl, но там партнерский материал, ничего не поделаешь.
2. https://container.training/kube-selfpaced.yml.html - 2232 слайда почему-то отбили желание копать дальше оглавления, но кишки и обертки рассматриваются, что уже хорошо. В конце, что важно, рассказывается как обновлять кластеры (я слышал, обновление куба вызывает паническую атаку даже у самых опытных YAML-разработчиков).
3. https://github.com/kelseyhightower/kubernetes-the-hard-way - лаба от отца-основателя. Хороша тем, что ступень за ступенью, плоха тем, что ориентирована на GCP, впрочем чего еще ожидать.

Курсы:
1. https://kodekloud.com/courses/certified-kubernetes-administrator-cka/ - собственно то, что я сейчас прохожу. Аналогии с кораблями и капитанами мне не заходят (говори со мной на моем языке, камон), но кишки рассказываются очень хорошо.
2. Курс от Слерм - я его не слушал, но слышал много хорошего про Слерм.

Экзамены я сдавать не собираюсь, поэтому мне нерелевантно, но если вдруг:
1. https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/
2. https://killer.sh/

Книги (ни одну не читал):
- https://www.amazon.com/Managing-Kubernetes-Operating-Clusters-World/dp/149203391X - посоветовали под постом, по оглавлению выглядит глубоко.
- https://www.amazon.com/Advanced-Platform-Development-Kubernetes-Management/dp/1484256107 - нашел сам, похоже на то, что я хочу делать с кубиком, т.е. не сколько поднять его, сколько поднять внутри него нужную инфраструктуру.
- https://www.packtpub.com/product/mastering-kubernetes-third-edition/9781839211256 - нашел сам, как опубликовавшийся автор Packt, я знаю, что книги серии Mastering лучшее, что может быть по теме, и эта книга не исключение (чего стоит покрытие федерации и кросс-региональных кластеров).

Конечно же это чудо я буду поднимать на AWS, скорее всего возьму EKS, но постараюсь выкинуть из него все AWS’ное: драйверы, контроллеры и прочее.

Ну и надо будет ковыряться в этом новом инструментарии. По поводу чего еще одна просьба - напишите в комментариях, что вы используете с кубом? Почему не взяли альтернативы?
Например: ArgoCD/Flux, CRI-O/containerd, istio/linkerd, calico/cilium?

Холивары допускаются, оскорбления друг друга нет.

#машины_aws #машины_разное

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

Всех деталей не раскрою, но если вы используете Nitro экземпляры ЕС2 в AWS, т.е. 5-ое поколение M и C типов, убедитесь, что в clocksource у вас kvm-clock. Сэкономите себе нервов.

https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html

#машины_разное

И еще немного о времени, уж очень у меня подгорело.

1. Привет, перевод часов.
2. Привет, еще один список заблуждений.

Когда там уже Meta сделает нормальное железо для времени?

#машины_aws

Я продолжаю издеваться на Code* сервисами… Хотя скорее они надо мной.

В этой части разбираюсь с поведением CodeDeploy в Blue/Green развертываниях, а так же с тем, что не умеет CodePipeline и CDK.

Ваше прокрастинационное чтиво.

#пятничное

(прочистил голос)

6. Отмена НДС на покупку золота.

Голос нидерландов:

1. Тикток ушел из России
2. Макдак закрылся
3. Старбакс закрылся
4. Кока кола уходит
5. Наворованное чиновниками национализируют в бюджет

Если б я не знал контекст, я бы подумал, что Россия не просто встала с колен, а аж подпрыгнула

(ну сначала немного подпрыгнула. прим. ред.)

#машины_aws

Моя эпопея с семейством Code* практически подошла к концу. Это был довольно интересный проект, которым я надеюсь однажды поделиться с амазонщиками либо на митапе, либо на конфе, там уж как Uber разрешит.

Добивающим фактором стала особенность поведения CodeDeploy при сине-зеленом развертывании с копированием AutoScaling Group (почитайте пост с Медиума, я там подробно по этому прохожусь). ASG, с которыми я работаю, привязаны к двум Target Group'ам Application Load Balancer'а. После релиза, я обнаружил, что новая ASG ни с одной TG не ассоциирована.

Оказалось, что это баг CodeDeploy - если группа привязана к одной TG, то все будет работать как надо. А вот если две, то ни одна цепляться не будет. CodeDeploy не поддерживает одновременно две TG на одну Deployment Group.

Решилась проблема с помощью скрипта, который в фазе AfterAllowTraffic делал работу, с которой CodeDeploy справляться был не в состоянии.

Решение подглядел у своих коллег по этой ссылке.

Теперь составляю список противных вещей в DevTools от AWS, который однажды туда отправлю. Вот, что собрал:
• Поддержка нескольких TG в CodeDeploy Deployment Group
• Ссылки в логе CodeBuild обладают подчеркиванием, но не кликабельны (привет, UX)
• Поддержка override параметров в CodePipeline во время запуска, например, разово взять исходники из другой ветки репозитория в стадии Source.

Кто активно пользуется, пишите в комментариях, что еще раздражает, чем длиннее будет список, тем лучше.

#машины_разное

А все заметили, что Jira прилегла? Эта новость особенно неприятно смотрится совместно с другой, а именно end of support self-hosted версий продукции Atlassian.

Понять решение Atlassian можно - сопровождать зоопарк из разных версий (многие, особенно толстые, заказчики не спешат с обновлением), железа, ОС и СУБД невероятный труд, не говоря уже о том, что масштабируется с трудом. Так что консолидация продаваемого продукта на мощностях самого поставщика осмысленна и прозрачна.

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

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

P.S. Могли бы просто конский ценник за сопровождение Atlassian Server выкатить, да и все. Теперь будем неделю слушать улюлюкание, что ваши клавды фуфло.

P.P.S. Инфраструктурщикам Atlassian сил и терпения, долгоживущие инциденты, пожалуй, самое мерзкое, что может произойти с дежурным.

#жиза #пятничное

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

Я набрался шишок, опыта во внутреконторском наставничестве, устроился им в Яндекс.Практикум и продолжаю прокачивать себя в этом направлении.

Без лишней дотошности могу сказать, что ближайшим ко мне определением наставничества является оное из абсолютно упоротого фильма “Замысел”:

Х: Над всеми стоят Наставники. Они создадут проблему и наставят на путь ее преодоления. Передадут самые ценные знания, ничего не требуя взамен.
(спустя сцену)
У: Там были грабли.
Х: Угу, это я их подложил.
У: Но мне же больно!
Х: Ты получил шишку на лоб и опыт за плечи. Шишка пройдет, а опыт останется. Задача наставника не рассказать как избежать беды, а наставит на ее преодоление.

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

P.S. А фильм посмотрите, он крутой.

#машины_aws

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

Если это сообщение наберет 500 🔥, я расскажу вам адовую историю о том, как недокументированное поведение CodeDeploy после успешного развертывания привело к уничтожению нашего промышленного кластера и отказу систем и как я потом добивался от техподдержки здравого смысла.

Обещаю лонгрид на русском (Хабр) и английском (Медиум) с краткой выжимкой тут.

#машины_разное #люди

Брендан Грегг покинул Netflix. Мы пока не знаем, куда именно, но одно известно: он продолжит работать с клавдиями, что безусловно подливает интриги в котел спекуляций.

За время работы в Sun, Грегг покричав на серверы, разработал DTrace, его опыт в Netflix подарил нам Systems Performance, flame graph'ы, много интересного контента и BPF Performance Tools.

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

#машины_разное

Яндекс открыл исходный код YDB, став на моей памяти первой именитой технической компанией, открывшей код своей системы хранения данных.

Я поздравляю команду Яндекса за очередной шаг, повышающий доверие инженерного сообщества и дающий возможность людям посмотреть, что за херню вы там написали предоставить обратную связь!

UPD1: В комментариях напомнили про Clickhouse, так что Яндекс сделал это дважды.

UPD2: Tarantool был раньше. :]

#машины_aws

Вчера проводили разбор вот этого инцидента, только раза со второго удалось объяснить сущности и хитрости поведения CodeDeploy - я натурально смотрел события в CloudTrail, чтобы понять мозги этой дуры.

Самое “приятное”: я за всю карьеру не написал столько пост-мортемов и не провел столько разборов инцидентов, сколько за год в Uber. Добавлю это в свой список сомнительных поводов для гордости.

Что касается самого инцидента, чем дальше я в него вгрызаюсь, тем больше хочется материться. Как тому чуваку, который устроился в контору, починил баг, который его раздражал, и уволился, мне хочется устроиться в AWS, устроиться в DevTools команду, починить CodeDeploy, и бумерангом вернуться в Uber.

Само собой, это легко звучит на бумаге и едва ли реализуемо на практике. Так что пока пинаю ТАМов, эскалирую куда могу и стою над душой.

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

Предвосхищая комментарии “А что, просто так нельзя?”, отвечу - я заводил этот канал в первую очередь с ориентацией на небольшое, но активное и заинтересованное количество людей. Писать для эрудитов, тянущихся к знаниям - сплошное удовольствие. Писать для тех, кому лень даже эмодзи поставить - себя не уважать.

#машины_разное #люди

Брендан Грегг таки не разочаровал и теперь будет работать в Intel.

Учитывая его вовлеченность в производительность систем от железа до программ, можно ждать новый виток нововведений от Intel. Брендан обещает тесную работу с AWS, так что ждем интересных новостей.

Это отличное решение для Intel в первую очередь. Надеюсь, экспертиза Грегга поможет конторе занять конкурирущющие позиции с многочисленными ARM производителями.

#машины_aws

Половину огоньков мы набрали. Пожалуй, этого хватит, чтобы запитать затею на английскую версию произошедшего. 🙂

Вашему вниманию очередной инцидент с AWS, который мне пришлось разобрать.

Вынужден признать, что из-за таких приключений лучшие умы Большого Теха ™ с недоверием относятся к managed service’ам облачных провайдеров.

#машины_разное

Группа черных шапок, известная в определенных кругах как NB65, некоторое время назад сообщила о взломе защищенного периметра Qiwi и утечке платежных данных.

Об этом написали несколько Телеграмм каналов (например), после чего шум быстро поутих. По моей информации из Qiwi ничего не утекало, сами Paysystem Tech какой-либо связи с Qiwi не имеют (сайт у них какой-то мутный вдобавок, они живы вообще?).

Если у вас есть другая информация, поделитесь со мной в ЛС или в комментариях.

NB65 выложил полученные платежные данные в открытый доступ (сами нагуглите). В комментариях тут же набежали оглоеды в надежде получить номер карты, срок действия, CVV и заняться богомерзким фродом, но их ожидает разочарование, ведь CVV там нет.

А все потому что по правилам PCI-DSS, хранение CVV кодов даже в системе токенизации запрещено. :) Утекший номер и дедлайн карточки все еще является критической информацией, он попадает под PCI и PII (персональные) данные, но простому хитрозадому болванчику с ними ничего особо не сделать.

Учитывая вышесказанное, неудивительно, что потуги хакеров не получили никакой реакции, кроме общественной ;)

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

#пятничное

Мальчик: изучает WAF.
Мужчина: изучает WAF.

Credits to @sergdudk

#деньги

Возвращаюсь к надежности платежных систем.

Однажды, устав компенсировать чарджбеки за фрод на банковских картах, лучшие умы AmEx, Visa и MasterCard решили создать консилиум под названием PCI (Payment Card Industry) Security Standards Council, в рамках которого начали разрабатывать стандарты безопасности.

PCI-DSS (Data Security Standard), в целом сложен, потому как подразумевает защиту данных на всех уровнях, как программных, так и физических.

Тут надо сделать небольшую паузу и уточнить неочевидное: не вся коммерция, принимающая оплату с помощью платежных карт, подвержена регуляторным требованиям; все зависит от объема платежей через оных. Не скажу наверняка, но "стартовый порог" - 6 миллионов долларов США. Ниже либо вообще ничего не надо делать, либо достаточно заполнить опрос онлайн.

Но это скучно! Куда лучше, когда к тебе приходит ОЦЕНЩИК.

Да-да, PCI терпеть ненавидит слово аудит, и компании проходят так называемую оценку. Семантика здесь играет роль: аудитор ищет нарушения, в то время как оценщик держит в руках список требований и собирает доказательства того, что контора добросовестно выполняет требования. Презумпция невиновности против декларативности.

Такие оценщики называются PCI QSA (Qualified Security Assessor). В конторах с особо крупными объёмами хранимых данных и платежей, есть как внутренние QSA, так и внешние. Внутренние оценщики регулярно следят за порядком и выступают основным контактом во время внешней оценки.

Что касается требований PCI-DSS, то их можно упрощенно разбить на такой список:
- Есть то, что можно хранить, например номер и срок действия карты, и что категорически нельзя, например CVC.
- Все данные шифруются от и до с момента, как данные карточки были введены. Читай, encryption-in-transit и encryption-at-rest.
- В открытом виде данные платежных карт не должны нигде проскакивать, за исключением особых случаев, например, передачи данных гос. органам.
- Компания-обработчик обязуется проводить регулярные испытания на уязвимость.
- Имеется мониторинг безопасности.

Я раскрою подробности в следующем посте, но самое любимое требование - не светить открытыми данными. Вы не поверите, но были времена, когда номера карт в открытом виде валялись в логах.

Зуб даю, где-нибудь и сейчас валяются.