DevOps Portal | Linux

Освой сети и командную строку с лучшими обучающими каналами 🤩 Network Admin - обучающий канал по сетевым технологиям 🤩 Network Admin | Guides - канал, где рассказывают полезную информацию про Windows/Linux 📱 BashTex - обучение работе с командной строкой

— Команды Docker для сетевого взаимодействия 🔹Подключение контейнера к сети Для подключения контейнера к сети используйте команду docker network connect:

docker network connect mynet container1

Это добавит контейнер container1 в сеть mynet. 🔹Создание сети Для создания новой сети используйте команду docker network create:

docker network create --driver bridge mynet

Это создаст новую сеть bridge с именем mynet. 🔹Отключение контейнера от сети Для того чтобы отключить контейнер от сети, используйте команду docker network disconnect:

docker network disconnect mynet container1

Это удалит контейнер container1 из сети mynet, и контейнер больше не сможет общаться с другими контейнерами в этой сети. 🔹Просмотр сети Для просмотра настроек сети и подключённых контейнеров используйте команду docker network inspect:

docker network inspect mynet

Эта команда выводит низкоуровневые данные о сети и её пирах. 🔹Список доступных сетей Для отображения всех сетей на хосте Docker используйте команду docker network ls:

docker network ls

Эта команда выведет список сетей, их идентификаторы, типы драйверов, IP-адреса и другие данные. 🔹Удаление сети Для удаления сети, которая больше не используется, используйте команду docker network rm:

docker network rm mynet

Эта команда удалит сеть mynet с хоста. Контейнеры больше не смогут обмениваться данными по этой сети. 🔹Публичное сетевое взаимодействие По умолчанию контейнеры не имеют доступа к публичной сети и изолированы от внешней сети. Чтобы открыть порты, используйте аргумент -p при запуске контейнера:

docker run -p 80:5000 myapp

Эта команда направит внутренний TCP-порт 5000 на внешний порт 80. Контейнер теперь будет доступен на порту 80 с внешней сети. — Заключение Сетевое взаимодействие Docker предоставляет различные драйверы сетей для изоляции или соединения контейнеров. Сетевые драйверы bridge просты в использовании, но драйверы overlay и macvlan предоставляют больше гибкости. Команды для работы с сетями позволяют создавать сети, подключать контейнеры и настраивать параметры. В целом, сетевые возможности Docker предоставляют мощные инструменты для проектирования распределённых приложений. 👉 DevOps Portal

Сетевое взаимодействие в Docker Сетевое взаимодействие Docker позволяет контейнерам общаться друг с другом и с внешним миром. Docker поддерживает различные типы сетей, каждый из которых предназначен для определённых случаев. В этом посте мы рассмотрим драйверы сетей, предоставляемые Docker, и приведём практические примеры. — Драйверы сетей Docker Docker упрощает коммуникацию между контейнерами, создавая сеть по умолчанию — bridge (мост), что позволяет разработчикам сосредоточиться на создании и запуске контейнеров, не беспокоясь о сетевом взаимодействии. Хотя эта сеть по умолчанию подходит для большинства случаев, Docker также предлагает другие варианты. Docker позволяет создавать три различных типа сетевых драйверов «из коробки»: bridge, host и none. Однако эти драйверы могут не подходить для всех случаев, поэтому мы также обсудим пользовательские сети, такие как overlay и macvlan. Давайте рассмотрим каждый из них более подробно. 🔹Драйвер Bridge Драйвер по умолчанию для сетей Docker — это драйвер bridge. Он создаёт частную сеть внутри хоста. Каждый контейнер, подключённый к сети bridge, получает внутренний IP-адрес, что позволяет контейнерам на одной и той же bridge-сети обмениваться данными. Для внешнего доступа необходимо открывать порты. Драйвер bridge создаёт интерфейс docker0 на хосте, который служит шлюзом между контейнерами и внешней сетью. Он управляет маршрутизацией между внутренними и внешними интерфейсами. Этот драйвер подходит, когда контейнеры должны работать в изолированном режиме, но иметь возможность обмениваться данными между собой. Однако использовать драйвер bridge не рекомендуется для рабочих (продакшн) окружений, так как контейнеры общаются через IP-адреса, а не через автоматическое обнаружение сервисов, чтобы сопоставить IP-адрес с именем контейнера. 🔹Драйвер Host Как следует из названия, драйвер host использует сетевую инфраструктуру хостовой машины, исключая сетевую изоляцию между контейнером и хостовой машиной, на которой работает Docker. Например, если контейнер использует порт 80 и применяется хостовая сеть, то приложение контейнера будет доступно на порту 80 IP-адреса хоста. Этот драйвер используется, если необходимо полагаться на сетевую инфраструктуру хоста, а не на Docker. Однако драйвер host несовместим с Docker Desktop и требует использования хостовой машины на базе Linux. Хостовые сети устраняют абстракцию контейнера, и их следует использовать с осторожностью, так как могут возникнуть конфликты портов между контейнерами и хостом. 🔹Драйвер None Драйвер none предоставляет контейнеру доступ к сети только через интерфейс loopback. Это полностью изолирует контейнер от внешних сетей. Такой драйвер полезен для приложений, которые обмениваются данными только внутри себя, а также для высокозащищённых приложений, где критична максимальная изоляция или когда сетевой доступ вообще не требуется. 🔹Драйвер Overlay Overlay-сети позволяют контейнерам на разных хостах Docker обмениваться данными в Docker Swarm. Это использует встроенное шифрование и распределённую компоненту для маршрутизации трафика между участвующими хостами. Overlay-сети позволяют контейнерам на разных хостах внутри кластера Swarm общаться так, как если бы они находились в одной локальной сети. Несколько приложений могут использовать одну и ту же overlay-сеть, но оставаться изолированными друг от друга. Это полезно для крупных распределённых приложений. 🔹Драйвер Macvlan Драйвер macvlan назначает каждому контейнеру уникальный MAC-адрес для виртуального сетевого интерфейса, что делает контейнеры видимыми как физические устройства в сети. Контейнеры получают уникальные IP-адреса во внешней сети. Этот драйвер даёт контейнерам такую же сетевую видимость, как у физических хостов, но при этом сохраняется абстракция Docker. С этим драйвером могут возникать конфликты IP-адресов между контейнерами и хостами.

