Это просто жемчужина! У меня лоб болит от того, что я так часто брови поднимал пока смотрел😲. А когда еще в конце услышал, что в следующем видео это еще и с Терраформом будет, то вообще под стол сполз. 😮🚑 Денис, я понимаю что на свете несколько миллиардов людей, но знай что среди них найдутся сотни или даже тысячи, которых ты вдохновил своим талантом учителя и ментора. Хочу от чистого сердца поблагодарить тебя за все что ты делашь, и пожелать тебе радости и мира. Именно твои видео заставили меня пойти учиться в Универ, окончить его и найти работу которая мне по душе! Спасибо тебе!🤝
Долгое время считал себя тупым. Не мог сломать барьер ООП. При этом почти 10 лет в сфере. С годами я понял. Тупой не тот кто не понял - а тот кто не смог объяснить так чтобы тот понял.
лучший канал по девопсу в рускоязычном пространстве , ansible, Jenkins , Python много чему отсюда учился, спасибо! ps добавлю что подача материала крутая , как будто опытный кореш по работе сидит рядом и на пальцах объясняет , что и как настраивать)), простым языком
Шикарственно! 26 минут и уже примерно ясно где, когда и для чего применять этот инструмент. Детали уже можно самостоятельно изучить. Спасибо за очереную удочку!
этот добрый человек, зачем-то удаляет комменты с замечаниями к видео, причем замечанием вполне по делу и без какого либо злого подтекста. про ApplicationSet, вместо предложенного тут App of Apps.
Когда то я по второй части (когда она вышла) все сделал, особо не вникая и понимая, но работало :) Все эти месяца я изучал кубернетес. Сейчас я смотрю первую, потому что хочу научиться деплоить своё приложение еще и через argocd. И самое забавное, что я все понимаю :) Мне самому удивительно. Я еще по ходу ролика думаю, где и как я прикручу в своих пайплайнах нужные шаги.
Супер видео! Большое спасибо) Хотелось бы увидеть на практике, как с помощью argo cd делать динамические окружения для fuature-веток в git репозитории приложения, которые самоуничтожаются после мержа в develop
@@ADV-IT есть bot image updater, который смотрит в dockerhub и потом автоматом создаёт PR, где меняет тэг образа в репе, и может его автоматом мёрджить, или слать нотификашку "нужному" персонажу.
Круто! Единственный нюанс что сколько лет прошло а argo похоже все еще не умеет сам патчить таги образов😅 FluxCD в этом плане по круче но, на мой взгляд, на порядок сложнее.
урок очень интересный и топ подача, но сама суть ArgoCD и зачем он нужен я не понял. зачем мне ждать до 3х минут пока ArgoCD решит сделать kubectl apply, когда в git репозитории появится новый комит, если я могу просто в конце пайплайна на тот же самый комит, в например GitHub Actions, тригернуть тот же самый kubectl apply и уже кубер мне всё задеплоит и тогда нет лишнего компонента (и сложность всей системы не увеличивается) единственное, что я увидел, что ArgoCD может предложить - это возможность Drift detection-а и передеплоя если по какой-то причине часть состояния кластера были изменена P.S. второй урок ещё не смотрел - может там больше раскроются преимущества ArgoCD
Спасибо Денис за видео. Хотел спросить тебя использовал ли ты когда-нибудь prometheus в kubernetes? Если да может посоветуешь какие нить хорошие ресурсы по данной тематике?
Спасиб большое за видео! Подскажите пожалуйста, как можно использовать переменные в том же app1, чтобы не публиковать секретные данные в github? Root приложение мы установили через terraform и использовали переменные, остальные приложения app1 и app2 это уже yaml файл. Скажем хочу создать ingress и вместо домена указать его через переменную!
Спасибо большое за видео, очень жду второе. Не знаешь HCP Vault ? Хотелось бы по нему guide, в русскоязычном youtube вообще нет полноценного гайда по этому инструменту, а он очень годный.
@@ADV-IT Работаю в одной из крупных организаций в РФ, нам безы вообще запрещают хранить секреты не в HCP Vault + если это кубер то интеграции секретов из Vault в кубер
Выглядит, как доп элемент в схеме, который нужно содержать/мониторить/админить. При этом, появляется общая репа девопсов. Не легче ли, даже в таком случае, просто накидать манифестов и через apply -f задеплоить, чем городить подобную схему? В нормальном случае helm install, добавленный в шаблон, решит все проблемы. Что даст ArgoCD в такой схеме? Защиту от дурака и всё?
В таком случае лучший ответ это "Подрастешь Поймешь". ArgoCD следит чтобы в ручную никто ничего не поломал в кластере, а если поломал, то сразу исправить на то что прописано в git repo. Если в git repo закинули манифест с багом, то argocd легко откатит обратно.
Денис, спасибо за видео, отличный инструмент) А может знаете, как можно api использовать? Иногда в рамках CI нужно остановить сервис полностью, либо пересоздать с нуля, но приходится каждый раз удалять аппликацию полностью и создавать заново
Чтобы ArgoCD API начал работать, ArgoCD нужно сначало установить. Потом можешь использовать API, argo-cd.readthedocs.io/en/release-1.8/user-guide/commands/argocd_app_create/ Только не вижу пользы в этом, только сложнее получается всё.
Если нужно остановить сервис, то просто количество реплик уменьшаешь до нуля. Зачем сносить Application? А если пересоздать с нуля - это считай то же самое что helm uninstall, только реализованный через удаление Application.
А как уйти от ручного изменения image tag. Разраб внес изменения в код - пайплайн собрал и запушил с произвольным tag (допустим commit id). Как теперь ему дать понять что нужно деплоить новый tag?
Я показал простой пример. Например: один HELM деплои App1 у которого только один контейнер с webserver. один HELM деплои App23 который совсем другой и совсем другие ресурсы.
Дженкинс на отдельном сервере. У нас просто лоигка CD настроена так, что на стейдже в дженкинс джобе поднимается контейнер с ансиблом: [...] Stage("Название этапа" { agent { docker { > } } steps { sh ''' > ''' } } [...] и там генерируются манифесты k8s для сервисов, конфигмапы, контейнеры для инициализации сервиса и тд. Не вижу пока как удобно на одном лишь ArgoCD построить нормальный деплой, если у тебя 50 сервисов, где 30-40 переменных окружения и всё это на 4 инстансах в кубере для разных групп разработки. Было бы интересно в видео про ArgoCD этот момент уточнить, потому что здесь ты говоришь, что нужно в ручную манифесты редачить. Мы так не делаем. У нас всё делает Jenkins. Здесь получается, что он нам всё равно будет нужен для сборки приложения, а вот CD процессы уже через ArgoCD настраивать как-то. Но тогда я только вижу вариант, когда джоба в дженкинсе пушит в репу какие-либо файлы, например тот же конфиг мап. И в таком случае смысл в ArgoCD улетучивается, потому что проще уже будет в конце сделать kubectl и применять нужные манифесты, чем использовать серверные ресурсы на доп. ПО. В общем ощущение, что ArgoCD создан для небольших проектов и маленький компаний, которые не хотят париться над настройкой логики развёртывания с помощью Groovy.@@ADV-IT
Я вижу преимущество в том, что ты хранишь стейт ворклоада в гите и это единственный source of truth. И это не серебряная пуля, а лишь один из подходов, который не является универсально применимым. И арго это не си сервер, так что каким образом формируются манифесты остается за скобками
@@olegen1 а какая разница truth или не truth? Если у тебя отлаженный проект, то проблем не будет. В реальной жизни каждый запуск сервиса - это запуск init контейнеров, чтобы в случае проблемы на каком либо этапе сервис не стартовал. А после старта liveness и readiness пробы.
Какой смысл в Ansible вообще в данном применении? Jenkins достаточно для деплоя чего угодно в Kubernetes. Точно так же как в случае с ArgoCD будет один источник истины - git репозиторий. Просто в Jenkins немного по-другому будет запускаться деплой в кубер: через плагин, либо вызовом helm с аргументами. Разница в том что на Jenkins можно реализовать и CI любой сложности, и CD, а ArgoCD для этого не предназначен, как я понял. Только CD, но более "бесшовно" что ли, чем в случае с Jenkins (хотя на нём можно точно так же всё периодическими задачами организовать).
Ну и зачем мне на деплой новой версии образа чтото кудато комиттить в гит? У меня ничего кроме тега не изменяется, а это динамический п-р для хелм upgrade
Все изменения в конфигурации должны журналироваться. Это суть принципа IaC. В любой момент можно посмотреть что задеплоено прямо сейчас, кто и когда вносил изменения в конфигурацию - просто заглянув в git репозиторий проекта.
Это просто жемчужина! У меня лоб болит от того, что я так часто брови поднимал пока смотрел😲. А когда еще в конце услышал, что в следующем видео это еще и с Терраформом будет, то вообще под стол сполз. 😮🚑 Денис, я понимаю что на свете несколько миллиардов людей, но знай что среди них найдутся сотни или даже тысячи, которых ты вдохновил своим талантом учителя и ментора. Хочу от чистого сердца поблагодарить тебя за все что ты делашь, и пожелать тебе радости и мира. Именно твои видео заставили меня пойти учиться в Универ, окончить его и найти работу которая мне по душе! Спасибо тебе!🤝
Спасибо!
Хочу выразить благодарность за предоставленный материал. А также отметить что у тебя хорошо получается объяснять сложные вещи простым языком.
Спасибо!
Приятно, когда тебе, как школьнику, на пальцах объясняют все подробно, но при этом максимально просто :) Спасибо
Долгое время считал себя тупым. Не мог сломать барьер ООП. При этом почти 10 лет в сфере. С годами я понял. Тупой не тот кто не понял - а тот кто не смог объяснить так чтобы тот понял.
лучший канал по девопсу в рускоязычном пространстве , ansible, Jenkins , Python много чему отсюда учился, спасибо!
ps
добавлю что подача материала крутая , как будто опытный кореш по работе сидит рядом и на пальцах объясняет , что и как настраивать)), простым языком
Шикарственно! 26 минут и уже примерно ясно где, когда и для чего применять этот инструмент. Детали уже можно самостоятельно изучить. Спасибо за очереную удочку!
Детали и готовое решение будут на следующей уроке
Классное видео. Спасибо. Идея для новых видео - мониторинг.
Вадим, спасибо вам большое. Обожаю все ваши видео!!!
Я стал DevOps-м и работаю на этой роли почти два года благодаря вашим урокам!!!
Благодаря Денису новые и пугающие инструменты становятся простыми и понятными. Спасибо!!!❤🎉
Ты лучше всех объясняешь! Спс за твою работу.
Ура блин, разлозжил всё по полочкам, доки читал и не понимал что и куда. А тут толково рассказал, спасибо.
Контент просто топ!
Я в восторге с этих уроков! 💎
Вселенский респект 🤟
Мое почтение, 0 воды, 100% конкретики.
Давно ждал эту тему!!!! Супер актуальная сейчас для меня. Больше спасибо за четкие разъяснения и легкую подачу информации!!
Очень круто спасибо! обязательно продолжайте добавляйте другие уроки 🙏
Хорошая тема. Следом хорошо б про Flux CD . Отличия, нюансы использования и т.д.
Поддерживаю, flux cd реально било б классно про него очень мало материалов
@@ВадимТкачук-ъ5ф th-cam.com/video/X5W_706-jSY/w-d-xo.html&ab_channel=ThatDevOpsGuy
ну есть нормальный туториал на официальном сайте@@ВадимТкачук-ъ5ф
Спасибо большое за супер полезные видео по ArgoCD!
Круто, как раз повод начать изучать ArgoCD
Denis spasibo za vse uroki!!!
ArgoCD klass jdem vtoroi chasti
респекту нет предела, чотинько все объяснил
Привет , четко, лаконично, весело и просто , двумя словами - это уровень :))
Большое спасибо за труд!
Спасибо тебе, добрый человек! Классная работа!
этот добрый человек, зачем-то удаляет комменты с замечаниями к видео, причем замечанием вполне по делу и без какого либо злого подтекста. про ApplicationSet, вместо предложенного тут App of Apps.
Единственные коменты которые я удаляю это оскорбления и тут же баню. всё.
Любая критика и другие мнения тут приветсвуются!
спасибо, офигенный гайд. просто и понятно
Когда то я по второй части (когда она вышла) все сделал, особо не вникая и понимая, но работало :) Все эти месяца я изучал кубернетес. Сейчас я смотрю первую, потому что хочу научиться деплоить своё приложение еще и через argocd. И самое забавное, что я все понимаю :) Мне самому удивительно. Я еще по ходу ролика думаю, где и как я прикручу в своих пайплайнах нужные шаги.
Отличное видео, спасибо! Ждем продолжения обозревания темы GitOps 💻🐒
очень воодушевлён и приятно удивлён!
ещё раз спасибо Вам, за то, что вы делаете)))
С нетерпением жду!
Ждем 2-й урок
Денис, супер! Спасибо за материал.
Спасибо за лекции.
Спасибо огромное за видео❤
Спасибо за урок, очень жду интеграцию через терраформ
Супер видео! Большое спасибо)
Хотелось бы увидеть на практике, как с помощью argo cd делать динамические окружения для fuature-веток в git репозитории приложения, которые самоуничтожаются после мержа в develop
Давно ждём
Автоматически лайк) Спасибо!!!
Круто! Ждем продолжения!
Супер! Но не обязательно менять версию в docker tag в yaml файлах, можно создать тег, например, prod и менять ему target image в docker hub
А как ArgoCD узнает что в Docker Hub что-то поменялось?
@@ADV-IT есть bot image updater, который смотрит в dockerhub и потом автоматом создаёт PR, где меняет тэг образа в репе, и может его автоматом мёрджить, или слать нотификашку "нужному" персонажу.
Отличный ролик, спасибо!
22:26 можно видеть у деплоя и RS "rev.2", также там рядышком висит RS "rev.1" - очень наглядно
По умолчанию хранится 10 последниз версий для быстрого rollback, только AutoSync надо отключить
Молоток, спасибо!
Устроилась на работу, DevOps, я после универа, и мне сейчас нужно за короткое время понять OpenShift, AgroCD, JFrog, Helm Chart, K8s. 🤪
AgroCD, Helm и основы k8s есть на канале
За короткое время, ну пиздец
спасибо за урок
Супер!! Спасибо!!
Спасибо как всегда супер!
Спасибо за урок . Очень интересно было послушать про Argo CD . Планируется ли и по Ранчеру какой нибудь урок?
А crossplane будет? =)
Отличная тема
Привет, Денчик. А чего тему с Volumes пропустил? Пришлось самому разбираться!))) Может расскажешь за эту тему?
Я один, а тем много, всё не успею.
Круто! Единственный нюанс что сколько лет прошло а argo похоже все еще не умеет сам патчить таги образов😅 FluxCD в этом плане по круче но, на мой взгляд, на порядок сложнее.
урок очень интересный и топ подача, но сама суть ArgoCD и зачем он нужен я не понял.
зачем мне ждать до 3х минут пока ArgoCD решит сделать kubectl apply, когда в git репозитории появится новый комит, если я могу просто в конце пайплайна на тот же самый комит, в например GitHub Actions, тригернуть тот же самый kubectl apply и уже кубер мне всё задеплоит
и тогда нет лишнего компонента (и сложность всей системы не увеличивается)
единственное, что я увидел, что ArgoCD может предложить - это возможность Drift detection-а и передеплоя если по какой-то причине часть состояния кластера были изменена
P.S. второй урок ещё не смотрел - может там больше раскроются преимущества ArgoCD
Хех это прям мой стек с работы.
О, топ гайд подъехал
Спасибо Денис за видео. Хотел спросить тебя использовал ли ты когда-нибудь prometheus в kubernetes? Если да может посоветуешь какие нить хорошие ресурсы по данной тематике?
Я не использовал сам, но видел что используют многие. Не могу посоветовать ничего тут, сорри, с ютубе вижу куча видео на эту тему.
@@ADV-IT понял спасибо за ответ, да видосы смотрел но все равно часто возникает много вопросов поэтому и интересовался
Дэн лучший
Спасиб большое за видео!
Подскажите пожалуйста, как можно использовать переменные в том же app1, чтобы не публиковать секретные данные в github?
Root приложение мы установили через terraform и использовали переменные, остальные приложения app1 и app2 это уже yaml файл. Скажем хочу создать ingress и вместо домена указать его через переменную!
Используй AWS Secret Manager, Hashicorp Vault и т.д.
@@ADV-IT Спасибо большое, нашел информацию Argo CD Vault Plugin
Спасибо большое за видео, очень жду второе. Не знаешь HCP Vault ? Хотелось бы по нему guide, в русскоязычном youtube вообще нет полноценного гайда по этому инструменту, а он очень годный.
Использовал только один раз, и то только устанавливал
@@ADV-IT Работаю в одной из крупных организаций в РФ, нам безы вообще запрещают хранить секреты не в HCP Vault + если это кубер то интеграции секретов из Vault в кубер
Ну это правильно в принципе
That is just 🤩
вот это тема! 🔥
Thanks!
Спасибо большое за поддержку!
АААА голова кипит)))))
Выглядит, как доп элемент в схеме, который нужно содержать/мониторить/админить.
При этом, появляется общая репа девопсов.
Не легче ли, даже в таком случае, просто накидать манифестов и через apply -f задеплоить, чем городить подобную схему?
В нормальном случае helm install, добавленный в шаблон, решит все проблемы. Что даст ArgoCD в такой схеме? Защиту от дурака и всё?
В таком случае лучший ответ это "Подрастешь Поймешь".
ArgoCD следит чтобы в ручную никто ничего не поломал в кластере, а если поломал, то сразу исправить на то что прописано в git repo.
Если в git repo закинули манифест с багом, то argocd легко откатит обратно.
@@ADV-IT
Спасибо за ответ!)
Соответственно, я и спрашиваю для того, чтобы "вырасти"))
Денис, спасибо за видео, отличный инструмент)
А может знаете, как можно api использовать? Иногда в рамках CI нужно остановить сервис полностью, либо пересоздать с нуля, но приходится каждый раз удалять аппликацию полностью и создавать заново
api кого?
@@ADV-IT API самого ArgoCD, доступно в /swagger-ui
И, если пробовали Argo-CD Autopilot - тоже было бы круто рассказать!
Чтобы ArgoCD API начал работать, ArgoCD нужно сначало установить.
Потом можешь использовать API, argo-cd.readthedocs.io/en/release-1.8/user-guide/commands/argocd_app_create/
Только не вижу пользы в этом, только сложнее получается всё.
Если нужно остановить сервис, то просто количество реплик уменьшаешь до нуля. Зачем сносить Application? А если пересоздать с нуля - это считай то же самое что helm uninstall, только реализованный через удаление Application.
💥💥💥💥💥
Так вот как на самом деле выглядит DevOps !!! Не смогу я стать девопсом, у меня уши маленькие и хвост не растет. 🤣🤣🤣
Там на руках копыта надо еще иметь, так что… вопросов много в общем, путь не простой )))
visa карта например
А как уйти от ручного изменения image tag. Разраб внес изменения в код - пайплайн собрал и запушил с произвольным tag (допустим commit id). Как теперь ему дать понять что нужно деплоить новый tag?
CI Pipeline которая делала Image, знает новый tag.
Она и должна обновить этот tag в yaml
Не удалял ничего.
А зачем столько helm chart,ов ? Нужен только один в который будут передаватся переменные при деплое
Я показал простой пример.
Например:
один HELM деплои App1 у которого только один контейнер с webserver.
один HELM деплои App23 который совсем другой и совсем другие ресурсы.
Единственное, что пока не совсем понятно: в чем главное преимущество перед связкой jenkins+ansible?
Тут Настраиваешь только ArgoCD.
Там настраиваешь и Jenkins и Ansible, плюс Jenkins и Ansible где работают, внутри k8s или снаружи?
Дженкинс на отдельном сервере. У нас просто лоигка CD настроена так, что на стейдже в дженкинс джобе поднимается контейнер с ансиблом:
[...]
Stage("Название этапа" {
agent {
docker {
>
}
}
steps {
sh '''
>
'''
}
}
[...]
и там генерируются манифесты k8s для сервисов, конфигмапы, контейнеры для инициализации сервиса и тд. Не вижу пока как удобно на одном лишь ArgoCD построить нормальный деплой, если у тебя 50 сервисов, где 30-40 переменных окружения и всё это на 4 инстансах в кубере для разных групп разработки. Было бы интересно в видео про ArgoCD этот момент уточнить, потому что здесь ты говоришь, что нужно в ручную манифесты редачить. Мы так не делаем. У нас всё делает Jenkins. Здесь получается, что он нам всё равно будет нужен для сборки приложения, а вот CD процессы уже через ArgoCD настраивать как-то. Но тогда я только вижу вариант, когда джоба в дженкинсе пушит в репу какие-либо файлы, например тот же конфиг мап. И в таком случае смысл в ArgoCD улетучивается, потому что проще уже будет в конце сделать kubectl и применять нужные манифесты, чем использовать серверные ресурсы на доп. ПО.
В общем ощущение, что ArgoCD создан для небольших проектов и маленький компаний, которые не хотят париться над настройкой логики развёртывания с помощью Groovy.@@ADV-IT
Я вижу преимущество в том, что ты хранишь стейт ворклоада в гите и это единственный source of truth. И это не серебряная пуля, а лишь один из подходов, который не является универсально применимым.
И арго это не си сервер, так что каким образом формируются манифесты остается за скобками
@@olegen1 а какая разница truth или не truth? Если у тебя отлаженный проект, то проблем не будет. В реальной жизни каждый запуск сервиса - это запуск init контейнеров, чтобы в случае проблемы на каком либо этапе сервис не стартовал. А после старта liveness и readiness пробы.
Какой смысл в Ansible вообще в данном применении? Jenkins достаточно для деплоя чего угодно в Kubernetes. Точно так же как в случае с ArgoCD будет один источник истины - git репозиторий. Просто в Jenkins немного по-другому будет запускаться деплой в кубер: через плагин, либо вызовом helm с аргументами.
Разница в том что на Jenkins можно реализовать и CI любой сложности, и CD, а ArgoCD для этого не предназначен, как я понял. Только CD, но более "бесшовно" что ли, чем в случае с Jenkins (хотя на нём можно точно так же всё периодическими задачами организовать).
а кроме paypal метод поддержки больше не чего нет ?
Лайк!
Ну и зачем мне на деплой новой версии образа чтото кудато комиттить в гит? У меня ничего кроме тега не изменяется, а это динамический п-р для хелм upgrade
Все изменения в конфигурации должны журналироваться. Это суть принципа IaC. В любой момент можно посмотреть что задеплоено прямо сейчас, кто и когда вносил изменения в конфигурацию - просто заглянув в git репозиторий проекта.
Все ложат на репозиторий😅
Да не скажем мы что это репликасет, всёравно еще не бычим в этих дровах ничего, пока только просмотрели но не проклацали…)
искал медь, а нашёл платину