199.1
Karma
144.2
Rating
Дмитрий Шурупов @shurup

Open Source geek

В 19% популярнейших Docker-образов нет пароля для root

+1
Фраза «пустой пароль» однажды использовалась в тексте и во избежание некорректного её прочтения исправил, спасибо.

Речь про строку в /etc/shadow определённого вида (root::…), что указано в описании работы скрипта. Такая строка означает, что пользователя root пустят в систему без даже просьбы вводить какой-либо пароль. В Ubuntu, например, по умолчанию делают root:!:…, что действительно означает уже совсем иное: никакой пароль не подойдёт (хэш не совпадёт).

Резервирование в Kubernetes: оно существует

TiKV — распределённая база данных key-value для cloud native

Переход Tinder на Kubernetes

0

Нет, всё это было в статье изначально при публикации. Сам ее публиковал, так что знаю точно :-)

Переход Tinder на Kubernetes

0
Так вот на него (или Linkerd?) и собираются перейти ведь:

В этом году мы планируем переход на полноценный service mesh с более продвинутым обнаружением сервисов…

Из жизни с Kubernetes: Как HTTP-сервер испанцев не жаловал

+6
Спасибо за замечание. По существу — он разве что «усложнил» цепочку трафика для troubleshooting'а, о чём сказано в тексте. Из хаба Kubernetes статью убрали.

P.S. А в заголовке K8s по той причине, что хотим сделать такой цикл из материалов, объединённых тем, что все они будут из практики эксплуатации приложений в Kubernetes, однако с самим K8s напрямую могут быть не связаны. Их суть в первую очередь о «просто интересном опыте» и более «системных» выводах из него (что вообще случается в нашей практике, как подходить к вопросам troubleshooting'а и т.п.).

Мониторинг мёртв? — Да здравствует мониторинг

+11
Посмотрите/почитайте тогда и вот это :-) Акцент в докладе на Kubernetes, но он и про мониторинг вообще.

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

0

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

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

0
Тема поднята хорошая, но просто невозможно охватить всё и сразу в интервью (тут вопрос больше о его целях у самих авторов).

«5-6 человек уйдут из компании» — это же вряд ли сразу случится (а если столько же инженеров сразу уйдут, тоже хорошего мало). И вообще: когда люди уходят, им находят замену, разве нет? :-) Поэтому в таком срезе вопрос немного странный.

В целом же, вот ещё несколько тезисов по теме:

  • Хорошо поставленный процесс означает, что он будет (пусть хуже и какое-то время, но будет) продолжать работать и в случае ухода некоторых людей. Т.е. клиенты не перестанут сразу же к нам приходить даже в том случае, когда ключевой(ые) человек внезапно уйдёт.
  • Отдельные подразделения маркетинга, продаж для каждой команды — это большой overhead. Когда это разделяемый ресурс, всё получается очень красиво. По крайней мере, в наших масштабах и процессах сейчас это так.
  • Команды участвуют и в маркетинге, и в продажах. Не на всех этапах, конечно, но всё же. Тимлиды встречаются с потенциальными клиентами (чтобы обсуждать технические вопросы). Инженеры, например, помогают со статьями на хабру, описывая свой опыт. Есть ещё доклады на конференциях, где тоже задействованы представители команд.

Kubernetes 1.14: обзор основных новшеств

0
Цикл историй успеха своих клиентов мы уже готовим. Скоро вы их увидите здесь же в блоге.

Kubernetes 1.14: обзор основных новшеств

+5
Это больше похоже на «хотелось вот такое написать, но не знал, к чему бы…».

«Продукты» бывают только от вендоров и только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)? Или вы считаете, что сам по себе Kubernetes (не будучи каким-то вендорским проявлением…) в принципе не готов к enterprise, поэтому не «продукт»?

Если вы хотите сказать, что ни один Open Source-проект сам по себе продуктом не является (так читаются рассуждения про L3 и т.п. Хотя природа Open Source такова, что патчи потенциально может сделать буквально каждый «продвинутый пользователь»), то больше вопросов возникает к слову «продукт». Но это какая-то демагогия про слова, а не суть…

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

0
Поиск сотрудника происходит усилиями HR'а и к этому не относится. Речь про адаптацию. Эта сумма — фактически ЗП нового члена команды на испытательный срок, но устроено всё таким хитрым образом (вместо прямой оплаты этой ЗП из «федерального бюджета» компании, как было раньше), чтобы сама команда была мотивирована минимально рисковать и брать людей, в которых она уверена/которые ей подходят. (Команда сама принимает решение о том, берёт ли такого-то найденного и протестированного человека к себе.)

Игра для любителей и знатоков Linux

+2
Приз в этом конкурсе один — первое место. Победитель получит официальный сертификат, подтверждающий победу в конкурсе.

— как-то совсем скучно…

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

0

Скриншот по ссылке из старого теста, который был сильно более "классическим" сисадминством. В актуальном от этого ушли больше в сторону того, о чем выше (хотя и задания по системной части остались, т.к. мы считаем их знание критичным). Менять (сносить/переставлять в системе) можно радикально буквально все — на это ограничений в задании нет

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

