Найважливіші команди Linux для DevOps. Повний гайд

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, друзі! Мене звати Макс, і вже майже десять років я живу у світі системного адміністрування. Звучить трохи занудно? Насправді — це драйв та суцільне задоволення! Щодня я розплутую задачі, які іншим можуть здаватися головоломками, і отримую від цього неабиякий кайф.

Якщо ви ще в пошуках своєї «справи життя», щиро бажаю знайти те, що змусить вас вставати вранці з радістю та натхненням. Бо коли робота справді драйвова, навіть понеділки стають легкими.

Ця стаття буде корисною як новачкам у системному адмініструванні, так і тим, хто цікавиться DevOps. Ви зможете дізнатися про важливі та корисні команди для Linux, які спростять вашу щоденну роботу.

Найважливіші команди Linux для DevOps

Володіння базовими командами Linux є ключовою навичкою для DevOps-спеціалістів. Адже Linux — це основа багатьох серверних рішень, і робота з терміналом дозволяє швидко керувати серверами, скриптами та налаштуваннями.

Я розгляну найважливіші команди Linux, які допоможуть DevOps-фахівцям ефективно працювати з системою, автоматизувати процеси та забезпечити стабільність серверів.

1.Основи роботи з файлами та каталогами

Ці команди дозволяють переглядати, переміщувати, копіювати та керувати файлами й папками.

ls — перегляд файлів і каталогів.
Приклад команди в bash:
ls -l # Показує деталі файлів у каталозі

cd — перехід до іншого каталогу.
Приклад команди в bash:
cd /var/log # Перехід до каталогу з логами

cp — копіювання файлів або каталогів.
Приклад команди в bash:
cp source.txt destination.txt # Копіює файл source.txt в destination.txt

mv — переміщення або перейменування файлів.
Приклад команди в bash:
mv old_name.txt new_name.txt # Перейменовує файл

rm — видалення файлів і папок.
Приклад команди в bash:
rm -rf /path/to/directory # Видаляє каталог і всі його файли

2. Робота з користувачами та правами

Безпека є критичною частиною DevOps. Контроль доступу до файлів і процесів виконується через команди для управління користувачами.

useradd та usermod — створення та налаштування користувачів.
Приклад команди в bash:
useradd newuser # Додає нового користувача

usermod -aG sudo newuser # Додає користувача до групи sudo

passwd — зміна пароля.
Приклад команди в bash:
passwd newuser # Зміна пароля для нового користувача

chmod та chown — зміна прав доступу та власника файлів.
Приклад команди в bash:
chmod 755 script.sh # Встановлює права доступу для файлу

chown user:group file.txt # Встановлює власника та групу для файлу

3. Процеси та їх моніторинг

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

ps — перегляд активних процесів.
Приклад команди в bash:
ps aux # Показує всі активні процеси

top — інтерфейс реального часу для моніторингу ресурсів.
Приклад команди в bash:
top # Показує стан процесів та використання ресурсів

kill та pkill — завершення процесів.
Приклад команди в bash:
kill −9 1234 # Завершує процес з ID 1234

pkill nginx # Завершує всі процеси, що пов’язані з nginx

4. Робота з мережевими налаштуваннями

Робота з мережею є невід’ємною частиною для DevOps, особливо під час налаштування серверів.

ifconfig та ip — перевірка та налаштування мережевих інтерфейсів.
Приклад команди в bash:
ifconfig # Показує інформацію про мережеві інтерфейси

ip addr # Показує деталі IP-адрес

ping — перевірка доступності серверів.
Приклад команди в bash:
ping google.com # Перевіряє з’єднання з Google

netstat — перегляд мережевих з’єднань.
Приклад команди в bash:
netstat -tuln # Показує активні з’єднання та відкриті порти

5. Робота з системними журналами та діагностика

Для виявлення причин неполадок DevOps-інженерам необхідно мати доступ до системних журналів.

dmesg — виводить системні повідомлення ядра.
Приклад команди в bash:
dmesg | tail # Показує останні повідомлення

journalctl — перегляд системних журналів (на системах з systemd).
Приклад команди в bash:
journalctl -u nginx # Показує логи для nginx

