Чем отличаются файлы .bashrc .bash_profile .profile и т.п.

Основное различие этих конфигурационных файлов заключается в том, что некоторые из них читаются только оболочками входа (login). Например, при входе в систему с другого хоста или при входе в текстовую консоль локальной unix-машины. Используются файлы .login .profile .zlogin. Зависит от того какая у вас оболочка.

Далее идут конфигурационные файлы, которые читаются «интерактивными» оболочками. То есть подключенными к терминалу или псевдотерминалу. Это файлы с именами .bashrc, .tcshrc, .zshrc и т.д.

Файл .bashrc читается только интерактивной и non-login оболочкой, поэтому большинство людей в конечном итоге инклудят в файле .bash_profile чтение файла .bashrc, например:

[[ -r ~/.bashrc ]] && . ~/.bashrc

Другие оболочки ведут себя по-другому. Например, в zsh, файл .zshrc всегда читается для интерактивной оболочки, независимо от того, является ли она login или нет.

А файл .profile, это просто сценарий входа в систему. И изначально использовался в /bin/sh. Оболочка Bash, будучи обратно совместимым с sh, будет читать .profile, если он конечно же существует.

Пример файла .profile

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

Как видим, при login’е заинклудится файл .bashrc.

В дистрибутивах семейства Debian сначала выполняется .profile, а потом уже .bash_profile. А вот в дистрибах производных от RHEL, сначала выполняется .bash_profile, а уже потом .profile. Ну вот прям каша! 

В документации bash хорошо объясняется, при каких обстоятельствах читается каждый файл. И поведение на разных машинах в целом одинаково.

Выжимка из man bash:

/bin/bash - The bash executable
/etc/profile - The systemwide initialization file, executed for login shells
/etc/bash.bashrc - The systemwide per-interactive-shell startup file
/etc/bash.bash.logout - The systemwide login shell cleanup file, executed when a login shell exits
~/.bash_profile - The personal initialization file, executed for login shells
~/.bashrc - The individual per-interactive-shell startup file
~/.bash_logout - The individual login shell cleanup file, executed when a login shell exits
~/.inputrc - Individual readline initialization file

👉 DevOps Portal

Awesome Linux Software

Ооооочень объёмный перечень приложений, ПО, инструментов и других материалов для разных дистрибутивов Linux.

👉 https://github.com/luong-komorebi/Awesome-Linux-Software

👉 DevOps Portal

Поговорим о команде enable. Она включает или отключает встроенные команды оболочки.

Отключение встроенных команды позволяет выполнить дисковую команду, имеющую то же имя, что и встроенная команда оболочки, без указания полного пути, даже если оболочка ищет встроенные команды перед дисковыми командами.

Запускаем:

bash 
type test

И видим: test is a shell builtin. То есть используется команда test встроенная в оболочку. А не та что лежит на пути в test: /usr/bin/test. Воспользуемся дисковой версией этой утилиты:

enable -n test
type test

И получим такое: test is /usr/bin/test. Получается мы сделали некое переключение. И по факту используем разные версии test.

Чтобы включить обратно встроенную команду test в оболочке, выполняем:

enable test

Можно подгрузить расширения поставляемые с оболочкой. Некие плагины, экстеншены. Для этого эти экстеншены нужно установить:

apt/yum install bash-builtins

Оно установится в папку /usr/lib/bash/. В ней будут всякие mkdir, rm, sleep и т.п. По сути это те же дисковые команды, только экстеншены для оболочки.

Для начала узнаем дисковую версию команды mkdir:

mkdir --version

mkdir (GNU coreutils) 8.32

Теперь загружаем экстеншен в оболочку:

enable -f /usr/lib/bash/mkdir mkdir
mkdir --version

Получаем такое: -bash: mkdir: --: invalid option

Теперь запускаем:

type mkdir

Видим: mkdir is a shell builtin, то есть теперь mkdir используется не системный (дисковый), а тот что подгружен в оболочку bash.

Например, мы снесли все системные бинарники и остался только bash. Через подгрузку экстеншенов можно без проблем обслуживать свою операционную систему, даже если в системе пропал mkdir и т.п.

Чтобы посмотреть что вообще подгружено в оболочку, воспользуемся командой:

lsof +fg -p $$

Получим отчет по текущему процессу, что подгружено в данный момент в оболочку и используется.

С версии 4.4 в bash появилась переменная BASH_LOADABLES_PATH, с помощью нее можно задать путь для поиска экстеншенов. Тогда при подгрузке этих модулей, не нужно будет использовать полные пути.

BASH_LOADABLES_PATH=/usr/lib/bash/
enable -f sleep sleep

👉 DevOps Portal

Руководство по командам Linux

Включает команды, сгруппированные по разделам: управление файлами, пользователями, процессами, оборудованием, сетью, сжатием данных, SSH, установкой пакетов и системной информацией.

Также содержит сочетания клавиш для работы в терминале.

Полезно 👍

👉 DevOps Portal

Как определить состояние контейнера Docker?


1️⃣Проверить статус всех контейнеров:

docker ps -a

Эта команда выводит список всех контейнеров, их идентификаторы, имена, статус и время работы. В колонке "STATUS" можно увидеть текущее состояние контейнера, например:
- Up X hours — контейнер работает.
- Exited (code) — контейнер завершил работу с определённым кодом выхода.

2️⃣ Проверить состояние конкретного контейнера:

Используйте команду docker inspect, чтобы получить подробную информацию о состоянии контейнера:

docker inspect <container_id>

Эта команда выводит всю информацию о контейнере, включая статус, ошибки, время работы и другие параметры. Для удобства можно использовать фильтрацию JSON-вывода, например:

docker inspect -f '{{.State.Status}}' <container_id>

