LinuxCamp | DevOps

⚡️ Все о программировании от экспертов BigTech! Собрались разработчики бигтеха и решили создать крутой канал, на котором простым языком расскажут все о мире IT: — Лучшие практики чистого кода — Продвинутые техники и рекомендации по разработке — Подробные разборы вопросов с собеседований — Интересные факты и новости из мира технологий — Полезные open-source утилиты 🌐 Присоединяйся к нам и учись на скоростях: IT CoLibry

docker init: как использовать на Windows Команда "docker init" создает стартовые файлы, связанные с Docker, для вашего проекта == автоматически генерирует их для запуска приложения под ваш стек. Docker init сейчас доступен только на Docker Desktop на Windows и MacOS, в большинстве ОС на linux данной команды нет:

- .dockerignore
- Dockerfile
- compose.yaml
- README.Docker.md

Устанавливаем Docker Desktop на устройство если не установлен. Если не имели раньше дела с питухоном питоном, также скачиваем его. Как все готово, создаем рабочий каталог:

mkdir my-fastapi-project
cd my-fastapi-project

Создаем и активируем виртуальное окружение чтобы изолировать зависимости проекта и с помощью команды pip freeze автоматически сформировать requirements.txt, не заполняя его вручную:

python3 -m venv venv
source venv/bin/activate

Cкачиваем необходимые для создания API зависимости с помощью пакетного менеджера pip и сохраняем их в requirements.txt:

pip install fastapi uvicorn
pip freeze > requirements.txt

Создадим в каталоге проекта файл "main.py" с простым API:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"Hello": "Docker Init"}

Теперь наконец можем запустить магию:

docker init

Нас встречает приветственное сообщение, которое просит нас выбрать язык проекта (python), его версию (3.12.7), порт на котором будет слушать приложение (8000). Далее нужно вписать команду для запуска. Он увидел что я работаю с fastapi и предлагает:

uvicorn 'main:app' --host=0.0.0.0 --port=8000

И тут видим, что автоматически были созданы перечисленные в начале файлы! Далее можем абсолютно спокойно поднять контейнер командой:

docker compose up --build

Дожидаемся пока сбилдится наше приложение и проверяем все ли ок. Переходим в браузер и видим заветное:

http://127.0.0.1:8000
{"Hello":"Docker Init"}

LinuxCamp | #devops #docker #bymaga #win

Реально же, SIGKILL не контрится) LinuxCamp | #memes

Из чего состоит Dockerfile Dockerfile - это набор команд, по которым docker собирает образ контейнера. Для начала нужно немного разъяснить, как это работает под капотом. Docker-образ - это как слоеный пирог. Почти каждая инструкция в Dockerfile создает новый слой поверх предыдущих. В одном из предыдущих постов, где мы собирали минимальный образ докера, фигурировал вот такой Dockerfile:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "127.0.0.1", "--port", "8000"]

Его и разберем построчно: 1) FROM - команда, которая создает базовый образ. В нашем случае это python:3.11-slim. Но что это и откуда берется? - из Docker Hub! То есть мы буквально скачиваем зависимость с официального репозитория образов. В хабе имеются образы на многие технологии, языки, базы данных и фреймворки, так что найти нужную базу под проект не будет проблемой. python:3.11-slim — это официальный образ Python версии 3.11 в минималистичной вариации "slim"; 2) WORKDIR - создает рабочую директорию проекта, в которой все команды будут выполняться. Также как и большинство инструкций, создает новый слой; 3) COPY - копирует файлы с хоста в контейнер. Можно заметить, что данная команда выполняется дважды в файле. Сначала копируется только файл requirements.txt для того, чтобы разделить установку зависимостей и основной код. Это делается ради кэширования слоёв: файл зависимостей меняется редко, и при пересборке будет использоваться уже готовый слой; 4) RUN - выполняет команду внутри контейнера на этапе сборки и создаёт новый слой. В данном случае ставит зависимости из requirements.txt; 5) Ещё один "COPY . ." — теперь закидываем остальной код проекта в контейнер. 6) Последняя инструкция CMD - не создает новый слой, там указаны команды которые выполняются при запуске контейнера. В нашем Dockerfile выполняются команды запуска fastapi-приложения: — "uvicorn" - сервер, который запускает fastapi-приложение — "main:app" - main — это имя файла python, а app — это объект fastapi внутри этого файла. — "--host", "127.0.0.1" - указывает, что сервер будет слушать на локальном интерфейсе. — "--port", "8000" - указывает порт, на котором работает приложение. LinuxCamp | #devops #docker #bymaga