tail та less — перегляд файлів журналів.
Приклад команди в bash:
tail -f /var/log/syslog # Перегляд логів у реальному часі

6. Пакетний менеджмент

Встановлення та оновлення програмного забезпечення — звична справа в DevOps.

apt (Debian/Ubuntu) та yum (CentOS/RHEL) — управління пакетами.
Приклад команди в bash:
apt update && apt upgrade # Оновлює систему на Debian/Ubuntu

yum install httpd # Встановлює Apache на CentOS/RHEL

7. Автоматизація за допомогою cron

Автоматизація завдань є важливою частиною DevOps. Команда cron дозволяє налаштовувати періодичні завдання.

crontab — налаштування періодичних завдань.
Приклад команди в bash:
crontab -e # Редагування crontab для поточного користувача

Наприклад, щоб запускати скрипт щодня о другій ночі:
Приклад команди в bash:
0 2 * * * /path/to/script.sh

8. Захист серверів за допомогою брандмауера

Забезпечення безпеки серверів — один із пріоритетів для DevOps.

ufw (Uncomplicated Firewall) і iptables — це обидва інструменти для керування брандмауером в Linux, але вони мають різний рівень складності та підходять для різних потреб.

ufw — це простіший інтерфейс, який дає змогу легко керувати правилами брандмауера. Він був створений для зручності та спрощення налаштувань, особливо для користувачів, які не є експертами в мережевій безпеці.
Приклад команди в bash:
ufw allow 22 # Дозволяє підключення по SSH

ufw enable # Увімкнення ufw

iptables — потужний та гнучкий інструмент, який дає змогу здійснювати детальний контроль за мережевими з’єднаннями. Однак його синтаксис і налаштування досить складні, що може вимагати знань мережевих протоколів і досвіду.

Додавання правила для дозволу трафіку на певному порту
Приклад команди в bash:
iptables -A INPUT -p tcp —dport 22 -j ACCEPT # Дозволяє вхідний трафік на порт 22 (SSH)

Блокування IP-адреси
Приклад команди в bash:
iptables -A INPUT -s 192.168.1.100 -j DROP # Блокує вхідний трафік від 192.168.1.100

Перегляд поточних правил
Приклад команди в bash:
iptables -L -v -n # Показує всі налаштовані правила

Видалення певного правила
Щоб видалити певне правило, спочатку дізнайтеся його номер:
Приклад команди в bash:
iptables -L —line-numbers # Показує номери правил

Потім використовуйте номер для видалення:
Приклад команди в bash:
iptables -D INPUT 1 # Видаляє перше правило в ланцюжку INPUT

Збереження та відновлення конфігурації iptables
Щоб зберегти правила (на Debian/Ubuntu):
Приклад команди в bash:
iptables-save > /etc/iptables/rules.v4

А щоб відновити їх:
Приклад команди в bash:
iptables-restore < /etc/iptables/rules.v4

9. Резервне копіювання та відновлення

Збереження даних — критично важлива задача.

tar — створення архівів.
Приклад команди в bash:
tar -cvzf backup.tar.gz /path/to/directory # Створює архів

gzip — стиснення файлів.
Приклад команди в bash:
gzip file.txt # Стискає файл file.txt до file.txt.gz

rsync — синхронізація даних між двома серверами.
Приклад команди в bash:
rsync -av /path/to/source/ user@remote:/path/to/destination/

10. Мережевий моніторинг із tcpdump

Команда tcpdump дозволяє аналізувати мережевий трафік, що є надзвичайно корисним для діагностики мережевих проблем, а також для моніторингу та безпеки.

tcpdump — аналіз мережевого трафіку в реальному часі.
Приклад команди в bash:
tcpdump # Переглядає весь трафік на всіх інтерфейсах

Щоб переглянути трафік на конкретному інтерфейсі (наприклад, eth0):
Приклад команди в bash:
tcpdump -i eth0 # Переглядає трафік на eth0

Щоб зберегти трафік у файл для подальшого аналізу:
Приклад команди в bash:
tcpdump -i eth0 -w capture.pcap # Зберігає трафік у файл capture.pcap

Для аналізу певного порту (наприклад, HTTP-трафіку на порту 80):
Приклад команди в bash:
tcpdump -i eth0 port 80 # Виводить лише трафік на порту 80