Возможные статусы:
- running — контейнер запущен.
- exited — контейнер завершил работу.
- paused — контейнер приостановлен.
- restarting — контейнер перезапускается.

3️⃣ Проверить логи контейнера:

Чтобы увидеть последние действия контейнера, можно просмотреть его логи:

docker logs <container_id>

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

👉 DevOps Portal

Kubetools — это тщательно подобранный список популярных инструментов для Kubernetes.

Хочу поделиться несколькими тулами, которые точно заслуживают внимания:

🔹 kubie - лично пользуюсь, удобно. Kubie - это kubectx + kubens в одной туле, в конфиге достаточно указать где искать kubeconfigs.

🔹 k9s - UI в терминале с кучей хоткеев, я раньше как-то недооценивал, то потом мне его продал Макс Витковский (кубер-шайтан из моей команды). В общем, теперь это primary cli тула в работе.

🔹 Lens - это красивая, но прожорливая приложуха. Отлично выглядит, но не более 😅 Удобно для девов, или начинающих крутить кубер. Плохо работает на большом скейле - безбожно тупит.

По ссылке ниже - ещё 100500 тулов для менеджмента, работы, аудита и анализа кубер кластера 👇
https://collabnix.github.io/kubetools/

👉 DevOps Portal

1000+ Bash скриптов для DevOps

Не всегда скрипты на Bash вообще нужны в DevOps, но иногда всё же возникает ситуация, когда нужно что-то автоматизировать, а готовых решений нет или они не подходят.
И именно в таких ситуациях может быть удобно быстро написать решение на Bash.

Так что держите эту большую подборку — это скрипты, связанные с настройкой и управлением AWS, GCP, Kubernetes, Docker, PostgreSQL, MySQL, Hive, Impala, Kafka, Hadoop, Jenkins, GitHub, GitLab, BitBucket, Azure TeamCity, Spotify, LDAP, Python и это далеко не полный список

Есть здесь даже скрипты для конфигурирования .bashrc, .vimrc, .gitconfig, .screenrc, tmux

⛓ Ссылка: тык

👉 DevOps Portal | #ресурсы

Упражнения для DevOps специалистов на GitHub

Репозиторий содержит в себе разные упражнения по:

- Linux
- DNS
- АРМ
- Go

И мноооого всего другого

⛓ Ссылка: тык

👉 DevOps Portal | #ресурсы

tailspin

Утилита, которая позволяет просматривать логи с подсветкой. Это удобно, красиво и сокращает много времени на анализ.

Но есть один минус - если привыкните, то читать логи без этой тулзы будет очень сложно 🤓

🔛 https://github.com/bensadeh/tailspin

👉 DevOps Portal | #ресурсы

Команды systemd для управления Docker

Для запуска Docker многие дистрибутивы Linux используют systemd. Для запуска сервисов используется команда systemctl. Если ее нет, следует использовать команду service.

$ sudo systemctl start docker
$ sudo service docker start

Чтобы добавить сервис в автозагрузку, либо убрать его:

$ sudo systemctl enable docker
$ sudo systemctl disable docker

Для проверки параметров запуска сервиса и их изменения:

$ sudo systemctl edit docker

Просмотра связанных с сервисом журналов:

$ journalctl -u docker

👉 DevOps Portal

KubePug

Загружает сгенерированный файл data.json, содержащий информацию об устаревании API Kubernetes

Проверяет текущий кластер Kubernetes или входные файлы, проверяя, существуют ли объекты в этих устаревших версиях API, позволяя пользователю проверить перед переносом

Особенности

🔛 Может запускаться в кластере Kubernetes, используя kubeconfig или текущий кластер
🔛 Может выполняться с другим набором манифестов/файлов
🔛 Позволяет указать целевую версию Kubernetes, подлежащую проверке
🔛 Предоставляет заменяющий API, который следует использовать
🔛 Сообщает версии, что API устарел или удален, в зависимости от версии целевого кластера

Как использовать

Запустите kubectl krew install deprecations

Как использовать с Helm

Если хотите проверить сгенерированные манифесты с помощью Helm, можно запустить так:

helm template -f values.yaml .0 | kubepug --k8s-version v1.22.0 --input-file=-

Измените аргументы в kubepug (и шаблоне Helm) по своему желанию

👉 DevOps Portal

#Cобеседования

df сообщает о наличии 20 Гб занятого пространства, подсчёт занятого файлами места при помощи du даёт результат в 20 Мб. При каких обстоятельствах может возникнуть описанная ситуация?

Когда файл удален т. к. файловый дескриптор «держит» его.

Ищем файл через:

lsof -a +L1 | grep var | grep httpd

При удалении файла, который в этот момент был «занят» процессом — его имя удаляется, но inode — остаётся в файловой системе до тех пор, пока не завершится процесс, который «держит» этот файл.

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

👉 DevOps Portal

Popeye — утилита, которая сканирует работающие кластеры Kubernetes и сообщает о потенциальных проблемах с развёрнутыми ресурсами и конфигурациями.

👉 DevOps Portal

Полный рабочий процесс CI/CD с Skaffold для вашего приложения

Современный способ построения полного рабочего процесса от локального до продакшена с помощью Skaffold и Gitlab на кластере Kubernetes для снижения когнитивной нагрузки и операционной сложности в стеках приложений.

🔛 Часть I
https://blog.equationlabs.io/cicd-workflow-with-skaffold-for-your-application-part-i

🔛 Часть II
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-ii

🔛 Часть III
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-iii

👉 DevOps Portal

Лучшие практики работы с Docker

Никогда не запускайте контейнер от имени root.

Запуск от имени root внутри контейнера означает запуск от имени root на хосте Docker. Если злоумышленник получит доступ к вашему контейнеру, он получит все привилегии root и сможет совершать атаки на хост.

👉 DevOps Portal