Что такое docker и какие инструменты linux лежат в основе? Для чего он используется?
Docker базируется на технологиях:
🔸 namespaces — обеспечивает изоляцию (например, можно айдишники процессов разместить в разных контейнерах)
🔸 cgroups — позволяет управлять группой процессов, и управлять их ресурсами
🔸 capabilities — позволяет дать некоторые рут привелегии процессам или исполняемым файлам. Например, изменить UID процесса на 0, или дать возможность монтировать файловые системы.
🔸 overlay namespaces — (overlayFS, overlay2-драйвер) - файловая система, которая умеет работать "слоями". Не сохранять каждый раз новые файлы, а наслаивать один слой на другой, тем самым экономя место на диске и время создания контейнера.
А вот докер — это уже штука, которая всеми этими технологиями рулит, удобным для нас образом.
Компоненты докера:
🔻 Docker Daemon — тот самый Container Engine; запускает контейнеры.
🔻 Docker CLI — утилита по управлению Docker.
🔻 Dockerfile — инструкция по тому, как собирать образ.
🔻 Image — образ, из которого раскатывается контейнер.
🔻 Container
🔻 Docker registry — хранилище образов.
На Docker_host работает Docker daemon и запускает контейнеры.
Client — передаёт команды: собери образ, скачай образ, запусти контейнер. Docker daemon ходит в registry и выполняет их. Docker-клиент может обращаться и локально (к юникс-сокету), и по TCP с удалённого хоста.
Docker daemon (демон) — это серверная часть, работающая на хост-машине: скачивает образы и запускает из них контейнеры, создаёт сеть между контейнерами, собирает логи. Когда мы говорим «создай образ», этим тоже занимается демон.
Docker CLI — клиентская часть Docker, консольная утилита для работы с демоном. Может работать не только локально, но и по сети.
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Docker базируется на технологиях:
🔸 namespaces — обеспечивает изоляцию (например, можно айдишники процессов разместить в разных контейнерах)
🔸 cgroups — позволяет управлять группой процессов, и управлять их ресурсами
🔸 capabilities — позволяет дать некоторые рут привелегии процессам или исполняемым файлам. Например, изменить UID процесса на 0, или дать возможность монтировать файловые системы.
🔸 overlay namespaces — (overlayFS, overlay2-драйвер) - файловая система, которая умеет работать "слоями". Не сохранять каждый раз новые файлы, а наслаивать один слой на другой, тем самым экономя место на диске и время создания контейнера.
А вот докер — это уже штука, которая всеми этими технологиями рулит, удобным для нас образом.
Компоненты докера:
🔻 Docker Daemon — тот самый Container Engine; запускает контейнеры.
🔻 Docker CLI — утилита по управлению Docker.
🔻 Dockerfile — инструкция по тому, как собирать образ.
🔻 Image — образ, из которого раскатывается контейнер.
🔻 Container
🔻 Docker registry — хранилище образов.
На Docker_host работает Docker daemon и запускает контейнеры.
Client — передаёт команды: собери образ, скачай образ, запусти контейнер. Docker daemon ходит в registry и выполняет их. Docker-клиент может обращаться и локально (к юникс-сокету), и по TCP с удалённого хоста.
Docker daemon (демон) — это серверная часть, работающая на хост-машине: скачивает образы и запускает из них контейнеры, создаёт сеть между контейнерами, собирает логи. Когда мы говорим «создай образ», этим тоже занимается демон.
Docker CLI — клиентская часть Docker, консольная утилита для работы с демоном. Может работать не только локально, но и по сети.
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍6❤2
Для чего нужна команда git commit --amend?
Команда
Основные случаи использования:
1. Изменение сообщения коммита: если было допущено опечатку или необходимо уточнить содержание сообщения коммита.
2. Добавление изменений в последний коммит: если были забыты изменения, которые нужно включить в последний коммит, можно их добавить, выполнить
3. Удаление ненужных файлов: если случайно добавлен лишний файл, можно удалить его с помощью
После выполнения
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Команда
git commit --amend используется для изменения последнего коммита в локальном репозитории. Она позволяет исправить сообщение коммита, добавить в него изменения, которые не были учтены, или удалить файлы, которые не должны были быть в коммите. Основные случаи использования:
1. Изменение сообщения коммита: если было допущено опечатку или необходимо уточнить содержание сообщения коммита.
git commit --amend -m "Новое сообщение коммита"
2. Добавление изменений в последний коммит: если были забыты изменения, которые нужно включить в последний коммит, можно их добавить, выполнить
git add для этих файлов и затем git commit --amend, чтобы объединить их с предыдущим коммитом.3. Удаление ненужных файлов: если случайно добавлен лишний файл, можно удалить его с помощью
git rm, затем выполнить git commit --amend, чтобы пересобрать коммит без этого файла.После выполнения
git commit --amend создается новый коммит с измененной историей, что важно помнить, если работа ведется в команде.Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍6❤1
Архитектура кластеров Kubernetes - выбор размера рабочего узла
Стоит ли создавать кластер Kubernetes с меньшим количеством крупных узлов или с большим количеством мелких узлов? В этой статье мы рассмотрим все плюсы и минусы.
Когда вы создаете кластер Kubernetes, одним из первых вопросов, который у вас может возникнуть, является: "Какой тип рабочих узлов я должен использовать и сколько их нужно?".
Если вы создаете локальный кластер, стоит ли заказывать серверы последнего поколения или использовать дюжину или около того старых машин, которые валяются в вашем центре обработки данных?
Или если вы используете управляемый сервис Kubernetes, например Google Kubernetes Engine (GKE), следует ли вам использовать восемь экземпляров n1-standard-1 или два экземпляра n1-standard-4 для достижения желаемой вычислительной мощности?
https://learnk8s.io/kubernetes-node-size
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Стоит ли создавать кластер Kubernetes с меньшим количеством крупных узлов или с большим количеством мелких узлов? В этой статье мы рассмотрим все плюсы и минусы.
Когда вы создаете кластер Kubernetes, одним из первых вопросов, который у вас может возникнуть, является: "Какой тип рабочих узлов я должен использовать и сколько их нужно?".
Если вы создаете локальный кластер, стоит ли заказывать серверы последнего поколения или использовать дюжину или около того старых машин, которые валяются в вашем центре обработки данных?
Или если вы используете управляемый сервис Kubernetes, например Google Kubernetes Engine (GKE), следует ли вам использовать восемь экземпляров n1-standard-1 или два экземпляра n1-standard-4 для достижения желаемой вычислительной мощности?
https://learnk8s.io/kubernetes-node-size
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Forwarded from Библиотека девопса | DevOps, SRE, Sysadmin
💡 Сегодня немного про боль Kubernetes-кластеров
Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.
👉 У каждого пода должны быть
👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.
👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.
В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.
Подпишись 👉@devopslib
Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.
👉 У каждого пода должны быть
requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.
👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.
В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.
Подпишись 👉@devopslib
👍6🔥1
Sudo без бинарного setuid или SSH через UNIX-сокет
В этом посте я подробно расскажу, как заменить
Я считаю, что программы с
Это связано с работой группы Confined Users SIG в Fedora.
https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
В этом посте я подробно расскажу, как заменить
sudo (программу с setuid), используя SSH через локальный UNIX-сокет.Я считаю, что программы с
setuid / setgid — это устаревшая часть наследия UNIX, которую следует исключить. В будущем посте я объясню причины безопасности, стоящие за этим утверждением.Это связано с работой группы Confined Users SIG в Fedora.
https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤1👎1🔥1
Teller — универсальный open-source менеджер секретов для разработчиков
Больше не нужно покидать терминал, чтобы использовать секреты при разработке, тестировании и создании приложений.
Вместо использования кастомных скриптов, токенов в файлах .zshrc, видимых команд EXPORT в истории bash, ошибочно размещенных файлов .env.production и других уязвимостей на рабочей станции, просто используйте Teller и подключите его к любому хранилищу секретов, ключевому хранилищу или облачному сервису, который вам нужен (Teller поддерживает HashiCorp Vault, AWS Secrets Manager, Google Secret Manager и многие другие).
Вы можете использовать Teller для упорядочения своего окружения или внедрения его как процесса и лучшей практики для вашей команды.
https://github.com/tellerops/teller
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Больше не нужно покидать терминал, чтобы использовать секреты при разработке, тестировании и создании приложений.
Вместо использования кастомных скриптов, токенов в файлах .zshrc, видимых команд EXPORT в истории bash, ошибочно размещенных файлов .env.production и других уязвимостей на рабочей станции, просто используйте Teller и подключите его к любому хранилищу секретов, ключевому хранилищу или облачному сервису, который вам нужен (Teller поддерживает HashiCorp Vault, AWS Secrets Manager, Google Secret Manager и многие другие).
Вы можете использовать Teller для упорядочения своего окружения или внедрения его как процесса и лучшей практики для вашей команды.
https://github.com/tellerops/teller
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
mk - Интерактивный запуск задач для Makefile(Taskfile.yml)
Функции:
- Интерактивный интерфейс: Просматривайте и выбирайте доступные команды make с помощью стрелок или фильтруйте, вводя текст.
- Документация: Ознакомьтесь с описанием каждой команды, чтобы понять её назначение и использование.
- Клавиши, как в Vim: Используйте
- Фильтрация: Быстро находите команды, вводя часть их названия. Нажмите
- Удалённый Makefile: Загрузите Makefile с удалённого URL и выполните команды.
- Локальный Makefile: Загрузите Makefile из любой директории и выполните команды.
- Поддержка Taskfile.yml: Загрузите Taskfile.yml из удалённого URL или локального пути и выполните задачи.
https://github.com/orangekame3/mk
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Функции:
- Интерактивный интерфейс: Просматривайте и выбирайте доступные команды make с помощью стрелок или фильтруйте, вводя текст.
- Документация: Ознакомьтесь с описанием каждой команды, чтобы понять её назначение и использование.
- Клавиши, как в Vim: Используйте
j и k для навигации, Enter для выполнения, а q для выхода. - Фильтрация: Быстро находите команды, вводя часть их названия. Нажмите
? для справки. - Удалённый Makefile: Загрузите Makefile с удалённого URL и выполните команды.
- Локальный Makefile: Загрузите Makefile из любой директории и выполните команды.
- Поддержка Taskfile.yml: Загрузите Taskfile.yml из удалённого URL или локального пути и выполните задачи.
https://github.com/orangekame3/mk
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍4
6 Docker-фич для продвинутого использования
Docker давно перестал быть просто инструментом для упаковки приложений в контейнеры. Сегодня это целая экосистема с множеством возможностей, о которых многие разработчики и даже DevOps специалисты догадываются лишь поверхностно.
В этой статье я расскажу о некоторых функциях Docker, которые редко попадают в учебные руководства и официальные туториалы, но которые могут облегчить жизнь разработчикам и понять Docker чуть глубже. По ходу статьи фичи будут переходить от более известных к менее известым (подобно когда-то популярному формату айсбергов)
https://habr.com/ru/companies/ruvds/articles/953990/
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Docker давно перестал быть просто инструментом для упаковки приложений в контейнеры. Сегодня это целая экосистема с множеством возможностей, о которых многие разработчики и даже DevOps специалисты догадываются лишь поверхностно.
В этой статье я расскажу о некоторых функциях Docker, которые редко попадают в учебные руководства и официальные туториалы, но которые могут облегчить жизнь разработчикам и понять Docker чуть глубже. По ходу статьи фичи будут переходить от более известных к менее известым (подобно когда-то популярному формату айсбергов)
https://habr.com/ru/companies/ruvds/articles/953990/
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍5❤2🔥1
Когда повторы убивают: метастабильные отказы в распределённых системах
Надёжность — базовая цель исследований по распределённым системам. Но несмотря на годы прогресса, инциденты продолжают случаться. Из опыта эксплуатации гипермасштабных систем за десятилетие мы выделяем класс отказов, которые ломают работу даже без аппаратных сбоев, кривых конфигов или багов. Эти метастабильные отказы становились причиной крупных инцидентов у больших интернет-компаний — от минут до часов. Парадокс в том, что корень проблемы часто в механизмах, призванных повысить эффективность или надёжность самой системы.
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Надёжность — базовая цель исследований по распределённым системам. Но несмотря на годы прогресса, инциденты продолжают случаться. Из опыта эксплуатации гипермасштабных систем за десятилетие мы выделяем класс отказов, которые ломают работу даже без аппаратных сбоев, кривых конфигов или багов. Эти метастабильные отказы становились причиной крупных инцидентов у больших интернет-компаний — от минут до часов. Парадокс в том, что корень проблемы часто в механизмах, призванных повысить эффективность или надёжность самой системы.
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
🔥2👍1
Buildg - Интерактивный отладчик для Dockerfile, с поддержкой IDE (VS Code, Emacs, Neovim и т.д.).
Source-level inspection
Breakpoints and step execution
Interactive shell on a step with your own debugigng tools
Based on BuildKit (with unmerged patches)
Supports rootless
https://github.com/ktock/buildg
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Source-level inspection
Breakpoints and step execution
Interactive shell on a step with your own debugigng tools
Based on BuildKit (with unmerged patches)
Supports rootless
https://github.com/ktock/buildg
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
1🔥4👍2❤1
Forwarded from Bash Советы
🧠 Логи — Самые частые IP-адреса в access.log
Когда нужно быстро понять, кто чаще всего лупит по серверу — вот простой однострочник:
🔍 Что делает:
1.
2.
3.
📊 Вывод будет примерно такой:
🔥 Подходит для NGINX, Apache и других web-логов с классическим форматом.
👉@bash_srv
Когда нужно быстро понять, кто чаще всего лупит по серверу — вот простой однострочник:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
🔍 Что делает:
1.
awk '{print $1}' — вытаскивает IP из первой колонки.2.
sort и uniq -c — считает повторы.3.
sort -nr | head — выводит топ-10 по частоте.📊 Вывод будет примерно такой:
152 192.168.1.10
103 203.0.113.45
87 172.16.0.5
🔥 Подходит для NGINX, Apache и других web-логов с классическим форматом.
👉@bash_srv
🔥6👍2
Git. GitLab
GitLab. Devops система. Установка в локальной сети. Настройка.
Git и GitHub для начинающих.
GitLab clone по SSH. Настройка SSH для Linux и Windows.
DevOps практика: GitlLab CI+Runners. Создание CI CD Pipeline.
GitLab: Свой Docker Registry. Создание и подключение.
источник
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
GitLab. Devops система. Установка в локальной сети. Настройка.
Git и GitHub для начинающих.
GitLab clone по SSH. Настройка SSH для Linux и Windows.
DevOps практика: GitlLab CI+Runners. Создание CI CD Pipeline.
GitLab: Свой Docker Registry. Создание и подключение.
источник
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍6
Перечислите некоторые исходные пространства имен, из которых запускается Kubernetes
Вот некоторые начальные пространства имен:
Default: это пространство имен включено Kubernetes, чтобы пользователи могли начать использовать новый кластер без необходимости предварительного создания пространства имен.
Kube-system: это пространство имен для объектов, созданное системой Kubernetes.
Kube-public: это пространство имен доступно для чтения как аутентифицированным, так и неаутентифицированным клиентам. Оно зарезервировано в основном для использования в кластере.
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Вот некоторые начальные пространства имен:
Default: это пространство имен включено Kubernetes, чтобы пользователи могли начать использовать новый кластер без необходимости предварительного создания пространства имен.
Kube-system: это пространство имен для объектов, созданное системой Kubernetes.
Kube-public: это пространство имен доступно для чтения как аутентифицированным, так и неаутентифицированным клиентам. Оно зарезервировано в основном для использования в кластере.
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Docker
01- Основы. Принцип работы. Почему docker. Сравнение с виртульной машиной. Применение.
02- Установка Docker в Linux и Windows.
03- Основные команды. Управление портами. Port Mapping.
04- Переменные. Environment Variables.
05- Volumes. Постоянные данные. Persisting Data.
06- Сети в докер. Network: bridge, host, none, macvlan, ipvlan
07- Dockerfile. Создаем СВОИ контейнеры.
08- Docker-COMPOSE. Простой запуск контейнеров.
09- Portainer. Управлять Docker ПРОСТО. Обзор, установка, настройка.
10- Watchtower. Автоматизация: обновление Docker контейнеров.
источник
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
01- Основы. Принцип работы. Почему docker. Сравнение с виртульной машиной. Применение.
02- Установка Docker в Linux и Windows.
03- Основные команды. Управление портами. Port Mapping.
04- Переменные. Environment Variables.
05- Volumes. Постоянные данные. Persisting Data.
06- Сети в докер. Network: bridge, host, none, macvlan, ipvlan
07- Dockerfile. Создаем СВОИ контейнеры.
08- Docker-COMPOSE. Простой запуск контейнеров.
09- Portainer. Управлять Docker ПРОСТО. Обзор, установка, настройка.
10- Watchtower. Автоматизация: обновление Docker контейнеров.
источник
Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍10❤1