💡 Быстрый совет по Linux Проверить bash-скрипт на синтаксические ошибки можно командой:

bash -n scriptname

👉 DevOps Portal

SuperHardio Вrothers*. Часть 3: Найти лису и обезвредить В этой серии боремся с уязвимостями платформы для совместной разработки GitLab - усложняем злоумышленникам путь к платформе и уменьшить поверхность атак на инфраструктуру. А также: — Обсудим популярность GitLab и архитектуру конфигураций платформы, — Поговорим о недопустимых событиях и параметрах безопасности, — Разберемся, с какими проблемами безопасности можно столкнуться при внедрении, настройке и масштабировании, — Построим лабиринт для хакера: разберем методы харденинга GitLab и лучшие практики безопасности платформы. Регистрируйтесь и присоединяйтесь к вебинару 4 марта в 17:00 МСК * SuperHardio Вrothers — герои-эксперты харденинга

Awesome-limits Репозиторий содержит полезную подборку ресурсов, связанных с различными ограничениями в вычислениях: лимиты файловых дескрипторов, памяти, процессов, сети и других аспектов операционных систем и облачных сервисов. Некоторые полезные материалы из репозитория: 🔹Ограничения в Linux (например, ulimit, sysctl). 🔹Лимиты облачных сервисов (AWS, Google Cloud, Azure). 🔹Ограничения баз данных (PostgreSQL, MySQL). 🔹Сетевые лимиты (максимальное количество подключений, ограничение портов). https://github.com/lorin/awesome-limits 👉 DevOps Portal

💡 Быстрый совет по Linux 🐧 Найдите недавно изменённые файлы за последние 5 минут:

find . -type f -mmin -5

Полезно, когда вы устраняете неполадки и хотите знать, какие файлы были недавно изменены 👉 DevOps Portal

🧑‍💻ТОП 2 канала для тех кто увлекатеся хакингом и кибербезопасностью: Этичный Хакер — крупнейший в СНГ канал по информационной безопасности. OSINT, анонимность, пентест, социальная инженерия. Лаборатория Хакера — авторский канал от специалиста по ИБ. Новости даркнета, сетевая разведка, обзоры инструментов с github, полезные подборки.