11. Моніторинг системи

Для постійного моніторингу стану серверів та ресурсів корисні наступні команди:

free — показує використання пам’яті (RAM).

Приклад команди в bash:
free -h # Виводить використання пам’яті у зручному для читання форматі

df — показує використання дискового простору.

Приклад команди в bash:
df -h # Показує доступний та використаний дисковий простір

uptime — показує час роботи системи з моменту останнього перезавантаження та завантаження системи.

Приклад команди в bash:
uptime # Показує, скільки часу сервер у роботі та його завантаження

vmstat — деталізована інформація про стан системи (пам’ять, процеси, ввід, вивід тощо).
Приклад команди в bash:
vmstat 1 # Показує оновлення інформації про систему кожну секунду

12. Робота з сервісами та журналами

DevOps-інженери часто працюють із сервісами та повинні відслідковувати їхні логи.

systemctl — управління службами на системах із systemd.
Приклад команди в bash:
systemctl start nginx # Запускає сервіс nginx

systemctl stop nginx # Зупиняє сервіс nginx

systemctl status nginx # Показує стан сервісу nginx

journalctl — перегляд журналів служб.
Приклад команди в bash:
journalctl -u nginx # Показує логи для конкретного сервісу nginx

13. Резервне копіювання та відновлення баз даних

Для збереження даних в базах можна використовувати специфічні інструменти резервного копіювання:

mysqldump (для MySQL/MariaDB).
Приклад команди в bash:
mysqldump -u username -p database_name > backup.sql # Створює резервну копію бази даних

pg_dump (для PostgreSQL).
Приклад команди в bash:
pg_dump -U username -d database_name > backup.sql # Створює резервну копію бази даних PostgreSQL

14. Автоматизація з допомогою скриптів та Cron

Автоматизація за допомогою bash-скриптів дозволяє DevOps-інженерам створювати регулярні процеси та оптимізувати рутинні завдання.

Приклад простого скрипта резервного копіювання:
Приклад команди в bash-скрипті:
#!/bin/bash

tar -czf /backup/backup_$(date +%F).tar.gz /path/to/important/data

Налаштування завдань у cron:
Приклад команди в bash:

crontab -e # Відкриває редактор для налаштування завдань cron

Наприклад, для запуску резервного копіювання щодня о третій ночі:
0 3 * * * /path/to/backup_script.sh

15. Інтерактивне управління мережевими з’єднаннями за допомогою netcat (nc)

netcat дозволяє встановлювати TCP та UDP з’єднання, перевіряти порти та навіть створювати прості сервери.

Відкриття порту та прослуховування
Приклад команди в bash:
nc -l 1234 # Відкриває порт 1234 та прослуховує підключення

Перевірка доступності порту
Приклад команди в bash:
nc -zv hostname 80 # Перевіряє, чи відкритий порт 80 на hostname

Висновок

Для мене Linux є справжнім фундаментом у роботі DevOps-інженера. Володіння базовими командами допомагає не лише підтримувати стабільність і швидкодію серверів, але й глибше розуміти, як працюють системи, якими я керую. Завдяки цим простим командам я можу швидко знаходити та розв’язувати проблеми, що виникають, і водночас покращувати інфраструктуру скриптами.

Також для мене була корисною книга з написання скриптів «Advanced Bash-Scripting Guide». Безперервне навчання та автоматизація процесів роблять мене більш ефективним та надають інструменти для побудови надійних, масштабованих рішень.

👍ПодобаєтьсяСподобалось25
До обраногоВ обраному21
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В мене є питання (не троллінг), чи до сих під в лінуксі не винайшли нічого кращого ніж bash? От майкрософт наваяв powershell, який незважаючи на місцями дикий синтакс, виглядає як космічний корабель у порівнянні.

Є zsh, який ненабагато, але кращий за bash.
Є ще fish, який, правда, не встановлений by default у більшості дистрибутивів (на відміну від bash і zsh).

в лінуксі вже давно можна використовувати що заманеться. #!/usr/bin/pwsh і скриптуй на павершелі чи пехопе чи пітоні.
хочеш не скриптувати, а писати однострочники в консолі?

