
Взлом Instagram*‑аккаунта — популярный запрос в поисковиках. Поэтому есть смысл рассказать о том, как это обычно работает. Просто для того, чтобы вы знали, откуда может пойти атака.
Senior Devops/SRE
Взлом Instagram*‑аккаунта — популярный запрос в поисковиках. Поэтому есть смысл рассказать о том, как это обычно работает. Просто для того, чтобы вы знали, откуда может пойти атака.
Команда Kubernetes as a Service в Mail.ru Cloud Solutions перевела статью, в которой автор помогает найти причины ошибок в Kubernetes, если вы совсем не понимаете, куда нужно смотреть. Далее текст от лица автора.
Kubernetes — непростая платформа, особенно когда что-то пошло не так и нужно срочно найти и устранить возникшую проблему. В основном трудности объясняются сложностью самой системы и отсутствием подробных сообщений об ошибках. Ситуация усугубляется еще и огромным количеством «шестеренок» в потоке оркестрации контейнеров — при том что для представления этого потока используется всего лишь несколько состояний. Например, есть как минимум шесть возможных причин, по которым под может зависнуть в состоянии ContainerCreating
или CrashLoppBackOff
.
Мы активно работаем с Kubernetes уже более трех лет и за это время составили длинный список сложных и в то же время трудно диагностируемых проблем. Большинство из них можно отнести к одной из трех категорий:
ContainerCreating
.CrashLoopBackOff
и периодический перезапуск контейнера.У Kubernetes высокий порог входа, не все готовы использовать его в своих проектах. Это достаточно сложная для внедрения технология, особенно если конфигурированием кластера заниматься самостоятельно. Но я попробую упростить для вас эту задачу.
Я Павел Селиванов, ведущий DevOps-инженер облачной платформы Mail.ru Cloud Solutions. Я расскажу про альтернативный способ развертывания Kubernetes — использование Managed-варианта от облачного провайдера. Мы запустим реальный API-сервис на примере нашего облака и пройдем основные шаги развертывания приложений в K8s, включая подготовку инфраструктуры, настройку CI/CD-конвейера и всех необходимых объектов Kubernetes: Deployment, Service, Ingress и так далее.
В результате попробуем убедиться, что 60 минут — вполне достаточное время для освоения азов работы с K8s при условии использования его в виде aaS.
Пытливый читатель при желании может повторить все мои действия с помощью бонусных рублей, которые выдаются на тестирование новым пользователям при регистрации.
Практикум в видеоформате можно посмотреть по ссылке.
Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь... Это не так!
Однажды ко мне пришли дамы из лаборатории и сказали, что мы будем делать гель для интимной гигиены. Женской. Дальше мы поговорили с большим количеством девочек, девушек и женщин — и я с удивлением узнала, что мракобесие есть не только в области прививок и состава медсредств, но и во вполне бытовых вещах вроде интимной гигиены.
Поэтому сегодня мы будем говорить о науке, стоящей за этим. Точнее, скорее, это научпоп, потому что науки будет не сильно много, а вот бытовых следствий — достаточно.
Особенность анатомии девушек подразумевает постоянное сообщение полости влагалища с внешним миром, что в свою очередь сделало их зависимыми от состояния микрофлоры. У мужчин не так.
Поэтому сегодня будем говорить про микрофлору влагалища и наружных половых органов, почему её так легко сломать и заработать, например, цистит. Которого, кстати, у мужчин почти не бывает. И про то, как сейчас пытаются продвигать средства гигиены с кучей странных эффектов, включая отбеливание ануса.
В общем, пора поговорить про пестики и тычинки.
В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает.
Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc
Однако я уверен, что есть такие люди, которым не хочется 2 часа смотреть вебинар, а хочется за 15 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде на то, что он найдет своего заинтересованного читателя.
Общий стаж моей работы в ИТ - около 14 лет. Я начинал с системного администрирования, потом перешел в разработку, поработав как в аутсорсе, так и в продукте. Не один раз проходил путь от рядового разработчика до тимлида.
В этом посте мы обсудим функции Terraform. Язык Terraform включает ряд встроенных функций, которые можно вызывать из выражений для преобразования и комбинирования значений. Общий синтаксис для вызовов функций — это имя функции, за которым следуют аргументы, разделенные запятыми, в круглых скобках.
Небольшая инструкция по использованию Terraform, чтобы изучить и применить различные типы встроенных функций, в том числе Numeric, String, и Date, и Time в этом инструменте IaC.
Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.
Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).
Через историю Лёхи вы узнаете о задачах, которые решает SRE, и причинах, по которым для решения этих задач пришлось выделять отдельный класс инженеров.
ReplicaSet
— но это ручной процесс. Команда Kubernetes aaS от Mail.ru реализовала в своем сервисе автоматическое машстабирование на уровне кластеров. Ну а если вы хотите оптимизироваться на уровне подов — то следуйте рекомендациям этого перевода.ReplicaSet
) декларативным образом с использованием спецификации Horizontal Pod Autoscaler. По умолчанию критерий для автоматического масштабирования — метрики использования CPU (метрики ресурсов), но можно интегрировать пользовательские метрики и метрики, предоставляемые извне.https://unsplash.com/photos/V41PulGL1z0
Выполнять Canary-деплой мы будем руками через GitOps и создание/изменение основных ресурсов Kubernetes. Эта статья предназначена в первую очередь для знакомства с тем, как работает в Kubernetes Canary деплой, так как есть более эффективные способы автоматизации, которые мы рассмотрим в следующих статьях.
Прим. перев.: С ростом числа YAML-конфигураций для K8s-окружений всё более актуальной становится потребность в их автоматизированной проверке. Автор этого обзора не просто отобрал существующие решения для этой задачи, но и на примере Deployment'а посмотрел, как они работают. Получилось весьма информативно для тех, кому эта тема интересна.
TL;DR: В статье сравниваются шесть статических инструментов проверки и оценки YAML-файлов Kubernetes на соответствие лучшим практикам и требованиям.
Рабочие нагрузки Kubernetes, как правило, определяются в форме YAML-документов. Одна из проблем с YAML'ом — сложность задания ограничений или взаимоотношений между файлами манифестов.
Если в переводном тексте кто-то что-то где-то начинает — то у меня сразу всплывают три дежурных варианта: begin/beginning, start/starting, first/firstly.
Судя по тому, что я вижу в присылаемых мне на проверку переводах, эта бедность речи наблюдается не только у меня. Зато у наших американских переводчиков я такого не наблюдаю — тут тебе и синонимы красивые, или вообще без всяких begin/start дело обходится.
Я подумал, что пришло время устранить этот пробел в знаниях, делюсь наиболее интересными находками.
Самые экзотические варианты (напр. ignite) сюда впихивать не стал, вроде и без них есть из чего выбрать (но если в будущем экзотика тоже интересует, напишите в комментах).
Поехали.
Я принял все предложения без споров и оправданий и начал действовать.
I accepted their advice without arguing or defending and acted on it.