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,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,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,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 - основы]]
|
||||
@@ -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,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