$ cat /etc/shells
/bin/ash
/bin/bash
/bin/csh
/bin/dash
/bin/false
...
/usr/bin/rash
/usr/bin/nu

В цих ваших лінупсах є купа робочих утиліт, котрі можна юзати звідусіль і котрі і виконують більшу частину роботи. А шелл лиш середовище.
у вінді з цим історично було слабіше, тому вони були вимушені розробити новий велосзореліт. В лінупсах же для подорожей бурхливими інформаційними морями вже давно є надійні кораблі і необхідності в зорельоті немає.

Ваше порівняння взагалі некоректне. Це повершелл має дикий синтакс, який запам’ятати неможливо.
Баш хорошо сам по собі, але його теж можно використовувати як універсальний скриптову мову, особливо для інтеграції з різними утілітами, повершелл, незважаючи на кросс-платформеність, дуже заточений на АД та виндовий реестр.

Наприклад для того ж ffmpeg краще користуватись баш-скриптом, ніж повершелл.

На додаток, linux shell без gnu tools, це не повноцінна річ, тому не треба розглядати bash без них, а з ними це дуже крута річ.

Крім того, не знаю що буде з powershell бо і софт проприєтарний і стандарт відсутній, щось своє. А bash — opensource та POSIX-compatible, а POSIX — це сумісність та стабільність на десятиліття.
Ну і взагалі, в linux вже давним давно винайшли, що скрипти можно писати на чому завгодно тому perl та python йдуть в комплекті майже в любому дистрибутиві. Чи вони вам теж недуже розвинені?

Так я і казав саме про дикий синтакс powershell. Що мені подобається в pwsh та не вистачає в bash: 1) непотрібно постійно парсити текст 2) хоч синтакс і трохи того, зате непотрібно вчити синтакс десятків різних утиліт 3) повний доступ до Win32 API (через interop на С#) та .Net классів 4) Approved verbs. Спочатку здається, що це дуже обмежує, але з часом стає зозуміло наскільки це мудре рішення, яке значно полегшує написання коду (при умові використання IDE або Windows Terminal).

Не знаю що ви маєте на увазі під заточенністю на реєстр, але те що це інструмент в першу чергу для вінди, то це факт.

Щодо long term support в мене такі самі думки.

Перл може з натяжкою претендувати на замінника, але там теж синтакс не від бога. Пітон тут взагалі ні до чого.

1. Так в баш також не обов’язково постійно парсити текст. Користуйтесь базами даних чи json
2. Не вчить різні утиліти, вивчить один awk чи один python та визивайте його з баш =)
3. В linux нема win32 Api, а linux api працює церез POSIX
4. повершелл та баш — трохи різна спеціалізація

В павершелі по пайплайну передаються «об’єкти», в баш — бінарні або текстові дані, тобто без ручного парсингу не обійтись.

Та я розумію що в лінуксі нема win32 api, мова шла про прямий доступ до ОС та будь-яких (dll) бібліотек.

Пітон я використовую, але це все таки компільована мова із відносно суворою типізацією, в якій до того ж немає пайплайнів та прямого доступу до ОС. One-liners на пітоні писати не вийде.

у тому й різниця. у лінуксі пайплайн об’єднує різні утиліти. ДОдати свою на чому завгодно — як два пальці. В павершелі такого (всмислі простоти) не зробиш (щоб об’єкт утиліті на пітоні пайплайнути), павершел багато в чому річ в собі, але йому це норм.

Якщо обмежитись .Net, то в принципі можна писати на багатьох мовах і об’єкти будуть доступні powershell. Типовий приклад — включати в скрипт код на C# за допомогою Add-Type. pwsh викликає компілятор сам.

А якщо не обмежуватись?
Об’єднувати різні утиліти це не включати .Net, це об’єднувати БУДЬ-ЩО. ffmpeg, jenkins, nodejs, apache/nginx, asteriks, docker, teamcity, моніторінг та інше — для всього цього достатньо трохи знати шелл, а не вчити .Net на рівні девелопера.
Ви ніколи не бачили умови в докерфайлі? Чи можа це зробити на powershell? А linux shell там просто працює.
Якщо я напишу шелл-скрипт з POSIX-сумісностью, мій скрипт відпрацює і зараз і через 10 років, і я майже впевнений що яйщо знайти якийсь застарілий брухт, що забули перегрузити 20 років тому, цей скрипт там також відпрацює.