🧩 Соберите свой комплект курсов как пазл! 3 видеокурса на ваш выбор за 55 000₽ Больше не нужно тратить время и деньги на лишнее — соберите персональный набор курсов под ваши цели и прокачивайте только те навыки, которые действительно нужны.  Собрать свой пазл  ➡️ по ссылке

Удаление файлов старше n дней Пользователи иногда сталкиваются с ситуацией, когда нужно почистить определенный каталог, удалив из него старые файлы, которые давно не используются. Через стандартный GUI проводник это делать не всегда удобно. Через терминал - самое то) Для CLI существует специальная команда find, которая отвечает за поиск файлов. Подробно говорили о ней тут. С помощью опции "-mtime" получится найти только те файлы, дата изменения которых старше заданного временного промежутка. В качестве примера возьмем каталог Downloads и срок в 35 дней:

$ find ~/Downloads -type f -mtime +35

Следующий шаг – непосредственно чистка:

$ find ~/Downloads -type f -mtime +35 -delete

Вам необязательно действовать напрямую и стирать сразу же все файлы. Их можно отсортировать дополнительно по еще одному признаку, например, по названию или расширению. Для этого есть опция "-name":

$ find ~/Downloads -name "*.zip" -type f -mtime +35 -delete

Также, чтобы сгоряча не удалить нужный и недавно используемый файл, можно для каждого элемента вывода выполнить "ls -l" и посмотреть дату последнего изменения ресурса:

$ find ~/Downloads -type f -mtime +5 -exec ls -l {} \;
... Feb 17 17:30 ./file

LinuxCamp | #microhelp #utils

⚡️ Айтишник из «VISION» скупил курсы айти школ и выложил гигабайты материалов к себе Каждый найдет что-то по душе: 1202 ГБ — Python 1811 ГБ — Frontend 1100 ГБ — C / C++ / C# 804 ГБ — Java 411 ГБ — SQL & БД 309 ГБ — DevOps 998 ГБ — ИБ & Хакинг 773 ГБ — Kotlin / Swift 189 ГБ — PHP 201 ГБ — GoLang 170 ГБ — Rust 167 ГБ — QA / Тестирование 310 ГБ — 1C + Лицензии 495 ГБ — Машинное обучение 704 ГБ — Аналитика Данных 991 ГБ — Дизайн Материалы в закрепе, постоянно пополняются👆🏻

Если часто просматриваешь логи, помни про "tail -f" Команда "tail -f" отображает последние строки файла и продолжает обновлять вывод в реальном времени. Это особенно полезно, когда работаешь с журналами, типа syslog. Утилиты head и tail рассматривали тут. Много раз слышал от людей, что они для дебага какого-то функционала сначала инициировали вывод в syslog, после чего либо через GUI редактор, либо через постоянный вызов tail просматривали логи. Как-то неэффективно... Для решения задач такого типа предлагаю использовать:

$ tail -f /var/log/syslog

Если нужно отображать больше последних строк, чем по дефолту, дописывайте флаг "-n". Когда дополнительно нужно прогнать вывод через фильтр, grep в помощь:

$ tail -n 100 -f /var/log/nginx/access.log

$ tail -f /var/log/nginx/error.log | grep "timeout"

Я помню, как сам мучился с дебагом, когда не был в курсе про этот чудо-флаг) Дело в том, что не все приложения выдают лог в консоль. Если вы работаете с демоном, то у него нет управляющего терминала и все идет в журналы. Как раз тут и было бы весьма удобно использовать "tail -f". LinuxCamp | #microhelp #utils