+1
Известный нам рынок труда ещё не готов к тому, чтобы требовать от каждого неплохих практических знаний Kubernetes на старте работы в компании… :-) Этому мы уже обучаем внутри. Сборка/запуск приложений, впрочем, вполне близки к реальности, при этом компетенции — более массовые.

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

0
Много где был на фейс ту фейс но по 8 часов ни разу.

С определённых (и уже довольно давних) времён тест у нас проводится удалённо. О своём прогрессе/результате кандидаты пишут в Slack.

5 наиболее распространенных проблем работодателей при подборе IT-специалистов с точки зрения рекрутера-аутсорсера

+1
Мы в очень общих чертах писали о нём здесь. Это специальная виртуальная машина, попав на которую, системный администратор сначала пытается заполучить [чуть спрятанное] задание, а затем — выполнить задачи на той же машине. Эти задачи связаны с починкой/настройкой служб, которые могут быть специально сломаны хитрым образом, а также со сборкой/запуском приложений на разных языках/платформах, которые, понятное дело, имеют ошибки, возникающие на разных этапах (пример кейса — это приложение перенесли с другого сервера и вот здесь оно почему-то перестало работать).

5 наиболее распространенных проблем работодателей при подборе IT-специалистов с точки зрения рекрутера-аутсорсера

+1
«Пускание пыли» (по крайней мере, в массе) отпадает хотя бы по той причине, что это происходит подозрительно часто и даже от тех, кто сам понял, что не возьмут (зачем им уже производить какое-то впечатление?). Я не утверждаю, что нет тех, кому такое сомнительно, но конкретно у нас таких [из попавших на сам тест] — явное меньшинство.

И ещё момент: у нас не разработчики, а DevOps-инженеры.

«Нетипичное отношение к финансам» — что если сотрудники сами будут управлять доходами. Разговор с Флант

+1
Всякое бывает… Мы вот недавно писали про Reddit, где:

В начале 2016 года у сервиса, реализованного в виде монолитного приложения, было всего около 20 инженеров [..] Однако этот год принёс большие перемены: уже к его концу в компании работали более 60 инженеров (а к концу 2018-го года их число увеличилось до 200, т.е. всего за 3 года случился 10-кратный рост штата).

И всё выглядит так, что ребята ещё на плаву ;-) Но этой кадровой революции внутри компании сопутствовала и технологическая…

5 наиболее распространенных проблем работодателей при подборе IT-специалистов с точки зрения рекрутера-аутсорсера

0
Про тестовое задание в статье действительно что-то не так. На основе нашего опыта, который превышает 17 вакансий за год, люди (в т.ч. и высокой квалификации) готовы тратить на него и гораздо больше. Более того, после этого могут быть (причём в подавляющем большинстве) очень благодарны за саму возможность так «себя проверить» и просто получить удовольствие от процесса. Более того — актуально даже для тех случаев, когда результат прохождения «не очень», что кандидаты сами понимают в процессе.

Вопрос, получается, во многом о том, насколько действительно интересно ваше задание (а не просто, насколько оно сложное или длинное) и насколько кандидаты действительно хотят у вас работать, а обобщения в духе «тестовое задание, требующее более 2-3 часов – это плохо»… устал их читать.

P.S. Да, у нас без «надзора», вообще всё удалённо, так что можно пользоваться интернетом и т.п.

Эволюция инфраструктуры БД: от базы и приложения на одном сервере до потоковой репликации

+1
Очень перекликается с докладом «Базы данных и Kubernetes» от коллеги, где рассказывалось про эволюцию инфраструктуры под БД и заканчивалось как раз на Stolon ;-)

Мониторинг ping'ов между узлами Kubernetes — наш рецепт

+1
Мысль правильная, спасибо. Можно сказать, что планировали, но наш план имеет большие масштабы. Пока что это на уровне «тайны» [о которой вскоре все узнают] :-)

Вышел релиз GitLab 11.8 с SAST для JavaScript, GitLab Pages для подгрупп и отслеживанием ошибок

В OpenStack расширяют портфолио и займутся CI/CD

0

Рассказали про Kubernetes как альтернативу от другой организации, но между K8s и OpenStack бывает и симбиоз, очень крупный, в production — см. ЦЕРН, eBay, SAP как примеры.

Назад к микросервисам вместе с Istio. Часть 1

0

А сами микросервисы уже в Kubernetes? Если да, то ничего страшного в yaml уже нет и всё не так уж сложно, т.к. органично вписывается в существующую [инфра-]структуру. А если нет, то всему своё время (и, возможно, масштабы)...

Зрелая исполняемая среда для контейнеров: containerd стал «выпускником» CNCF

0
Думаю, что это вопрос времени, причём весьма скорого. Надо вспомнить, что etcd в принципе попал в список проектов CNCF лишь в декабре 2018. (Тут можно почитать, как этот шаг обсуждали в сообществе причастных.)

k3s – маленький, но сертифицированный Kubernetes от Rancher Labs