Це і є задача інструмента, і його розширювати прийнято зовнішніми утілітами.
Внутрішньо bash і не повинен змінюватись, для цього є zsh/fish, але штатний шелл в 90% дистрибутивів — bash, а деінде взагалі sh/dash, тому що цьго достатньо для задач.

P.S. Є таке правило — якщо робиш тулзу, треба щоб вона робила якусь справу і робила це добре. А комбайн робити не треба.
Це правило вельми розумне для open-source, бо якщо зробити комбайн, і автор не зможе його підтримувати — цей комбайн помре. А прості речі будуть жити віками. Не забувайте, що bash — opensource, freeware soft, написаний ентузіастами в GNU, ніхто вам не заважає придумати та зробити свій вклад.

Так можна далеко зайти. Я лише підмітив, що в pwsh є цікаві рішення, яких мені не вистачає в bash. За бажанням на pwsh можна писати скрипти, які майже не відрізняютимутися від bash, от тільки питання доцільності.

якщо робиш тулзу, треба щоб вона робила якусь справу і робила це добре. А комбайн робити не треба.

Одна справа, це коли утиліта просто читає файл і видає результат, ну можливо з 1-2-ма параметрами. Якщо в утиліти 10-20 параметрів, то це вже не одна справа.

Не забувайте, що bash — opensource

pwsh теж опенсорс.

pwsh теж опенсорс.

Подивимся скільки він проживе, як часто буде штатно встановлений в будь-яку ОС, та наскількі буде обратно-сумісний через 10 років.

Пітон я використовую, але це все таки компільована мова із відносно суворою типізацією

Але дінамічною і без вимоги зарані обʼявляти змінні.

в якій до того ж немає пайплайнів та прямого доступу до ОС.

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

One-liners на пітоні писати не вийде.

Ні, виходить.

Ні, виходить.

Я не нападаю на python, мені він теж подобається. Просто деякі речі на ньому робити недоцільно. Приклад: Get-ChildItem . -Filter *.zip -recurse | Expand-Archive (думаю суть команди очевидна).

а якщо .rar чи .ha чи .gz ?

Тоді можна використовувати спец. утиліти, точно так як в bash.

Але вони не вміють працювати з об’єктами, тобто повертаємося до роботи з текстом и парсингом.
Надодаток, суть команди для мене була не очевидна.Що за ChildItem? А працює з линками? А якщо недостатньо прав? А чому *.zip не в лапках?

Але вони не вміють працювати з об’єктами, тобто повертаємося до роботи з текстом и парсингом.

Так, для більшості «класичних» утиліт все по суті як і в bash. Ну хіба що різні output streams можна зберегти у різні змінні і обробити вже за допомогою powershell.

суть команди для мене була не очевидна

Суть: розпакувати всі zip архіви у всіх вкладених папках рекурсивно починаючи з поточної. У вінді також вже є натів підтримка rar, але як нею користуватись через pwsh не знаю.

Що за ChildItem?

В MS вирішили уніфікувати роботу з файловою системою та реєстром (а по бажанню і з іншими деревовидними контейнерами даних). Тобто item = файл або папка (директорія), або ключ реєстру, а залежності від контексту. Як на мене, сумнівне рішення, але звикнути не складно.

А працює з линками?

Буде слідувати за лінками.

А якщо недостатньо прав?

Буде exception (error), ловиться try/catch. Або можна взагалі ігнорувати помилки для конкретної команди (-ErrorAction SilentlyContinue) і просто перевіряти її результат на $null.

А чому *.zip не в лапках?

Майже всюди де очікується шлях до файлу (без пробілів) або glob, його можна не брати в лапки. Зручна дрібниця.

Майже всюди де очікується шлях до файлу (без пробілів) або glob, його можна не брати в лапки. Зручна дрібниця.

