Forwarded from DevOps&SRE Library
How to Structure a Terraform Project
https://dev.to/spacelift/how-to-structure-a-terraform-project-1ojn
As exciting as starting a new Terraform project may sound, the first question is where and how we begin. What should be the first file that needs to be created? When the project grows, we realize a few things and learn our lessons about structuring a project in a certain way, but it is too late to put in refactoring efforts.
Various aspects influence the way we manage our Terraform config in a repository. In this post, we will learn about them and discuss a few important strategies and best practices around structuring Terraform project files in an efficient and standardized way.
https://dev.to/spacelift/how-to-structure-a-terraform-project-1ojn
👍2
Forwarded from linkmeup
Я обычно не люблю, когда программисты вещают про сети, но тут прям хорошо. Без заумных слов и чтобы понял даже самый отбитый девопс. Мне кажется, это верный признак того, что автору пришлось усиленно разбираться в теме, перед тем как делать и выходить на публику.
Даже от набросов сетевиков в конце отбился достойно.
https://www.youtube.com/watch?v=-6iWRYkeF14
Даже от набросов сетевиков в конце отбился достойно.
https://www.youtube.com/watch?v=-6iWRYkeF14
YouTube
Сам себе вендор. Внедрение EVPN в VK Cloud / Александр Попов (VK, VK Cloud)
Приглашаем на конференцию HighLoad++ 2025, которая пройдет 6 и 7 ноября в Москве!
Программа, подробности и билеты по ссылке: https://highload.ru/moscow/2025
________
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Highload++…
Программа, подробности и билеты по ссылке: https://highload.ru/moscow/2025
________
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Highload++…
👎5👍4
Forwarded from Уютный IT адочек
Товарищи настраивали web application firewall․ Прислали им новый список айпишников‚ которые надо добавить в whitelist․
Полетел список по процедуре к инженерам‚ те копипастнули и фиганули на прод.
Конечно, всё упало․
А почему упало⁉
Потому что в условно 5 из 200 айпишниках вместо обычной точки использовалась армянская точка․
Будьте внимательнее‚ когда получаете данные! Ну нельзя же спутать
Правда⁉
Вам кажется‚ что вы никогда не попадёте в такую ситуацию⁉
Тогда обратите внимание‚ что в этом тексте нет НИ ОДНОГО стандартного знака препинания!
‚ ‒ это не ,
․ ‒ это не .
и даже вот чёрточки ‒ которые использовались выше - это не дефисы, и даже не тире․
Полетел список по процедуре к инженерам‚ те копипастнули и фиганули на прод.
Конечно, всё упало․
А почему упало⁉
Потому что в условно 5 из 200 айпишниках вместо обычной точки использовалась армянская точка․
Будьте внимательнее‚ когда получаете данные! Ну нельзя же спутать
127։0։0։1
127·0·0·1
127․0․0․1
Правда⁉
Вам кажется‚ что вы никогда не попадёте в такую ситуацию⁉
‚ ‒ это не ,
․ ‒ это не .
и даже вот чёрточки ‒ которые использовались выше - это не дефисы, и даже не тире․
👍3👎2🔥2
Forwarded from запуск завтра
This media is not supported in your browser
VIEW IN TELEGRAM
Дорогие программисты (особенно кто кодит не профессионально и не часто), если не пользовались Cursor — рекомендую попробовать.
Это редактор кода на основе VS Code, в который встроили хорошую поддержку AI. Можно выбирать API из множества провайдеров, он сам корректно добавляет контекст, очень удобно подсвечивает добавления/изменения кода.
Я часто прошу накинуть прототип, который дальше довожу до ума. Можно выделить кусочек кода и попросить в нем что-то поменять.
Лично для меня полезно, потому что я программирую редко и часто не помню интерфейсы библиотек (и даже части синтаксиса), но хорошо понимаю, что хочу получить.
Хорошие фул-тайм программисты говорят, что им полезно как мощный инструмент рефакторинга, который берет на себя рутину.
Я сижу на бесплатном тарифе, больше тяжелых запросов — за 20$ в месяц.
Upd. Коллеги напоминают, что совсем недавно Lex Fridman взял интервью у создателей — занимательный разговор!
Это редактор кода на основе VS Code, в который встроили хорошую поддержку AI. Можно выбирать API из множества провайдеров, он сам корректно добавляет контекст, очень удобно подсвечивает добавления/изменения кода.
Я часто прошу накинуть прототип, который дальше довожу до ума. Можно выделить кусочек кода и попросить в нем что-то поменять.
Лично для меня полезно, потому что я программирую редко и часто не помню интерфейсы библиотек (и даже части синтаксиса), но хорошо понимаю, что хочу получить.
Хорошие фул-тайм программисты говорят, что им полезно как мощный инструмент рефакторинга, который берет на себя рутину.
Я сижу на бесплатном тарифе, больше тяжелых запросов — за 20$ в месяц.
Upd. Коллеги напоминают, что совсем недавно Lex Fridman взял интервью у создателей — занимательный разговор!
👎12👍1
Forwarded from Enabling.team Insights
В конце октября 2024 года вышел 10-й юбилейный отчет Accelerate State of DevOps 2024 от DORA и Google Cloud. Напомним, что исследование Accelerate State of DevOps проводится ежегодно с 2014 года, за 10 лет в исследовании приняли участие свыше 39 тысяч профессионалов по всему миру, работающих в компаниях различных размеров и отраслей. Авторы отчета - команда DORA (DevOps Research and Assessment), которая входит в Google Cloud и состоит из исследователей, архитекторов, консультантов, технических писателей, экспертов по UX и DX. В этом году отчет получился на 120 страниц, мы внимательно изучили новый отчет и подготовили краткий обзор.
Исследование в этом году сфокусировано на таких направлениях и практиках, как применение AI, Platform Engineering, Developer Experience, Transformational leadership и их влиянии на Software delivery performance, Reliability, Product performance, Team и Organizational performance, Productivity и Well-being.
Что интересного мы отметили:
1. В исследовании приняло участие 3000 профессионалов из 3-х основных индустрий Technology (36%), Financial Services (16%) и Retail/E-commerce (9%). Большинство участников (76%) работают в компаниях размером больше 100 сотрудников, 46% в компаниях больше 1000 сотрудников. Инженеров и руководителей практически поровну, 90% FTE (Full-time employee), в среднем имеют 16 лет опыта, 5 лет на текущей роли и 3 года в текущей команде. Участники исследования из 104 стран, топ-6 стран: США, Великобритания, Канада, Германия, Япония, Индия, есть участники из Китая и России;
2. В начале отчета даны хорошие определения ключевым терминам, практикам и метрикам используемым в исследовании, чтобы синхронизировать терминологию;
3. По изменениям в ключевых метриках: в прошлом году Time to Restore Service переименовали в Failed deployment recovery time, в этом - Change failure rate переименовали в Change fail rate и экспериментируют с 5-й метрикой Rework rate, а также изменили концепцию измерения Software Delivery Performance;
4. По изменениям в профилях эффективности команд: соотношение Elite (19%) и Medium (35%) осталось практически без изменений с прошлого года, профиль High сократился на 10%, а Low вырос с 17% до 25%;
5. По изменениям ключевых метрик в профилях: Change fail rate у профилей High вырос с 10% до 20%, у Medium сократился с 15% до 10%, у Low сократился c 64% до 40%. Также у Low профилей Deployment frequency и Change lead time увеличился до 6 месяцев;
6. Приведены результаты исследования применение AI практик и инструментов и их влияние на ключевые метрики, индивидуальную продуктивность и инженерные практики. Этому направлению отведено четверть отчета, отметим хорошо составленный набор задач для которых применяют AI инструменты и анализ доверия к результатам работы AI инструментов;
7. Отдельная секция посвещена Platform Engineering, авторы ссылаются на книгу Team Topologies, опыт компаний Spotify и Netflix, дают хорошее определение: "Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self-service, and repeatability of processes". Исследуют влияние внутренних платформ (Internal developer platform) на индивидуальную и командную продуктивность, на ключевые метрики и результаты в разрезе 1, 2 и 5 лет использования платформ;
8. Исследование затронуло применение продуктового подхода (User-centered approach) в командах, в отчете приведены результаты влияния на Developer Experience и ключевые метрики;
9. Из Transformational Leadership охвачены такие аспекты как: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition и их влияние на Employee burnout, Job satisfaction, Team performance и Organizational performance;
В конце отчета рассмотрена методология, включающая модель исследования, форматы проведения интервью и опросов, примеры гипотез и вопросов, исследуемые инженерные практики, метрики и результаты. Подробнее про результаты исследования читайте в новом отчете Accelerate State of DevOps 2024.
Исследование в этом году сфокусировано на таких направлениях и практиках, как применение AI, Platform Engineering, Developer Experience, Transformational leadership и их влиянии на Software delivery performance, Reliability, Product performance, Team и Organizational performance, Productivity и Well-being.
Что интересного мы отметили:
1. В исследовании приняло участие 3000 профессионалов из 3-х основных индустрий Technology (36%), Financial Services (16%) и Retail/E-commerce (9%). Большинство участников (76%) работают в компаниях размером больше 100 сотрудников, 46% в компаниях больше 1000 сотрудников. Инженеров и руководителей практически поровну, 90% FTE (Full-time employee), в среднем имеют 16 лет опыта, 5 лет на текущей роли и 3 года в текущей команде. Участники исследования из 104 стран, топ-6 стран: США, Великобритания, Канада, Германия, Япония, Индия, есть участники из Китая и России;
2. В начале отчета даны хорошие определения ключевым терминам, практикам и метрикам используемым в исследовании, чтобы синхронизировать терминологию;
3. По изменениям в ключевых метриках: в прошлом году Time to Restore Service переименовали в Failed deployment recovery time, в этом - Change failure rate переименовали в Change fail rate и экспериментируют с 5-й метрикой Rework rate, а также изменили концепцию измерения Software Delivery Performance;
4. По изменениям в профилях эффективности команд: соотношение Elite (19%) и Medium (35%) осталось практически без изменений с прошлого года, профиль High сократился на 10%, а Low вырос с 17% до 25%;
5. По изменениям ключевых метрик в профилях: Change fail rate у профилей High вырос с 10% до 20%, у Medium сократился с 15% до 10%, у Low сократился c 64% до 40%. Также у Low профилей Deployment frequency и Change lead time увеличился до 6 месяцев;
6. Приведены результаты исследования применение AI практик и инструментов и их влияние на ключевые метрики, индивидуальную продуктивность и инженерные практики. Этому направлению отведено четверть отчета, отметим хорошо составленный набор задач для которых применяют AI инструменты и анализ доверия к результатам работы AI инструментов;
7. Отдельная секция посвещена Platform Engineering, авторы ссылаются на книгу Team Topologies, опыт компаний Spotify и Netflix, дают хорошее определение: "Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self-service, and repeatability of processes". Исследуют влияние внутренних платформ (Internal developer platform) на индивидуальную и командную продуктивность, на ключевые метрики и результаты в разрезе 1, 2 и 5 лет использования платформ;
8. Исследование затронуло применение продуктового подхода (User-centered approach) в командах, в отчете приведены результаты влияния на Developer Experience и ключевые метрики;
9. Из Transformational Leadership охвачены такие аспекты как: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition и их влияние на Employee burnout, Job satisfaction, Team performance и Organizational performance;
В конце отчета рассмотрена методология, включающая модель исследования, форматы проведения интервью и опросов, примеры гипотез и вопросов, исследуемые инженерные практики, метрики и результаты. Подробнее про результаты исследования читайте в новом отчете Accelerate State of DevOps 2024.
👍2❤1
Forwarded from Записки админа
🔩 Boot Time Presentations - сборник докладов и выступлений, тема которых так или иначе связана с ускорением загрузки системы.
Материалы представлены в списке от самых свежих - выступлений 2024 года, до самых старых - презентаций 2006 года...
https://elinux.org/Boot_Time_Presentations
#linux #boot #speed
Материалы представлены в списке от самых свежих - выступлений 2024 года, до самых старых - презентаций 2006 года...
https://elinux.org/Boot_Time_Presentations
#linux #boot #speed
👍3
Forwarded from DevOps&SRE Library
Understanding DNS in Kubernetes
https://povilasv.me/understanding-dns-in-kubernetes
In this post, we will cover the following:
- Overview of DNS Resolution and CoreDNS, the default DNS provider in Kubernetes.
- Kubernetes DNS policies, such as ClusterFirst, Default, and None, and their effects on pod DNS configurations.
- Differences between The GNU C Library (glibc) and musl libraries.
https://povilasv.me/understanding-dns-in-kubernetes
Forwarded from PythonDigest
Mount — ещё один способ уменьшения размера Docker-образа
https://ift.tt/i30KPnG
Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby... Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб. Cделали следующее, чтобы сократить размер
https://ift.tt/i30KPnG
Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby... Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб. Cделали следующее, чтобы сократить размер
👍7👎4
Forwarded from PythonDigest
Werkzeug - 3.1.2
https://ift.tt/63TjigP
Швейцарский армейский нож веб-разработки Python. Скачать можно по ссылке: https://pypi.python.org/pypi/Werkzeug/
https://ift.tt/63TjigP
Швейцарский армейский нож веб-разработки Python. Скачать можно по ссылке: https://pypi.python.org/pypi/Werkzeug/
🔥1
Forwarded from linkmeup
Собственно, тут как в анекдоте - два путя.
Первый: ты в курсе, что DNS это не только чОрная магия, но ещё и увлекательный тулинг вокруг, поэтому ржёшь над девопсами, узнавшими про NS1.
Второй: ты никогда не слышал про NS1, route 53 и прочие DNS-сервисы, поэтому в докладе тебя ждёт удивительный мир.
https://www.youtube.com/watch?v=Fa2-CdzY75g
Первый: ты в курсе, что DNS это не только чОрная магия, но ещё и увлекательный тулинг вокруг, поэтому ржёшь над девопсами, узнавшими про NS1.
Второй: ты никогда не слышал про NS1, route 53 и прочие DNS-сервисы, поэтому в докладе тебя ждёт удивительный мир.
https://www.youtube.com/watch?v=Fa2-CdzY75g
YouTube
Артем Мещеряков — Умный DNS: вариации и области применения
Подробнее о конференции DevOops: https://jrg.su/t1mP5U
— —
Скачать презентацию с сайта DevOops — https://jrg.su/dOhbWf
Артем рассказывает о своем пути в область Intelligent DNS и использовании NS1 как провайдера динамически определяемых DNS-записей. Как…
— —
Скачать презентацию с сайта DevOops — https://jrg.su/dOhbWf
Артем рассказывает о своем пути в область Intelligent DNS и использовании NS1 как провайдера динамически определяемых DNS-записей. Как…
👍5🔥2
Forwarded from PythonDigest
PSQLBuddy — резервное копирование и восстановление PostgreSQL
https://ift.tt/pic3CIe
Все мы так или иначе решаем вопросы резервирования наших данных. Но всегда хочется, чтобы думать об этом приходилось как можно меньше, стоило это дешевле, а восстановление было простой задачей. Это я и попытался сделать в своем проекте PSQLBuddy.
https://ift.tt/pic3CIe
Все мы так или иначе решаем вопросы резервирования наших данных. Но всегда хочется, чтобы думать об этом приходилось как можно меньше, стоило это дешевле, а восстановление было простой задачей. Это я и попытался сделать в своем проекте PSQLBuddy.
Forwarded from Технологический Болт Генона
Как-то я пропустил, но тут в сентябре наконец-то выпустили Falco Talon условно стабильной версии.
Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).
Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.
Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293
Ответом на запрос в контексте реагирования появился Falco Talon
Introducing Falco Talon v0.1.0
https://falco.org/blog/falco-talon-v0-1-0/
Если кратко, то как это работает (схематично на первой картинке)
https://docs.falco-talon.org/docs/actionners/list/
Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/
Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.
В посте, где рассказывают про релиз, показан пример со складированием трафика в Amazon S3 (на второй картинке)
GitHub
https://github.com/falcosecurity/falco-talon
Документация
https://docs.falco-talon.org/
Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).
Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.
Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293
Ответом на запрос в контексте реагирования появился Falco Talon
Falco Talon is a Response Engine for managing threats in Kubernetes clusters. It enhances the solutions proposed by the Falco community with a no-code tailor-made solution. With easy rules, you can react to events from Falco in milliseconds.
Introducing Falco Talon v0.1.0
https://falco.org/blog/falco-talon-v0-1-0/
Если кратко, то как это работает (схематично на первой картинке)
Falco ловит событие, которое прокидывается на falco-talon (можно через sidekick). После этого, согласно настроенным actionner выполняется действие. На данный момент список поддерживаемый- kubernetes:terminate
- kubernetes:label
- kubernetes:networkpolicy
- kubernetes:exec
- kubernetes:script
- kubernetes:log
- kubernetes:delete
- kubernetes:drain
- kubernetes:download
- kubernetes:tcpdump
- aws:lambda
- calico:networkpolicy
- cilium:networkpolicy
https://docs.falco-talon.org/docs/actionners/list/
Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/
Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.
В посте, где рассказывают про релиз, показан пример со складированием трафика в Amazon S3 (на второй картинке)
GitHub
https://github.com/falcosecurity/falco-talon
Документация
https://docs.falco-talon.org/
🔥3❤1👍1
Forwarded from запуск завтра
Аналогичная штука для командной строки — Warp. Терминал с нормальной поддержкой AI.
Одну из ключевых идей Юникс можно понять за минуту: каждая программа должна уметь делать только одну вещь и делать её хорошо. Программы можно комбинировать, передавая результат работы первой как входные данные для второй, создавая сколь угодно длинные цепочки.
По сути, ты получаешь в руки набор кубиков Lego и каждый раз собираешь именно ту программу, которую нужна тебе прямо сейчас. Безграничные возможности.
К сожалению, в отличие от деталек Лего, которые различаются только шириной, высотой и длиной, и которые можно окинуть взглядом разложив на столе, Юникс программ огромное множество и особенности их поведения контролируется ключами, которых у каждой могут быть десятки.
Конечно, если проводишь в командной строке весь день — то большинство знаний отпечатываются на подкорке, входят в мышечную память.
Если никогда не чувствовал мощь шелла под своими пальцами, то это, наверное, как рассказывать вкус халвы тому, кто ни разу её не пробовал. И не так грустно, что у тебя ее нет. Но без практики все знания теряются.
Последние годы я часто обнаруживаю себя в ситуации, когда знаю, что задачу можно решить с помощью Шела за пару минут, но трачу полчаса на поиск нужных команд и ключей.
Warp возвращает мне эти знания, а порой подсказывает вещи, которых и я не знал никогда.
—
На практике, вместо написания команд можно нажать шорткат и сказать, что хочешь получить — на английском — и Warp предлагает тебе команду.
При этом у него есть контекст происходящего — что ты делал раньше и каким был результат. Можно прямо сказать «там че-то homebrew ругается, почини». И он чинит!
А ещё у него обычный ввод текста, не readline, так что можно наконец редактировать длинные многострочные команды прямо в нем.
Я сижу на бесплатном тарифе — 100 AI-запросов в месяц, дальше от 15$ в месяц. Пока только для Mac и Linux, Windows версию обещают скоро.
Одну из ключевых идей Юникс можно понять за минуту: каждая программа должна уметь делать только одну вещь и делать её хорошо. Программы можно комбинировать, передавая результат работы первой как входные данные для второй, создавая сколь угодно длинные цепочки.
По сути, ты получаешь в руки набор кубиков Lego и каждый раз собираешь именно ту программу, которую нужна тебе прямо сейчас. Безграничные возможности.
К сожалению, в отличие от деталек Лего, которые различаются только шириной, высотой и длиной, и которые можно окинуть взглядом разложив на столе, Юникс программ огромное множество и особенности их поведения контролируется ключами, которых у каждой могут быть десятки.
Конечно, если проводишь в командной строке весь день — то большинство знаний отпечатываются на подкорке, входят в мышечную память.
Если никогда не чувствовал мощь шелла под своими пальцами, то это, наверное, как рассказывать вкус халвы тому, кто ни разу её не пробовал. И не так грустно, что у тебя ее нет. Но без практики все знания теряются.
Последние годы я часто обнаруживаю себя в ситуации, когда знаю, что задачу можно решить с помощью Шела за пару минут, но трачу полчаса на поиск нужных команд и ключей.
Warp возвращает мне эти знания, а порой подсказывает вещи, которых и я не знал никогда.
—
На практике, вместо написания команд можно нажать шорткат и сказать, что хочешь получить — на английском — и Warp предлагает тебе команду.
При этом у него есть контекст происходящего — что ты делал раньше и каким был результат. Можно прямо сказать «там че-то homebrew ругается, почини». И он чинит!
А ещё у него обычный ввод текста, не readline, так что можно наконец редактировать длинные многострочные команды прямо в нем.
Я сижу на бесплатном тарифе — 100 AI-запросов в месяц, дальше от 15$ в месяц. Пока только для Mac и Linux, Windows версию обещают скоро.
👎15👍6
Forwarded from DevOps Deflope News
Долгожданный релиз containerd 2.0 предлагает множество новых функций, включая поддержку плагинов для проверки образов и интеграцию с OpenTelemetry. Это первое мажорное обновление с 2017 года.
samuel.karp.dev
containerd 2.0 (and KubeCon NA 2024)
The containerd maintainers (including me) are happy to announce the release of containerd 2.0! This is the first major release of containerd since 1.0 was released in 2017, and represents a committment both to the evolution of the containerd project and continued…
🔥15
Forwarded from HABR FEED + OPENNET
Проверка готовности приложения к работе в реальном ненадежном мире. Часть 2 #habr
https://habr.com/ru/companies/slurm/articles/857144/
Tags: go, golang, приложение, tutorial
Author: Hedgehog_art (Слёрм)
https://habr.com/ru/companies/slurm/articles/857144/
Tags: go, golang, приложение, tutorial
Author: Hedgehog_art (Слёрм)
Хабр
Проверка готовности приложения к работе в реальном ненадежном мире. Часть 2
Вторая часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий...
👍1
Forwarded from Go Library
👎1
Forwarded from DevOps FM
В своем блоге Адольфо поделился опытом работы с dockerfileless-образами контейнеров. Два главных урока, которые вы можете вынести из статьи:
1. It is a true pain to deal with OCI images manually.
2. Рeeking under the hood of container images will not void your warranty, and is a great way to get a better idea of what an OCI image actually is.
#devops #docker #контейнеры
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥4
Forwarded from DevOpsConf Channel
Ops или Engineering?
Новый, с пылу, с жару выпуск подкаста с Игорем Курочкиным — членом Программного комитета DevOpsConf 2025. Обсуждали DevOps и развитие инжиниринговых практик.
Говорили бодро, также обсуждали NextOps, который не то, чем кажется! Вспомнили массу приятных книг и не только.
Слушайте 321 подкаст The Art of Programming🔄
iTunes
ВКонтакте
Яндекс Музыка
🖐️ CFP на DevOpsConf 2025 открыт
П.С. Cut-Cut 321. Ops или Engineering? тут.
Новый, с пылу, с жару выпуск подкаста с Игорем Курочкиным — членом Программного комитета DevOpsConf 2025. Обсуждали DevOps и развитие инжиниринговых практик.
Говорили бодро, также обсуждали NextOps, который не то, чем кажется! Вспомнили массу приятных книг и не только.
Слушайте 321 подкаст The Art of Programming
iTunes
ВКонтакте
Яндекс Музыка
🖐️ CFP на DevOpsConf 2025 открыт
П.С. Cut-Cut 321. Ops или Engineering? тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1👎1
Forwarded from DevOps Deflope News
Вышел Jaeger v2. Новая версия интегрирует OpenTelemetry и предлагает пользователям улучшенные возможности обработки данных и упрощённое развёртывание: https://goo.su/GuMQln
👍2
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 11. Сравнение видов многозадачности
В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.
Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.
Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.
Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).
Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.
Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.
А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊
На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇
В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.
Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.
Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.
Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).
Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.
Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.
А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊
На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