Лучшие практики Terraform, которые вам нужно знать 1. Структура кода, качество кода и организация Никогда не храните всю конфигурацию в одном main.tf файле. Разделяйте файлы по папкам в зависимости от ресурсов, окружений, регионов и проектов. Если конфигурация простая, используйте команду terraform workspaces для управления несколькими окружениями. Это также ускоряет выполнение Terraform. Стандартизируйте соглашения по именованию. Используйте входные и выходные переменные — не хардкодьте значения, которые можно передавать в переменные или получать из источников данных. 2. Поддерживаемость и повторное использование Создавайте переиспользуемые модули для инфраструктурных компонентов (ресурсные и инфраструктурные модули). Храните модули в отдельном репозитории или в специальной директории (modules/). Думайте о них как о шаблонах для ваших ресурсов. Старайтесь, чтобы ресурсные модули были максимально простыми. 3. Управление состоянием Всегда используйте удаленное хранилище для файлов состояния. Варианты хранения: 🔹S3 с блокировкой DynamoDB (AWS) 🔹Google Cloud Storage 🔹Azure Storage 🔹Terraform Cloud 🔹MinIO (самостоятельный хостинг) 🔹GitLab (да, GitLab поддерживает хранение состояния Terraform) 4. Практики безопасности 🔹Избегайте хардкодинга секретов. Используйте переменные окружения или инструменты управления секретами, такие как Hashicorp Vault, AWS Secrets Manager, Google Secret Manager. 🔹Шифруйте файл состояния в удаленном хранилище. 🔹Управляйте доступом к файлу состояния через IAM-политики. 🔹Избегайте использования учетной записи администратора. Определите IAM-роль или сервисный аккаунт для выполнения Terraform. 5. Продвинутый подход: применяйте принцип DRY с Terragrunt Terragrunt — это обертка для Terraform и инструмент для оркестрации инфраструктуры. Он нативно поддерживает инфраструктурные модули и управляет зависимостями, что позволяет уменьшить дублирование кода. Именно поэтому ключевой принцип — DRY (Don't Repeat Yourself — Не повторяйся). 👉 DevOps Portal

💡 Быстрый совет по Linux При работе в редакторе nano нажмите Alt+# чтобы отобразить номера строк 👉 DevOps Portal

Войти в айти НЕ ИЗИ! 😬 Тебя не бесят «гуру», которые обещают зп от 300к после двух недель на их легендарном курсе по Python за 150к? 😂 - Меня ДА! Забудь про «развалить айти рыночек своим умищем»❌ Чтобы стать программистом, надо пропахать как чёрт за партой хотя бы годик! А чтобы не свихнуться в одиночку, залетай в чат начинающих Python-щиков, где ты получишь: 1️⃣ Разбор сложных вопросов простым языком 2️⃣ Поддержку тех, кто тоже с 0 учит Python, и не боится показаться глупым 3️⃣ Регулярные плюшки в виде стримов от препода с 15-ти летним опытом ➡️А еще, в закрепе есть БЕСПЛАТНЫЙ вводный курс по Python, ну это так, к слову)) Короче, всё для прокачки! Залетай — ссылка на чат (тык)

Автоматизируем выпуск валидных SSL-сертификатов в локальном Kubernetes

В данном туториале максимально просто расскажу и покажу на практике как настроить автоматический выпуск сертификатов в локальном kubernetes так, что бы ваша локальная машина доверяла им. Я постарался написать его так, чтобы даже новичкам можно было настроить свой куб просто следуя данной инструкции

👉 Читать 👉 DevOps Portal

💡 Совет по Docker: Используйте аргументы в вашем Dockerfile для таких вещей, как тег базового образа. Таким образом, вам не придется изменять Dockerfile при каждом обновлении базового образа.

$ docker build --build-arg BASE_IMAGE_TAG=20.04 -t my-image .

👉 DevOps Portal

Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает? Психолог взрослого человека - канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам. ✔️ Как научиться отвлекаться от работы и отдыхать? ✔️ Как совместить кучу рабочих задач и время с семьей? ✔️ Как справиться с прокрастинацией? ✔️ Как не растерять запал, даже если кажется, что ничего не выходит? Подписывайтесь на канал @vadimpetrov_psy и научитесь работать без упахивания, выгорания и ущерба для личной жизни! 👨🏻‍💻 Псс. Заходите в закреп канала - там много полезного, и даже бесплатный мини-курс.

1. Монолитная архитектура: Подходит для небольших приложений с ограниченными требованиями, а также для проектов, не предполагающих значительного роста или необходимости масштабировать отдельные компоненты. 2. Микросервисная архитектура: Подходит для более сложных и масштабных приложений, где важна возможность масштабирования, изоляция отказов и технологическая гибкость. Особенно полезна для организаций с несколькими кросс-функциональными командами, работающими над разными частями приложения. — Заключение Выбор между монолитной и микросервисной архитектурой зависит от конкретных требований, ограничений и целей вашего приложения и организации. Монолитные приложения проще в разработке и развертывании, тогда как микросервисы обеспечивают масштабируемость, отказоустойчивость и технологическую гибкость. Важно тщательно оценить потребности вашего проекта и взвесить все «за» и «против», прежде чем принимать окончательное решение. 👉 DevOps Portal