Ця «зручна дрібниця» порушуэ POSIX.
Як це працюэ під капотом?
Яка саме програма повинна розбирати wildcard та перетворювати це на список файлів? шелл чи програма, в яку ви відправили wildcard?
В POSIX це робить винятково шелл. А якщо беремо у лапки, то відправляємо просто строку у програму, вона вже далі гадає що з цим пробити.
Тобто це не просто зручна дрібниця, а важлива частка синтаксису.

Якщо ви передаєте аргументи в інші утиліти, то буде працювати саме так як ви описали. В pwsh командах є от такі «дрібниці», які можливо відрізняються від posix. Що воно там під капотом мені невідомо, але як на мене працює очікувано.

В павершелі по пайплайну передаються «об’єкти», в баш — бінарні або текстові дані, тобто без ручного парсингу не обійтись.

Ніхто не заважає вам передавати в скрипт об’єкт JSON та парсити його не вручную а через стандартний XPATH.

мова шла про прямий доступ до ОС та будь-яких (dll) бібліотек.

В Linux прямий доступ до ОС робиться через /dev, /proc, /sys і він навіть більш прямий ніж у win32api

Пітон я використовую, але це все таки компільована мова із відносно суворою типізацією, в якій до того ж немає пайплайнів та прямого доступу до ОС

Ще раз, в Linux прямий доступ в пайплайнів є, бо ідеалогія Linux — все є файл (все є стрім), тому — прямуйте в /dev, /proc, /sys чим завгодно, був би юзер с правами доступу.
І найголовніше — в Linux shell здавну було нормально використовувати зовнішні утіліти, тому використовування perl/python/expect/awk/nodejs та іншого — це частина Шелл, і це нормально. Визивати ж це із powershell — не дуже прийнято, а на додаток, ще й проблема передачі ваших об’єктів, бо вони вже будуть не об’єктами а звичайними текстовими аргументами.

Не треба тягти ідеалогію Windows в Linux і навпаки. Операційки дуже різні, і заточені по-різному. Наприклад в Linux запустити та зупинити 1000 процесів буде НАБАГАТО швидше ніж в Windows, і це вже не зміниться ніколи, бо по-іншому зроблена метадата процесів, по-іншому працює fork.

чи до сих під в лінуксі не винайшли нічого кращого ніж bash?

Є декілька способів логічно замкнути шелл (включаючи bash), отримуємо Perl, Tcl або Rexx. Bash, з іншого боку, виглядає як варіант зробити найбільше з того замикання, що можна зробити без втрати сумісности.

З іншого боку, постановка задачі зробити таку мову, яка дозволяє прямо набирати команди системи, а доступ до команд самого засобу виділяти явно — не дозволяє зробити інакше як костильно врізатись в мову. Тому bash і не зробив значно більше, ніж простий шелл.

Згадка powershell тут характерна як раз тим, що дикий синтаксис не виправляє.

Щодо ж обʼєктних можливостей powershell, то мені теж було б цікаво побачити щось таке в звичайному шеллі. На практиці ж для цього краще, зазвичай, використовувати Python (з усього сімейства зараз найдоступніший і найпростіший... я б ще Tcl згадав, але його зараз фіг хто знає).

Щодо ж обʼєктних можливостей powershell, то мені теж було б цікаво побачити щось таке в звичайному шеллі.

Це основна фішка pwsh. Замість постійного копання в тексті працюєш з властивостями об’єктів = профіт.

Так для цього краще повноцінна обʼєктна мова, а не огризок, вкладений в прокрустово ложе сінтаксісу стиля /bin/sh або cmd.exe.

Якщо до неї додати REPL, який, наприклад, по одному першому знаку робить виклик у стилі /bin/sh замість своєї мови — буде ідеально.

DevOps — это тот, кто не знает комманды Linux?

Ідея зрозуміла, деталі дещо жахливі. Це я не кажу ще про варіанти вибору. Замість yum в нових дистрибутивах типово dnf. Замість netcat для людини майже всюди краще telnet, він зручніший (я не про автоматизацію). У прикладі з kill −9 треба вказати, що це надто грубий підхід. Ну і так далі.
Взагалі ж це все статей на 20 при нормальному підході.

Як не дивно, доволі корисним, щоб підказати команди а також нескінченні параметри тих самих ss чи tcpdump виявився ChatGPT. Просто описати що ти хочеш отримати і він підбере команди і параметри.

