backup: 2026-04-17 11:28
This commit is contained in:
Dmitry
@@ -0,0 +1,34 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
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|Автоматически собираемая с машин информация|
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Fail2Ban - Ansible
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Inventory - Ansible
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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:
|
||||
```
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Loops - Ansuble
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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,89 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Modules - Ansible
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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
|
||||
```
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Playbooks - Ansible
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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
|
||||
updated: 2026-03-01
|
||||
title: DevOps - основы
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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,52 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
title: IaC - Основы
|
||||
---
|
||||
|
||||
# IaC - Основы
|
||||
|
||||
*Infrastructure-as-Code (Инфраструктура как код)*
|
||||
|
||||
Основными инструментами выступают Terraform и Ansible
|
||||
|
||||
## Terraform
|
||||
|
||||
- ПО, разработанное компанией HashiCorp, призванное управлять инфрой в декларативном ключе.
|
||||
|
||||
Для работы с инфрой через terraform необходимо лишь описать желаемое состояние (конфигурацию), в которой в декларативном формате изложена желаемая инфраструктура.
|
||||
|
||||
> Декларативный подход - пишем не "как" надо сделать, а "какое" **состояние** мы хотим увидеть
|
||||
|
||||
Описывается в файле `main.ttf`:
|
||||
|
||||
|
||||
|
||||
Terraform-провайдер
|
||||
|
||||
- Это обязательное звено - это интерпретатор, который обрабатывает наш конфиг и вызывает нужные API для работы непосредственно с вендором.
|
||||
|
||||
|
||||
|
||||
Поддерживаемые в terraform типы ресурсов (CRUD):
|
||||
|
||||
- аккаунты и ресурсные группы
|
||||
- ВМ, контейнеры
|
||||
- виртуальные сетевые сегменты
|
||||
- диски и образы
|
||||
- оркестраторы контейнерных и неконтейнерных нагрузок
|
||||
- и т.д. …
|
||||
|
||||
## Ansible
|
||||
|
||||
- ПО, от компании Red Hat, изначально созданное для управления конфигурацией.
|
||||
|
||||
Использует также декларативный язык
|
||||
|
||||
|
||||
|
||||
[[Ansible - основы]]
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- container
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
title: Kubernetes
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
K8s состоит из двух основных компонент:
|
||||
1) **Control Plane** - плоскость управления
|
||||
2) **Data Plane** - плоскость данных
|
||||
![[Pasted image 20251220211253.png|600]]
|
||||
|
||||
## Компоненты Control Plane
|
||||
1) etcd - open-source key-value хранилище, использующее алгоритм консенсуса raft для обеспечения надежного способа хранения данных.
|
||||
В k8s используется для хранения конфигурации всего кластера.
|
||||
![[Pasted image 20251220211307.png|300]]
|
||||
2) kube-api-server - основной компонент для взаимодействия с кластером и обязательный посредник между всем компонентами k8s в data и control plane
|
||||
- используется REST API
|
||||
- является точкой входа в кластер
|
||||
- обязательный участник любого взаимодействия с компонентами кластера
|
||||
- обеспечение разграничивания прав доступа к содержимому кластера (авторизация и аутентификация)
|
||||
- stateless-компонент
|
||||
- установка на каждую master-ноду
|
||||
- выбор лидера происходит по алгоритму **lease**
|
||||
|
||||
> [!abstract] lease
|
||||
> Алгоритм выбора лидирующего узла в распределнных системах, позволяющий сохранять консистентность данных
|
||||
> Суть проста: узел, который первым запишет себя в хранилище конфигурации кластера, как лидер, тот и станет лидером
|
||||
> Если лидер перестал выполнять свои функции, то борьба за место лидера по такому же принципу
|
||||
|
||||
3) kube-controller-manager - компонент, ответственный за работу контроллеров.
|
||||
- связывает kube-controller и отвечает за их работу
|
||||
- сборка мусора
|
||||
- stateless
|
||||
- на каждой master-ноде
|
||||
- выбор лидера аналогично по алгоритму lease
|
||||
![[Pasted image 20251220211330.png|400]]
|
||||
|
||||
Существующие kube-controllers:
|
||||
- node-controller - поддержка связи с узлами кластера, инициализация перенаправления рабочих нагрузок с вышедший из строя узлов.
|
||||
- replicaset-c. - инициализация процедуры создания и функционирования сущности [[ReplicaSet]]
|
||||
- endpoint-c.
|
||||
- token-c.
|
||||
- account-c.
|
||||
|
||||
Конспект от MA: [[Devops вводный 9 урок. Введение в Kubernetes. Компоненты control и Data plane.pdf]]
|
||||
|
||||
Другие решения:
|
||||
[[Docker Swarm]]
|
||||
[[Apache Mesos]]
|
||||
[[HashiCorp Nomad]]
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
title: ReplicaSet
|
||||
---
|
||||
|
||||
# ReplicaSet
|
||||
**ReplicaSet** - базовый контроллер в K8s, задача которого - поддерживать в кластере ровно столько реплик подов, сколько было указано в конфигурации.
|
||||
|
||||
ReplicaSet постоянно сравнивает текущее состояние кластера с желаемым состоянием, которое описано администратором.
|
||||
Состоит из трех ключевых элементов:
|
||||
1) Селектор (Selector) - определяет, какими подами должен управлять этот RS.
|
||||
2) Количество реплик (Replicas) - число, указывающее на желаемое количество реплик в поде.
|
||||
3) Шаблон пода (Pod Template) - описание того, как должен выглядеть новый под, если его понадобится создать.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
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` -
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
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]]
|
||||
[[01 Library/02 DevOps/Контейнеризация/Kubernetes]]
|
||||
[[HashiCorp Nomad]]
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
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]]
|
||||
[[01 Library/02 DevOps/Контейнеризация/Kubernetes]]
|
||||
[[HashiCorp Nomad]]
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Docker - Дополнительные Знания
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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**.
|
||||
- Практически все команды докера существуют в подмане.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Images, Dockerfile - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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
|
||||
```
|
||||
|
||||
- Использование легковесных базовых образов, где есть такая возможность
|
||||
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Multistaging - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# Multistaging - Docker
|
||||
|
||||
При сборке docker-образов мы можем использовать механизм многоэтапной сборки - Multistaging.
|
||||
|
||||
При использовании multistaging мы разделяем процедуру сборки на несколько этапов, обозначая их метками.
|
||||
|
||||
|
||||
|
||||
**Использование механизма Multistaging позволяет:**
|
||||
|
||||
- Собирать легковесные образы.
|
||||
- Сократить время сборки образов и запуска на основе контейнеров.
|
||||
- Повысить производительность работы контейнеров.
|
||||
- Переиспользовать вспомогательные образы из промежуточных этапов.
|
||||
- Сократить поверхность атаки на наши контейнеры для потенциального
|
||||
злоумышленника.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Network Drivers - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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)
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Storage Drivers - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Volume - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# 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>"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
updated: 2026-02-27
|
||||
title: Основы - Docker
|
||||
created: 2025-12-17
|
||||
---
|
||||
|
||||
# Основы - Docker
|
||||
|
||||
## Виртуализация
|
||||
|
||||
**Виртуализация** - это набор вычислительных ресурсов, обеспечивающих логическую изоляцию процессов, выполняющихся на одном физ.хосте.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2026-02-13
|
||||
updated: 2026-02-27
|
||||
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]]
|
||||
[[01 Library/02 DevOps/Контейнеризация/Kubernetes]]
|
||||
[[Apache Mesos]]
|
||||
Reference in New Issue
Block a user