tgindex

DevOps на минималках

описание

Все самое полезное для девопсера в одном канале. 1. Библиотека книг и статей по теме DevOps. 2. Задачи и тесты по DevOps для тренировки и обучения. 3. Вопросы с собеседований по DevOps и ответы на них. по рекламе: @jannytg

2 809
подписчиков
Охват к подписчикам
44,2%
ERR
Реакции к просмотрам
0,26%
111 на 29 постов
Пересылки к просмотрам
1,55%
670
Постов в день
0,3
всего 29

Где отзываются чаще

доля реакций к просмотрам
  • 2 июл.но двери уже закрыты и тебя вышвырнули на улицу в самый кризис1,19%
  • 15 авг.Знали, как не дать cron-задаче запуститься второй раз поверх первой? Иногда скрипт запускается по расписанию, но предыдущий запуск ещё не закончился. Например, backup, импорт данных, rsync или очистка логов могут выполняться дольше обычного. Обычный cron выглядит так: * * * * * /opt/jobs/backup.sh Если backup занимает больше минуты, следующий запуск начнётся параллельно: backup.sh backup.sh backup.sh Это может привести к битым архивам, двойной нагрузке, конфликтам файлов и странным ошибкам. Для таких случаев используют flock: flock -n /tmp/backup.lock /opt/jobs/backup.sh Файл /tmp/backup.lock здесь не хранит данные. Он нужен как точка блокировки. Ключ -n означает: если lock уже занят, не ждать, а сразу выйти: flock -n /tmp/backup.lock ./backup.sh В cron это можно записать так: * * * * * flock -n /tmp/backup.lock /opt/jobs/backup.sh Если первый запуск ещё работает, второй просто не стартует. Для более явного варианта можно использовать shell: flock -n /tmp/backup.lock \ bash -c 'echo start; ./backup.sh' А если нужно немного подождать lock, есть timeout: flock -w 10 /tmp/backup.lock ./backup.sh Так команда подождёт до 10 секунд, а потом завершится, если блокировка всё ещё занята.1,12%
  • 4 июн.😀 Крутая шпаргалка по командам Git на русском echo "# название" >> README.md - создание файла README.md git init - инициализация репозитория git add README.md - добавления файла README.md в проект git commit -m "first commit" - получает проиндексированный снимок состояния и выполняет его коммит в историю проекта git remote add origin https://github.com/stanruss/название.git - команда, которой устанавливается подключение к удаленному серверу и git репозиторию, размещающемуся на нем. git push -u origin master - кзменения отправляются на удаленный сервер git log --oneline - посмотреть все коммиты. git checkout . - восстановить все. git checkout "код коммита" - вернуть до состояния этого коммита. git checkout master - вернуться в ветку мастер. Восстановить файлы на локальном компьютере: git fetch --all git reset --hard origin/master или git reset --hard origin/<название_ветки> git add text.txt - Добавить файл в репозиторий git rm text.txt - Удалить файл git status - Текущее состояние репозитория (изменения, неразрешенные конфликты и тп) git commit -a -m "Commit description" - Сделать коммит git push origin - Замерджить все ветки локального репозитория на удаленный репозиторий git push origin master - Аналогично предыдущему, но делается пуш только ветки master git push origin HEAD - Запушить текущую ветку, не вводя целиком ее название git pull origin - Замерджить все ветки с удаленного репозитория git pull origin master - Аналогично предыдущему, но накатывается только ветка master git pull origin HEAD - Накатить текущую ветку, не вводя ее длинное имя git fetch origin - Скачать все ветки с origin, но не мерджить их в локальный репозиторий git fetch origin master - Аналогично предыдущему, но только для одной заданной ветки git checkout -b some_branch origin/some_branch - Начать работать с веткой some_branch (уже существующей) git branch some_branch - Создать новый бранч (ответвится от текущего) git checkout some_branch - Переключиться на другую ветку (из тех, с которыми уже работаем) git branch # звездочкой отмечена текущая ветвь - Получаем список веток, с которыми работаем git branch -a # | grep something - Просмотреть все существующие ветви git merge some_branch - Замерджить some_branch в текущую ветку git branch -d some_branch - Удалить бранч (после мерджа) git branch -D some_branch - Просто удалить бранч (тупиковая ветвь) git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4 - Изменения, сделанные в заданном коммите git push origin :branch-name - Удалить бранч из репозитория на сервере git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4 - Откатиться к конкретному коммиту и удалить последующие (хэш смотрим в «git log») git push -f - Залить на сервер измененные коммиты git clean -f - Удаление untracked files 👉 DevOps на минималках0,75%
  • 5 июн.без подписи0,55%
  • 2 июн.✏️ Шпаргалка по звёздочкам Нашли для вас полезную шпаргалку по составлению cron-выражений. 💾 Сохраняйте себе, чтобы не потерять DevOps на минималка0,55%
  • 8 июл.без подписи0,47%
  • 11 мар. 2025 г.Образы - значимая единица в Docker. Управление ими во многом похоже на управление контейнерами, но есть ряд отличий, которые важно учитывать. Причем как в командах, так и в опциях. У команд для управления образами есть общий синтаксис, который выглядит так: docker image название команды Рассмотрим основные команды для управления образами. Docker чатик 🐬 #команды #docker0,45%
  • 9 окт. 2024 г.Образы - значимая единица в Docker. Управление ими во многом похоже на управление контейнерами, но есть ряд отличий, которые важно учитывать. Причем как в командах, так и в опциях. У команд для управления образами есть общий синтаксис, который выглядит так: docker image название команды Рассмотрим основные команды для управления образами. #команды0,42%
  • 12 июн.👩‍💻 Наглядно: Как работает Docker 👉 DevOps на минималках0,38%
  • 7 окт. 2024 г.Как в Kubernetes устроена работа с хранилищами? У Kubernetes есть volumes, например, нативный emtyDir. Часть из них stateless, то есть они живут, пока жив под. Судьба у данных, которые туда попадают, аналогичная. Для statefull-приложений используются постоянные хранилища, Persistent Volumes (PV). Persistent Volumes (PV) — это единицы хранения, которые были выделены кластеру Kubernetes его администратором. Это могут быть локальные диски, СХД, внешние дисковые полки. Они никак не зависят от жизненного цикла подов. Persistent Volume Claim (PVC) — это запрос на выделение PV определенных характеристик: типа хранилища, объема, типа доступа (чтение и/или запись). Для описания подробных характеристик доступных PV используются Storage Classes. В динамике это все выглядит следующим образом: под отправляет PVC, а PVC уже обращается к PV и передает ее поду. Схема выделения PV подам на картинке ниже #kb #собес0,37%
  • 29 июн.без подписи0,33%
  • 17 апр.Что выведет этот GitHub Actions workflow? name: Test Job on: workflow_dispatch: jobs: test: runs-on: ubuntu-latest steps: - name: Set var run: echo "RESULT=ok" >> $GITHUB_ENV - name: Check var run: | if [ "$RESULT" == "ok" ]; then echo "Success"; else echo "Fail"; fi 👾 — Success 👍 — Fail 🥰 — Ошибка выполнения скрипта ⚡ — Переменная не найдена, но пайплайн не упадет0,31%