Как раз для k8s нужен именно демон, который реализует cri интерфейс, podman не реализует cri интерфейс, k8s с ним не работает. На текущий момент их не так много, основных: containerd, docker, cri-o (https://kubernetes.io/docs/setup/production-environment/container-runtimes/). Docker внутри использует containerd, то есть по сути это containerd vs cri-o, и я бы не сказал что cri-o обладает супер преимуществами, чтобы делать выбор в его сторону, более того с ним я испытал больше проблем чем с containerd (от docker). Поэтому считаю сомнительными все эти похороны докера.
А какая з/п была указана в вакансии?
Я просто очень сомневаюсь, что спецы, которые писали пайплайны и деплой в других компаниях, затрудняются ответить на вопросы как эти самые пайплайны у них были устроены. Либо такой человек обманывает, либо он просто был рядом и видел как это делал его старший коллега.
3 года работаю с jenkins, до сих пор нахожу много чего нового. Не знаю как можно его за два дня изучить во время онбординга да ещё и groovy в придачу. За годы работы в shared lib много скопилось groovy кода, куча трюков и хаков. Уверен, человек за два дня вряд-ли там что-то поймёт в этом коде.
Это не так, nginx при reload ждёт окончания соединений или отвала по таймауту. При этом запускает новые воркеры для обслуживания новых соединений. Старые воркеры будут остановлены только когда все текущие соединения будут завершены или по таймауту worker_shutdown_timeout
Для ускорения обратной связи, можно попробовать bolt, им можно например запускать puppet agent -t на машинах из ci. Он хорошо интегрируется в экосистему puppet, например список целей для выполнения задачи может брать из puppetdb, выполнять задачи, которые описаны в модулях puppet и многое другое.
Небезопасные умолчания, это проблема у многих. Например раньше по умолчанию elasticsearch или mongodb запускались открытыми для подключений без какой либо аутентификации и авторизации. Но справедливости ради, стоит отметить что kubenetes на мой взгляд больше является фреймворком, на котором ты строишь свои решения, поэтому минимум настроек по умолчанию это норм для такого проекта. Тот же openshift уже законченое решение на kubernetes, и там эти настройки выставлены в приемлемый вид.
В любом случае, автор статьи претендующий рассказать о безопасности в docker и kubernetes, просто об этом не упомянул или не знал. Мне кажется такие статьи вообще не стоят перевода.
в Kubernetes есть возможность переопределить uid пользователя от которого будет запущен контейнер или просто запретить запуск от рута, запретить любую запись в фс в контейнере, запретить монтирование папок с хоста (HostPath), тем самым запретив прокидывать сокет докера.
Если у человека есть доступ, понятное дело он может прочитать переменные среды, это вообще никак не связано с тем как запускается приложение, в контейнере, виртуальной машине или на железе.
P. S. статья не уровня Southbridge, слишком поверхностно
Я и не говорю, что старые инструменты были лучше или такие-же. Я про ваши тезисы:
"речь про других опсов, которые придут потом и по гиту всегда могут посмотреть, чем занимался предыдущий опс и что конкретно и как он делал"
"что бы сделать работу непонятных админов прозрачной и повторяемой другими людьми"
имеется в виду devops: "На моей практике эта тема про IaaC, CI/CD, централизованый и прозрачный мониторинг"
Все это было, до хайпа devops. И говорить что это нам devops принес инфраструктуру как код или CI/CD, а "непонятные" админы раньше бегали и все руками настраивали на мой взгляд неверно.
Теперь "непонятных" админов называют devops, и по моему субъективному опыту мало кто из разработчиков поймет, что там в репозитории описания инфраструктуры творится. Разработчиков бы с docker подружить уже победа, а говорить о всяких ansible, puppet, bolt, chef, salt, terraform, pulumiи т.д. вообще не приходится. Понятны и прозрачны ли будут разработчику все твои yaml для kubernetes, helm чарты, mutating webhook на golang, правила для prometheus? Я так не думаю.
Да даже для другого опса это может стать проблемой, когда нет документации к этому коду, или он вообще не знаком с этим. Например работал он все время на ansible и docker swarm, пришел в другую компанию, а там puppet, pulumi и kubernetes, и весь код на puppet dsl или typescript — для него это будет темный лес, поэтому про прозрачность это очень условное утверждение.
Это было задолго до хайпа devops. CFEngine в 93 появился, puppet в 2005. Использовались админами вполне. Но почему-то теперь во время хайпа, считается что админы внезапно перестали это делать, а придут девопсы (которых не существует, на самом деле придут админы) и внезапно внедрят инфраструктуру как код, они и 20 лет назад это делали.
Так нет проблемы централизации. Сертификат и ключ можно заливать в какой-нибудь vault, а он уже будет раскатываться по серверам с помощью любой реализации IaC. А как заливаются сертификат и ключ в vault уже не имеет значение для секурности.
А вот certbot как мне кажется, наоборот противоречит принципу Infrastructure as Code, так как это скрипт, который меняет конфиги веб-сервера. Да, ему можно запретить менять конфигурацию веб-сервера, но всё равно, генерить сертификат на сервере, не самый лучший вариант.
Если вы не доверяете сторонним программам, которые обновляют вам сертификат, то вы можете написать свою. Let's encrypt предоставляет API для этого. В любом случае, это можно автоматизировать.
Про защиту не написали, что очень важно на мой взгляд. Tiller умеет в аутентификацию по сертификатам, также имеет смысл на всякий случай его вынести в отдельный ns или иметь на каждый ns по своему tiller с ограниченными правами. Ну и c помощью network policy тоже стоит ограничить к нему подключения. Правда с выходом helm3 это уже всё не актуально, как было замечено в статье.
А зачем использовать глобальные переменные для этого? Как писали выше это чревато проблемами. Плюс, чтобы перезаписывать глобальные переменные, задаче нужны полные доступы в jenkins, что явно небезопасно.
Вижу несколько вариантов решения проблемы:
использовать штатный механизм артефактов. Задача с параметрами сохраняет артефакт со всеми опциями. Задача которая запускается регулярно, используя плагин copyArtifact, копирует артефакт себе. Так как файл очень маленький, он будет копироваться моментально
написать метод для shared libs, который достает все параметры из нужной задачи. Пример кода(код не проверял, возможно где-то ошибки):
Кстати, может кто-то из читателей этой статьи сможет объяснить, почему нужно выполнять все операции (сборка дистрибутива, его тестирование и т. д.) на той же машине, где расположен Jenkins?
Нет такой необходимости, jenkins имеет штатный механизм агентов
У вас из блока скрипта в active choise судя по всему можно выполнить любой код, например создать пользователя с правами админа. То есть, те кто имеют права конфигурировать эту задачу, имеют полные права в системе. Крайне небезопасно
Вам в любой конфигурации придётся управлять пользователями — и «костылить» описание инфраструктуры всё равно придётся
Пользователю достаточно подключиться к VPN, и он получит все сетевые настройки от сервера. В случае с wireguard вы так и не описали, каким образом вы поддерживаете сетевые настройки кучи устройств удаленных сотрудников. Я подробно расписал, почему это сделать крайне затруднительно с указанным подходом.
Если вы это реализовали с помощью ansible, и реально поддерживаете конфигурацию wireguard на телефонах, лаптопах, пк, планшетах удаленных сотрудников в разных частях света, напишите об этом статью, я думаю она будет крайне познавательной и интересной.
Вам в любой конфигурации придётся управлять пользователями — и «костылить» описание инфраструктуры всё равно придётся. (Хотя, конечно, есть вариант потыкать мышкой и быть уверенным, что всё правильно — без тестов, без стейджинга, этакие тёплые ламповые 90ые).
Не очень понял мысль про стейджинг и ламповые девяностые. Речь идет про устройства сотрудников. Где и что тыкать мышкой не совсем понял вас. Серверная инфраструктура под IaC это стандарт, но я никогда не видел, чтобы IaC пытались использовать для конфигурирования устройств удаленных сотрудников, особенно в условиях, когда им разрешено работать из собственных устройств. Если в это реализовали, очень прошу напишите об этом. Мне действительно интересно.
Насчёт опровержения… Увы, да, я не тестировал wg на 10G, потому что у меня дома гигабит. Но гигабит он выедает в потолок, нагружая одно ядро примерно в 60-70% (и то не понятно, то ли это сетевуха такая фиговая, то ли это сам wg). В статье могут много обсуждать, какой он медленный, но у меня рядом openvpn, который едва-едва три сотни делает при 100% CPU.
Вообще моя изначальная мысль была не о скорости, а о централизации и готовности wireguard к enterprise. На моя взгляд, решения на основе ipsec или anyconnect cisco гораздо лучше подходят.
А насчет скорости, тут нужно тестить, а такие заявления это просто субъективный опыт. На мой субъективный взгляд openvpn медленнее чем wireguard, но я его никогда толком не тюнил под скорости, ну и надо упомянуть в какой конфигурации все это тестили. И если уж сравнивать скорость, то делать как положено со всеми подробностями, тоже тянет на отдельную статью.
Примерно так:
([^\.]+\.[^\.]+)\.([^\.]+)\.(.*)заменяем на$1,$2,$3Например входной файл:
После замены:
Или же через sed:
Как раз для k8s нужен именно демон, который реализует cri интерфейс, podman не реализует cri интерфейс, k8s с ним не работает. На текущий момент их не так много, основных: containerd, docker, cri-o (https://kubernetes.io/docs/setup/production-environment/container-runtimes/). Docker внутри использует containerd, то есть по сути это containerd vs cri-o, и я бы не сказал что cri-o обладает супер преимуществами, чтобы делать выбор в его сторону, более того с ним я испытал больше проблем чем с containerd (от docker). Поэтому считаю сомнительными все эти похороны докера.
А какая з/п была указана в вакансии?
Я просто очень сомневаюсь, что спецы, которые писали пайплайны и деплой в других компаниях, затрудняются ответить на вопросы как эти самые пайплайны у них были устроены. Либо такой человек обманывает, либо он просто был рядом и видел как это делал его старший коллега.
3 года работаю с jenkins, до сих пор нахожу много чего нового. Не знаю как можно его за два дня изучить во время онбординга да ещё и groovy в придачу. За годы работы в shared lib много скопилось groovy кода, куча трюков и хаков. Уверен, человек за два дня вряд-ли там что-то поймёт в этом коде.
Это не так, nginx при reload ждёт окончания соединений или отвала по таймауту. При этом запускает новые воркеры для обслуживания новых соединений. Старые воркеры будут остановлены только когда все текущие соединения будут завершены или по таймауту worker_shutdown_timeout
Не обязательно на всех нодах, можно цеплять по запросам из puppetdb, например:
или
Запросы к puppetdb можно строить довольно сложные, и разной степени гибкости
Для ускорения обратной связи, можно попробовать bolt, им можно например запускать puppet agent -t на машинах из ci. Он хорошо интегрируется в экосистему puppet, например список целей для выполнения задачи может брать из puppetdb, выполнять задачи, которые описаны в модулях puppet и многое другое.
Небезопасные умолчания, это проблема у многих. Например раньше по умолчанию elasticsearch или mongodb запускались открытыми для подключений без какой либо аутентификации и авторизации. Но справедливости ради, стоит отметить что kubenetes на мой взгляд больше является фреймворком, на котором ты строишь свои решения, поэтому минимум настроек по умолчанию это норм для такого проекта. Тот же openshift уже законченое решение на kubernetes, и там эти настройки выставлены в приемлемый вид.
В любом случае, автор статьи претендующий рассказать о безопасности в docker и kubernetes, просто об этом не упомянул или не знал. Мне кажется такие статьи вообще не стоят перевода.
в Kubernetes есть возможность переопределить uid пользователя от которого будет запущен контейнер или просто запретить запуск от рута, запретить любую запись в фс в контейнере, запретить монтирование папок с хоста (HostPath), тем самым запретив прокидывать сокет докера.
Если у человека есть доступ, понятное дело он может прочитать переменные среды, это вообще никак не связано с тем как запускается приложение, в контейнере, виртуальной машине или на железе.
P. S. статья не уровня Southbridge, слишком поверхностно
Я и не говорю, что старые инструменты были лучше или такие-же. Я про ваши тезисы:
Все это было, до хайпа devops. И говорить что это нам devops принес инфраструктуру как код или CI/CD, а "непонятные" админы раньше бегали и все руками настраивали на мой взгляд неверно.
Теперь "непонятных" админов называют devops, и по моему субъективному опыту мало кто из разработчиков поймет, что там в репозитории описания инфраструктуры творится. Разработчиков бы с docker подружить уже победа, а говорить о всяких ansible, puppet, bolt, chef, salt, terraform, pulumiи т.д. вообще не приходится. Понятны и прозрачны ли будут разработчику все твои yaml для kubernetes, helm чарты, mutating webhook на golang, правила для prometheus? Я так не думаю.
Да даже для другого опса это может стать проблемой, когда нет документации к этому коду, или он вообще не знаком с этим. Например работал он все время на ansible и docker swarm, пришел в другую компанию, а там puppet, pulumi и kubernetes, и весь код на puppet dsl или typescript — для него это будет темный лес, поэтому про прозрачность это очень условное утверждение.
Это было задолго до хайпа devops. CFEngine в 93 появился, puppet в 2005. Использовались админами вполне. Но почему-то теперь во время хайпа, считается что админы внезапно перестали это делать, а придут девопсы (которых не существует, на самом деле придут админы) и внезапно внедрят инфраструктуру как код, они и 20 лет назад это делали.
Там вроде можно сразу пускать в логин системы, и будет обычное окно логина рабочего окружения (gnome, kde, xfce и т.д.).
Да, такое можно сделать. Даже можно такое провернуть и для rdp, помню делал это c помощью xrdp.
Так нет проблемы централизации. Сертификат и ключ можно заливать в какой-нибудь vault, а он уже будет раскатываться по серверам с помощью любой реализации IaC. А как заливаются сертификат и ключ в vault уже не имеет значение для секурности.
А вот certbot как мне кажется, наоборот противоречит принципу Infrastructure as Code, так как это скрипт, который меняет конфиги веб-сервера. Да, ему можно запретить менять конфигурацию веб-сервера, но всё равно, генерить сертификат на сервере, не самый лучший вариант.
Если вы не доверяете сторонним программам, которые обновляют вам сертификат, то вы можете написать свою. Let's encrypt предоставляет API для этого. В любом случае, это можно автоматизировать.
Про защиту не написали, что очень важно на мой взгляд. Tiller умеет в аутентификацию по сертификатам, также имеет смысл на всякий случай его вынести в отдельный ns или иметь на каждый ns по своему tiller с ограниченными правами. Ну и c помощью network policy тоже стоит ограничить к нему подключения. Правда с выходом helm3 это уже всё не актуально, как было замечено в статье.
Еще есть неплохой openshift-console (работает и в нативном кубе тоже).
А зачем использовать глобальные переменные для этого? Как писали выше это чревато проблемами. Плюс, чтобы перезаписывать глобальные переменные, задаче нужны полные доступы в jenkins, что явно небезопасно.
Вижу несколько вариантов решения проблемы:
Нет такой необходимости, jenkins имеет штатный механизм агентов
Пользователю достаточно подключиться к VPN, и он получит все сетевые настройки от сервера. В случае с wireguard вы так и не описали, каким образом вы поддерживаете сетевые настройки кучи устройств удаленных сотрудников. Я подробно расписал, почему это сделать крайне затруднительно с указанным подходом.
Если вы это реализовали с помощью ansible, и реально поддерживаете конфигурацию wireguard на телефонах, лаптопах, пк, планшетах удаленных сотрудников в разных частях света, напишите об этом статью, я думаю она будет крайне познавательной и интересной.
Не очень понял мысль про стейджинг и ламповые девяностые. Речь идет про устройства сотрудников. Где и что тыкать мышкой не совсем понял вас. Серверная инфраструктура под IaC это стандарт, но я никогда не видел, чтобы IaC пытались использовать для конфигурирования устройств удаленных сотрудников, особенно в условиях, когда им разрешено работать из собственных устройств. Если в это реализовали, очень прошу напишите об этом. Мне действительно интересно.
Вообще моя изначальная мысль была не о скорости, а о централизации и готовности wireguard к enterprise. На моя взгляд, решения на основе ipsec или anyconnect cisco гораздо лучше подходят.
А насчет скорости, тут нужно тестить, а такие заявления это просто субъективный опыт. На мой субъективный взгляд openvpn медленнее чем wireguard, но я его никогда толком не тюнил под скорости, ну и надо упомянуть в какой конфигурации все это тестили. И если уж сравнивать скорость, то делать как положено со всеми подробностями, тоже тянет на отдельную статью.