Архив рубрики: О программировании

Тайна «Debug adapter process has terminated unexpectedly»

vs code

Любопытная история приключилась со мной намедни. Моя основная C# IDE на никсовых системах — Visual Studio Code — внезапно приказала долго жить. Не целиком, а самая полезная её часть — дебаггер. Стоило мне поставить брейкпоинт где-нибудь в коде и запустить проект, как редактор останавливал праздник интеллекта с ошибкой «Debug adapter process has terminated unexpectedly»:

Debug adapter process has terminated unexpectedly

A вот раньше всё работало просто прекрасно. Так как незадолго до проблемы я устанавливал на Убунту сразу несколько новых связанных с дебаггингом утилит (lldbperf и lttng), то естественно подумал, что проблема пришла от них. Но ни их удаление, ни переустановка VS Code целиком не изменили ровным счётом ничего.

В довесок к этому единственная внятная альтернатива VS Code для работы с C# на Linux — JetBrains Rider — тоже косячит. Какие-то проекты она может запустить и дебаггить, какие-то — нет. Те, что мне нужны, например, она даже запустить не может. В общем, не оставалось ничего другого кроме как начать разбираться, кто убил VS Code. Читать далее Тайна «Debug adapter process has terminated unexpectedly»

Отправляем .NET Core метрики в Graphite через StatsD

.NET Core StatsD

Уже прошло больше года с тех пор, как я подключил кусок JavaScript к collectd плагину и начал собирать данные мониторинга с нашей CI, чтобы потом хранить их в Graphite. И знаете что? Оно до сих пор работает. Даже JavaScript’овая часть. Но настали времена, когда мне нужно будет собирать метрики с .NET Core сервисов, и, чувствую, связкой JavaScript + collectd я уже не отделаюсь.

По идее, проблем быть не должно. В Graphite ведь можно отправлять данные хоть по TCP в виде текста, так что сервисы вполне могут заняться этим самостоятельно. Но можно сделать даже ещё проще. Читать далее Отправляем .NET Core метрики в Graphite через StatsD

Тестирование серверов и контейнеров с goss

тестирование серверовНедавно почитывал последний выпуск Technology Radar и нашёл вот какую интересную штуку в разделе новых техник программирования: «разработка контейнеров по TDD». Мдя. Ментально я пока ещё не могу провести соединительную линию между Докером и TDD, но инструменты, которые там упомянуты, оказались достаточно интересными.

Первый — serverspec. С его помощью можно прогонять локальные и удалённые сервера-контейнеры по набору BDD-подобных юнит-тестов. Тулза выглядит вполне зрелой и продуманной, поддерживает не только Linux, и всё было бы хорошо, если бы один огромный косяк (возможно, только для меня): serverspec написан на Ruby, и значит, что он абсолютно не совместим со стеком, в котором я обычно работаю.

Вторая тулза — goss — оставляет впечатление небольшого швейцарского ножика. Вроде и то немного умеет, и это. Обычно я к таким инструментам отношусь настороженно, но… goss какой-то странно прикольный, так что на него хочется посмотреть поближе. Читать далее Тестирование серверов и контейнеров с goss

Профайлинг .NET Core приложения в Linux

flamegraphА тем временем я продолжаю разбираться в том, как дебагить .NET Core приложения в Linux. Теперь я уже более или менее представляю, как анализировать проблемы с памятью, но таких на самом деле у нас не так уж и много. Самая распространённая проблема — загрузка процессора под 100%, и тогда очень, очень хочется понять, чем же это приложение таким занимается.

На Windows я первым делом лезу в логи и трейс-файлы. Когда их не хватает, приходит очередь PerfView, который с огромной частотой сэмплирует приложение, и тогда уже можно посмотреть, сколько потоков сейчас запущено, чем они занимаются, какие самые горячие места, и т. п.

Логи и трейсы, разумеется, существуют и на Linux, но мне было интересно, можно ли на нём профайлить .NET Core примерно так же, как и на Windows. Как оказалось, инструментов почти куча, но применительно к .NET Core основными выглядят три: утилиты perf, lttng  и perfcollect. Вот на них мы сейчас и посмотрим. Читать далее Профайлинг .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Большую часть прошлой недели мне пришлось экспериментировать с виндовым .NET проектом под Linux и в Kubernetes. Это на самом деле не такая уж и дурка, как кажется поначалу. Проект мы заранее перевели на кросс-платформенный .NET Core, я отловил практически все проблемы, которые вплыли в никсе под контейнерами, и по итогу в K8s проект действительно заработал. Почти.

На практике всё равно остались мелкие неприятности. Эпизодически выскакивали всякие StackOverflow (хорошо хоть не segmentation faults), да и мой дебагерский виндовый опыт оказался практически бесполезным на никсах.