⚡️ Ты неправильно используешь нейросети! Нет смысла писать в ChatGPT обычные вопросы, пока кто-то с помощью других ИИ получает себе профессии. Подписывайтесь, тут айтишник делится нейросетями, которые ищет каждый: https://t.me/+J76vZFqMsJBmZGYy

Пацаны/девчата, напоминаю, что у нас есть чат "LinuxCamp | Chat", в котором вы можете задавать вопросы по администрированию, разработке и прочим техническим штукам. Там и я подмогу и другие активисты. Добавил в него бота-модератора, с которым по приятнее должна быть атмосферка)

Как узнать тип сессии: Wayland или Xorg? Многие популярные дистрибутивы уже используют Wayland по умолчанию. Однако у Wayland всё ещё есть проблемы. Многие старые программы не поддерживаются или работают плохо. Если у вас возникли какие-либо проблемы при работе с старыми программами, нужно проверить какой дисплейный сервер вы используете. Есть несколько способов сделать это. Самый простой способ посмотреть какой дисплейный сервер используется в данный момент, это вывести содержимое переменной окружения XDG_SESSION_TYPE:

$ echo $XDG_SESSION_TYPE
wayland

Кроме того, можно узнать тип текущей сессии с помощью loginctl. Для этого нужно сначала вывести список активных сессий через list-sessions:

$ loginctl list-sessions

SESSION  UID    USER      SEAT  TTY  
3      1000    parallels   seat0 tty2 
c1     127       gdm      seat0 tty1 
 
2 sessions listed.

Потом выводим тип конкретной сессии через опцию show-session:

$ loginctl show-session 3 -p Type
Type=wayland

Или можно сделать всё одной командой, получив идентификатор сессии из переменной окружения XDG_SESSION_ID (если определена):

$ loginctl show-session "$XDG_SESSION_ID" -p Type

LinuxCamp | #microhelp #sessions

Где же сидят эти службы? Прежде всего нужно упомянуть, что службы Systemd можно разделить на две категории: 1) системные службы, которые запускаются от суперпользователя. Для управления такими службами нужно использовать sudo. 2) пользовательские службы, которые запускаются от определённого юзера, который имеет над ними полный контроль без необходимости в sudo. Системные службы лежат в: 1) /usr/lib/systemd/system; 2) /lib/systemd/system; 3) /etc/systemd/system; Пользовательские служы лежат в: 1) /usr/lib/systemd/user; 2) /lib/systemd/user; 3) /etc/systemd/user; 4) /home/user/.config/systemd/user; Файлы сервисов, поставляемые с пакетами, как правило, располагаются в каталогах lib и /usr/lib, а в /etc/ расположены модифицированные юниты, переопределяющие стандартные настройки. LinuxCamp | #systemd

Курсы пройдены. Диплом на руках. А оффера всё нет? Вы не одиноки. Многие разработчики застревают между «я всё знаю» и «меня никто не зовёт». На этой неделе в канале «Код Меркури» вместе с опытным DevOps-инженером мы разбираем: 📌 как заявить о себе в IT? 📌 зачем вам pet-проекты и личный бренд? 📌 и что нужно, чтобы не быть вечным мидлом? С 31 марта по 4 апреля — реальные кейсы, ошибки и советы из практики. Подпишитесь на @mercdev, чтобы прокачать карьеру — по-настоящему. #реклама О рекламодателе

systemd: проверка статуса службы Система инициализации Systemd позволяет не только запускать и останавливать службы, но и проверять их состояние. Для просмотра информации о сервисе используется команда status утилиты systemctl. Например, чтобы посмотреть состояние docker нужно выполнить:

$ systemctl status docker
 
