1000+ свежих IT-вакансий каждый месяц в одном месте 🤘

Пока другие листают hh — мы ищем вакансии по всему рынку: каналы, сайты компаний, стартапы и закрытые источники.

IT Россия
IT СНГ
Стажировки
Digital
Международка
Удалёнка
Python
Бигтех
Дизайн
QA
Джунам
Frontend
Аналитика
Стартапы за рубежом
DevOps
Не с HH
Автоотклики

Почему sudo echo всё равно может вернуть Permission denied?

Часто системный файл пытаются изменить так:

sudo echo "PORT=8080" \
  > /etc/myapp/app.conf

Но команда может завершиться ошибкой доступа, хотя перед echo указан sudo.

Причина в порядке выполнения. sudo запускает с повышенными правами только echo, а перенаправление > обрабатывает текущий shell ещё до запуска команды.

Именно обычный пользователь пытается открыть системный файл для записи.

Для таких случаев удобно использовать tee:

echo "PORT=8080" |
  sudo tee /etc/myapp/app.conf \
  > /dev/null

Здесь файл открывает уже tee, запущенный через sudo.

Чтобы не перезаписывать файл, а добавить строку в конец, используйте -a:

echo "LOG_LEVEL=info" |
  sudo tee -a /etc/myapp/app.conf \
  > /dev/null

Многострочный конфиг можно записать через heredoc:

sudo tee /etc/myapp/app.conf \
  > /dev/null <<'EOF'
PORT=8080
LOG_LEVEL=info
CACHE_ENABLED=true
EOF

Кавычки вокруг 'EOF' запрещают shell подставлять переменные и выполнять команды внутри блока. Содержимое будет записано буквально.

➡️ DevOps Ready | #совет

Шпаргалка по командам Docker CLI!

Например, docker run -p 8080:80 nginx запускает контейнер и публикует его порт, а docker logs -f <container> показывает новые строки логов в реальном времени.

На картинке команды для сборки и удаления образов, запуска и остановки контейнеров, просмотра логов и статистики, открытия shell внутри контейнера, а также загрузки и публикации образов через Docker Hub.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Bash-конвейер может скрыть ошибку одной из команд!

По умолчанию код завершения конвейера определяется последней командой:

curl -sS "$URL" | jq -r '.version'

Если curl завершится с ошибкой, но jq успешно обработает пустой ввод, весь конвейер может вернуть код 0. Скрипт решит, что команда выполнилась успешно.

Опция pipefail меняет это поведение:

set -o pipefail

Теперь конвейер завершится с ошибкой, если неуспешной была любая его часть:

curl -fsS "$URL" |
    jq -r '.version' > version.txt

Коды отдельных команд последнего конвейера можно посмотреть через PIPESTATUS:

curl -fsS "$URL" | jq -r '.version'
printf '%s\n' "${PIPESTATUS[@]}"

В автоматизированных Bash-скриптах часто включают сразу несколько строгих настроек:

set -euo pipefail

-e завершает скрипт при необработанной ошибке, -u запрещает использование необъявленных переменных, а pipefail обнаруживает сбой внутри конвейера.

Ожидаемые ошибки при этом лучше обрабатывать явно:

if ! grep -q "READY" health.log; then
    echo "Service is not ready"
fi

Добавляйте pipefail в Bash-скрипты, где ошибка загрузки, сборки или обработки данных не должна остаться незамеченной.

➡️ DevOps Ready | #совет

Контроль целостности системных утилит Linux через проверку хэш-сумм.

При компрометации сервера злоумышленники часто подменяют базовые системные бинарники (например, ss, ps или login) на модифицированные версии с бэкдорами. Мы напишем лаконичный bash-скрипт, который создаст эталонные слепки контрольных сумм SHA-256 для критически важных утилит и проверит их на предмет несанкционированных изменений. Этот базовый механизм Host IDS (интрузивного детектирования) позволяет оперативно обнаружить факт присутствия атакующего в системе.

Сформируем базу данных эталонных хэш-сумм для выбранных системных утилит и сохраним её в защищенный файл:

# Создание эталонных хэшей для проверки
sha256sum /bin/ps /bin/ss /usr/bin/whoami > /root/sys_integrity.db

Файл базы данных успешно создан и содержит уникальные криптографические отпечатки чистых бинарников.

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

# Скрипт проверки и вывода измененных файлов
sha256sum -c /root/sys_integrity.db 2>&1 | grep -v 'OK' || echo "Integrity check: SUCCESS"

Команда выполнит сверку всех строк и выведет предупреждение только в случае несовпадения хэшей.

# проверка (контрольная эмуляция подмены для проверки реакции парсера)
echo "test" >> /root/sys_integrity.db && sha256sum -c /root/sys_integrity.db 2>&1 | grep 'FAILED'

Ожидаемый вывод: /root/sys_integrity.db: FAILED

# cleanup (удаление тестовой базы данных из системы)
rm -f /root/sys_integrity.db

Регулярный запуск такого скрипта через cron помогает вовремя заметить активность руткитов и троянов. Чтобы атакующий не смог подделать саму базу хэшей, обязательно храните эталонный файл sys_integrity.db на удаленном сервере логирования или на флешке в режиме "только чтение".

🚪 Linux Ready | #практика

📂 Напоминалка по локальной отладке CI/CD-скриптов!

Ошибки в пайплайне лучше находить до запуска в CI. Локальная отладка позволяет быстрее проверить логику скриптов, переменные окружения, Docker-окружение и конфигурацию, не тратя время на повторные запуски пайплайна.

На картинке — 7 полезных команд для локальной проверки CI/CD: от shellcheck и docker run до set -x, jq, git diff и других инструментов, которые помогают быстрее находить ошибки и делать пайплайны более надёжными.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Как в Bash гарантированно удалить временные файлы через trap?

В shell-скриптах часто создают временную папку:

tmp_dir=$(mktemp -d)

А потом в конце вручную удаляют её:

rm -rf "$tmp_dir"

Проблема в том, что скрипт может завершиться раньше: ошибка команды, Ctrl+C, ранний exit. Тогда временные файлы останутся лежать на диске.

Для таких случаев в Bash используют trap:

tmp_dir=$(mktemp -d)
trap 'rm -rf "$tmp_dir"' EXIT

Теперь cleanup выполнится при выходе из скрипта почти в любом сценарии:

cp app.log "$tmp_dir/"
grep "ERROR" "$tmp_dir/app.log"

Даже если grep завершится ошибкой, trap всё равно сработает при выходе.

Это удобно сочетать со строгим режимом:

set -euo pipefail

Полный минимальный шаблон:

set -euo pipefail

tmp_dir=$(mktemp -d)
trap 'rm -rf "$tmp_dir"' EXIT

Если нужно выполнить несколько действий при завершении, лучше вынести cleanup в функцию:

cleanup() {
    rm -rf "$tmp_dir"
}

trap cleanup EXIT

Такой подход полезен для архивов, временных конфигов, скачанных файлов, тестовых директорий и промежуточных данных в CI/CD.


➡️ DevOps Ready | #совет

Шпаргалка по kubectl-командам!

Например, kubectl get pods показывает поды, kubectl describe pod помогает посмотреть детали ресурса, а kubectl logs быстро достаёт логи контейнера.

На картинке команды kubectl для просмотра ресурсов, создания и применения YAML, удаления объектов, запуска команд внутри контейнера, работы с логами, kubeconfig и короткими именами Kubernetes-ресурсов.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Практически любую команду можно запустить в отдельной cgroup!

Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения.

Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run:

systemd-run --user --scope \
  -p MemoryHigh=1536M \
  -p MemoryMax=2G \
  make -j32

Теперь ограничения действуют только на эту команду и всё её дерево процессов. После завершения временная cgroup автоматически исчезнет.

Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу):

systemd-run --user --scope \
  -p CPUQuota=200% \
  npm test

Или собрать сразу несколько политик для ресурсоёмкой задачи:

systemd-run --user --scope \
  -p MemoryMax=4G \
  -p CPUQuota=300% \
  -p IOWeight=100 \
  cargo build --release

Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2).

🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов.

🚪 Linux Ready | #совет