Например, практически сразу мы заметили, что, запускаясь под контейнером, проект с ходу отъедал 300 мегабайт физической памяти и около 2-х гигов виртуальной. В виндовом продакшене, конечно, под нагрузкой бывало и на порядки больше, но вот тут, на Linux, в демо-режиме, это много, мало, или вообще как? Как это проверить в принципе? На Винде я бы сделал дамп процесса, запустил Visual Studio или WinDBG и гуглил, что теперь делать дальше. А что тут?

Как выяснилось, гугл под Linux тоже работает, так что через пару часов медитации на монитор я выучил несколько интересных штук, о которых и хотел бы рассказать сегодня. Читать далее Дебаггинг памяти .NET Core приложения в Linux

Однократные задачи в Kubernetes

Задачи в KubernetesПока что все примеры, что я делал для Docker Swarm и Kubernetes постов, строились вокруг какого-нибудь сервиса: веб-сервера, очереди сообщений или шины сообщений. В принципе, оно и не удивительно, весь тот же Docker Swarm построен вокруг концепции сервисов. Да что там Swarm, сами «микро-сервисы», из-за которых мы контейнеры в облака забрасываем, ни о чём не говорят?

Но не всё есть «сервис» в облаках. Есть и эпизодические задачи: рутинное обслуживание, запланированные задачи, конечные вычислительные таски — всё, у чего есть начало и вполне определённый конец.

Читать далее Однократные задачи в Kubernetes

Разбираем Kubernetes пример

Kubernetes пример

К моему глубочайшему удивлению, начиная с прошлой недели Kubernetes стал неотъемлемой частью моей работы. То есть теперь я не просто должен им интересоваться, его нужно ещё и понимать. А с этим, как можно судить по прошлому Kubernetes посту, есть проблемы. Вроде ж и пример тогда простой был, и по всем шагам прошёлся, но всё равно осталось какое-то ощущение недосказанности.

Читать далее Разбираем Kubernetes пример

Автоматическое масштабирование билд-серверов в GitLab CI

автоматическое масштабирование билд-серверов

На своём рабочем проекте Gitlab CI я использую уже где-то с год, и с большего всё было хорошо. Начинали мы с трёх билд-серверов (GitLab раннеров) под проект, а когда в команде появлялись новые люди, пытающиеся валом коммитов удивить начальство, либо билд-задач просто становилось больше, я добавлял ещё один сервак для возросшей нагрузки, и чувствовал себя героем. Но когда количество серверов пошло на второй десяток, то как-то стало понятно, что такой подход больше не работает.

Во-первых, всё равно случались пиковые нагрузки, с которыми билд-кластер справиться не мог. Хотя бы пару раз в неделю были периоды, когда количество билд-задач было раза в два больше, чем сервера могли вытянуть.

Во-вторых, этот зоопарк серверов начал стоить заметных денег, при этом большую часть времени абсолютно ничего не делая: ночные коммиты у нас тут редкость.

В общем, стало ясно, что существующий подход надо на что-то менять. Желательно на что-нибудь динамическое. И что здорово, в GitLab CI -таки встроено автоматическое масштабирование билд-серверов под текущую нагрузку. Её-то мы и будем сегодня пробовать.

Читать далее Автоматическое масштабирование билд-серверов в GitLab CI

Новая игрушка — бессерверное приложение

Способов, как задеплоить своё приложение, становится всё больше и больше. Не успели остыть Докер и его контейнеры, как появилась ещё одна идея: а что, если вместо упаковывания кусков приложения по контейнерам, мы отправим его логику прямиком в облако? Глупость ведь сказал ведь, правда? Но при этом практически у всех крупных провайдеров появилась такая штука как «функция-как-сервис» (FaaS), при помощи которой (а так же объектного хранилища и облачной базы данных) можно собрать полностью работоспособное приложение прямо в облаке — бессерверное приложение.

Конечно, сервер всё-таки где-то будет. Может, даже несколько. Но нас они совершенно не колышут, так как ими и всей инфраструктурой теперь управляет провайдер. Читать далее Новая игрушка — бессерверное приложение

Храним секреты приложения в Vault

HashiCorp Vault

Недавно я тут общался с одним из наших экспертов по безопасности и пытался выбить у него наш супер-секретный сертификат для одного из своих приложений. Но выбить не просто так, а чтобы приложение могло достучаться до сертификата, а я — нет. Вдруг я на тёмную сторону силы подамся. Нетривиальная задача, скажу я вам.

Уже чуть позже, вгугливая, какие вообще есть инструменты для управления секретами, я наткнулся на HashiCorp Vault, и немного прифигел от того, как много вещей, оказывается, надо организовать и знать, чтобы эту задачу решить. Будучи всё ещё под впечатлением, сегодня я решил пройтись по основам Vault и, если получится, показать, насколько интересные решения умные люди нашли на этом поприще.

Читать далее Храним секреты приложения в Vault