Пользователь
Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby...
Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.
Эта история начинается с того, что я попытался переустановить Windows на ноутбуке, доставшемся мне вот с такой наклейкой Certificate of Authenticity (COA): часть символов серийника видны хорошо, остальные – в большей или меньшей степени угадываются; но несколько попыток ввести серийник «на глаз» успехом не увенчались. Пришлось углубляться в вопрос подробнее.
Сегодня хочу поговорить с вами о наболевшем, об обновлениях Microsoft, требующих перезагрузки. Я отношусь к тем, кто обычно устанавливает рекомендуемые на широком канале Windows Update, так как считаю безопасность превыше всего. Однако, перезагрузки безумно напрягают. Не одного меня, конечно. Так сложилось, что Microsoft очень давно разрабатывала технологию установки обновлений без перезагрузок. Мало кто знает, что еще с Windows Server 2003 SP1 была предложена технология HotPatching, позволяющая на лету устанавливать заплатки и библиотеки, не требуя перезагрузки. Правда, почему то, после выхода Windows Server 2003 SP2 выпуск обновлений, не требующих перезагрузок был свёрнут. О подробностях применения горячих обновлений в те древние времена можно почитать тут. Сегодня я расскажу о горячей установке обновлений на Windows Server 2025 и Windows 11 24H2 без всяких подписок. Но давайте по порядку…
С выходом Windows Server 2019 технология была переработана и для издания Windows Server 2019 Datacenter Azure Edition (Core) доставлялись горячие обновления, если машины размещались в Azure. С Windows Server 2022 такая возможность появилась и для версии Windows Server 2022 Datacenter Azure Edition с полным рабочим столом. Но требование издания Azure Edition и размещения в облаках Microsoft никуда не делось. Позже разрешили обновлять без перезагрузок виртуальным машины Azure Edition, развернутые в датацентрах заказчика на кластерах Azure Stack HCI при наличии подписки Azure. Гм, тоже не моя история 😊
На связи Егор из блока поддержки платформы F5, сегодня предлагаем вспомнить основы systemd. Поскольку утилит и возможностей в нем много, а новые функции добавляются регулярно, следить за всем этим может быть непросто, так что начнем с основ.
Systemd — это init процесс, который запускается при загрузке ядра операционной системы linux и его задачей является форкать другие процессы. Информацию о том, какие процессы необходимо исполнить он берет из, так называемых “юнитов” (systemd unit - https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html). Юниты бывают различных типов, каждый из которых выполняет определенную задачу.
Приложению cara.app пришёл счет от Vercel на 96280$. Многие стартапы начинают с Vercel и Firebase, затем из нежелания платить гуглу уходят на свои сервера
Поговорим с нюансами про стэк технологий и оценим усилия на миграцию на свои сервера. Разберём на примере Go с k8s и инфраструктурой мониторинга, но без Firebase (Github)
Есть отличный термин self hosted, который очень популярен в англоязычном интернете.
Но он плохо переводится, почти как open source - хотя википедия и пытается дать ужасно звучащий термин "самохостинг"...
Как ни странно, на Хабре нет про него обзорных статей, и даже нет соответствующего тега, хоть я и искал.Возможно, плохо искал, и вы кинете в комментарии что-то хорошее.
В общем, self hosted - это когда вы решаете, что какие-то вещи лучше хранить у себя, а не отдавать злым корпорациям - фотографии, почту, умный дом, книги, и так далее.
И собираете под это какой-то сервер, полноценным хозяином которого являетесь только вы.
Эту статью я пишу во многом для нескольких друзей, которые решили приобщиться к этому тренду, и здесь будет обзор моего личного self hosted - про всякие разные штуки, которые показались полезны лично мне, и плотно заняли своё место на моём домашнем сервере.
На хабре много опытных пользователей, так что если вам что-то кажется очевидным - смело листайте дальше. Здесь есть много классных подробных статей, которые идут в глубину, а в этой статье я хотел дать общее представление, куда вообще можно копать и что делать.
Несколько лет назад я писал пост о том, как вырастить на гидропонике крайне острый Trinidad Scorpion CARDI. Он, при его живительных 1.2 миллионах единиц Сковилла, на неподготовленных перцеедов производит впечатление эквивалентное облизыванию паяльника.
Пока Монстр плодоносил и радовал в течение нескольких лет, я продумывал более удобный вариант гидропонной установки, который было бы не стыдно показывать в приличном интерьере гостям. Классический вариант “юного гидропониста” из канализационных труб, алюминиевого скотча и вороха булькающих трубочек был с негодованием забракован женой. Я разработал и протестировал несколько прототипов с 3D-печатными элементами, но потом проект был поставлен на паузу.
Окончательно доделать его получилось после того, как внезапно выяснилось, что коллеги тоже фанаты острого. Мы собрались в нашей виртуальной “курилке”, запилили проект со всеми положенными milestone в Asana и начали тестировать. Садитесь поудобнее, сегодня будет лонгрид-оффтопик, про то, как толпа DevOPS из WiseOPS пилила совместный хобби проект для украшения офиса. Да, мы заняты не только работой) А еще я поделюсь подробной инструкцией и файлами для 3D-печати.
Сегодня расскажу про то, как правильно утопить растение, спроектировать прототип и выйти в релиз, даже если твои тестеры очень сильные люди.
Привет, Хабр!
В последние несколько лет все больше и больше людей ищут возможность войти в ИТ или поглубже изучить Linux, повысив уровень своей квалификации. Вместе с тем полноценных обзоров с практическом уклоном по типу «все и сразу» написано не так уж и много (особенно на русском языке).
Главная задача данной статьи – указать начинающим специалистам направление развития, дать ключевые понятия для дальнейшего изучения и показать несколько простых практических приемов. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно сильно упрощен.
Посмотрев видео Анастасии Брюхановой мне очень захотелось найти еще какие то подтверждения наличию вбросов. И я стал думать, что бы сделал бы я сам, если бы мне нужно было сделать вброс. Ну, я бы составил список людей, от которых шли фейковые голоса, сделал бы так, что бы они попали в списки избирателей. Дальше люди или роботы голосовали бы от имени людей по этим спискам.
А значит порядок голосования совпадал бы с порядком регистрации. Вот это гипотезу я и решил проверить.
Недавно мне пришлось, что называется, перебороть себя. Дать доступ на свой любимый сервер некоему чужаку. Он натоптал своими грязными ботинками в моей уютной домашней директории, мацал косматыи лапами мои опрятные скрипты инициализации, рылся в логах, натащил в /opt какого-то барахла непонятно откуда. В общем, вел себя, как у себя дома.
Привет, я Паша из Ozon. В рабочее время занимаюсь тестированием поиска, а по вечерам надеваю маску инди-разработчика. И моя самая частая задача — написать скрипт → залить его на сервер → периодически мониторить, что сервер доступен. Эта статья как раз и будет строиться вокруг последнего пункта.
Вы наверняка в курсе, что существуют Grafana, Prometheus, Kibana, LogDNA и другие инструменты для мониторинга, визуализации и анализа данных. C первыми двумя я вплотную познакомился в Ozon, а про Kibana слышал когда-то давно и только в паре со словом «логи». Чтобы графики в Grafana рисовать — придется штат аналитиков нанять (ба-дум-тсс). Для пет-проекта это перебор, нужно что-то сильно проще (с точки зрения стоимости, простоты настройки и удобства). Ниже расскажу, какие готовые инструменты для мониторинга небольших пет-проектов я нашёл в пучинах интернета, а также оставлю комментарии и рекомендации по использованию.
Последние года 3 я активный пользователь Linux. Мне нравится возможность полной настройки и экспериментов, которые позволяет эта система. Единственным неудобством, на мой взгляд, являлась невозможность сохранить свои изменения в сам LiveCD с системой. Это решалось послеустановочными скриптами, но хотелось сделать уже настроенную под себя систему прямиком в LiveCD. Потратив кучу времени, сил и нервов мне удалось реализовать эту цель. Далее постараюсь описать все шаги подробно, чтобы не оставлять "пустых" мест.
Я прикипел к дистрибутиву Lubuntu, на его примере и опишу кастомизацию, но вы можете использовать мои рекомендации для Debian, Ubuntu (любой редакции), Manjaro. На этих Linux мой алгоритм испробован с успехом. Вероятно с другими ОС он тоже сработает, но сам не проверял.
Приступим.