+3
А зачем без cut? Можно было побольше рассказать про k3s — тут же не Reddit :-) У проекта и README достаточно подробный, и на сайте есть схема работы с прочими подробностями…

Истории успеха Kubernetes в production. Часть 10: Reddit

+1
В случаях, когда service owners требуется получить доступ к production, они пользуются внутренней консольной разработкой (под названием rkube) для инициации процесса аутентификации через OpenID Connect (см. также OpenID Connect Tokens в документации Kubernetes). По своей сути он очень похож на аналогичную реализацию в CLI-утилите gcloud для GCP (инженеры Reddit заимствовали всю идею оттуда).

После успешной аутентификации в локальный конфиг (.kube/config) на машине разработчика записывается JSON Web Token. Этот токен имеет ограниченное (небольшое) время жизни. В нём содержится подписанный payload, в котором указано имя пользователя и его членство в группах. В свою очередь политики, настроенные на стороне Kubernetes-кластера, ориентированы на выдачу прав по этим самым группам.

Поскольку для каждого сервиса создаётся своё пространство имён, дальнейшая задача — выдать service owner'ам полные права на нужные namespaces (т.е. соответствующие сервисам, которыми они владеют).

Итог: service owners могут получить права на свои сервисы и только их.

Истории успеха Kubernetes в production. Часть 10: Reddit

0
Вот с этого момента подробности рассказывают: youtu.be/z7TIzCAEo0M?t=1132

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

Представлен Talos — «современный Linux-дистрибутив для Kubernetes»

+4
Не могу не поделиться полученным несколько часов назад письмом от Andrew Rynhard:

Hi Dmitry,

I am the developer of Talos. I just want to thank you for taking the time to write about Talos on habr.com. You described it better than me :D.

Уязвимость runC, затрагивающая Kubernetes, Docker и containerd

0
Да, неужели ru_vds сложно вбить «runc» в поиске хабры перед тем, как публиковать дубль?

Уязвимость CVE-2019-5736 в runc, позволяющая получить права root на хосте

+1
Из NVD (ссылка есть в статье):

This occurs because of file-descriptor mishandling, related to /proc/self/exe.

В этом патче (к LXC; тоже есть ссылка в статье) — больше подробностей:

The attack can be made when attaching to a running container or when starting a
container running a specially crafted image. For example, when runC attaches
to a container the attacker can trick it into executing itself. This could be
done by replacing the target binary inside the container with a custom binary
pointing back at the runC binary itself. As an example, if the target binary
was /bin/bash, this could be replaced with an executable script specifying the
interpreter path #!/proc/self/exe (/proc/self/exec is a symbolic link created
by the kernel for every process which points to the binary that was executed
for that process). As such when /bin/bash is executed inside the container,
instead the target of /proc/self/exe will be executed — which will point to the
runc binary on the host. The attacker can then proceed to write to the target
of /proc/self/exe to try and overwrite the runC binary on the host. However in
general, this will not succeed as the kernel will not permit it to be
overwritten whilst runC is executing. To overcome this, the attacker can
instead open a file descriptor to /proc/self/exe using the O_PATH flag and then
proceed to reopen the binary as O_WRONLY through /proc/self/fd/ and try to
write to it in a busy loop from a separate process. Ultimately it will succeed
when the runC binary exits. After this the runC binary is compromised and can
be used to attack other containers or the host itself.

Трезвый взгляд на Helm 2: «Вот такой, какой есть...»

0
Будет ли объективным обзор от того, кто им не пользуется? :-) Или вы считаете, что только от того, кто пользовался, но перестал (это ведь тоже потенциальный перекос в одну из сторон)? В общем, несколько демагогия… давайте лучше по сути [недостатков Helm и/или альтернатив], если есть такие вопросы/замечания.

Как победить дракона: переписываем вашу программу на Golang

+1
Это был долгий процесс… Скоро представим проект отдельной публикацией — там и расскажем! ;-)

Как победить дракона: переписываем вашу программу на Golang

+1
только первый выглядит адекватным для перехода именно на go.

Выше автор уже так и написал:
Инфраструктура — главный аргумент.

Как победить дракона: переписываем вашу программу на Golang

+1
Как минимум (и этого достаточно) — потому что «во-первых» (экосистема Kubernetes).

Как победить дракона: переписываем вашу программу на Golang

+2
Сложно согласиться. Когда проект для широкого сообщества, которое поголовно пишет на Go, и взаимодействует с другими проектами этой экосистемы, вопрос вовсе не в одном конкретном API.

Всегда ли нужны Docker, микросервисы и реактивное программирование?

Kubernetes: сборка образов Docker в кластере

+2
нужно что-то вроде Docker внутри Docker.

Это название конкретного решения — странно переводить его по всему тексту.

Оригинальная статья от августа, и с тех пор у kaniko случилось много релизов (0.3.0 → 0.7.0). Впрочем, несмотря на это:

Только учтите, что kaniko пока находится в разработке и поддерживает не все команды Dockerfile, например --chownflag для команды COPY.

… проблема (только --chown, а не --chownflag) и ныне здесь, хотя давно есть github.com/GoogleContainerTools/kaniko/pull/250
1 There