docker.service - Docker Application Container Engine 
Loaded: loaded (/lib/systemd/system/docker.service; enabled;> 
Active: active (running) since ...

Давайте рассмотрим полный вывод: Loaded - означает что файл юнита загружен успешно и здесь же выводится путь к этому файлу. Тут возможны и другие значения, например, masked если юнит скрыт или not-found если он не найден. Также здесь находится информация добавлен ли юнит в автозагрузку (enabled/disabled); Active - текущее состояние и подсостояние юнита, если он запущен, выводится active(running), если он не был запущен, то inactive(dead) если что-то пошло не так, failed и т.д. Docs - название man страницы с документацией для службы. Process - запускаемые процессы, их состояние и код выхода. Main PID - идентификатор основного процесса службы. Tasks - количество процессов, запущенных в рамках этой службы. Memory - потребление памяти службой. CPU - использование процессора службой. Для того чтобы посмотреть все доступные значения состояний для полей Loaded и Active выполните:

$ systemctl --state help

Списочек получите некороткий) За доп. инфой направлю вас в man. После всех полей статуса выводится журнал службы - последние 10 строк вывода основного процесса. Если хотите получить больше строк, используйте опцию "--lines" с нужным количеством:

$ systemctl status --lines=50 avahi-daemon

LinuxCamp | #systemd

Собираем минимальный Docker образ Docker — это инструмент для запуска приложений в изолированных контейнерах. Он делает разработку и развертывание проще, быстрее и безопаснее. Нужен он для: изоляции приложений и зависимостей, переносимости (софтина работает одинаково на любой системе) и DevOps-процессов. Плюсы докера: простота развёртывания, экономия ресурсов по сравнению с виртуальными машинами, стандартизация окружения. Минусы докера: не подходит для задач, требующих полной виртуализации, не оптимален для GUI-приложений, требует грамотной настройки безопасности. Минимальный пример запуска первого Docker-контейнера с Python (FastAPI): 1. Для развертывания для начала создадим новый проект и установим зависимости. Если не имели раньше дела с питухоном питоном и докером, также скачиваем все необходимое:

$ sudo apt install python3 python3-pip -y
$ sudo apt install docker.io -y

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

$ mkdir fastapi_backend && cd fastapi_backend

Активируем виртуальное окружение, чтобы изолировать зависимости проекта и с помощью команды pip freeze автоматически сформировать requirements.txt, не заполняя его вручную:

$ python3 -m venv venv
$ source venv/bin/activate

Cкачиваем необходимые для создания API зависимости с помощью пакетного менеджера pip и сохраняем их в requirements.txt:

$ pip install fastapi uvicorn
$ pip freeze > requirements.txt

2. Создадим в каталоге проекта файл "main.py" с простым API:

$ touch main.py

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "LinuxCamp"}

3. Ну и наконец добавим в локальный каталог сам Dockerfile - это инструкция по созданию docker контейнера. Cейчас приведу общий пример, в следующих постах подробнее разберем его структуру:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "127.0.0.1", "--port", "8000"]

4. На этом все! Мы уже можем собрать свой Docker-образ и запустить его, после чего приложение будет доступно по адресу ниже:

$ sudo docker build -t myapp .
$ sudo docker run -d -p 8000:8000 myapp

$ curl -L http://127.0.0.1:8000 
$ {"Hello":"LinuxCamp"}

http://127.0.0.1:8000

Также можно посмотреть наличие нашего docker контейнера в списке запущенных контейнеров с помощью команды docker ps:

$ docker ps

CONTAINER ID   IMAGE                     COMMAND             
640d6f4d1acb   fastapi_backend   "uvicorn main:app --…" 

LinuxCamp | #devops #docker #bymaga

Чемпионат для подростков по 14 направлениям от «Алабуга Политех»☺️ Программирование и Битва роботов, Экономика и Юриспруденция, 3D моделирование и Английский язык и многое другое, чтобы каждый нашел свою дисциплину. Для участия тебе нужно☺️ ☺️Оставь заявку на сайте😀 ☺️Пройди заочный этап на HR-платформе: Business Cats до 1,0 по «Общению» и «Аналитике» для оплаты дороги туда и обратно😀 ☺️Приезжай на чемпионат😀 Мы предлагаем тебе☺️ ☺️Общий призовой фонд турнира составляет 450 000 рублей😀 ☺️Проживание и дорога бесплатно😀 ☺️Возможность поступить в «Алабуга Политех»😀 Участвуй в турнире от образовательного центра мирового уровня и получай призы и преимущество в поступлении☺️

