Комментарии 13
отличная статья, очень много полезных инструментов в одном месте, спасибо!
https://rancherdesktop.io/ вместо minikube использовали? Только он для mac и Windows.
Внедряли у себя тесты CIS Benchmark? Есть для Linux (разных версий, тут я как раз пишу роль для проверки), Nginx, Docker, для кубера вроде есть kube-beacon (я так понимаю, тот же функционал, что и kube-bench).
Для деплоя в Kubernetes Argo CD еще не внедряли?
Для ведения собственной документации (дома локально + можно синхронизировать стандартно в Гугл, т.к. их синхронизация платная) использую Obsidian https://obsidian.md/download — там всё в Markdown.
Добрый день!
Ранчер десктоп еще не приходилось использовать. В minikube в первую очередь привлекает стабильность работы, скорость обновлений и возможность включать/выключать встроенные плагины. В любом случае, спасибо за рекомендацию. В свободное время изучу инструмент :)
CIS Benchmark доводилось использовать только как встроенную функцию в Rancher. Инструментов для проверки безопасности появилось достаточно много за последние пару лет - и есть из чего выбрать. В большинстве проектов хватало первичного аудита текущего состояния. Дальше по результатам формировался беклог/секьюрити задачи. Ну а постоянные проверки запускали сторонней командей на регулярной основе. Там уже они сами выбирают для себя инструменты и подходы.
С ArgoCD мне доводилось работать несколько раз, но в боевых проектах применять не удавалось. Он либо был слишком накрученным и я делала выбор в пользу того же FluxCD, либо ему не доставало гибкости в настройке. Опять же для интеграции инструментов из категории GitOps в крупных компаниях, необходимо предоставить возможность быстрых роллбеков, контроль процесса деплоя, быструю обратную связь: нотификации, дашборды, кастомные интерфейсы, ну и контроль доступа/безопасности. В этом плане приходится выстраивать целую экосистему вокруг одного инструмента, а это не всегда целесообразно ;)
За рекомендацию Obsidian - отдельное спасибо. Пока для своих целей использую Notion, но это не всегда оказывается удобным.
Здравствуйте!
Отличная статья, понравилось ^_^
Кста, то канико мы отказались в пользу ванильного докера, так как у нас выделенные раннеры, а втаскивать новый инструмент не стали. (Сравнили производительность на сборках, по итогу разница была не более чем в 5-10 секунд)
Polaris тоже понравился в свое время, казалось что пишем вроде бы норм вещи, но Polaris подсветил вещи на которых глаза уже замылены =)
Добрый день! Спасибо за фидбек :)
По поводу канико vs docker все довольно спорно. В ситуации, где раннеры в кубернетесе, хочется избежать предоставления привилегированного доступа + докер собираются убирать в одной из следующих мажорных версий Kubernetes, поэтому нам не хотелось оттягивать нужное изменение. В последних версиях у канико также появились проблемы со стабильностью - периодически возникают весьма странные баги. Но с другой стороны инструмент хороший, позволяет одной командой пушить образы в несколько реджистри и особо проблем не доставляет. Главное, указывать конкретный докер тег в своих пайплайнах :)
У Polaris просто супер UI, который нестыдно пошарить с разработчиками/лидами/менеджерами, что бывает очень даже полезно.
Очень круто написано, у меня пока очень мало опыта в DevOps, но я понял почти всё
Я не понял, как тема "построить с нуля" свелась к "как провести аудит того, что есть". Как быть если вообще ничего нет: ни пайплайнов, ни CI/CD, ни K8S? Возможен альтернативный сценарий, когда что-то есть, но развитие и эволюция не приносит результата, нужна революция в виде построения с нуля. Было бы интересно послушать про такой опыт.
Добрый день! Спасибо за ваш фидбек и вопрос.
Отвечаю по порядку: в начале статьи я написала, что поддержка проекта - это отдельный этап, на котором приложение может мигрировать в новую среду, разработчики переходить на другие проекты/в другие компании и т.д., а поддерживать текущее решение нужно. Отсюда и построение плана проведения аудита - какое сейчас состояние и к чему мы хотим прийти.
Если вы начинаете вести проект с нуля, то можно попробовать пойти следующим образом - задать несколько вопросов и в обсуждениях найти на них ответы:
1. Что у меня есть сейчас? (только код / сборка / тестовая среда ..)
2. Что я хочу получить? (чтобы работало / гибкость / масштабирование ..)
3. Какие инструменты я могу / хочу использовать?
4. Чем я ограничен? деньги на этот проект, глобальные подходы в компании, существующие решения.
Например, у нас легаси веб проектик на Ruby, который вполне активно развивается нашими разработчиками. Мы хотим уметь быстро масштабироваться под новых клиентов и деплоить код в несколько окружений(датацентров=регионов).
1. Сейчас у нас есть кодовая база, тесты
2. Мы хотим получить артефакт сборки, задеплоить его в конечные окружения, уметь быстро масштабироваться под новых клиентов
3. Если я в облаке, то я могу быстро попробовать затащить приложение в Docker (образ = артефакт), задеплоить сырые манифесты или helm-ом в Kubernetes и проверить автомасштабирование под нагрузкой
4. Нужно в AWS/GCP/Azure калькуляторе посчитать затраты. Если в компании уже есть свой Kubernetes кластер, то можно его переиспользовать или поднять аналогичный.
Если денег не дают, то берем и поднимаем нужно число виртуалок, процесс деплоя описываем Ansibl-ом и заворачиваем в пайплайн в нашем CI/CD инструменте.
По итогам нужно обязательно прикинуть трудозатраты на поддержку - для этого нужно оценивать сложность выбранных инструментов, насколько у нас хорошая экспертиза в них и насколько человекозатратной будет поддержка.
Примерно так - но в реальной жизни не так много проектов, где нужно "реально" что-то делать с нуля. Обычно, разработчики пишут какие-то пайплайны, или в компании это не первый проект и т.д.
Если у вас есть еще вопросы, то задавайте! Постараюсь ответить :)
Спасибо, ответ обстоятельный, но немного не о том :) Перечисленные шаги 1-4 вполне может сделать менеджер проекта или тимлид. Они описывают стратегические решения, процессы, управленческие вопросы, бюджеты. А мне хочется техники. Ведь весь DevOps сейчас не сводится к выкладке через Docker/K8S/Облака? <мем с Падме и Энакином.png> Что если проект не ложится в контейнер? Как организовать сборки проекта с учетом версионирования, релизной политики? Какие инструменты следует использовать, какие у них слабые и сильные стороны? Как хранить "паспорт контура" (набор переменных от среды к среде параметров) и как накатывать его автоматом? Как развертывать новые тестовые контура по требованию?
Вопросов десятки :) Я когда-то запарился и написал статью, в которой реально все рассказано с нуля, разжевано для самых маленьких. Было бы очень круто услышать альтернативное видение.
Возможно, разбор техники будет в какой-нибудь следующей статье :) Основной идее этой было дать какую-то отправную точку тем, для кого подобные задачи ставятся впервые и нужно с чего-то начать. Про каждый инструмент написаны десятки статей тут и на медиум, с подробным сравнением и описанием сценариев, поэтому не думаю, что смогу привнести что-то новое.
С вашей статьей я ознакомилась - это здорово, что вы собрали и упорядочили свой опыт, чтобы создать end-to-end руководство для начинающих.
Думаю, что читатели найдутся на все в текущих реалиях. :)
DevOps Cookbook: как построить процессы с нуля