vault backup: 2026-05-24 15:03:28
This commit is contained in:
Dmitry
@@ -0,0 +1,46 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: Ansible - Основы
|
||||
---
|
||||
|
||||
# Ansible - Основы
|
||||
|
||||
**Ansible** - инструмент автоматизации развертывания и оркестрации инфраструктуры.
|
||||
|
||||
**Характеристики**
|
||||
|
||||
- **Безагентский**: не требует установки ПО на управляемых хостах (использует SSH).
|
||||
- Язык описания задач — YAML: декларативный и простой в чтении (формат playbook).
|
||||
- **Idempotency**: повторное выполнение не меняет результат, если всё уже настроено.
|
||||
|
||||
## Основные Понятия
|
||||
|
||||
|Term|Def|
|
||||
|---|---|
|
||||
|Playbook|Декларативное описание инфраструктуры, с которой работает в декларативном ключе|
|
||||
|Inventory|Файл инвентаризации, призван отслеживать хосты, к которым мы <br>применяем свои команды и сценарии|
|
||||
|Include|Конструкция, позволяющая переиспользовать уже написанные структуры кода (tasks, playbooks, handlers, vars)|
|
||||
|Task|Единица работы, которая описывается в плейбуке и выполняется <br>во время запуска на исполнение|
|
||||
|Handlers|Обработчики, которые позволяют выполнить некоторую описанную <br>задачу после выполнения другой задачи (вызов через _**notify**_)|
|
||||
|Tags|Механизм тегирования (присвоения меток) задачам (Tasks) и ролям <br>(Roles), позволяющий запускать в плейбуке только те задачи и роли, которые <br>помечены определенной меткой (тегом)|
|
||||
|Vars|Переменные могут быть заданы во время сбора фактов при запуске плейбука <br>или указаны вручную.|
|
||||
|Role|Сборник плейбуков|
|
||||
|Module|Минимальная единица действия - набор действий, встроенных в Ansible|
|
||||
|Facts|Автоматически собираемая с машин информация|
|
||||
|
||||
## В этом разделе
|
||||
- [[Playbooks - Ansible]] — структура плейбуков, синтаксис задач
|
||||
- [[Inventory - Ansible]] — описание хостов и групп
|
||||
- [[Modules - Ansible]] — встроенные модули
|
||||
- [[Loops - Ansuble]] — циклы в задачах
|
||||
- [[Fail2Ban - Ansible]] — пример роли для Fail2Ban
|
||||
|
||||
## Контекст
|
||||
- [[IaC - основы]] — Ansible в контексте Infrastructure as Code
|
||||
- [[DevOps - основы]] — место Ansible в DevOps-практиках
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Fail2Ban - Ansible
|
||||
---
|
||||
|
||||
# Fail2Ban - Ansible
|
||||
|
||||
**Fail2ban** — это система защиты от brute-force атак (например, перебора паролей по SSH, FTP, веб-панелям). Она анализирует лог-файлы и временно блокирует IP-адреса, с которых замечена подозрительная активность.
|
||||
|
||||
## Установка С Помощью Средств Ansible
|
||||
|
||||
Образец конфига `jail.local`
|
||||
|
||||
```text
|
||||
[sshd]
|
||||
enabled = true
|
||||
port = ssh
|
||||
logpath = /var/log/auth.log
|
||||
maxretry = 5
|
||||
bantime = 3600
|
||||
findtime = 600
|
||||
```
|
||||
|
||||
```text
|
||||
- name: Установка и настройка Fail2ban
|
||||
hosts: all
|
||||
become: true
|
||||
tasks:
|
||||
- name: Установить fail2ban
|
||||
apt:
|
||||
name: fail2ban
|
||||
state: present
|
||||
|
||||
- name: Копировать конфиг jail.local
|
||||
template:
|
||||
src: jail.local.j2
|
||||
dest: /etc/fail2ban/jail.local
|
||||
owner: root
|
||||
group: root
|
||||
mode: 0644
|
||||
|
||||
- name: Перезапустить fail2ban
|
||||
service:
|
||||
name: fail2ban
|
||||
state: restarted
|
||||
enabled: true
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[DHCP-snooping]] — defence-in-depth: Fail2Ban блокирует атаки на L7 (SSH brute-force), DHCP Snooping — на L2 (rogue DHCP); разные уровни одной стратегии защиты
|
||||
- [[Super-user]] — `become: true` в Ansible использует sudo для установки и управления Fail2Ban
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Inventory - Ansible
|
||||
---
|
||||
|
||||
# Inventory - Ansible
|
||||
|
||||
Особенности Ansible:
|
||||
|
||||
1. Подключение по SSH
|
||||
2. Agentless - нет программ на клиентах
|
||||
|
||||
Структура файла `hosts.ini`
|
||||
|
||||
```text-xml
|
||||
192.168.0.1
|
||||
192.168.0.2
|
||||
|
||||
[web] # группа серверов
|
||||
192.168.0.3
|
||||
192.168.0.4
|
||||
```
|
||||
|
||||
Можно использовать псевдонимы, вместо ip
|
||||
|
||||
```text
|
||||
app ansible_host=ip_server1
|
||||
db ansible_host=ip_server2
|
||||
web ansible_host=ip_server3
|
||||
```
|
||||
|
||||
Другие полезные параметры **inventory**:
|
||||
|
||||
- `ansible_connection: ssh/winrm/local/docker` - тип подключения к серверу
|
||||
- `ansible_port: 22/5986` - порт подключения
|
||||
- `ansible_user: root` - логин для входа по ssh (или др.)
|
||||
- `ansible_ssh_pass: password` или `ansible_password: password` - пароль для входа по ssh.
|
||||
|
||||
Группы для объединения групп:
|
||||
|
||||
```text
|
||||
[mail_internal]
|
||||
mail1.serv
|
||||
|
||||
[mail_external]
|
||||
mail2.serv
|
||||
|
||||
[mail_all:children]
|
||||
mail_internal
|
||||
mail_external
|
||||
```
|
||||
|
||||
Помимо `ini`-формата, можно использовать YAML-файлы:
|
||||
|
||||
```yaml
|
||||
all:
|
||||
children:
|
||||
webservers:
|
||||
hosts:
|
||||
web1.example.com:
|
||||
ansible_host: 192.168.1.10
|
||||
ansible_user: admin
|
||||
web2.example.com:
|
||||
ansible_host: 192.168.1.11
|
||||
vars:
|
||||
ansible_port: 22
|
||||
ansible_python_interpreter: /usr/bin/python3
|
||||
|
||||
databases:
|
||||
hosts:
|
||||
db1.example.com:
|
||||
db2.example.com:
|
||||
|
||||
production:
|
||||
children:
|
||||
webservers:
|
||||
databases:
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[DHCP]] — если хосты получают IP динамически через DHCP, inventory должен использовать имена (DNS), а не IP-адреса
|
||||
- [[DNS]] — `ansible_host: web1.example.com` требует DNS-резолвинга; `/etc/resolv.conf` определяет, где искать
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Loops - Ansuble
|
||||
---
|
||||
|
||||
# Loops - Ansuble
|
||||
|
||||
Для перебора значений в модулях Ansbible используются две конструкции:
|
||||
|
||||
1. `loop` - универсален, используется, когда перебираемые значения - это строки в словаре (`user = { name: Boris; age: 22 }`)
|
||||
2. Директива `with_*` - где `*` - обозначение конкретного итератора
|
||||
|
||||
## Loop
|
||||
|
||||
```text
|
||||
-
|
||||
name: Цикл
|
||||
hosts: all
|
||||
tasks:
|
||||
-
|
||||
name: Цикл loop для создания пользователя
|
||||
user:
|
||||
name: '{{ item.name }}'
|
||||
age: '{{ item.age }}'
|
||||
uid: '{{ item.uid }}'
|
||||
loop:
|
||||
- name: Boris
|
||||
age: 22
|
||||
uid: 1011
|
||||
- name: Anna
|
||||
age: 23
|
||||
uid: 1012
|
||||
...
|
||||
```
|
||||
|
||||
## with_
|
||||
|
||||
```text
|
||||
-
|
||||
name: Цикл
|
||||
hosts: all
|
||||
tasks:
|
||||
-
|
||||
name: Цикл with для создания пользователя
|
||||
user:
|
||||
name: '{{ item }}'
|
||||
age: '{{ item }}'
|
||||
uid: '{{ item }}'
|
||||
with_items:
|
||||
- name: Boris
|
||||
- name: Anna
|
||||
...
|
||||
```
|
||||
|
||||
```text
|
||||
-
|
||||
name: 'Print list of fruits'
|
||||
hosts: localhost
|
||||
vars:
|
||||
fruits:
|
||||
- Apple
|
||||
- Banana
|
||||
- Grapes
|
||||
- Orange
|
||||
tasks:
|
||||
-
|
||||
command: 'echo "{{ item }}"'
|
||||
with_items: '{{ fruits }}'
|
||||
```
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Modules - Ansible
|
||||
---
|
||||
|
||||
# Modules - Ansible
|
||||
|
||||
## Module Command
|
||||
|
||||
Выполнение команды на удаленном узле.
|
||||
|
||||
```yaml
|
||||
- name: Display home directory
|
||||
command: ls ~/
|
||||
```
|
||||
|
||||
У самих команд могут быть параметры, например
|
||||
|
||||
```yaml
|
||||
command: cat resolv.conf chdir=/etc # ansible сначала убедится, что мы в директории /etc или перейдет в неё, а затем выполнит команду cat
|
||||
|
||||
command: mkdir /folder creates=/folder # ansible создаст папку только в том случае, если её не существует
|
||||
```
|
||||
|
||||
# Module Script
|
||||
|
||||
Выполняет скрипт, находящийся на хост-контроллере
|
||||
|
||||
```yaml
|
||||
-
|
||||
name: Тестовый плейбук со скриптом
|
||||
hosts: all
|
||||
tasks:
|
||||
- name: Запуск скрипта с хоста
|
||||
script: /root/script.sh -arg1 -arg2
|
||||
```
|
||||
|
||||
## Module LineInFile
|
||||
|
||||
Записывает указанную строку в конец указанного файла _если точнее, ansible убеждается в наличии такой строки, но если её нет, то записывает в конец_
|
||||
|
||||
```yaml
|
||||
-
|
||||
name: Тестовый плейбук
|
||||
hosts: all
|
||||
tasks:
|
||||
- lineinfile:
|
||||
path: /etc/resolv.conf
|
||||
line: 'nameserver 10.1.250.10'
|
||||
```
|
||||
|
||||
## Module Service
|
||||
|
||||
Работает с сервисами сервера (systemd)
|
||||
|
||||
```yaml
|
||||
-
|
||||
name: 'Execute a script on all web server nodes'
|
||||
hosts: web_nodes
|
||||
tasks:
|
||||
-
|
||||
name: 'Start httpd service on web server nodes'
|
||||
service:
|
||||
state: started
|
||||
```
|
||||
|
||||
## User
|
||||
|
||||
> ansible.builtin.user
|
||||
|
||||
Работа с пользователями системы (linux)
|
||||
|
||||
```yaml
|
||||
-
|
||||
name: 'Create new user'
|
||||
hosts: all
|
||||
tasks:
|
||||
-
|
||||
name: 'Create user John'
|
||||
user:
|
||||
name: John
|
||||
uid: 1040
|
||||
group: dev
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[File Permissions]] — модуль `user` управляет uid/gid пользователей Linux; `lineinfile` редактирует системные файлы; все это работает поверх Linux-прав доступа
|
||||
- [[Super-user]] — `become: true` использует sudo; модуль `user` создаёт пользователей без root-прав для следующих задач
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- ansible
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Playbooks - Ansible
|
||||
---
|
||||
|
||||
# Playbooks - Ansible
|
||||
|
||||
- Playbook - отдельный yml файл.
|
||||
|
||||
_Module_ - любое атомарное действие в Ansible.
|
||||
|
||||
Запуск playbook:
|
||||
|
||||
```text
|
||||
ansible-playbook playbook.yml
|
||||
```
|
||||
|
||||
Существует возможность запуска каких-то модулей без использования playbook Например, можно провести `ping` какой-то машины с хоста с помощью команды:
|
||||
|
||||
```text
|
||||
ansible node1 -m ping
|
||||
```
|
||||
|
||||
В общем случае, для любого модуля:
|
||||
|
||||
```text
|
||||
ansible <hosts> -m <module>
|
||||
```
|
||||
|
||||
Также можно на узле выполнить команду:
|
||||
|
||||
```text
|
||||
ansible <hosts> -a <command>
|
||||
```
|
||||
|
||||
Например
|
||||
|
||||
```text
|
||||
ansible all -a "/sbin/reboot"
|
||||
```
|
||||
|
||||
Если необходимо отладить сценарий можно добавить к команде `-vv`
|
||||
|
||||
```text
|
||||
ansible-playbook playbook.yml -vv
|
||||
```
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: DevOps - основы
|
||||
---
|
||||
|
||||
# DevOps - Основы
|
||||
|
||||
Конспект урока: [Devops вводный 1 урок. Что такое Devops и история его развития.pdf](#root/4yWHzaG6M7iE/SWLwobVesSih/pRoFr75wb413/O6DeMoaS4kWb)
|
||||
|
||||
## Возникновение DevOps
|
||||
|
||||
**DevOps** - _методология взаимодействия_ специалистов по разработке с экспертами по информационно-технологическому обслуживанию, а также взаимная интеграция их рабочих процессов для обеспечения высокого качества продукта.
|
||||
|
||||
### Инфраструктура Как Код (IaC)
|
||||
|
||||
Подход к развертыванию, работе и настройке инфраструктуры в виде файлов конфигурации и систем управления конфигурацией.
|
||||
|
||||
DevOps-инженер управляет инфраструктурой и конфигурацией с помощью декларативных подходов.
|
||||
|
||||
- Управление инфраструктурой
|
||||
- Стандартизация образов
|
||||
- Использование инструментов для декларативного управления инфраструктурой, конфигурацией и сервисами (Ansible, Terraform).
|
||||
|
||||
[[IaC - основы]]
|
||||
|
||||
### Непрерывная Сборки И Доставка (развертывание) (CI/CD)
|
||||
|
||||
Методология разработки и деплоя, подразумевающая автоматическую сборку, тестирование и развертывание программного кода.
|
||||
|
||||
- Технологии контейнеризации (Docker, Podman)
|
||||
- Микросервисная архитектура
|
||||
- Обеспечение непрерывной доставки продукта
|
||||
- Обеспечение безопасности контейнеров и микросервисов
|
||||
|
||||
### Мониторинг, Логирование, Аудит, Трассировка
|
||||
|
||||
- Принципы работы систем мониторинга
|
||||
- Инструменты логирования и аудита
|
||||
- Сбор и обработка логов приложений и инфраструктуры
|
||||
- Трассировка приложений в контексте взаимодействия с командами разработки
|
||||
|
||||
### Контейнерная Оркестрация
|
||||
|
||||
- Оркестрация контейнерных и неконтейнерных нагрузок
|
||||
- Обеспечение ИБ контейнеров и оркестраторов
|
||||
- Развертывание и администрирование высоконагруженных кластеров
|
||||
- Интеграция оркестраторов с инструментами CI/CD
|
||||
|
||||
## Инструментарий
|
||||
|
||||
1. Системы контроля версий (Git, SVC)
|
||||
2. CI/CD (**Gitlab Ci**, Jenkins, Teamcity)
|
||||
3. Контейнеризация (**Docker**, Podman, Cri-o)
|
||||
4. Оркестрация (**Kubernetes**, Swarm, Nomad, Mesos)
|
||||
5. Управление конфигурацией (**Ansible**, Chef, Puppet)
|
||||
6. Управление инфраструктурой (**Terraform**, Cloudformation)
|
||||
7. Мониторинг (Prometheus, Loki, Grafana, …)
|
||||
8. Безопасность (Trivy, Clair, Falco, Kube-hunter, …)
|
||||
9. DevSecOps-анализ (SAST, SCA, DAST, IAST, RASP)
|
||||
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- cicd
|
||||
- gitlab
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Gitlab
|
||||
---
|
||||
|
||||
# Gitlab
|
||||
|
||||
**Gitlab** — веб-платформа для управления репозиториями, командной разработкой и CI/CD-процессами поверх [[Git]].
|
||||
|
||||
Gitlab можно использовать как облачный сервис или развернуть на собственном сервере.
|
||||
|
||||
## Возможности
|
||||
|
||||
Gitlab позволяет:
|
||||
|
||||
- создавать, изменять и удалять репозитории;
|
||||
- управлять пользователями и правами доступа;
|
||||
- проводить code review;
|
||||
- настраивать проверки качества кода;
|
||||
- автоматизировать сборку, тестирование и доставку через CI/CD;
|
||||
- отслеживать задачи, релизы, метрики и состояние приложений.
|
||||
|
||||
## Gitlab в DevOps
|
||||
|
||||
В [[DevOps - основы]] Gitlab относится к инструментам CI/CD и командной разработки.
|
||||
|
||||
Gitlab помогает связать несколько процессов:
|
||||
|
||||
- управление исходным кодом через [[Git]];
|
||||
- review изменений;
|
||||
- автоматическое тестирование;
|
||||
- релизный цикл;
|
||||
- проверки безопасности;
|
||||
- наблюдаемость и сбор метрик.
|
||||
|
||||
## Работа с кодом
|
||||
|
||||
Gitlab поддерживает разные модели управления исходным кодом: GitFlow, Trunk Based Development и другие.
|
||||
|
||||
Основная работа ведётся через проекты, репозитории, ветки, коммиты и merge request. Практические операции с локальным репозиторием описаны в [[Основные команды git]].
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Git]]
|
||||
- [[Основные команды git]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- vcs
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Git
|
||||
---
|
||||
|
||||
# Git
|
||||
|
||||
**Git** — распределённая система контроля версий, разработанная Линусом Торвальдсом в 2005 году.
|
||||
|
||||
Git используется для управления историей изменений исходного кода, командной разработки и организации процессов доставки ПО. В [[DevOps - основы]] Git относится к базовым инструментам контроля версий.
|
||||
|
||||
## Зачем нужен Git
|
||||
|
||||
- хранит историю изменений проекта;
|
||||
- позволяет работать с ветками и объединять изменения;
|
||||
- поддерживает распределённую модель разработки;
|
||||
- помогает проводить code review и восстановление предыдущих состояний кода;
|
||||
- интегрируется с платформами вроде [[Gitlab]] и CI/CD.
|
||||
|
||||
## Преимущества
|
||||
|
||||
### Производительность
|
||||
|
||||
Git оптимизирован для локальных операций: большинство действий выполняется без обращения к удалённому серверу. История проекта хранится как набор объектов, связанных с содержимым файлов и метаданными версий.
|
||||
|
||||
### Безопасность
|
||||
|
||||
Git использует хеширование объектов, что помогает контролировать целостность истории изменений. Это защищает проект от незаметной подмены данных в истории.
|
||||
|
||||
### Гибкость
|
||||
|
||||
Git поддерживает разные модели разработки: от простой работы в одной ветке до сложных процессов с релизными, функциональными и hotfix-ветками.
|
||||
|
||||
## Базовые сущности
|
||||
|
||||
- **commit** — зафиксированное состояние изменений;
|
||||
- **branch** — ветка разработки;
|
||||
- **merge** — объединение веток;
|
||||
- **diff** — сравнение изменений между состояниями проекта.
|
||||
|
||||
Практические команды вынесены в заметку [[Основные команды git]].
|
||||
|
||||
## GitFlow
|
||||
|
||||
**GitFlow** — модель ветвления, где используются основные ветки и временные ветки для разработки функциональности.
|
||||
|
||||
Основные ветки:
|
||||
|
||||
- `main` — официальная история релизов;
|
||||
- `release` — подготовка готового функционала к выпуску;
|
||||
- `develop` — основная ветка разработки;
|
||||
- `feature` — разработка отдельной функциональности.
|
||||
|
||||
Когда в `develop` накоплен достаточный объём изменений, создаётся `release`-ветка. После тестирования она сливается в `main` и обратно в `develop`.
|
||||
|
||||
![[Pasted image 20260430152221.png|597]]
|
||||
|
||||
Недостатки GitFlow:
|
||||
|
||||
- не всегда хорошо сочетается с CI/CD;
|
||||
- избыточен для проектов с частыми релизами;
|
||||
- может усложнять историю слияний.
|
||||
|
||||
## Trunk Based Development
|
||||
|
||||
**Trunk Based Development (TBD)** — модель разработки, где основная работа ведётся вокруг одной главной ветки, называемой `trunk`.
|
||||
|
||||
Идея TBD: чаще интегрировать изменения в основную ветку, уменьшать долгоживущие ветки и поддерживать возможность выпуска релиза в любой момент.
|
||||
|
||||
![[Pasted image 20260430153712.png]]
|
||||
|
||||
TBD лучше сочетается с CI/CD-процессами, потому что уменьшает риск крупных конфликтов слияния и ускоряет обратную связь от сборок и тестов.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Основные команды git]]
|
||||
- [[Gitlab]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: IaC - Основы
|
||||
---
|
||||
|
||||
# IaC - Основы
|
||||
|
||||
*Infrastructure-as-Code (Инфраструктура как код)*
|
||||
|
||||
Основными инструментами выступают Terraform и Ansible
|
||||
|
||||
## Terraform
|
||||
|
||||
- ПО, разработанное компанией HashiCorp, призванное управлять инфрой в декларативном ключе.
|
||||
|
||||
Для работы с инфрой через terraform необходимо лишь описать желаемое состояние (конфигурацию), в которой в декларативном формате изложена желаемая инфраструктура.
|
||||
|
||||
> Декларативный подход - пишем не "как" надо сделать, а "какое" **состояние** мы хотим увидеть
|
||||
|
||||
Описывается в файле `main.ttf`:
|
||||
|
||||
|
||||
|
||||
Terraform-провайдер
|
||||
|
||||
- Это обязательное звено - это интерпретатор, который обрабатывает наш конфиг и вызывает нужные API для работы непосредственно с вендором.
|
||||
|
||||
|
||||
|
||||
Поддерживаемые в terraform типы ресурсов (CRUD):
|
||||
|
||||
- аккаунты и ресурсные группы
|
||||
- ВМ, контейнеры
|
||||
- виртуальные сетевые сегменты
|
||||
- диски и образы
|
||||
- оркестраторы контейнерных и неконтейнерных нагрузок
|
||||
- и т.д. …
|
||||
|
||||
## Ansible
|
||||
|
||||
- ПО, от компании Red Hat, изначально созданное для управления конфигурацией.
|
||||
|
||||
Использует также декларативный язык
|
||||
|
||||
|
||||
|
||||
[[Ansible - основы]]
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
---
|
||||
status: processing
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Control Plane - Плоскость управления
|
||||
---
|
||||
|
||||
# Control Plane - Плоскость управления
|
||||
|
||||
В k8s плоскостью управления выступают master-узлы, они контролируют работу worker-узлов и следят за здоровьем системы, в целом.
|
||||
|
||||
К основным компонентам Control plane относятся:
|
||||
1) Etcd
|
||||
2) Kube-api-server
|
||||
3) Kube-scheduler
|
||||
4) Kube-controller-manager
|
||||
5) Cloud-controller-manager
|
||||
|
||||
![[Pasted image 20260429090040.png|400]]
|
||||
|
||||
## Etcd
|
||||
|
||||
**Etcd** — Opensource *key-value* хранилище, использующее алгоритм консенсуса [[Алгоритм консенсуса raft|raft]] для обеспечения надежного способа хранения данных.
|
||||
|
||||
- Рекомендуемое Kubernetes хранилище конфигурации кластера.
|
||||
- Единственный *Stateful*-компонент кластера Kubernetes.
|
||||
- Инсталлируется на каждую Master node.
|
||||
- Для выбора лидера используется алгоритм Raft.
|
||||
|
||||
## Kube-api-server
|
||||
|
||||
**Kube-api-server** — основной компонент для взаимодействия с кластером и обязательный посредник между всеми компонентами Kubernetes в Data и Control plane.
|
||||
|
||||
- Использует REST API интерфейс.
|
||||
- Является точкой входа в кластер.
|
||||
- Обязательный участник любого взаимодействия между компонентами кластера.
|
||||
- Обеспечивает разграничение прав доступа к содержимому кластера (авторизация и аутентификация).
|
||||
- *Stateless*-компонент.
|
||||
- Инсталлируется на *каждую* Master node.
|
||||
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
|
||||
|
||||
## Kube-controller-manager
|
||||
**Kube-controller-manager** — компонент, ответственный за работу множества kube-controllers.
|
||||
|
||||
- Является *связующим* звеном при взаимодействии Kube-controllers и отвечает за их работу.
|
||||
- Отвечает за *сборку мусора* (Garbage collecting) в кластере Kubernetes.
|
||||
- *Stateless*-компонент.
|
||||
- Инсталлируется на каждую Master node.
|
||||
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
|
||||
|
||||
### Распространенные kube-controllers
|
||||
- **Node-controller** (поддерживает связь с узлами кластера Kubernetes, инициирует перенаправление рабочих нагрузок с вышедших из строя узлов.
|
||||
- **Replicaset-controller** (инициирует процедуру создания и функционирования сущности Replicaset).
|
||||
- **Endpoint-controller** (выполняет создание endpoint - связи между Pod и его Service).
|
||||
- **Token-controller** (обеспечивает создание и работу токенов для доступа к API кластера Kubernetes).
|
||||
- **Account-controller** (обеспечивает функциональность учетных записей в Kubernetes).
|
||||
|
||||
### Garbage collecting
|
||||
|
||||
Обязанности за сборку мусора (Garbage collecting) в кластере Kubernetes также возложены на компонент *Kube-controller-manager*.
|
||||
|
||||
Примером сборки мусора может выступать отслеживание и удаление старых версий наборов репликаций развертываний (Replicaset).
|
||||
|
||||
Если в кластере превышен лимит старых ревизий Replicaset — наиболее старая ревизия становится *мусором* и ее нужно удалить.
|
||||
|
||||
## Cloud-controller-manadger
|
||||
|
||||
**Cloud-controller-manager** — компонент, ответственный за работу множества Cloud-controllers.
|
||||
|
||||
> Не реализован в Kubernetes по умолчанию. Самостоятельная реализация привлекательна для вендоров, желающих предоставлять Kubernetes как облачную услугу.
|
||||
|
||||
- Является связующим звеном при взаимодействии Cloud-controllers и отвечает за их работу.
|
||||
- Cloud-controller-manager, как и сами Cloud-controllers не реализованы по умолчанию.
|
||||
|
||||
## Kube-scheduler
|
||||
|
||||
**Kube-scheduler** — компонент, ответственный за выбор подходящих узлов Data plane для запуска рабочих нагрузок.
|
||||
|
||||
При принятии решения руководствуется следующими факторами: *Requests/Limits*, *QoS*, *Affinity/Anti-affinity rules*, *Priority class/Preemption policy*
|
||||
|
||||
- Отвечает за распределение рабочих нагрузок на узлы Data plane с учетом *определенных факторов*.
|
||||
- *Stateless*-компонент.
|
||||
- Инсталлируется на каждую Master node.
|
||||
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
|
||||
|
||||
Kube-scheduler принимает к сведению имеющиеся у развертываний указания по минимальным и максимальным требованиям к вычислительным ресурсам (*Requests* и *Limits*).
|
||||
|
||||
**Requests:** Минимальный объем вычислительной мощности (Cpu, Ram), необходимый для функционирования рабочей нагрузки.
|
||||
|
||||
**Limits:** Максимальный объем вычислительных ресурсов, выделяемый рабочей нагрузке.
|
||||
|
||||
![[Pasted image 20260429090719.png|200]]
|
||||
|
||||
Kube-scheduler руководствуется присвоенным рабочей нагрузке значением QoS (Quality of Service).
|
||||
|
||||
**В зависимости от указанных в развертывании Requests и Limits,** **уровень обслуживания (QoS) может принимать следующие** **значения:**
|
||||
|
||||
- *BestEffort* (Requests и Limits не указаны вовсе).
|
||||
- *Burstable* (хотя бы для одного контейнера в Pod указаны requests по Cpu или Ram).
|
||||
- *Guaranteed* (все контейнеры в Pod имеют одинаковые Requests и Limits).
|
||||
|
||||
**Affinity/Anti-affinity rules:**
|
||||
|
||||
Kube-scheduler также руководствуется применяемыми к рабочей нагрузке Affinity/Anti-affinity rules.
|
||||
|
||||
Правила Affinity и Anti-affinity описываются в спецификации развертывания и позволяют влиять на решение Kube-scheduler о направлении рабочих нагрузок на узлы кластера за счет расширения типов возможных ограничений.
|
||||
|
||||
![[Pasted image 20260429090816.png|400]]
|
||||
|
||||
**Политика вытеснения:**
|
||||
|
||||
В критических ситуациях Kube-scheduler может прибегнуть к процедуре вынужденного *выселения* (*переселения*) рабочих нагрузок с низким приоритетом (Priority class) в пользу рабочих нагрузок с *высоким* приоритетом, руководствуясь "*политикой вытеснения*" (Preemption policy).
|
||||
|
||||
Данное поведение характерно для ситуаций, при которых узел с рабочей нагрузкой высокого приоритета выходит из строя — в таком случае, во избежание Downtime *высокоприоритетного* развертывания, оно будет отправлено на узел, имеющий низко приоритетную нагрузку (и она будет выселена принудительно).
|
||||
|
||||
![[Pasted image 20260429090930.png]]
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
---
|
||||
status: processing
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Data Plane - Плоскость данных
|
||||
---
|
||||
|
||||
# Data Plane - Плоскость данных
|
||||
К плоскости данных (Data plane) кластера Kubernetes относят рабочие узлы (Workers), на которых запускаются рабочие нагрузки.
|
||||
|
||||
Компоненты Kubelet и Kube-proxy устанавливаются как на узлы управления (Masters), так и на рабочие узлы (Workers), обеспечивая работоспособность рабочих нагрузок в Data-plane и отвечая за их связь с плоскостью управления (Control plane).
|
||||
|
||||
![[Pasted image 20260429085656.png]]
|
||||
## Kubelet
|
||||
**kubelet** - агент на *каждом* узле кластера.
|
||||
- Работает как процесс системы, а не контейнер;
|
||||
- поддержка *любой* k8s-совместимой системы оркестрации (CRI - docker, podman);
|
||||
- запускает контейнеры с *рабочими* нагрузками;
|
||||
- обеспечение проверок (**startup**, **readines**, **liveness probes**).
|
||||
|
||||
Т.е. это агент k8s непосредственно на клиенте (как zabbix-agent, например), он взаимодействует с системой worker-node (и master, тоже)
|
||||
|
||||
## Проверки kubelet
|
||||
1) **startup probe** - применяется первой для определения факта запуска контейнера;
|
||||
![[Pasted image 20260428175708.png|200]]
|
||||
2) **readiness probe** - проверка готовности развернутого в контейнере приложения принимать и обрабатывать рабочую нагрузку;
|
||||
![[Pasted image 20260428175716.png|200]]
|
||||
3) **liveness probe** - периодическая проверка запущенного приложения.
|
||||
![[Pasted image 20260428175720.png|200]]
|
||||
|
||||
## Kube-proxy
|
||||
**kube-proxy** - компонент, отвечающий за *сетевое проксирование* и обеспечивающий *базовые* сетевые правила на узлах управления (Masters) и узлах данных (Workers).
|
||||
|
||||
- Управляет основными сетевыми правилами на узлах кластера Kubernetes
|
||||
- Запускается в контейнере.
|
||||
- Может делегировать часть своих функций сетевым плагинам (CNI).
|
||||
|
||||
### Интерфейсы универсального взаимодействия (плагины)
|
||||
1) **CRI (Container Runtime Interface)** — интерфейс *коммуникации* между компонентом *Kubelet* и используемой kubernetes-совместимой *системой контейнеризации*.
|
||||
2) **CNI (Container Network Interface)** — интерфейс для выполнения сетевых функций кластера Kubernetes-совместимыми сетевыми плагинами (Network plugins).
|
||||
3) **CSI (Container Storage Interface)** — интерфейс обеспечения необходимых действий над персистентным хранением данных рабочих нагрузок кластера kubernetes-совместимыми Volume-drivers.
|
||||
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
- container
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Deployment и ReplicaSet
|
||||
---
|
||||
|
||||
# Deployment и ReplicaSet
|
||||
|
||||
Два ключевых контроллера k8s, отвечающих за развёртывание приложений.
|
||||
|
||||
## Deployment
|
||||
|
||||
**Deployment-controller** управляет декларативным описанием приложения для его развёртывания и обновления.
|
||||
|
||||
Способен создать Deployment из образа или из готового манифеста:
|
||||
|
||||
```sh
|
||||
kubectl create deployment mariadb --image=mariadb:4.0
|
||||
kubectl apply -f nginx-deployment-manifest.yaml
|
||||
```
|
||||
|
||||
Deployment работает только с **Pods** и **ReplicaSets**.
|
||||
|
||||
## ReplicaSet
|
||||
|
||||
**ReplicaSet** — сущность k8s, обеспечивающая поддержку стабильного набора реплик Pod в любой момент времени.
|
||||
|
||||
Приложение = Pod (объединение контейнеров). ReplicaSet управляет множеством таких Pod.
|
||||
|
||||
## Service
|
||||
|
||||
Для связи Pod с другими Pod и внешним миром используется **Service**.
|
||||
|
||||
Pod связывается с Service через **Endpoint** (управляет Endpoint-controller).
|
||||
|
||||
Создание Service:
|
||||
|
||||
```bash
|
||||
kubectl expose deployment mariadb --port=8080
|
||||
kubectl apply -f nginx-service-manifest.yaml
|
||||
```
|
||||
|
||||
## Возможности связки Deployment + ReplicaSet
|
||||
|
||||
| Операция | Описание |
|
||||
|---|---|
|
||||
| Rolling update | Обновление без downtime |
|
||||
| Rollback | Откат текущего обновления |
|
||||
| Revision | Просмотр истории обновлений |
|
||||
| Rollback to revision | Откат до конкретной ревизии |
|
||||
| Scaling | Масштабирование приложения |
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
status: stable
|
||||
type: moc
|
||||
tags:
|
||||
- devops
|
||||
- container
|
||||
- kubernetes
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: Kubernetes
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
|
||||
K8s — система оркестрации контейнеров. Кластер состоит из двух плоскостей:
|
||||
|
||||
- **[[Control Plane - Плоскость управления]]** — master-узлы: etcd, kube-api-server, kube-scheduler, kube-controller-manager, cloud-controller-manager
|
||||
- **[[Data Plane - Плоскость данных]]** — worker-узлы: kubelet, kube-proxy, CRI/CNI/CSI
|
||||
|
||||
![[Pasted image 20260429091836.png]]
|
||||
## Рабочие нагрузки
|
||||
|
||||
- [[Deployment и ReplicaSet]] — развёртывание, rolling update, rollback, scaling
|
||||
|
||||
## Хранение данных
|
||||
|
||||
- [[PV, PVC]] — персистентное хранилище: Persistent Volume и Persistent Volume Claim
|
||||
|
||||
|
||||
|
||||
## Альтернативные решения
|
||||
|
||||
- [[Docker Swarm]]
|
||||
- [[Apache Mesos]]
|
||||
- [[HashiCorp Nomad]]
|
||||
|
||||
## Источники
|
||||
|
||||
[[Devops вводный 9 урок. Введение в Kubernetes. Компоненты control и Data plane.pdf]]
|
||||
|
||||
## Связанные заметки
|
||||
- [[Шаблонизатор Helm]]
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
- storage
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: PV, PVC
|
||||
---
|
||||
|
||||
# PV, PVC
|
||||
|
||||
Сущности k8s для персистентного хранения данных.
|
||||
|
||||
## Persistent Volume (PV)
|
||||
|
||||
**PV** — отражение реального раздела на диске в терминах k8s. Такой же ресурс кластера, как Master или Worker node.
|
||||
|
||||
- Не зависит от namespace
|
||||
- Создаётся вручную (Manifest) или автоматически (Provisioning)
|
||||
|
||||
## Persistent Volume Claim (PVC)
|
||||
|
||||
**PVC** — запрос приложения на подключение к PV.
|
||||
|
||||
- Зависит от namespace
|
||||
- Описывает требования к хранилищу (размер, класс, режим доступа)
|
||||
|
||||
## Схема подключения
|
||||
|
||||
```
|
||||
Pod → PVC → PV → физический диск
|
||||
```
|
||||
|
||||
**Deployment** может содержать ссылку на PVC — тогда при развёртывании Pod автоматически получает доступ к нужному хранилищу.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- k8s
|
||||
- devops
|
||||
- kubernetes
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Алгоритм выбора лидера Lease
|
||||
---
|
||||
|
||||
# Алгоритм выбора лидера Lease
|
||||
|
||||
Алгоритм выбора лидирующего узла в распределнных системах, позволяющий сохранять консистентность данных
|
||||
|
||||
**Суть проста**: узел, который первым запишет себя в хранилище конфигурации кластера, как лидер, тот и станет лидером
|
||||
|
||||
Если лидер перестал выполнять свои функции, то борьба за место лидера по **такому же принципу**.
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Алгоритм консенсуса raft
|
||||
---
|
||||
|
||||
# Алгоритм консенсуса raft
|
||||
|
||||
**Raft** — алгоритм консенсуса, применяющийся в распределенных системах, и обеспечивающий безопасную и согласованную репликацию данных между всеми участниками.
|
||||
|
||||
Состоит из двух фаз:
|
||||
1) Выбор лидера (**leader election**)
|
||||
2) Репликация данных (**log replication**)
|
||||
|
||||
Каждый участник в любой момент времени находится только в одном состоянии:
|
||||
1) Лидер (**leader**) - только один;
|
||||
2) Кандидаты в лидеры (**candidate**);
|
||||
3) Ведомый (**follower**).
|
||||
|
||||
*Raft* в фазе выбора лидера опирается на понятие кворума (**quorum**) - большинства.
|
||||
Из-за этого, в частности, есть рекомендация: *количество master-node должно быть нечетным*.
|
||||
|
||||
Визуализация алгоритма консенсуса Raft: http://thesecretlivesofdata.com/raft/
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
status: seed
|
||||
type: guide
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
- helm
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Шаблонизатор Helm
|
||||
---
|
||||
|
||||
# Шаблонизатор Helm
|
||||
|
||||
**Helm** — менеджер пакетов и шаблонизатор для развёртывания приложений в [[Kubernetes]].
|
||||
|
||||
Helm помогает описывать, устанавливать, обновлять и удалять приложения через готовые или собственные Helm charts.
|
||||
|
||||
## Зачем нужен Helm
|
||||
|
||||
Helm позволяет:
|
||||
|
||||
- искать готовые charts;
|
||||
- устанавливать приложения в Kubernetes;
|
||||
- обновлять релизы;
|
||||
- удалять приложения;
|
||||
- переиспользовать шаблоны манифестов;
|
||||
- параметризовать установку через values.
|
||||
|
||||
## Helm chart
|
||||
|
||||
**Helm chart** — пакет с шаблонами Kubernetes-манифестов, значениями по умолчанию и метаданными приложения.
|
||||
|
||||
Chart можно:
|
||||
|
||||
- найти в публичном chart-репозитории;
|
||||
- создать самостоятельно под своё приложение.
|
||||
|
||||
## Базовый workflow
|
||||
|
||||
Добавить chart-репозиторий:
|
||||
|
||||
```sh
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
```
|
||||
|
||||
Обновить индекс репозиториев:
|
||||
|
||||
```sh
|
||||
helm repo update
|
||||
```
|
||||
|
||||
Найти chart:
|
||||
|
||||
```sh
|
||||
helm search repo bitnami
|
||||
```
|
||||
|
||||
Установить приложение:
|
||||
|
||||
```sh
|
||||
helm install my-mysql bitnami/mysql
|
||||
```
|
||||
|
||||
Посмотреть доступные параметры:
|
||||
|
||||
```sh
|
||||
helm show values istio/base
|
||||
```
|
||||
|
||||
Установить или обновить значения через `--set`:
|
||||
|
||||
```sh
|
||||
helm install istiod istio/istiod --set requests.cpu=300m
|
||||
```
|
||||
|
||||
Посмотреть установленные релизы:
|
||||
|
||||
```sh
|
||||
helm list
|
||||
```
|
||||
|
||||
Обновить релиз:
|
||||
|
||||
```sh
|
||||
helm upgrade istiod istio/istiod --set requests.cpu=600m
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Kubernetes]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- terraform
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: Terraform
|
||||
---
|
||||
|
||||
# Terraform
|
||||
|
||||
[Devops вводный 3 урок. Работа с IaC через terraform и ansible.pdf](#root/LjCayegQsEBv/vJCtNA7LSLFA/ARzmNd1EFrgt)
|
||||
|
||||
Terraform - ПО, разработанное HashiCorp для централизованного управления инфраструктурой по методологии [[IaC - основы|IaC]].
|
||||
|
||||
Использует в своей работе сущности:
|
||||
|
||||
1. `main.tf` - основной файл с декларативным описанием желаемого состояния инфраструктуры.
|
||||
2. `terraform.d/` -директория, в которой хранится terraform-провайдер (api для взаимодействия с конкретной платформой) после его загрузки.
|
||||
3. `.terraform/` - директория, в которой хранятся файлы, в том числе и файлы провайдера.
|
||||
4. `terraform.lock.hcl` - файл блокировки для кэша `.terraform/`.
|
||||
5. `terraform.tfstate` - файл, для регистрации состояния инфраструктуры
|
||||
|
||||
Команды, используемые в работе с Terraform:
|
||||
|
||||
1. `terraform init` - инициализация рабочей директории, содержащей файлы tf.
|
||||
2. `terraform plan` - команда для предварительного просмотра изменений без фактического применения.
|
||||
3. `terraform apply` - применение изменений на инфре.
|
||||
4. `terraform refresh` -
|
||||
|
||||
## Связанные заметки
|
||||
- [[NAT]] — NAT-шлюзы, пулы IP-адресов и сетевые сегменты — типовые ресурсы, которые Terraform декларативно управляет в облачной инфраструктуре
|
||||
- [[IaC - основы]] — методология, которую реализует Terraform
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: Apache Mesos
|
||||
---
|
||||
|
||||
# Apache Mesos
|
||||
|
||||
- инструмент менеджмента кластерных решений по оркестрации контейнерных и не-контейнерных нагрузок.
|
||||
|
||||
Архитектура основана на трех составляющих:
|
||||
|
||||
|
||||
|
||||
1. Узлы управления (master node)
|
||||
2. Рабочие узлы (agent)
|
||||
3. Фреймворки (framework)
|
||||
|
||||
Одновременно могут использоваться несколько фреймворки - именно они запускают рабочие нагрузки.
|
||||
|
||||
Фреймворки состоят из:
|
||||
|
||||
1. Планировщик фреймворка (scheduler)
|
||||
2. Исполнитель фреймворка (executor)
|
||||
|
||||
Планировки устанавливается на всех узлах, а исполнитель выполняет задачи на рабочих узлах.
|
||||
|
||||
Master-узлы предоставляют ресурсы используемым фреймворкам, а Scheduler фреймворка выбирает, на каких ресурсах agent-узлов Executor будет выполнять рабочее задание.
|
||||
|
||||
Популярные фреймворки:
|
||||
|
||||
1. Marathon (оркестрация контейнерных нагрузок)
|
||||
2. Apache Aurora (оркестрация рабочих cron-заданий) - deprecated*
|
||||
3. Mesosphere dc/os (операционная система на базе Apache mesos и Marathon.
|
||||
Имеется community и enterprise-версии. ) - deprecated
|
||||
4. Mesosphere dc/os 2.0 (Kubernetes-совместимый фреймворк - nobest (не готово)
|
||||
|
||||
Другие решения:
|
||||
[[Docker Swarm]]
|
||||
[[Kubernetes]]
|
||||
[[HashiCorp Nomad]]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: Docker Swarm
|
||||
---
|
||||
|
||||
# Docker Swarm
|
||||
|
||||
- встроенное в docker решение по обеспечению оркестрации контейнеров
|
||||
- оркестрирует только контейнеры и причем только docker
|
||||
- но весь прост в освоении
|
||||
|
||||
|
||||
|
||||
Архитектура делится на:
|
||||
|
||||
1. Узлы управления (master)
|
||||
2. Рабочие узлы (worker)
|
||||
|
||||
Docker Swarm не поддерживает шаблонизацию
|
||||
|
||||
---
|
||||
|
||||
Swarm поддерживает следующие типы сетей:
|
||||
|
||||
- bridge
|
||||
- overlay
|
||||
- ingress (overlay с возможностью балансировки трафика)
|
||||
|
||||
В Swarm есть поддержка **service-discovering** (обнаружение сервисов)
|
||||
|
||||
Работа с персистентным хранением решается через Volumes.
|
||||
|
||||
Нет автоскейлинга (масштабирования)
|
||||
|
||||
Зато есть поддержка паттерна **rolling update** (постепенное обновление сервисов без downtime)
|
||||
|
||||
Docker Swarm хорошо интегрируется с инструментами мониторинга.
|
||||
|
||||
Существует встроенное хранилище секретами - docker secrets.
|
||||
|
||||
Есть mTLS
|
||||
|
||||
Сетевые политики (network policy) не поддерживаются.
|
||||
|
||||
Другие решения:
|
||||
[[Apache Mesos]]
|
||||
[[Kubernetes]]
|
||||
[[HashiCorp Nomad]]
|
||||
|
||||
## Связанные заметки
|
||||
- [[Сегментация сети]] — network policy в Swarm (не поддерживается нативно) решает ту же задачу изоляции трафика, что VLAN в физической сети
|
||||
- [[CA и NGINX]] — встроенный mTLS между нодами Swarm использует ту же PKI-инфраструктуру, что и SSL-сертификаты в NGINX
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Docker - Дополнительные Знания
|
||||
---
|
||||
|
||||
# Docker - Дополнительные Знания
|
||||
|
||||
## Запуск Контейнера С Непривилегированным Пользователем
|
||||
|
||||
Рассмотрим пример работы с непривилегированным пользователем:
|
||||
|
||||
- не использовать root внутри контейнера и не запускать его с повышенными привелегиями
|
||||
- создать пользователя можно сразу создать в Dockerfile
|
||||
- переключить пользователя можно с помощью директивы **USER** в Dockerfile
|
||||
|
||||
```dockerfile
|
||||
FROM mariadb
|
||||
USER 999
|
||||
```
|
||||
|
||||
## Rootless-mode - Podman
|
||||
|
||||
Docker решил предпринять попытки отказаться от docker daemon и docker socket с root привилегиями и разрабатывает концепцию rootless-mode
|
||||
|
||||
- Идея нетривиальна в реализации, так как возникают особенности установки бинарников и запуска скриптов.
|
||||
- Логичной заменой есть Podman, написанный на golang, она уже rootless и daemonless по умолчанию.
|
||||
- Podman обратно совместим в docker (в т.ч. собирает свои образы из Dockerfile)
|
||||
- Существует podman builder, позволяющий описывать образы с помощью **bash**.
|
||||
- Практически все команды докера существуют в подмане.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Super-user]] — "не использовать root внутри контейнера" — прямое применение принципа наименьших привилегий из Linux; rootless Podman реализует его на уровне демона
|
||||
- [[Проблемы дистрибутивов]] — реальный кейс: запуск Rails в контейнере как решение проблемы OpenSSL на Arch Linux
|
||||
+91
@@ -0,0 +1,91 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Images, Dockerfile - Docker
|
||||
---
|
||||
|
||||
# Images, Dockerfile - Docker
|
||||
|
||||
Запуск контейнеров происходит на основе images (образов). Образы собираются с помощью Dockerfile.
|
||||
|
||||
Основные инструкции в Dockerfile:
|
||||
|
||||
- **FROM** - использование базового образа
|
||||
- **RUN** - выполнение команд и создание слоя образа
|
||||
- **COPY** - копирование в контейнер файлов и папок
|
||||
- **ADD** - аналогично COPY, но с распаковкой архивов
|
||||
|
||||
Дополнительные:
|
||||
|
||||
- _LABEL_ - описание метаданных
|
||||
- _ENV_ - задание переменных среды
|
||||
- _CMD_ - описание команд с аргументами для выполнения при запуске контейнера
|
||||
- _WORKDIR_ - задание рабочей директории для следующей инструкции
|
||||
- _ARG_ - задание переменных для передачи во время сборки
|
||||
- _ENTRYPOINT_ - предоставление команды с аргументами для вызова во время выполнения контейнера
|
||||
- _VOLUME_ - создание точки монтирования для работы с docker volume
|
||||
- _EXPOSE_ - открытие порта в контейнере
|
||||
|
||||
> Все эти команды создают отдельный слой (layer) для сборки контейнера
|
||||
|
||||
## Оптимизация Образа
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update
|
||||
RUN apt install python3 -y
|
||||
RUN apt install python3-dev -y
|
||||
```
|
||||
|
||||
- Сокращение инструкций **RUN** (уменьшение количества слоев)
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update
|
||||
RUN apt install python3 python3-dev -y
|
||||
```
|
||||
|
||||
> Docker будет пересобирать только те слои, которые были изменены
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y
|
||||
```
|
||||
|
||||
- Удаление кеша пакетных менеджеров
|
||||
|
||||
```dockerfile
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y \
|
||||
rm -rf /var/lib/apt/lists/*
|
||||
```
|
||||
|
||||
- Удаление файлов в той же инструкции, где их создавали
|
||||
- Инструкции, которые предположительно будут часто изменяться, ставить ниже остальных
|
||||
- Сокращение количество инструкций **COPY**
|
||||
|
||||
```dockerfile
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y \
|
||||
rm -rf /var/lib/apt/lists/*
|
||||
|
||||
COPY file1 file2 file3 ./dir
|
||||
```
|
||||
|
||||
- Использование легковесных базовых образов, где есть такая возможность
|
||||
|
||||
|
||||
|
||||
## Связанные заметки
|
||||
- [[Environment Variables]] — инструкция `ENV` в Dockerfile устанавливает переменные окружения внутри контейнера; это расширение того же механизма Linux env vars
|
||||
- [[Volume - Docker]] — инструкция `VOLUME` в Dockerfile объявляет точки монтирования для Docker Volumes
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Multistaging - Docker
|
||||
---
|
||||
|
||||
# Multistaging - Docker
|
||||
|
||||
При сборке docker-образов мы можем использовать механизм многоэтапной сборки - Multistaging.
|
||||
|
||||
При использовании multistaging мы разделяем процедуру сборки на несколько этапов, обозначая их метками.
|
||||
|
||||
|
||||
|
||||
**Использование механизма Multistaging позволяет:**
|
||||
|
||||
- Собирать легковесные образы.
|
||||
- Сократить время сборки образов и запуска на основе контейнеров.
|
||||
- Повысить производительность работы контейнеров.
|
||||
- Переиспользовать вспомогательные образы из промежуточных этапов.
|
||||
- Сократить поверхность атаки на наши контейнеры для потенциального
|
||||
злоумышленника.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Основы - Docker]]
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Network Drivers - Docker
|
||||
---
|
||||
|
||||
# Network Drivers - Docker
|
||||
|
||||
При работе с docker возникает необходимость обеспечить работу контейнеров в сети:
|
||||
|
||||
- настройка правил маршрутизации (iptables)
|
||||
- формирование пакетов
|
||||
- инкапсуляция пакетов
|
||||
- шифрование и безопасность
|
||||
|
||||
Для этого используются Network Drivers
|
||||
|
||||
Сетевых драйверов поддерживаются несколько вариаций, каждый из них способен обеспечить все основные функции:
|
||||
|
||||
- bridge (мост)
|
||||
- host
|
||||
- overlay
|
||||
- macvlan
|
||||
- none
|
||||
- 3rd-party plugins
|
||||
|
||||
**Bridge**
|
||||
|
||||
Объединение контейнеров в bridge-сеть:
|
||||
|
||||
- контейнеры обьеденены в сеть
|
||||
- контейнеры в сети имеют связь друг с другом
|
||||
- контейнеры из другой сети не имеют сетевой связности
|
||||
- используется в docker **по умолчанию**
|
||||
|
||||
**Host**
|
||||
|
||||
Использует сеть хоста (удаляется сетевая изоляция)
|
||||
|
||||
- удаляет сетевую изоляцию между контейнером и хостом
|
||||
- возможны проблемы с занятым портов, сетевыми ограничениями хостовой сети (поддерживается только в Linux)
|
||||
|
||||
**Overlay**
|
||||
|
||||
Создание сети для объединения контейнеров на разных хостах путем создания оверлейной сети
|
||||
|
||||
- не поддерживает шифрование на win-хостах
|
||||
|
||||
**MacVLAN**
|
||||
|
||||
Работа с контейнерами, как с физическими устройствами
|
||||
|
||||
- присваивает каждому контейнеру в сети физический MAC-адрес
|
||||
- позволяет обращаться к контейнеру как к настоящему устройству
|
||||
- поддерживается только в Linux
|
||||
|
||||
**None**
|
||||
|
||||
Отключение всех сетей в контейнере
|
||||
|
||||
- может быть использован для изоляции контейнера
|
||||
|
||||
## Работа С Bridge-сетями
|
||||
|
||||
Docker по умолчанию использует bridge-сеть, так как он позволяет добиться большей изоляции от внешних сетей хоста.
|
||||
|
||||
Контейнеры внутри одного "бриджа" не имеют доступа к другим из других бридж сетей.
|
||||
|
||||
Если нам нужна гибкая настройка сети внутри самого контейнера, потребуются доп. **capabilities** (например, **CAP_NET_ADMIN**)
|
||||
|
||||
В качестве альтернативы можно рассмотреть CNI-плагины (сторонние - 3rd-party)
|
||||
|
||||
## Связанные заметки
|
||||
- [[Модель OSI]] — bridge/overlay/macvlan реализуют концепции L2/L3 из модели OSI; iptables работает на L3/L4
|
||||
- [[VLAN - Base]] — bridge-изоляция контейнеров ≈ VLAN-изоляция устройств: разные бриджи не видят друг друга, как разные VLAN
|
||||
- [[VPN]] — overlay-сеть реализует принцип VPN: инкапсуляция трафика одной сети поверх другой
|
||||
- [[Сегментация сети]] — изоляция контейнеров по bridge-сетям = программная сегментация сети
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Storage Drivers - Docker
|
||||
---
|
||||
|
||||
# Storage Drivers - Docker
|
||||
|
||||
Для работы с данными в контейнере имеется специальный контейнерный слой (**container layer**). Он появляется только в момент запуска контейнера, для работы с данными.
|
||||
|
||||
|
||||
|
||||
Для работы с данными в контейнерном слое и работы со слоями образа _docker_ задействует _**драйверы хранилища**_ **(storage drivers).**
|
||||
|
||||
Доступны в Docker 6 SD:
|
||||
|
||||
|
||||
|
||||
## Block Level (блочные хранилища)
|
||||
|
||||
- распределяют данные на блоки одинакового размеры по оборудованию
|
||||
- не зависит от пути к данным
|
||||
- быстрое получение
|
||||
|
||||
Примеры: ZFS, DeviceMapper
|
||||
|
||||
## File Level (файловые хранилища)
|
||||
|
||||
- данные хранятся единым фрагментов
|
||||
- присутсвует иерархия директорий
|
||||
- доступ к файлу зависит от единственного пути
|
||||
- наиболее распространенный способ хранения данных
|
||||
|
||||
Примеры: AUFS, Overlay, **Overlay2** (по умолчанию)
|
||||
|
||||
## Object Level (объектно-ориентированные хранилища)
|
||||
|
||||
- данные распределяются по оборудованию по частям
|
||||
- связывает объекты данных с их метадатой
|
||||
- объекты могут быть только перезаписаны (изменять нельзя)
|
||||
- для доступа требуется реализация API интерфейса
|
||||
|
||||
По умолчанию, в Docker используется Overlay2, изменить это можно в `/etc/docker/daemon.json`
|
||||
|
||||
**Backing Filesystem**
|
||||
|
||||
Резервная файловая система, в которой расположен `/var/lib/docker`
|
||||
|
||||
Для работы storage driver требуется **совместимая** backing filesystem.
|
||||
|
||||
|
||||
|
||||
## Связанные заметки
|
||||
- [[Основы - Docker]]
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Volume - Docker
|
||||
---
|
||||
|
||||
# Volume - Docker
|
||||
**Некоторые данные стоит хранить независимо от контейнера, для этого существует понятие Volume.**
|
||||
|
||||
Стоит так хранить: БД, логи, конфиги, артефакты, настройки, …
|
||||
|
||||
Для постоянного или персистентного хранения используются Docker Volume. Это буквально монтирование хостовой директории внутрь контейнера, для работы с данными контейнера напрямую.
|
||||
|
||||
Возможности Docker Volumes:
|
||||
|
||||
1. Выгрузка данных контейнера на постоянное хранение
|
||||
2. Работа в подмонтированных каталогах с интенсивной записью данных
|
||||
3. Совместное использование данных несколькими контейнерами
|
||||
|
||||
Docker volumes создают тома, которые монтируются в контейнер.
|
||||
По умолчанию тома docker volumes создаются в каталоге `/var/lib/docker/volumes/`
|
||||
|
||||
|
||||
|
||||
## Типы Volumes
|
||||
|
||||
1. **Host** DV:
|
||||
`docker run -v /home/mount/data:/var/lib/mysql/data`
|
||||
При запуске контейнера, мы пробрасываем конкретный каталог на хосте в конкретный каталог в контейнере
|
||||
(есть опция флагов, для редактирования прав доступа)
|
||||
2. **Anonymous** DV:
|
||||
`docker run -v /var/lib/mysql/data`
|
||||
При таком подходе, Volume создастся в `/var/lib/docker/volumes`
|
||||
3. **Names** DV:
|
||||
`docker run -v name:/var/lib/mysql/data`
|
||||
Аналогично второму варианту, Volume создается в директории по умолчанию, но ему присваивается метка `name`, которую можно переиспользовать.
|
||||
|
||||
## Организация Доступа К Файлам В Docker Volumes
|
||||
|
||||
По умолчанию, uid/gid внутри контейнера и на хосте идентичны, поэтому владелец/группа и права доступа внутри смонтированного каталога будут эквиванлентны.
|
||||
|
||||
Изменить данные поведение поможет фича под названием "userns-remap" - она позволит соотнести uid/gid контейнера к другим uid/gid хоста
|
||||
|
||||
Проблема в том, что по умолчанию, в volume владелец root - что не очень хорошо.
|
||||
|
||||
Для управления этой фичей, нужно отредактировать конфигурацию по пути `/etc/docker/daemon.json`
|
||||
|
||||
```bash
|
||||
{
|
||||
"userns-remap": "<username>"
|
||||
}
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[File Permissions]] — uid/gid маппинг в Docker Volumes напрямую зависит от Linux-прав доступа; проблема "владелец root по умолчанию" решается через chmod/chown
|
||||
- [[Active Storage]] — Active Storage в Rails хранит файлы вне БД; в Docker-деплое они должны персистироваться через Volume, иначе теряются при перезапуске контейнера
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Основы - Docker
|
||||
---
|
||||
|
||||
# Основы - Docker
|
||||
|
||||
## Виртуализация
|
||||
|
||||
**Виртуализация** - это набор вычислительных ресурсов, обеспечивающих логическую изоляцию процессов, выполняющихся на одном физ.хосте.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Storage Drivers - Docker]]
|
||||
- [[Multistaging - Docker]]
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
created: 2026-02-13
|
||||
updated: 2026-05-07
|
||||
title: HashiCorp Nomad
|
||||
---
|
||||
|
||||
# HashiCorp Nomad
|
||||
|
||||
**nomad** - фреймворк для построения кластерных решений, поддерживает не только контейнерные нагрузки, но и не-контейнерные. Существуют платные и бесплатные версии продукта.
|
||||
|
||||
Существует возможность установки расширений:
|
||||
|
||||
- consul (service-discovering)
|
||||
- vault (secret management)
|
||||
- prometheus, grafana, ELK (monitoring, logging, etc)
|
||||
- и т.д.
|
||||
|
||||
Установка nomad проста, но с увеличением расширений _сложность администрирования возрастает_.
|
||||
|
||||
Архитектура представляет собой совокупность управляющих (server) и управляемых (clients) узлов.
|
||||
|
||||
В Nomad используется концепция "job-tasks", где task - это атомарная единица работы, выполняемая выполняемая тем или иным драйвером:
|
||||
|
||||
- docker
|
||||
- qemu
|
||||
- java
|
||||
- etc
|
||||
|
||||
---
|
||||
|
||||
Nomad не поддерживает использование шаблонизаторов.
|
||||
|
||||
Для работы с манифестами nomad использует проприетарный язык HCL с ограниченной возможностью двусторонней конвертации HCL в json и yml.
|
||||
|
||||
Nomad поддерживает использование CNI-плагинов, и имеется поддержка CSI (Container Storage Interface)
|
||||
|
||||
Nomad поддерживает горизонтальное и вертикальное скалирование:
|
||||
|
||||
1. Горизонтальное - создание новых инстансов для балансировки нагрузки.
|
||||
2. Вертикальное - увеличение ресурсов у уже существующих инстансов.
|
||||
3. Кластерное скалирование - увеличение рабочих и управляющих узлов.
|
||||
|
||||
Другие решения:
|
||||
[[Docker Swarm]]
|
||||
[[Kubernetes]]
|
||||
[[Apache Mesos]]
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
status: seed
|
||||
type: guide
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- cli
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Основные команды git
|
||||
---
|
||||
|
||||
# Основные команды git
|
||||
|
||||
Эта заметка — краткий справочник по базовым командам [[Git]].
|
||||
|
||||
## Создание и получение репозитория
|
||||
|
||||
- `git init` — создать новый Git-репозиторий в текущем проекте.
|
||||
- `git clone` — создать локальную копию удалённого репозитория.
|
||||
|
||||
## Работа с ветками
|
||||
|
||||
- `git branch` — показать, создать или удалить ветки.
|
||||
- `git checkout` — переключиться на ветку, файл или коммит.
|
||||
- `git merge` — слить одну ветку в другую.
|
||||
- `git rebase` — перебазировать ветку поверх другой ветки.
|
||||
|
||||
## Работа с изменениями
|
||||
|
||||
- `git status` — показать состояние рабочего каталога.
|
||||
- `git add` — добавить изменения в индекс.
|
||||
- `git commit` — зафиксировать проиндексированные изменения.
|
||||
- `git restore` — откатить изменения или убрать их из индекса.
|
||||
- `git revert` — создать новый коммит, отменяющий выбранный старый коммит без переписывания истории.
|
||||
|
||||
## Работа с удалённым репозиторием
|
||||
|
||||
- `git push` — отправить локальные коммиты в удалённый репозиторий.
|
||||
- `git pull` — получить изменения из удалённого репозитория и сразу объединить их с локальной веткой.
|
||||
|
||||
Платформы вроде [[Gitlab]] используют эти операции как основу для командной разработки, merge request и CI/CD.
|
||||
|
||||
## Merge и rebase
|
||||
|
||||
`git merge` и `git rebase` решают одну задачу: переносят изменения из одной ветки в другую. Разница в том, как они меняют историю.
|
||||
|
||||
### Merge
|
||||
|
||||
`git merge` создаёт слияние веток без переписывания уже существующих коммитов. Это безопасный вариант для публичных веток.
|
||||
|
||||
|
||||
|
||||
### Rebase
|
||||
|
||||
`git rebase` переносит коммиты текущей ветки поверх другой ветки и помогает получить более линейную историю.
|
||||
|
||||
|
||||
|
||||
> [!important] Золотое правило rebase
|
||||
> Не выполнять `git rebase` над публичной веткой, если её уже используют другие разработчики.
|
||||
|
||||
## Когда выбирать merge или rebase
|
||||
|
||||
- Если нужно сохранить полную историю и не переписывать публичные коммиты — использовать `git merge`.
|
||||
- Если нужна чистая линейная история в локальной или личной ветке — использовать `git rebase`.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Git]]
|
||||
- [[Gitlab]]
|
||||
- [[DevOps - основы]]
|
||||
Reference in New Issue
Block a user