Bash Days | Linux | DevOps

Вот те на!

if [ false ]; then echo "HELP"; fi

Большинство думает, что [ — это часть команды if как скобки в других языках программирования. Но нихуя! ㅤ В Bash if просто запускает команду. Команда [ ... ] — это обычный бинарник, аналогично команде test, а не специальный синтаксис. Скобка ] нужна только для красоты и завершения команды [. Команда выше напечатает HELP, потому что строка "false" — непустая, а значит, условие считается истинным. Теперь о главном Если хочешь использовать grep в if, не надо писать скобки! Плохая практика:

if [ grep -q "foo" myfile ]; then
  echo "Найдено!"
fi

[... ] — ожидает условие, а не команду grep — это команда, а не логическое выражение Внутри [ запускать команды нельзя — это приведёт к ошибке Хорошая практика:

if grep -q "foo" myfile; then
  echo "Найдено!"
fi

if просто запускает grep Если grep нашёл совпадение, он вернёт 0 (успех), и выполнится then И Всё работает как надо, без лишних скобок! [ — это как калькулятор, а grep — это поиск. В калькуляторе искать бесполезно! Выводы Никогда не пиши if [ grep ... ] — это ошибка! Пиши просто if grep ..., чтобы проверить результат команды. if работает с командами. [ — это тоже команда, но не синтаксис. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

Ваша инфраструктура — ваш код. Готовы управлять ею правильно? GitOps — это способ автоматизировать управление приложениями в Kubernetes, минимизировать ошибки и ускорить развертывание. ⏺На открытом уроке «Управление приложениями в Kubernetes» 03.04.2025 в 20:00 мы разберем ключевые команды, работу с YAML-манифестами и научимся эффективно управлять приложениями в Kubernetes. Записывайтесь на вебинар и получите гарантированную скидку на курс «GitOps»: https://vk.cc/cKhZRm Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Продолжаем делать правильно. ㅤ Этот код выглядит вполне нормально:

grep foo bar.txt | while read -r; do ((count++)); done

Он считает, сколько строк в файле bar.txt содержат слово foo. Здесь главная проблема — переменная count не изменится вне цикла while, потому что в Bash каждая команда в пайплайне (|) запускается в отдельной оболочке (subshell). То есть count++ происходит «внутри», и снаружи этого не видно. Если простым языком: Каждая часть, разделённая |, запускается в отдельной «коробке» (subshell). То есть while работает внутри своей коробки. B всё что там происходит, не видно снаружи.

Некоторые оболочки ksh93 или Bash с включённой настройкой shopt -s lastpipe работают по-другому — цикл выполняется в той же оболочке, и тогда count изменится.

count=0
echo -e "one\ntwo\nthree" | while read line; do ((count++)); done
echo $count

Этот код вернет 0, несмотря на count++, а вот например в zsh вернется 3. Как быть? Первый вариант:

shopt -s lastpipe

Эта штука говорит интерпретатору — что последний элемент конвейера будет выполнен в окружении текущей оболочки. Второй вариант: Вообще избавиться от while и всё сделать через grep:

count=$(grep -c foo bar)
echo $count

Можно еще наколхозить и передавать значения через временный файл, но это прям пиздец шляпа и костыль. Выводы Нужно просто посчитать строки:

count=$(grep -c foo bar)

Нужно обрабатывать строки:

while read line; do ...; done < bar

Хочешь использовать pipe:

shopt -s lastpipe

Вот и вся наука. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

😱 Вся правда о рынке труда: как стать востребованным Linux-администратором 👉 Хотите попасть в IT и стать востребованным специалистом, но не знаете, с чего начать? Подходящий момент настал. Открытый вебинар 2 апреля в 20:00 мск расскажет вам не только о том, какие специалисты по Linux актуальны сегодня, но и о том, как выгодно выделиться среди тысяч кандидатов. На уроке разберем: - Какие Linux-специалисты на пике спроса и что от них ожидают работодатели. - Как составить резюме, которое не пройдет незамеченным. - Какие навыки критичны для начинающего админа. - Как правильно выстроить карьеру и не потеряться в океане вакансий. 📝 Реальные тренды, практичные рекомендации и шаги, которые помогут вам получить работу мечты. 🎁 Участники вебинара получат скидку на большое обучение «Administrator Linux. Basic». 👉 Для участия зарегистрируйтесь: https://vk.cc/cKfcWd Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Если написать так [[ $foo > 7 ]], то далеко не факт что это правильно отработает. ㅤ Двойные скобки [[ ... ]] в Bash предназначен для проверки условий, но не для работы с числами. Для чисел лучше хуячить (( ... )). ➡️ Бест-практика

(( foo > 7 ))

А если хочется прям строго соответствовать POSIX, делай так:

[ "$foo" -gt 7 ]

Теперь давай разберемся почему с [[ $foo > 7 ]] словишь ошибку. Символ > в [[ ... ]] сравнивает строки, а не числа. Например, "10" < "7", потому что 1 идёт раньше 7 в алфавите. В [...] символ > вообще означает «перенаправление вывода», и создаст файл с именем 7 в текущей папке. Еще пример:

case $foo in
    ("" | *[!0123456789]*) echo "Ошибка: foo не число!" && exit 1 ;;
    *) [ "$foo" -gt 7 ] ;;
esac

Если $foo содержит что-то вроде $(rm -rf /), то при определённых условиях это может привести к пиздецу. Поэтому перед проверкой лучше убедиться, что $foo — это число. Код выше проверяет, является ли переменная $foo числом, и если да, сравнивает её с 7.

case $foo in — конструкция для проверки значений переменной $foo по шаблонам. "" — пустая строка (если $foo пустое). ("" | *[!0123456789]*) — строка, содержащая хотя бы один символ, который не цифра (например, abc, 12a3). Если условие выполняется, выводится сообщение "Ошибка: foo не число!", и скрипт завершает работу с кодом 1 (exit 1). * — означает «всё остальное» (то есть, если $foo не попал под первый шаблон). [ "$foo" -gt 7 ] — проверяет, больше ли $foo чем 7.

Выводы: для работы с числами используем (( ... )) или [ "$foo" -gt 7 ], а переменные перед проверкой лучше очищать от лишних символов. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

Хакатон от МТС: 5 треков и 1 500 000 рублей. Для тех, кто готов воплотить идею в прототип Приглашаем на хакатон МТС True Tech Hack 2025. Протестируй свои идеи и разработай решение на базе одной из пяти ИТ-платформ МТС. Призовой фонд соревнования — 1 500 000 рублей. Участие могут принять системные аналитики, Data Scientists, Data Engineers, frontend и backend-разработчики, Android-разработчики, бизнес-аналитики, аналитики данных, MLOps-инженеры, DevOps-инженеры, Product-менеджеры, ИТ-архитекторы, UI/UX-дизайнеры. На хакатоне ты сможешь: — Выбрать свой трек и создать решение на базе ИТ-платформ МТС. — Побороться за призовой фонд — 1 500 000 рублей. — Расширить свои профессиональные связи через нетворкинг с участниками хакатона и экспертами МТС. — Повысить шансы на прохождение стажировки в МТС. — Узнать больше о продуктах и технологиях МТС от экспертов компании Регистрация до 16 апреля. Регистрируйся прямо сейчас: https://truetechhack.ru/

Представь, что у тебя есть две коробки. На одной написано «хуи дрочёны», а на другой «пики точены». Ты хочешь проверить: ㅤ — В первой коробке хуи? — Во второй коробке пики? Если оба условия верны, ты говоришь — заебись!. Бэд практика:

[ "хуи" = "коробка1" -a "пики" = "коробка2" ]

Тут -a (И) считается устаревшим и в некоторых случаях это работать не будет. Так что если такое видишь или пишешь, сразу сноси, это хуйня!

Одна из проблем с [ A = B -a C = D ] (или -o) в том, что POSIX не определяет, как должна работать команда [ ... ], если у неё больше 4 аргументов.

Бест-практика: Разделяем на две проверки:

[ "коробка1" = "хуи" ] && [ "коробка2" = "пики" ]

Сначала проверяется первое условие, затем второе. Если оба верны — команда выполнится. Либо делаем конкретно под Bash:

[[ "коробка1" = "хуи" && "коробка2" = "пики" ]]

Здесь можно использовать &&, всё будет работать правильно. Выводы: Если используешь [ ... ], то делай две отдельные проверки. Если [[ ... ]], то можно писать всё внутри. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

Посмотрели на новые ограничения последней версии Sonatype Nexus и прослезились 🥲 Благо, к 2025 году уже появились отечественные аналоги, способные частично или полностью заменить функционал зарубежного менеджера репозиториев. Продукт Сфера.Дистрибутивы и лицензии максимально адаптирован для работы в крупных корпоративных средах и решает самые разные задачи, включая безопасность, масштабируемость и отказоустойчивость. Возможности репозитория артефактов Сфера.Дистрибутивы и лицензии: 🛑 единое хранилище артефактов разработки с поддержкой 18 типов репозиториев, объединение и подключение репозиториев из другой сети; 🛑 быстрый поиск и получение нужных версий библиотек, образов, дистрибутивов; 🛑 контроль лицензий и уязвимостей open-source-компонентов; 🛑 повторное использование проверенных артефактов, ускорение разработки, управление политиками очистки хранилища; 🛑 масштабирование на множество распределенных команд и проектов. Продукт входит в состав DevOps-конвейера от платформы «Сфера», что позволяет автоматизировать все этапы разработки ПО от написания кода до развертывания на продакшене. 📤 Подробнее об одном из самых эффективных решений отечественного рынка хранилищ артефактов на сайте. Реклама. ООО «ГК «Иннотех»» ИНН: 9703073496. Erid: 2SDnjd31D48

Представь что у тебя есть переменная:

f="My Documents/file.txt"

И в скрипте мы делаем так:

cd $(dirname "$f")

Это ошибочный вариант, бэд мать его практика. Команда cd $(dirname "$f") должна вернуть путь к папке, где лежит файл. ㅤ НО! Результат этой команды разбивается на части, если в нём есть пробелы. Например:

dirname "My Documents/file.txt"

Выдаст: My Documents А если так:

cd My Documents

Логично, получаем ошибку: cd: No such file or directory: My Bash думает что это два отдельных слова, а не один путь. ➡️ Бест-практика

cd -P -- "$(dirname -- "$f")"

1. Кавычки защищают результат команды от разбиения. 2. И cd получит целый путь, даже если в нём есть пробелы. Как работают кавычки - Когда Bash видит $(...), он воспринимает это как отдельную область, некий «уровень». - Кавычки внутри $(...) работают только внутри. - Кавычки снаружи не объединяются с внутренними. Наглядно, можно представить так:

cd "$( dirname "$f" )"

Внутренние кавычки "$f" защищают переменную f Внешние кавычки "" защищают результат dirname "$f" Теперь даже если переменная будет содержать пробелы команда не разобьётся на части. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

Живешь в мире масштабирования и аптайма? 🖱 GoCloud — конференция для IT-экспертов про облака и AI. На GoCloud тебя ждут 30+ докладов, где расскажут и покажут: ➡как работают облачные сетевые сервисы ➡как подключать блочные хранилища к железным серверам ➡как запустить приложения в два клика, при этом сэкономив ресурсы ➡как реализована архитектура DBaaS поверх K8s А еще будут ломать приложение в реальном времени и рассказывать про инструменты для защиты от уязвимостей. Нетворкинг, презентации новых продуктов, live-демо и afterparty ждут тебя 10 апреля. Регистрация по ссылке 👈

Когда в Bash ты сравниваешь две переменные, важно не проебаться с кавычками.

[ $foo = "bar" ]

В этом примере если переменная $foo будет пустой, то по итогу ты попадешь в просак:

[ = "bar" ]

bash: [: =: unary operator expected

Логично вылезет ошибка, потому что «=» ожидает два значения. Чтобы избежать этой ситуации, на помощь приходят — кавычки.

[ "$foo" = "bar" ]

Теперь всё в поряде. Ошибки никакой нет. Но Bash не пальцем деланный, поэтом сравнить две переменные можно иначе.

[[ $foo == bar ]]

Теперь кавычки нахуй не нужны. Но опять же если в переменной будут спецсимволы, то тебя ожидают грабли. Есть еще легаси способ:

[ x"$foo" = x"bar" ]

В современном мире ты вряд ли с ним столкнешься, но в каких-то допотопных скриптах вполне можешь найти. Если $foo пустая, то без x получится:

[ = bar ]

А с x будет:

[ x = xbar ]

В [[ ... ]] переменные не разделяются на слова, даже если содержат пробелы.

foo="hello bashdays"
[[ $foo = "hello bashdays" ]]

А если сделать так:

foo="hello bashdays"
[ $foo = "hello bashdays" ]

Получишь ошибку: bash: [: too many arguments Все это справедливо для Bash. Если пишешь под sh, то твой путь это одинарные скобки [...]. ㅤ А еще в двойных скобках можно использовать шаблоны:

foo="hello bashdays"
[[ $foo == h* ]]

Вернёт true, потому что foo начинается с «h». Либо написать сложное условие:

[[ $foo = "bar" || $bar = "baz" ]]

В одинарных кавычках это выглядело бы так:

[ "$foo" = "bar" -o "$bar" = "baz" ]

Выводы: Всё что тебе нужно знать это первые два способа:

[ "$foo" = "bar" ]
[[ $foo == bar ]]

Это трувей, бестпрактика и мастхев. Изучай. tags: #bash #badpractices #bestpractices — 🔔 @bashdays➡️ @gitgate

К предыдущему посту было написано достаточно много полезных комментариев и один из них представляет собой очень достойный чек-лист от Андрея по разбору инцидентов. Что делать если все сломалось? 👇 https://blog.bashdays.ru/сhto_delat_esli_vse_slomalos/

5 советов начинающему DevOps-инженеру 1️⃣ Развивайте критическое мышление. В DevOps ценится умение анализировать проблемы и находить оптимальные решения. Спрашивайте себя: «Почему это работает так?» и «Можно ли лучше?» 2️⃣ Учитесь договариваться. DevOps-инженеру важно объяснять технические вопросы разным командам. Начните с простого — формулируйте мысли чётко и по делу. 3️⃣ Тренируйте навык решения нестандартных задач. В DevOps нет универсальных схем, поэтому не бойтесь экспериментировать и искать альтернативные подходы. 4️⃣ Изучайте Linux и работу с сетями — это база. Чем лучше разберётесь в основах, тем быстрее овладеете инструментами DevOps и сможете претендовать на повышение. 5️⃣ Не тратьте время на хаотичный поиск информации. На курсе Нетологии «DevOps-инженер с нуля» вы разберётесь в сложных темах с поддержкой экспертов, поработаете над реальными кейсами и выполните дипломный проект в Yandex Cloud. Промокод DEVOPS10 даст дополнительную скидку 10 000 ₽ Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5xJw2uv

Представь, ты работаешь в компании единственным специалистом в своей роле. Ну, то есть ты ОДИН фронт/бекендер/девопс/qa и т.п. Тимлида в такой ситуации обычно не бывает, максимум есть СТО (техдир) и то он родственник CEO. ㅤ Возникает ситуация — ты что-то закомитил, прод уебался. С кого спрос? Само собой с техдира, а дальше клубочек ведет уже к тебе. И хуй ты там стрелочку переведешь, банально некуда. А техдир давно не советчик (не помощник), по причине — максимальная деградация и просиживание штанов на созвонах. Всё что ты получишь:

Алёша, ты чё блядь Супер Марио? Об грибок уебался?

Что делать с упавшим продом? Естественно чинить самому! В этой ситуации ты можешь положиться только на себя. Ты тот самый Брюс Уиллис, который полетел в космос и выебал астероид. Тут уже никто не спрашивает — можешь ты это починить или нет. Ты обязан с этим разобраться и починить. А как? Вообще никого не ебет — предоставьте результат. Из помощников только гугол, твоя насмотренность и опыт. Больше положиться не на кого, ты гуглиш, экспериментируешь, по итогу чинишь всё это дерьмище и чилиш. Ну и надеешься чтобы на ретро тебя в жопу не выебали. Ситуация вторая Ты не единственный специалист в своей роле. Аналогично, ты что-то запушил в мастер и все уебалось. Что ты делаешь? Пытаешься починить, не выходит, еще раз пытаешься, гуглишь, используешь нейросети, становится только хуже… Следующий твой шаг — делегируешь свой факап своему коллеге (коллегам, тегаешь всех @channel), у них опыта больше, наверное посоветуют, разберутся. Это сразу провальный вариант! ➡️ Если что-то сломал — чини сам! Это аксиома! Но опять же если это прод, не грех посоветоваться с коллегами, если такие есть. Всеобщими усилиями это поднять, а потом уже жопу свою на ретро отдать на экзекюцию, но не забыть заранее выписать бочку вазелина с Озона. Короче вывод такой — никогда ни на кого не надейся! Сразу в башке носи мысль — ты один и разбираться с этим тебе одному. Такой подход неистово качает твой скиллз и ты никогда не будешь зависеть ни от кого. И это очень ценный навык в айти, кем бы ты ни был. Как только ты станешь самостоятельным, тебе будет похер вообще на всё и на всех, ты будешь Альфа-Ктулху, который решит любую проблему! Такие дела, нового ничего не сказал, рабочие будни. tags: #рабочиебудни — 🔔 @bashdays➡️ @gitgate

ㅤ РБПО на конвейере: как Hantis избавляет исследователя от рутины Разработка безопасного ПО и укрепление доверия к свободным проектам напрямую связаны с постоянным анализом исходного кода и наблюдением за поведением приложения во время выполнения. Команда направления безопасности разработки программного обеспечения «Базальт СПО» создала инструмент, который позволяет: 🔸Сохранить и зафиксировать накопленный опыт; 🔸Автоматически запускать все предыдущие наработки для новых релизов; 🔸Отслеживать срабатывания инструментов анализа и формировать задания на триаж; 🔸Гарантировать устранение всех выявленных несоответствий, не дав им затеряться. Как конвейер автоматизации Hantis помогает минимизировать число рутинных операций и какие подходы к РБПО-исследованиям применяет команда «Базальт СПО», рассказываем в новом ролике. Смотрите на любой удобной площадке: 📹 VK Видео 📹 RuTube 📹 YouTube 📹 Дзен Реклама. ООО "Базальт СПО", ИНН: 7714350892, Erid:2VtzqxhyULF

Хотел тебя порадовать годнотой, но чёт батарейка села за неделю, как обычно, повылазила рутина, там прод пизданулся, здесь кластер развалился, и т.п. Планируешь задачу одну, а получаешь хуем по лбу. Такова жизнь в айти, никогда не знаешь что тебя ожидает через минуту. Ну да ладно, со всем справимся, мыж с вами позитивные типы. Самое главное, что сегодня пятница и завтра можно лишний часик подрыхнуть. Ну а если ты ночной страж, то сил тебе и терпения. Всё наладится! В общем с пятницей ребят, берегите себя и выкраивайте лишний часик, чтобы отдохнуть, всех денег не заработаешь, а горящие продакшены могут и подождать. Завтра снова рутина, как только так сразу вернусь к тебе! Всех обнял!

😱 Переходите с Windows на Linux, но не знаете, с чего начать? Задача выглядит пугающе? ⏰ На открытом уроке 24 марта в 20:00 мск мы раскроем все основы Linux. Вы узнаете, как работать с консолью, научитесь базовым командам и разберетесь, что отличает Linux от Windows. ⭐️ Спикер Андрей Буранов — системный администратор в VK, входит в топ-3 лучших преподавателей образовательных порталов. Мы покажем, как легко освоить Linux, установив программы и управляя пакетами, а также объясним, как устроена файловая система и как эффективно с ней работать. Участники вебинара получат скидку на большое обучение «Administrator Linux. Basic»: 👉 Записывайтесь прямо сейчас: https://vk.cc/cJTGdY Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Такс, как и обещал притаранил тебе рабочий пайплайн для авто деплоя mkdocs через gitea. ㅤ Чтобы всё это заработало, в проекте тебе нужно создать структуру:

.gitea/workflows/deploy.yml

Файл можешь обозвать как угодно.

name: Build and Deploy Bashdays Blog

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: super-runner
    container:
        image: catthehacker/ubuntu:act-22.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies and build
        run: |
          pip install -r requirements.txt
          mkdocs build

      - name: Deploy to Server
        uses: https://gitea.com/aquelle1/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc -i --delete" 
          SOURCE: "site/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Давай пробежимся: Триггер on: push: запускается если что-то запушено в ветку main.

Почему в main а не в master? Читай тут.

Следом запускается джоба build на раннере super-runner, не забываем зарегать себе раннер, без него нихуя не получится.

Что такое раннеры и как с ними работать, можешь загуглить, там по сути ничего сложного. Поэтому этот этап пропущу. Чуть позже отдельным постом запилю про это.

Дальше используем адаптированный контейнер с убунтой 22.04 специально адаптированный под тестирование GitHub Actions через act. Почему GitHub Actions? Потому что gitea унаследовало синтаксис и пайплайны в теории могут переносится между системами. Пиздеть не буду, не переносил, но если у тебя есть опыт, то было бы интересно увидеть его в комментариях. Потом идут шаги speps, клонируется репозиторий с проектом в контейнер, устанавливаются необходимые зависимости через «пипку», ну и билдится финальная статика. После сборки идет секция с деплоем, я использую этот экшен. Основан он на rsync поверх ssh. Забиваем нужные ключи и переменные, которые требуются для работы этого экшена. Переменные определяешь в настройках проекта в gitea в секции secrets. SSH_PRIVATE_KEY = Приватный ssh ключ с которым раннер пойдет на твой сервер и подключиться по ssh к нему. Соответственно публичная часть ключа должна быть прописана у пользователя на сервере в файле ~/.ssh/authorized_keys.

Как работать с ssh ключами, читай по тегу #linuxfactory

ARGS = Аргументы для rsync, рекурсивное копирование, сохранение прав доступа, удаление файлов которые не в локальной версии. SOURCE = Какой каталог со статикой отправляем. В Mkdocs статика генерится по умолчанию в папку site. REMOTE_HOST & REMOTE_USER = Айпишник или домен продакшена на который деплоим + имя пользователя под которым подключаемся к серверу. TARGET = В какую папку на проде скинуть содержимое папки site. Параметров в экшене гораздо больше, у меня приведен необходимый минимум. Про все ключи и свистоперделки этого экшена можешь почитать тут. Вот и всё. Теперь при пуше в main ветку, автоматически запустится пайплайн и на прод выкатятся изменения. В моем случае выкатываются новые посты в markdown. Этот процесс хочу автоматизировать и продублировать все посты из этого канала в блог, сделать наконец нормальную навигацию и поиск. А то чёрт ногу сломит уже, хуй чё найдешь. Но это пока только мечты, мечты... Короче хорошего тебе вечера, теперь уже до завтра! tags: #devops #cicd — 🔔 @bashdays➡️ @gitgate

⚙️ Из каких частей состоит Kubernetes Этот вебинар посвящён внутреннему устройству Kubernetes — одной из самых популярных платформ для контейнеризации и оркестрации. Вы узнаете, из каких ключевых компонентов состоит Kubernetes, как они взаимодействуют между собой и как настроить их для эффективного управления контейнерными приложениями. На вебинаре вы узнаете: 1. Основные компоненты архитектуры Kubernetes: Control Plane, Worker Nodes, и их роли в системе. 2. Как работают ключевые элементы Control Plane: API Server, etcd, Scheduler, Controller Manager. 3. Функции Worker Nodes, включая kubelet, kube-proxy и контейнерный runtime (например, Docker или containerd). 4. Как работают Pods, Namespaces, ConfigMaps, Secrets, и их роль в управлении контейнерами. 5. Принципы масштабирования приложений и обеспечения отказоустойчивости с помощью Kubernetes. 6. Настройка сетевого взаимодействия и хранения данных с использованием Ingress, Persistent Volumes и Storage Classes. 👉 Регистрация и подробности о курсе "Инфраструктурная платформа на основе Kubernetes": https://vk.cc/cJRGab Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Вчера после статьи про CrowdSec много ребят обратились с вопросом — мужик, а чё за движок такой у твоего блога? Отвечу сразу всем. Это не движок, это статика. И сделана она при помощи фреймворка MKDocs + Material. ㅤ Суть там простая, верстаешь статейки в markdown, пушишь в гит репу, оно собирается в статику и автоматом выкатывается в прод. Скорость работы по сравнению с wordpress просто ебейшая (статика хули). Сейчас занимаюсь SEO оптимизацией, роботсы, сайтмепы и т.п. Порог вхождения прям минимальный. А самое главное — отлично написанная документация. Можно чёрта закостомить, реврайтить базовые вещи, js писать, полностью менять верстку. Но обычно коробочных приколюх уже достаточно. Плюс к этому полно роликов на ютубе, как эту чачу заводить и размещать на серверах. Базовый файл requirements.txt выглядит так:

mkdocs
mkdocs-material
mkdocs-material-extensions

В моём случае я просто подключил нативный плагин блога в mkdocs.yml и немного его сконфигурял.

plugins:
  - search
  - tags
  - blog:
      blog_dir: .
      blog_toc: false
      archive_name: Архив
      archive_toc: false
      archive_date_format: yyyy
      archive_url_date_format: yyyy
      authors_file: "{blog}/.authors.yml"
      post_url_format: "{slug}"
      post_date_format: short
      pagination: true
      pagination_per_page: 5
      draft: true
      draft_on_serve: true
      post_readtime_words_per_minute: 300

Больше боли мне доставило написать пайплайн для gitea, но я поборол этого босса и вечерком скину наработки. Глядишь под гитхаб адаптируешь, там синтаксис почти один в один.

Gitea использую для личных проектов, без всяких наворотов, встроенного CI/CD и раннера вполне хватает.

Настоятельно рекомендую потыкать этот Mkdocs с полезной нагрузкой Material, я прям в восторге прибываю. И да, это отличный способ развернуть свою личную wiki и не ебстись со всякими конфлюенсами и т.п. Ну либо документацию к проектам к своим описывать тоже маст-хевная штукенция. Кстати в GitGate оно как-то от Димы уже прилетало, но там про material не упоминалось. Ладно, не смею тебя больше отвлекать, вечерком еще увидимся. tags: #рабочиебудни #frameworks — 🔔 @bashdays➡️ @gitgate