Всем привет!
Чтобы после моей предыдущей статьи о тестировании пайплайнов Jenkins не сложилось впечатления, что проблем нет и провалидированный IDEA, скомпилированный и оттестированный JUnit и Pipeline Unit тестами код сразу заработает в Jenkins - вот три больших ложки дегтя. Уточню, речь про scripted pipeline.
1) CPS. Детально что это за зверь написано тут https://www.jenkins.io/doc/book/pipeline/cps-method-mismatches/
Суть в том, что при выполнении код пайпа интерпретируется специальным образом, чтобы в любой момент на диске лежал актуальный слепок текущего состояния пайпа и можно было восстановить состояние после рестарта Jenkins. К слову, по моему опыту это не всегда работает, возможно пайпы кривые, возможно есть проблемы с плагинами. При этом далеко не весь вызываемый в runtime код можно так трасформировать, т.е. весь код делится на CPS и NonCPS. Не трансформируется Java standart library код, конструкторы и методы, помеченные @NonCPS. И есть правило - NonCPS код не может вызывать CPS код.
На модульном тесте это проверить невозможно, функционал PipelineUnit для этого по факту не работает.
2) Groovy DSL. Код пишется не на Groovy, а на Groovy DSL, а это две большие разницы) ну может не совсем большие, но точно разницы. Т.е. почитав доки по Groovy ты видишь там разные крутые фичи, думаешь - о, а у него есть плюсы по сравнению в Java, пробуешь их использовать - и облом. Вот некоторые примеры:
а) не работает with
б) не работают traits
в) не работает ссылка на метод через .& - используем {}. В принципе это даже более Groovish, но факт остается фактом
г) переопределять методы enum в пайпе нельзя https://issues.jenkins.io/browse/JENKINS-48722
д) использовать @MapConstructor тоже нельзя https://issues.jenkins.io/browse/JENKINS-45901
е) без аннотации map constructor тоже не работает
Как видно, на некоторые проблемы заведены баги, которые не решаются годами. Подозреваю, по двум причинам - разработчики фокусируются на declarative pipeline и трудоемкость исправления
3) Sandbox. В целях безопасности на большинстве нормально настроенных Jenkins включен режим Sandbox https://www.jenkins.io/doc/book/managing/script-approval/
Суть в том, что код запускается в песочнице, где разрешен вызов методов по whilelist. Есть возможность добавить в whitelist новые методы, но нужно апрувить каждый (!) метод. В зависимости от типа среды и компании это может быть трудоемко. Предположим, решили вы использовать новый Java DataTime API, написали 10 строк кода, вызвали пяток метод и все пять приходится апрувить. И узнаешь об этом также только когда выполнение кода дошло до нужного метода.
По моему опыту именно на разруливание этих трех проблем тратится максимум времени при отладке пайпа.
#devops #jenkins #unittest #debug
Чтобы после моей предыдущей статьи о тестировании пайплайнов Jenkins не сложилось впечатления, что проблем нет и провалидированный IDEA, скомпилированный и оттестированный JUnit и Pipeline Unit тестами код сразу заработает в Jenkins - вот три больших ложки дегтя. Уточню, речь про scripted pipeline.
1) CPS. Детально что это за зверь написано тут https://www.jenkins.io/doc/book/pipeline/cps-method-mismatches/
Суть в том, что при выполнении код пайпа интерпретируется специальным образом, чтобы в любой момент на диске лежал актуальный слепок текущего состояния пайпа и можно было восстановить состояние после рестарта Jenkins. К слову, по моему опыту это не всегда работает, возможно пайпы кривые, возможно есть проблемы с плагинами. При этом далеко не весь вызываемый в runtime код можно так трасформировать, т.е. весь код делится на CPS и NonCPS. Не трансформируется Java standart library код, конструкторы и методы, помеченные @NonCPS. И есть правило - NonCPS код не может вызывать CPS код.
На модульном тесте это проверить невозможно, функционал PipelineUnit для этого по факту не работает.
2) Groovy DSL. Код пишется не на Groovy, а на Groovy DSL, а это две большие разницы) ну может не совсем большие, но точно разницы. Т.е. почитав доки по Groovy ты видишь там разные крутые фичи, думаешь - о, а у него есть плюсы по сравнению в Java, пробуешь их использовать - и облом. Вот некоторые примеры:
а) не работает with
б) не работают traits
в) не работает ссылка на метод через .& - используем {}. В принципе это даже более Groovish, но факт остается фактом
г) переопределять методы enum в пайпе нельзя https://issues.jenkins.io/browse/JENKINS-48722
д) использовать @MapConstructor тоже нельзя https://issues.jenkins.io/browse/JENKINS-45901
е) без аннотации map constructor тоже не работает
Как видно, на некоторые проблемы заведены баги, которые не решаются годами. Подозреваю, по двум причинам - разработчики фокусируются на declarative pipeline и трудоемкость исправления
3) Sandbox. В целях безопасности на большинстве нормально настроенных Jenkins включен режим Sandbox https://www.jenkins.io/doc/book/managing/script-approval/
Суть в том, что код запускается в песочнице, где разрешен вызов методов по whilelist. Есть возможность добавить в whitelist новые методы, но нужно апрувить каждый (!) метод. В зависимости от типа среды и компании это может быть трудоемко. Предположим, решили вы использовать новый Java DataTime API, написали 10 строк кода, вызвали пяток метод и все пять приходится апрувить. И узнаешь об этом также только когда выполнение кода дошло до нужного метода.
По моему опыту именно на разруливание этих трех проблем тратится максимум времени при отладке пайпа.
#devops #jenkins #unittest #debug
Pipeline CPS Method Mismatches
Jenkins – an open source automation server which enables developers around the world to reliably build, test, and deploy their software
Всем привет!
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Bandlem
Git Tip of the Week: Git Notes - AlBlue’s Blog
Git Tip of the Week: Git Notes
Gtotw
2011
Git
Th...
Gtotw
2011
Git
Th...
Всем привет!
Читаю сейчас книжку "Release it! Проектирование и дизайн для тех, кому не все равно". Несмотря на то, что книге 15 лет, полезного много.
Сегодня хочу поднять одну интересную мысль:
файлы конфигурации для сопровождения - это как UI или API для пользователей приложения. Но если UI проектирует дизайнер, API тоже проектируют, ну я на это надеюсь по крайней мере), то на файлы конфигурации часто забивают.
А это риски для ПРОМа.
Что нужно делать:
1) Infrastructure As Code - хранить конфигурацию в git
2) разделять стендозависимую и постоянную конфигурацию, чтобы случайно не поменять что-то важное для корректной работы сервиса. Также имеет смысл разделить настройки для разных компонентов системы, пользовательские и настройки стенда.
3) убрать дублирование, все тот же принцип DRY - Don't Repeat Yourself
4) не забывать чистить конфигурацию от неиспользуемых параметров
5) наименование параметров должно отвечать на вопрос "зачем", а не "что"
6) нужен инструмент для сравнения конфигураций - на разных стендах, в дистрибутиве и на стенде.
Про книжку напишу подробнее.
#configuration #support #devops
Читаю сейчас книжку "Release it! Проектирование и дизайн для тех, кому не все равно". Несмотря на то, что книге 15 лет, полезного много.
Сегодня хочу поднять одну интересную мысль:
файлы конфигурации для сопровождения - это как UI или API для пользователей приложения. Но если UI проектирует дизайнер, API тоже проектируют, ну я на это надеюсь по крайней мере), то на файлы конфигурации часто забивают.
А это риски для ПРОМа.
Что нужно делать:
1) Infrastructure As Code - хранить конфигурацию в git
2) разделять стендозависимую и постоянную конфигурацию, чтобы случайно не поменять что-то важное для корректной работы сервиса. Также имеет смысл разделить настройки для разных компонентов системы, пользовательские и настройки стенда.
3) убрать дублирование, все тот же принцип DRY - Don't Repeat Yourself
4) не забывать чистить конфигурацию от неиспользуемых параметров
5) наименование параметров должно отвечать на вопрос "зачем", а не "что"
6) нужен инструмент для сравнения конфигураций - на разных стендах, в дистрибутиве и на стенде.
Про книжку напишу подробнее.
#configuration #support #devops
Forwarded from Я-HR
https://youtu.be/pWSUBdxq568
Брюс Эккель Философия java
https://kotlinlang.org/docs/getting-started.html
Канал Дениса: https://t.me/javaKotlinDevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Java&Kotlin&Devops
Java&Kotlin&Devops
Приглашенный эксперт: Денис Орехов
Подписывайся на Дениса: https://t.me/javaKotlinDevOps
#1c #java #kotlin #devops #ЯHR #КристинаОрехова #ДенисОрехов
Приглашенный эксперт: Денис Орехов
Подписывайся на Дениса: https://t.me/javaKotlinDevOps
#1c #java #kotlin #devops #ЯHR #КристинаОрехова #ДенисОрехов
Всем привет!
Есть такая шутка: в мире существует 10 конкурирующих фреймворков, делающих что-то полезное. Дайте сделаем один, самый лучший, который заменит их всех! ... Прошло время. У нам 11 конкурирующих фреймворков)))
Работает часто, хотя бывают исключения: k8s, Docker.
И работает не только для технологий, но и для методологий.
Если почитать книжки или статьи по DevOps, то ключевая мысль: DevOps - это совместная работа у Dev и Ops, общие цели, и в результате мы снимаем противоречия между Dev и Ops. Да, стоит добавить, что аббревиатура некоректна и в ней забыли как минимум тестировщиков и безопасников.
Что у нас по факту? К командам Dev и Ops добавляется команда DevOps, а число источников проблем возврастает до 3: Dev vs Ops, Dev vs DevOps, Ops vs DevOps )))
#devops
Есть такая шутка: в мире существует 10 конкурирующих фреймворков, делающих что-то полезное. Дайте сделаем один, самый лучший, который заменит их всех! ... Прошло время. У нам 11 конкурирующих фреймворков)))
Работает часто, хотя бывают исключения: k8s, Docker.
И работает не только для технологий, но и для методологий.
Если почитать книжки или статьи по DevOps, то ключевая мысль: DevOps - это совместная работа у Dev и Ops, общие цели, и в результате мы снимаем противоречия между Dev и Ops. Да, стоит добавить, что аббревиатура некоректна и в ней забыли как минимум тестировщиков и безопасников.
Что у нас по факту? К командам Dev и Ops добавляется команда DevOps, а число источников проблем возврастает до 3: Dev vs Ops, Dev vs DevOps, Ops vs DevOps )))
#devops
Всем привет!
Нашел хорошую статью-боль https://habr.com/ru/articles/739452/
Она как бы про DevOps, но на самом деле нет - точно такая же проблема есть у разработчиков, тестировщиков, сопровождения.
Корень проблемы на мой взгляд - то, что в ИТ многие пришли из других специальностей, не изучая Computer Science - базовые алгоритмы, устройство процессора, памяти, сетей, файловой системы. Либо из такого ВУЗа, который преподает по "советским" лекалам - т.е. устаревшую информацию.
Потому что если ты эти знания не получил в ВУЗе, то нужно желание учиться и годы опыта. Я, если что, пошел по второму пути)
А если нет ни базового образования, ни желания разбираться - получается узкий специалист, который "сломается" на первой же более менее сложной проблеме. А проблемы кто-то должен решать... и за это платят деньги)
P.S. 943 коммента показывают актуальность темы)
#computer_science #найм #devops
Нашел хорошую статью-боль https://habr.com/ru/articles/739452/
Она как бы про DevOps, но на самом деле нет - точно такая же проблема есть у разработчиков, тестировщиков, сопровождения.
Корень проблемы на мой взгляд - то, что в ИТ многие пришли из других специальностей, не изучая Computer Science - базовые алгоритмы, устройство процессора, памяти, сетей, файловой системы. Либо из такого ВУЗа, который преподает по "советским" лекалам - т.е. устаревшую информацию.
Потому что если ты эти знания не получил в ВУЗе, то нужно желание учиться и годы опыта. Я, если что, пошел по второму пути)
А если нет ни базового образования, ни желания разбираться - получается узкий специалист, который "сломается" на первой же более менее сложной проблеме. А проблемы кто-то должен решать... и за это платят деньги)
P.S. 943 коммента показывают актуальность темы)
#computer_science #найм #devops
Хабр
Я — айтишник, я не хочу много знать
За последнее время мне довелось провести немало технических собеседований на позицию DevOps инженера, в связи с чем появилась идея формализовать полученные выводы в этой статье. Хочу поделиться своими...
Всем привет!
Хочется сказать пару слов о практике T-Shape. Это когда помимо своей основной специальности - например, разработки, ты развиваешь навыки в чем-то еще. Какие именно - если рассмотреть состав типовой команды, то это будут аналитик или тестировщик. Если смотреть дальше - это могут быть DevOps, НТ. Даже может быть сопровождение ПРОМа. Насколько я знаю, такая практика применяется в лидере российского ИТ - Яндексе. Рассмотрим плюсы и минусы на примере разработчика-тестировщика.
Плюсы в целом очевидны:
1) взаимозаменяемость членов команды
2) упрощение найма за счет унификации
Но есть и минусы.
1) суть работы тестировщика - найти проблемы в коде, рассматривая его как черный ящик. Именно потому, что тестировщик не знает, что внутри, но знает, как оно должно работать - ему удается найти те баги, которые не увидел разработчик. У которого просто замылился глаз, т.к. код он знает, он его проектировал, рефакторил, отлаживал. По тому же принципу, к слову, работает ручное код-ревью. Код-ревью и тестирование можно рассматривать как 2 последовательных рубежа обороны. Конечно, можно ввести практик: код пишет один разраб, а тестирует обязательно другой. Но это уже усложнение и влияние человеческого фактора.
2) как я вижу развитие инженерных специальностей и ИТ в частности - все развиваются в сторону более узкой специализации. Да, любую технологию, фреймворк, библиотеку или платформу можно изучить. Проблема в том, что их очень много. Много и в разработке, и в тестировании. И "распыляя" свои усилия на 2 направления есть риск полноценно не научится ни тому, ни другому.
3) этот пункт субъективный из-за того, что я разработчик. Сравнивая разработку и тестирование как две области деятельности я бы всегда выбирал разработку. IMHO, подчеркну, что INHO, она сложнее, имеет больше направлений и поэтому интереснее. Отсюда риск, что на тестирование будет выделяться меньше времени. Вопрос в уровне инженерной культуры и дисциплине, но это снова человеческий фактор. В каких-то командах баланс будет найден, в каких-то нет и в итоге мы получим недотестированный код и баги ПРОМа.
Итог - практика интересная, но требует высокой инженерной культуры в компании и подвержена рисками человеческого фактора.
#t_shape #devops #testing #dev
Хочется сказать пару слов о практике T-Shape. Это когда помимо своей основной специальности - например, разработки, ты развиваешь навыки в чем-то еще. Какие именно - если рассмотреть состав типовой команды, то это будут аналитик или тестировщик. Если смотреть дальше - это могут быть DevOps, НТ. Даже может быть сопровождение ПРОМа. Насколько я знаю, такая практика применяется в лидере российского ИТ - Яндексе. Рассмотрим плюсы и минусы на примере разработчика-тестировщика.
Плюсы в целом очевидны:
1) взаимозаменяемость членов команды
2) упрощение найма за счет унификации
Но есть и минусы.
1) суть работы тестировщика - найти проблемы в коде, рассматривая его как черный ящик. Именно потому, что тестировщик не знает, что внутри, но знает, как оно должно работать - ему удается найти те баги, которые не увидел разработчик. У которого просто замылился глаз, т.к. код он знает, он его проектировал, рефакторил, отлаживал. По тому же принципу, к слову, работает ручное код-ревью. Код-ревью и тестирование можно рассматривать как 2 последовательных рубежа обороны. Конечно, можно ввести практик: код пишет один разраб, а тестирует обязательно другой. Но это уже усложнение и влияние человеческого фактора.
2) как я вижу развитие инженерных специальностей и ИТ в частности - все развиваются в сторону более узкой специализации. Да, любую технологию, фреймворк, библиотеку или платформу можно изучить. Проблема в том, что их очень много. Много и в разработке, и в тестировании. И "распыляя" свои усилия на 2 направления есть риск полноценно не научится ни тому, ни другому.
3) этот пункт субъективный из-за того, что я разработчик. Сравнивая разработку и тестирование как две области деятельности я бы всегда выбирал разработку. IMHO, подчеркну, что INHO, она сложнее, имеет больше направлений и поэтому интереснее. Отсюда риск, что на тестирование будет выделяться меньше времени. Вопрос в уровне инженерной культуры и дисциплине, но это снова человеческий фактор. В каких-то командах баланс будет найден, в каких-то нет и в итоге мы получим недотестированный код и баги ПРОМа.
Итог - практика интересная, но требует высокой инженерной культуры в компании и подвержена рисками человеческого фактора.
#t_shape #devops #testing #dev
Всем привет!
Когда заходит речь о разделении обязанностей между разработчиками и DevOps споры возникают в двух моментах - манифесты k8s\Openshift и CI джобы - они же джобы сборки.
Поговорим про первые.
Мое мнение - за манифесты k8s\Openshift должны отвечать разработчики. Почему? А вот почему:
1) liveness\readiness probes - только разработчики знают, по каким URL они находятся. Конечно в мире Spring Boot и Actuator есть некая стандартизация, но не везде и не всегда. Не всегда actuator подходит для healthcheck, но это отдельная тема
2) liveness\readiness timeouts - разработчики точно знают сколько времени старт пода. DevOps-ы могут это время эмпирически определить, но это требует времени)
3) timeouts, circuit breaker, retry - опять же только разработчики могут сказать, реализовали они их на прикладном уровне или требуется настройка на уровне Service Mesh. Могут быть требования корпоративной архитектуры\сопровождения ПРОМ, их определяющие, но опять же не везде и не всегда.
4) куда пишутся логи, какие существуют метрики, где их можно взять. Снова можно повториться, что где-то это стандартизировано, где-то нет.
5) любые другие тонкие облачные настройки - переменные среды, значение параметров в ConfigMap, поддержка graceful shutdown ....
Наверняка DevOps или сопровожденец со всем этим разберется. Но будет ли это эффективно?
#dev #devops
Когда заходит речь о разделении обязанностей между разработчиками и DevOps споры возникают в двух моментах - манифесты k8s\Openshift и CI джобы - они же джобы сборки.
Поговорим про первые.
Мое мнение - за манифесты k8s\Openshift должны отвечать разработчики. Почему? А вот почему:
1) liveness\readiness probes - только разработчики знают, по каким URL они находятся. Конечно в мире Spring Boot и Actuator есть некая стандартизация, но не везде и не всегда. Не всегда actuator подходит для healthcheck, но это отдельная тема
2) liveness\readiness timeouts - разработчики точно знают сколько времени старт пода. DevOps-ы могут это время эмпирически определить, но это требует времени)
3) timeouts, circuit breaker, retry - опять же только разработчики могут сказать, реализовали они их на прикладном уровне или требуется настройка на уровне Service Mesh. Могут быть требования корпоративной архитектуры\сопровождения ПРОМ, их определяющие, но опять же не везде и не всегда.
4) куда пишутся логи, какие существуют метрики, где их можно взять. Снова можно повториться, что где-то это стандартизировано, где-то нет.
5) любые другие тонкие облачные настройки - переменные среды, значение параметров в ConfigMap, поддержка graceful shutdown ....
Наверняка DevOps или сопровожденец со всем этим разберется. Но будет ли это эффективно?
#dev #devops
Всем привет!
В продолжение предыдущего поста попробую сам себе возразить.
Предположим, что наши DevOps инженеры так круто настроили pipeline, что все атрибуты, которые должен настроить разработчик, параметризованы и могут быть легко настроены разработчиком. Например, с помощью чартов Helm. Хотя по большому счёту не важно.
Значит ли это, что разработчик может расслабиться и не изучать все эти ваши Deployment, Service, EnvoyFilter, VirtualService и прочие? Мой ответ - нет. И вот почему.
1) если рассуждать дальше, то и Docker разработчику не нужен. Пусть его же DevOps-ы настраивают. А я на Tomcat встроенном запущу. Но вспомним в чем суть Docker - единая среда у разработчиков, тестировщиков и ПРОМа. Что позволяет избежать большой части ошибок, возникающих из-за разницы настроек окружения. Не всех, но большого числа
2) окей, Docker пусть будет. А k8s? Но идея та же. Приложение в облаке ведёт себя по другому, чем в standalone. Его может в любой момент прибить k8s и поднять на другой node. А это ограничивает возможности локального кэширования. В облаке несколько приложений может работать параллельно. Это нужно учитывать, например, при чтении из топика Kafka. Более того число подов может меняться - см. HorizontalPodAutoscaler. Еще момент - по умолчанию у нас ephemeral storage и надеятся на то, что те же логи сохранятся после перезапуска, нельзя. Ещё момент - одно из Cloud Native требований - быстрый старт приложения, опять же из-за потенциального перезапуска в любой момент. На этот момент не всегда обращают внимание, хотя варианты улучшения времени запуска есть, см. серию постов выше. И это я вспомнил навскидку, возможно что-то ещё упустил.
Надеюсь, я вас убедил. Если нет - жду в комментах)
#dev #devops
В продолжение предыдущего поста попробую сам себе возразить.
Предположим, что наши DevOps инженеры так круто настроили pipeline, что все атрибуты, которые должен настроить разработчик, параметризованы и могут быть легко настроены разработчиком. Например, с помощью чартов Helm. Хотя по большому счёту не важно.
Значит ли это, что разработчик может расслабиться и не изучать все эти ваши Deployment, Service, EnvoyFilter, VirtualService и прочие? Мой ответ - нет. И вот почему.
1) если рассуждать дальше, то и Docker разработчику не нужен. Пусть его же DevOps-ы настраивают. А я на Tomcat встроенном запущу. Но вспомним в чем суть Docker - единая среда у разработчиков, тестировщиков и ПРОМа. Что позволяет избежать большой части ошибок, возникающих из-за разницы настроек окружения. Не всех, но большого числа
2) окей, Docker пусть будет. А k8s? Но идея та же. Приложение в облаке ведёт себя по другому, чем в standalone. Его может в любой момент прибить k8s и поднять на другой node. А это ограничивает возможности локального кэширования. В облаке несколько приложений может работать параллельно. Это нужно учитывать, например, при чтении из топика Kafka. Более того число подов может меняться - см. HorizontalPodAutoscaler. Еще момент - по умолчанию у нас ephemeral storage и надеятся на то, что те же логи сохранятся после перезапуска, нельзя. Ещё момент - одно из Cloud Native требований - быстрый старт приложения, опять же из-за потенциального перезапуска в любой момент. На этот момент не всегда обращают внимание, хотя варианты улучшения времени запуска есть, см. серию постов выше. И это я вспомнил навскидку, возможно что-то ещё упустил.
Надеюсь, я вас убедил. Если нет - жду в комментах)
#dev #devops
Всем привет!
Минутка философии на канале. Если почитать идеологов DevOps, он не про инструменты, а про взаимодействие. Взаимодействие Dev и Ops. А отдельная команда DevOps, если и существует, то для разработки тех самых инструментов, которыми пользуются Dev и Ops. И тогда релизный процесс улучшается, скорость реакции на инциденты растёт.
Рассмотрим обратный случай — типичный, к слову. Есть команда DevOps, она настраивает стенды и пайплайны, которыми пользуются Ops. Какой будет эффект? Вообще говоря, разный, зависит от степени взаимодействия команд. Но вполне может быть, что с появлением команды DevOps процессы только замедлятся. Ops во всём надеются на DevOps. При любой проблеме Ops идёт к DevOps, Dev при этом получает информацию посредством испорченного телефона или вообще не получает. И наоборот, в случае с тестовыми стендами. Грусть, печаль, баги прома.
#devops
Минутка философии на канале. Если почитать идеологов DevOps, он не про инструменты, а про взаимодействие. Взаимодействие Dev и Ops. А отдельная команда DevOps, если и существует, то для разработки тех самых инструментов, которыми пользуются Dev и Ops. И тогда релизный процесс улучшается, скорость реакции на инциденты растёт.
Рассмотрим обратный случай — типичный, к слову. Есть команда DevOps, она настраивает стенды и пайплайны, которыми пользуются Ops. Какой будет эффект? Вообще говоря, разный, зависит от степени взаимодействия команд. Но вполне может быть, что с появлением команды DevOps процессы только замедлятся. Ops во всём надеются на DevOps. При любой проблеме Ops идёт к DevOps, Dev при этом получает информацию посредством испорченного телефона или вообще не получает. И наоборот, в случае с тестовыми стендами. Грусть, печаль, баги прома.
#devops