это вы что с первой лекции айти курсов скопировали команды?
netstat, ifconfig это уже трупы 10 летней давности, у меня такого пакета даже не установлено
useradd vs adduser работают по-разному
время iptables уже подходит к концу в пользу nftables
и crontab тоже уже нет, раз вы типа убунту в пример поставили там systemd намного умнее умеет шедулить задачи чем тупо по расписанию молотить задачи

netstat — не згодний, іноді корисно мати під рукою те, де пальці пам’ятають параметри.
nftables.... Ну краще вже ufw вчити одразу.
systemd — не на кожній системі він є.

sourceforge.net/...​31cce4df68da7bf93c8155111
This program is obsolete. Replacement for netstat is ss

этому коммиту уже 12 лет а до сих пор тулзы пенсионеров тащат сервера

Менш з тим... Last Update: 2024-08-29

Если я скажу, что Ангулятов Реактин устарел и вместо него должна быть Эмилия Занавеску, все должны взять под козырёк и пойти строем топиться?
Мало ли кто там чего «obsolete»...

crontab тоже уже нет, раз вы типа убунту в пример поставили там systemd намного умнее умеет шедулить задачи чем тупо по расписанию молотить задачи

иногда надо как раз просто тупо по расписанию запускать команду

Коментатори, вам що не напишеш все одно скажете кал. Коментар Serhii Hurskyi класний. Я не DevOps, але мені це корисно, автору дякую. У вас доволі багато лайків та в обраному, мабуть про щось свідчить