Микросервисы vs Монолитная архитектура В разработке программного обеспечения выбранный архитектурный подход может существенно повлиять на масштабируемость, удобство сопровождения и общую производительность приложения. Два основных архитектурных шаблона — монолитная архитектура и микросервисы — широко используются в современной разработке. Сегодня мы рассмотрим ключевые различия между ними, их преимущества и недостатки, а также дадим рекомендации по выбору подходящего подхода для конкретного случая. — Что такое монолитная архитектура? Монолитная архитектура — это традиционный подход, при котором все компоненты приложения, такие как пользовательский интерфейс, бизнес-логика и уровень доступа к данным, объединены в единую, неделимую систему. Эти компоненты тесно связаны между собой и развертываются как единое целое. Этот стиль архитектуры используется десятилетиями и остается актуальным для определенных типов приложений. 🔹Преимущества монолитной архитектуры 1. Простое развертывание: Монолитные приложения развертываются как единое целое, что делает процесс развертывания относительно простым. 2. Упрощенная разработка и тестирование: Поскольку все компоненты находятся в одном кодовом репозитории, разработчики могут легче понимать логику приложения, что упрощает разработку и тестирование. 3. Эффективное взаимодействие компонентов: В монолитном приложении компоненты взаимодействуют напрямую, так как работают в одном адресном пространстве памяти, что минимизирует накладные расходы на коммуникацию. 🔹Недостатки монолитной архитектуры 1. Проблемы с масштабируемостью: По мере роста и усложнения приложения становится трудно масштабировать отдельные компоненты независимо. В большинстве случаев приходится масштабировать всю систему, что может быть неэффективно и дорого. 2. Сложности при непрерывном развертывании: Любое обновление или исправление ошибки требует повторного развертывания всего приложения, что может привести к простою и усложнению процесса обновления. 3. Ограничения по технологиям: Монолитные приложения обычно разрабатываются на одном технологическом стеке, что снижает гибкость в выборе новых технологий для отдельных компонентов. — Что такое микросервисная архитектура? Микросервисная архитектура — это подход, при котором приложение строится как набор небольших, независимых сервисов, каждый из которых отвечает за определенную бизнес-логику. Эти сервисы слабо связаны друг с другом, взаимодействуют через четко определенные API и могут разрабатываться, развертываться и масштабироваться независимо. 🔹Преимущества микросервисной архитектуры 1. Гибкость в масштабировании: Каждый сервис можно масштабировать независимо в зависимости от его потребностей, что позволяет более эффективно использовать ресурсы. 2. Изоляция отказов: Если один сервис выходит из строя, это не обязательно влечет за собой сбой всего приложения, так как другие сервисы продолжают работать. 3. Технологическая гибкость: Каждый сервис может быть разработан с использованием наиболее подходящего технологического стека, что позволяет командам выбирать лучшие инструменты и языки программирования. 4. Непрерывное развертывание: Обновления и исправления могут применяться отдельно к каждому сервису, снижая риск сбоев и позволяя выпускать новые версии чаще. 🔹Недостатки микросервисной архитектуры 1. Усложнение системы: Разделение приложения на множество сервисов создает сложности в управлении межсервисной коммуникацией, обеспечении согласованности данных и мониторинге системы в целом. 2. Дополнительные операционные расходы: Управление множеством сервисов требует более сложной инфраструктуры и инструментов мониторинга. 3. Накладные расходы на производительность: Коммуникация между сервисами осуществляется через сеть, что может привести к дополнительной задержке из-за сериализации и десериализации данных. — Выбор между монолитной и микросервисной архитектурой Решение о выборе архитектурного подхода должно основываться на ряде факторов, таких как сложность приложения, требования к масштабируемости, размер команды и цели организации. Вот несколько общих рекомендаций:

💡 Совет по Linux Получайте уведомления, когда ваши команды в терминале завершаются!

$ sudo apt update; notify-send "Обновление завершено" "Получение обновлений завершено"

Замените apt update на любую команду, выполнение которой займет некоторое время. Не забудьте сначала установить inotify-tools:

$ sudo apt install inotify-tools

👉 DevOps Portal

Крутая программа для тех, кто уже работает с Linux и хочет погрузиться DevOps. В двух словах: программа на 2 месяца, ты учишься, тебе еще и платят. Начинка: начинающий и продвинутый курс по Linux, погружение в DevOps. Обучение с практикой, лабораторными и под контролем экспертов из K2 Сloud. Подробнее можно узнать на сайте

🤓 Что такое git stash? Git stash позволяет временно сохранить черновик ваших изменений, которые еще не были зафиксированы (committed), и вернуть рабочую директорию в чистое состояние. Это полезно, если вам нужно переключиться на другую задачу, но вы не хотите коммитить незавершенную работу. — Как работает Git Stash? Когда вы выполняете команду git stash, Git берет все незакоммиченные изменения из вашей рабочей директории и сохраняет их в специальном хранилище (stash) — по сути, это стек отложенных изменений. После этого все незакоммиченные изменения удаляются из рабочей копии, и она снова соответствует последнему коммиту (HEAD). Сохраненные изменения остаются в отдельном месте, пока вы не будете готовы снова применить их. Это позволяет переключаться между ветками, получать обновления из удаленного репозитория, выполнять rebase и другие операции, не мешая текущей незавершенной работе. — Рабочий процесс с Git Stash 🔹Сохранение изменений в stash Перед тем как зафиксировать изменения в stash, сначала добавьте файлы в индекс, чтобы Git начал их отслеживать:

$ git add .

Если нужно сохранить только определенные файлы, укажите их при добавлении:

$ git add file.txt demo.txt
Затем создайте новый stash:
```bash
$ git stash

Эта команда сохранит ваши изменения и вернет рабочую директорию в состояние последнего коммита. 🔹Присвоение имени stash Чтобы дать stash понятное название, используйте параметр -m:

git stash -m "<имя>"

Это поможет вам легче идентифицировать нужные сохраненные изменения позже. 🔹Просмотр списка stash'ей Чтобы увидеть список всех сохраненных stash'ей, используйте:

$ git stash list

Для просмотра краткого описания stash'а выполните: ```bash git stash show Где <stash> — это идентификатор stash'а из списка git stash list. 🔹Применение stash'а Когда вы готовы вернуть сохраненные изменения, используйте команду git stash pop:

git stash pop

Эта команда применяет изменения и удаляет stash из списка. Если вы хотите сохранить stash после применения, используйте:

git stash apply

🔹Применение конкретного stash'а Чтобы применить stash, кроме последнего, используйте:

git stash apply <stash>

Или:

git stash pop --index <stash>

Где <stash> — идентификатор stash'а из git stash list. apply сохраняет stash, а pop удаляет его после применения. 🔹Создание новой ветки с stash'ем Вы можете создать новую ветку и применить к ней изменения из stash'а:

git stash branch <branch-name> <stash>

Эта команда создаст новую ветку с изменениями из stash'а, привязанными к коммиту, в котором stash был создан. 🔹Удаление stash'ей Когда stash больше не нужен, удалите его командой:

git stash drop <stash>

Это удаляет один stash. Чтобы удалить все stash'и, используйте:

git stash clear

После очистки stash'и невозможно будет восстановить. 🔹Дополнительные возможности Git stash поддерживает множество дополнительных опций, включая возможность отправки stash'ей в удаленный репозиторий. Подробнее читайте в официальной документации. — Когда использовать Git Stash? Git stash полезен в следующих ситуациях: 🔹Переключение на другую ветку для получения обновлений 🔹Временное сохранение работы для исправления критической ошибки (hotfix) 🔹Разрешение конфликтов при выполнении git rebase 🔹Пауза в работе для слияния другой ветки в вашу С помощью stash можно легко менять контексты работы без необходимости делать временные коммиты. — Заключение Git stash позволяет откладывать локальные изменения без коммитов, помогая гибко управлять рабочим процессом и переключаться между ветками. Это делает его важным инструментом для эффективной работы с Git. 👉 DevOps Portal

💡 Быстрый совет по Linux 🐧 Команда diff — полезный инструмент для поиска различий между файлами в терминале Linux. Однако, icdiff предлагает еще более удобное сравнение, выводя файлы бок о бок с цветным отображением изменений.

$ icdiff config-1 config-2

Результат выведет оба файла рядом, с выделением различий красным и зеленым цветами, что позволяет легко увидеть различия. 👉 DevOps Portal