Как сделать службу недоступной? Иногда возникает необходимость удалить службу Systemd или хотя бы сделать её недоступной для использования. Сам юнит файл удалять нет смысла, потому что при следующем обновлении пакета он восстановится. Самый простой способ избавиться от службы - это удалить пакет, вместе с котором она поставляется. Сначала нужно найти путь к файлу юнита. Это можно сделать с помощью команды "status":

$ systemctl status docker

docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Теперь узнаем имя пакета, с которым служба поставляется. Если мы работаем с deb сборками, используем флаг "-S":

$ dpkg -S /lib/systemd/system/docker.service
docker.io: /lib/systemd/system/docker.service

После того, как имя пакета известно, удаляем его:

$ sudo apt remove docker.io 

Если вы не хотите удалять пакет, например, потому что он системный и это может что-то сломать, можно замаскировать службу. Замаскированные службы нельзя запустить вручную и они не активируются на старте системы (даже если добавлены в автозагрузку). Для маскировки используется команда mask:

$ sudo systemctl mask docker
Created symlink /etc/systemd/system/docker.service → /dev/null

Прикольно, конечно, реализована маскировка - в системном каталоге для сервисов создается симлинка на устройство "/dev/null" (говорили о нем тут). Если посмотрим на состояние службы, увидим, что она замаскирована:

$ sudo systemctl status docker
docker.service
Loaded: masked (Reason: Unit docker.service is masked.)

Для того, чтобы убрать маскировку используем команду unmask. Ссылка удалится и не будет мешать старту сервиса:

$ sudo systemctl unmask docker
Removed /etc/systemd/system/docker.service.

LinuxCamp | #systemd

😎 PyLinux - канал для тех, кто изучает Python и хочет начать разбираться в Linux! ➡️ Почему не стоит упустить: - удобные инструменты Linux - библиотеки и полезные материалы по Python - bash скрипты и гайды - а также, многое другое! 🔥 Заходи прямо сейчас, чтобы не потерять - PyLinux!

Полезные опции для поиска файлов через grep Иногда нужно найти один/несколько файлов, содержащих определённую строку в: логах, конфигах или исходном коде. Для этого очень часто под рукой оказывается утилита grep. Для сводки, интересные флаги и регулярные выражения для grep мы рассматривали тута. По умолчанию команда фильтрует один файл. Для того чтобы выполнять поиск по каталогу, нужно добавить флаг "-r":

$ grep -r "root" /etc/
/etc/mdadm/mdadm.conf:MAILADDR root
...

Если хотим подсветить вхождения цветом, используем опцию "--color=always":

$ grep --color=always -r "root" /etc/

Опции "-C, -B, -A" вообще имбовые, использую их целую неделю) Вы можете включить отображение не только текущей строки, в которой было найдено вхождение, но и n строк до/после: 1) -C: выводит n строк до и после вхождения;

$ grep -C2 -r --color=always "Hello3" ./
./hello-Hello1
./hello-Hello2
./hello:Hello3
./hello-Hello4
./hello-Hello5

2) -B: выводит n строк перед вхождением;

$ grep -B2 -r --color=always "Hello3" ./
./hello-Hello1
./hello-Hello2
./hello:Hello3

3) -A: выводит n строк после вхождения;

$ grep -A2 -r --color=always "Hello3" ./
./hello:Hello3
./hello-Hello4
./hello-Hello5

Если наш шаблон поиска походит на регулярное выражения, нужно использовать флаг "-F". Таким образом мы говорим команде искать ровно то, что мы запросили - без скрытых подтекстов. Без флага мы получим строки, в которых присутствует хотя бы 1 символ из набора (H, e, l, o). С флагом получим строки с буквальным совпадением:

$ grep "[Hello]" hello
Help me please
Helloup
[Hello]

$ grep -F "[Hello]" hello
[Hello]

LinuxCamp | #utils

⚡️ Дождались! Ребята сделали крутейший канал про Linux Здесь на простых картинках и понятном языке обучают работе с этой ОС, делятся полезными фишками и инструментами Подписывайтесь: @linuxos_tg