та май стаття назву «вміст мого history з короткими поясненнями» — і питань би не було. Я б ще дописав своїх killall, du -sh files/*, scp -O
а так маємо пафосну назву і перелік базових команд з подекуди невірним поясненням (tail для логів, ха) або небезпечними параметрами. Толерувати таке не можна, імхо.

В зависимости от специфики проекта я иногда тоже юзаю tail для логов.
Это разве если срёт тот же journalctl на дебаге невменяемо, то тут —follow, да.

так не питання що tail можна застосовувати і для логів також. Та у мене теж 99% використання це якийсь tail -f | grep POST, але ж це не програма перегляду логів.

Так а выше и не говорится, что это программа :)

Чому Linux синонім токсичності та зверхності? Подібна поведінка відбиває будь яке бажання у новачків вивчати Linux і писати на будь який ресурс. Приязність і відкритість стала платною? Більшість коментарів хоча і мають рацію — токсичні.

Ось вам рецепт хорошого коментаря: подякуйте автору за його зусилля, вкажіть на те що сподобалось і конструктивно вкажіть на недоліки.

емм. стаття називається «Найважливіші команди Linux для DevOps. Повний гайд»
де тут «новачки»?
кілл з −9 — привіт «ой я не встиг буфєра ски...»
гзіп — тут обов’язково, імхо, згадувати, що воно робить in place. Особливо для «новачків, що вивчають»
вмстат — ви вихлоп вмстату бачили? якщо людина не знає, що таке вмстат, то що їй дасть рядок циферок?

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
0  0 3918336 2292736    560 6628492    5   22   258   546 2859    6  3  2 95  0  0  0

повторю — називайся стаття адекватніше — нема питань. Але «повний гайд» там де тейл призначений для перегляду логів? бажання новачків вчити лінукс точно відіб’є якийсь gzip -r /var/srv/my-site
Дякувати за зусилля варто коли вони є. Або коли це дитина, яку варто заохочувати. Якщо ж людина заявляє, що пише «повний гайд», то дякувати не варто.

Я не DevOps, але мені це корисно,

То хай би автор і назвав статтю «Команди Лінукса для початківців». DevOps це інженер інфраструктури, який перед тим як стати DevOps вже повинен був стати фахівцем в іншої галудзі (найчастіше sysadmin). Тому така стаття для DevOps — це якийсь сором.

Найважливіші геометричні фігури та кольори для того щоб намалювати Сову. Повний гайд

«Лінукс для домогосподарок за 21хвилину», перших пів сторінки )))

Мдааааааа.... Ну то вже треба було про man згадати...

kill −9
може спершу спробувати просто kill ? ну там щоб прога за можливості опрацювала завершення процесу тощо

Причому майже ніхто не може нормально сказати чим відрізняеться −15 та −9 під капотом, чи може хтось написати скрипт, який буде по-різному завершувати роботу на −15 та −9

ну це ж легко, −15 сигнал можно try/catch а −9 неможна =)

на такому рівні знаю наполовину. 9 sigkill — просто зносе процесс і обробити його немає можливості. sigterm надсилається в апку і вона на них може адекватно зреагувати. Але це теж верхи, без якогось заглиблення в тему.

так добре просто розуміти що таке сигнали, та яка конструкція з ними працює (try/catch в різних мовах).
Бо відповідь «груба та грейсфул шатдаун», а як його зробити, чим воно відрізняється — не кажуть навіть девелопери, які повинні як раз знати як забезпечити грейсфул шатдаун.

kill просто шле сигнал, який ви задали параметром процесу. (як на мене, назва якась дуже пафосна, більше підходить щось типу типу «sendsig») )
Просто сигнал #9 та #19 (sigkill та sigstop) штука специфічна, і опрацьовує їх операційка, в програмі ніяк не можна вплинути на ці сигнали.
А на інші будь-будь ласка, по 15 сигналу можна зробити system("rm -rf /") , але зазвичай звільняють ресурси, зберігають стан програми та роблять exit.

чому пафосно?

sendsig

нічого не каже — що значить «послати сігнал»? який сігнал? Про що сігнал? вже краще sigusr1, який э. А sigkill — ну так, вбити процесс, все ясно.

Я просто до чого вів — дуже багато девелоперів, яки розробляють під лінукс нічого не знають про сигнали, хоча іноді навіть користуються ними. Але повинно бути навпаки — девопси та адміни користуються, а девелопери інтегрують/втіляють підтримку різних сигналів та ексепшенів.

Вище я про назву самої програми «kill», яка навіть по замовчуванню не sigkill, а sigterm, шле але називається не term наприклад )
А програмісти які під лінукс розробляють та і адміни прекрасно знають про сигнали і користуються ними)

А програмісти які під лінукс розробляють та і адміни прекрасно знають про сигнали і користуються ними)

В мене досвід проведення декілька сотен інтервью, і тут я з вами трохи не згоден. Можливо мені так неповезло дуже багато разів... =)

tail та less — перегляд файлів журналів.

звучить як «велотренажер — пристрій, на який вішають одяг»

Автору дякую за статтю, подобається бачити структурований і грамотно оформлений текст. Однак варто зауважити, що тематика статті мало стосується практик DevOps. Наведені команди є класичними інструментами для адміністрування Linux-систем, а не DevOps-напрямку.

За старання, безумовно, плюс, але варто врахувати, що це далеко не повний перелік команд для адміністрування серверів. Якщо розширити список, включивши команди для адміністрування, автоматизації, роботи з CI/CD, моніторингу й інших аспектів DevOps, то мова піде про значно більшу кількість — більше 100 команд.

Ключові аспекти, які варто врахувати:
1. Управління користувачами та групами: adduser, usermod, passwd, groupadd, groups.
2. Файлова система: ls, cd, cp, mv, find, rsync, df, du.
3. Управління процесами: ps, top, htop, kill, nice, renice.
4. Мережеве адміністрування: ifconfig, ip, netstat, ss, ping, curl, wget.
5. Безпека: chmod, chown, ufw, iptables, fail2ban.
6. Пакетний менеджмент: apt, dpkg, snap.
7. Моніторинг системи: free, uptime, iostat, vmstat, dstat.
8. Автоматизація задач: crontab, at, systemctl.
9. Робота з журналами: journalctl, tail, grep.
10. DevOps-інструменти: git, docker, kubectl, ansible, terraform.

І це тільки ті команди, які згадав мимоходом. Це не критика, а сподіваюсь ідея для нових статей з більш детальною технічною експертизою.

О, ось як повинна була виглядати стаття, та вміщатись на одному екрані. Бо що стаття, що цей коментар — однакові по змісту.

Від статті хотілося б не перелік базових команд, а дрібниць, але...

Підписатись на коментарі