🤔 Где бы хранил tfstate если много разрабов?

Файл terraform.tfstate содержит текущее состояние инфраструктуры. Если его неправильно хранить, возможны конфликты и повреждение данных.

🚩Плохие решения

Локально (terraform.tfstate в репозитории)
Потеря данных, если разработчик сменит машину.
Конфликты, если несколько человек применяют terraform apply.
Невозможно откатиться к старому состоянию.
Не поддерживает блокировки (terraform lock).
Возможны проблемы с одновременным доступом.

🚩Лучшие решения для хранения `tfstate`

🟠S3 + DynamoDB (AWS) → Самый популярный способ
S3 хранит tfstate, а DynamoDB предотвращает конфликты.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

🟠Terraform Cloud/Enterprise → Официальное SaaS-решение
Terraform Cloud хранит tfstate в облаке HashiCorp.

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
  }
}

🟠Google Cloud Storage (GCS) + Firestore (GCP)
Для GCP аналог AWS S3 — это Google Cloud Storage (GCS), а DynamoDB заменяется Firestore.

terraform {
  backend "gcs" {
    bucket  = "my-tfstate-bucket"
    prefix  = "terraform/state"
  }
}

🟠Azure Storage + Azure CosmosDB (Azure)
Для Azure можно использовать Azure Storage и блокировки через Azure CosmosDB.

terraform {
  backend "azurerm" {
    resource_group_name  = "my-rg"
    storage_account_name = "myterraformstate"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Если у нас несколько контейнеров — размещаем ли мы их на разных воркер-нодах?

- Зависит от политики и ресурсов.
- Обычно Kubernetes сам решает, как распределить контейнеры (через scheduler), с учётом:
- Нагрузки.
- Доступных ресурсов (CPU, память).
- affinity/anti-affinity правил.
Размещение на разных нодах повышает отказоустойчивость.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Где хранить приватный PGP ключ?

Приватный PGP-ключ – это чувствительные данные, которые нельзя хранить в незащищенных местах. Потеря или компрометация ключа может привести к утечке зашифрованных данных.

🚩Лучшие способы хранения приватного PGP-ключа

🟠На аппаратном токене (YubiKey, Nitrokey, SmartCard)
- Ключ никогда не покидает устройство.
- Физическая защита от копирования.
- Можно использовать для SSH, GPG, подписи кода.

🟠В защищенном хранилище (Bitwarden, 1Password, KeePassXC)
- Хранилище зашифровано и требует пароль или биометрию.
- Можно синхронизировать между устройствами без потери безопасности.
- Экспортировать ключ в зашифрованный файл:

  gpg --export-secret-keys --armor > private-key.asc

🟠В зашифрованном виде на диске (LUKS, VeraCrypt, EncFS)
- Физическая защита – даже если диск украдут, без пароля его не открыть.
- Работает на Linux, Windows, MacOS.
1⃣Создать зашифрованный контейнер с LUKS (Linux):

   cryptsetup luksFormat /dev/sdX
   cryptsetup luksOpen /dev/sdX secure_disk
   mkfs.ext4 /dev/mapper/secure_disk

2⃣Хранить ключ внутри /mnt/secure_disk/private-key.asc.

🟠4. В HSM или облачном KMS (AWS KMS, HashiCorp Vault, Azure Key Vault)
- Подходит для энтерпрайз-решений.
- Аппаратное шифрование (HSM) делает взлом практически невозможным.
- AWS KMS или Vault можно использовать для PGP.

vault kv put secret/pgp_key key="$(cat private-key.asc)"

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как вывести в VOIP из файла с логами только ошибки?

Можно использовать команду, которая фильтрует строки по ключевому слову, например "ERROR", из файла логов. Это позволяет быстро найти только строки с ошибками без просмотра остального.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Куда идет деплой из релизных веток?

Касается подходов к управлению релизами в системах контроля версий, таких как Git, и их интеграции с процессами CI/CD. Ответ зависит от структуры разработки и процесса релиза в конкретной команде или компании. Однако, в общем, деплой из релизных веток обычно идет на тестовые, стейджинговые или продакшн-окружения. Давайте разберем этот процесс подробнее.

🚩Что такое релизные ветки?

Это ветки, которые создаются на этапе, когда функционал и исправления, готовые к выпуску, отделяются от основной ветки разработки (например, main или develop). Они позволяют:
Заморозить текущий набор изменений для подготовки к релизу.
Отделить доработки и исправления релиза от активной разработки.
Упростить процесс тестирования и последующего деплоя.

🚩Куда обычно идет деплой из релизных веток?

🟠Тестовое окружение (QA environment)
На тестовое окружение деплой из релизной ветки осуществляется для прохождения проверок качества: Автоматизированное и ручное тестирование.
Проверка производительности, безопасности и других аспектов.

stages:
  - test
deploy:
  stage: test
  script:
    - echo "Deploying release branch to QA"
    - ./deploy.sh qa
  only:
    - release/*

🟠Стейджинговое окружение (Staging)
После успешного прохождения тестов релизную ветку деплоят в стейджинг. Это окружение максимально похоже на продакшн и используется для финального тестирования: Проверка совместимости с продакшн-системами.
Демонстрация функционала заказчикам или заинтересованным сторонам.

stages:
  - staging
deploy:
  stage: staging
  script:
    - echo "Deploying release branch to Staging"
    - ./deploy.sh staging
  only:
    - release/*

🟠Продакшн (Production)
После прохождения всех этапов тестирования изменения из релизной ветки деплоятся в продакшн: Обычно это делается автоматически после финального подтверждения.
В некоторых командах финальный мерж релизной ветки в main инициирует деплой.

stages:
  - production
deploy:
  stage: production
  script:
    - echo "Deploying release branch to Production"
    - ./deploy.sh production
  only:
    - release/*

🚩Зачем это нужно?

🟠Изоляция релиза
Релизные ветки позволяют избежать включения новых, неподготовленных изменений в текущий релиз.
🟠Гибкость
Если в процессе тестирования или релиза найдены баги, их можно исправить прямо в релизной ветке без влияния на разработку.
🟠Управление рисками
Релизные ветки упрощают управление разными стадиями разработки и релиза.

🚩Пример использования

1⃣Разработчик создает ветку release/1.0.0 от develop.
2⃣Выполняются тесты на QA окружении.
3⃣Исправляются баги в release/1.0.0, и изменения деплоятся на стейджинг.
4⃣После успешного тестирования ветка мержится в main, и начинается деплой в продакшн.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что будет происходить при kubectl apply?

Команда kubectl apply применяет конфигурации, указанные в YAML или JSON-файлах, к объектам Kubernetes. Если объект уже существует, Kubernetes обновляет его состояние в соответствии с файлом. Если объект отсутствует, он создаётся. Это декларативный подход, позволяющий описывать желаемое состояние системы.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как определить ресурс, который необходим одной node?

Чтобы определить нагрузку на Node и правильно выделить ресурсы, нужно:
Проверить текущее потребление ресурсов (CPU, RAM, диски)*
Оценить нагрузку от подов (requests и limits)
Использовать мониторинг (Prometheus, Grafana, kubectl top)

🚩Проверить нагрузку на Node (`kubectl top node`)

Команда

sh  
kubectl top nodes  

Вывод

NAME        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%  
node-1      500m         25%    2Gi             50%  
node-2      1000m        50%    4Gi             80%  

🚩Проверить потребление ресурсов подами (`kubectl top pods`)

Команда

sh  
kubectl top pods --all-namespaces  

Вывод

NAMESPACE   POD            CPU(cores)   MEMORY(bytes)  
default     web-app-1      250m         256Mi  
default     web-app-2      300m         512Mi  
monitoring  prometheus-1   600m         1Gi  

🚩Анализ `requests` и `limits` подов

Команда

sh  
kubectl describe node node-1  

Вывод (пример секции Allocatable)

Allocatable:  
  cpu:                4  
  memory:             8Gi  
  pods:               110  

Проверить requests и limits у подов

sh  
kubectl describe pod my-pod  

Вывод

Requests:  
  cpu:     500m  
  memory:  1Gi  
Limits:  
  cpu:     1  
  memory:  2Gi  

🚩Использование Prometheus и Grafana для анализа нагрузки

Prometheus-запросы для анализа Node
Средняя загрузка CPU за 5 минут

promql  
avg(rate(node_cpu_seconds_total[5m])) * 100  

Среднее использование памяти

promql  
avg(node_memory_Active_bytes) / avg(node_memory_MemTotal_bytes) * 100

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что возвращает функция в bash?

Функция в bash возвращает:
- Целое число (exit code) — через return или $?, обычно от 0 до 255.
- Если ты хочешь вернуть текст или строку, это делается через echo, и затем значение можно перехватить в переменную.
Exit code важен для понимания успеха/ошибки выполнения.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как бы организовал хранение и доступ к секретам?

В DevOps и Kubernetes важно безопасно хранить секретные данные (пароли, API-ключи, токены). Нельзя хранить их в коде, в Git, в .env файлах без шифрования.

🚩HashiCorp Vault (лучший вариант для масштабных проектов)

Полностью управляемое решение для хранения и динамической ротации секретов.
Шифрование с поддержкой KMS.
API-доступ и интеграция с CI/CD.
Как получить секрет через CLI?

vault kv put secret/db password="SuperSecret123"
vault kv get secret/db

Как использовать в Jenkins?

withVault([vaultSecrets: [[path: 'secret/db', secretValues: [['envVar': 'DB_PASS', 'vaultKey': 'password']]]]]) {
    sh 'echo $DB_PASS'  # Переменная доступна только внутри блока
}

🚩Kubernetes Secrets (если приложение в K8s)

Интеграция с Kubernetes, управление через kubectl.
Доступ через переменные окружения или монтирование в файл.
Можно использовать Sealed Secrets или SOPS для шифрования.
Как создать секрет?

kubectl create secret generic db-secret --from-literal=password='SuperSecret123'

Как использовать в Deployment?

env:
  - name: DB_PASS
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

🚩AWS Secrets Manager / Azure Key Vault / GCP Secret Manager

Интеграция с облачными сервисами (IAM, Lambda, RDS).
Автоматическая ротация ключей.
Как получить секрет в AWS?

aws secretsmanager get-secret-value --secret-id my-secret

Как подключить к Kubernetes?
Используем External Secrets Operator:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  secretStoreRef:
    name: aws-secrets
    kind: SecretStore
  target:
    name: db-secret
  data:
  - secretKey: password
    remoteRef:
      key: my-db-password

🚩SOPS + GitOps (для хранения в Git, но зашифрованно)

Позволяет хранить секреты в Git без утечек.
Работает с KMS, PGP, age.
Как зашифровать секрет?

sops --encrypt --age YOUR_PUBLIC_KEY secrets.yaml > secrets.enc.yaml

Как расшифровать?

sops --decrypt secrets.enc.yaml

Ставь 👍 и забирай 📚 Базу знаний

🤔 Если у тебя 4 ноды, можно ли в replica count указать 5 или 6?

Нет, нельзя.
- replica count не может превышать число брокеров в кластере.
- На 4-х брокерах максимум — replica count = 4.
Если задать больше — Kafka вернёт ошибку при создании топика.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 По какой причине inode могут закончиться?

Это структуры данных, которые хранят информацию о файлах и каталогах. Каждый файл или каталог на диске ассоциируется с одним inode, который содержит метаданные файла, такие как его размер, разрешения, временные метки, ссылки на блоки данных и т.д. Количество inode на файловой системе обычно определяется в момент её создания и не может быть изменено без переформатирования или значительных изменений в файловой системе.

🚩Причины исчерпания

🟠Большое количество мелких файлов
Одной из наиболее частых причин исчерпания inode является наличие очень большого количества маленьких файлов на файловой системе. Поскольку каждый файл использует как минимум один inode, системы с большим количеством мелких файлов могут исчерпать доступные inode, даже если дисковое пространство по-прежнему доступно.

🟠Недостаточное количество выделенных inode
При создании файловой системы, если количество выделенных inode было рассчитано неправильно (слишком мало для предполагаемого использования), это может привести к раннему их исчерпанию. Это особенно актуально для серверов или систем, где ожидается большое количество файлов.

🟠Особенности файловой системы
Некоторые файловые системы, такие как Ext3 или Ext4, имеют фиксированное соотношение inode к объёму файловой системы, которое задаётся при их создании. Если создать файловую систему с недостаточным количеством inode для конкретного случая использования, то в дальнейшем это может стать проблемой.

🚩Решения проблемы исчерпания

🟠Проверка использования
С помощью команды df -i можно проверить, сколько inode используется и сколько ещё доступно в вашей файловой системе.

🟠Очистка файловой системы
Удаление ненужных или временных файлов может освободить inode.

🟠Изменение файловой системы
Если возможно, можно увеличить количество inode путём изменения файловой системы или пересоздания файловой системы с более высоким количеством inode. Для файловых систем, таких как XFS или некоторые конфигурации Btrfs, можно динамически добавлять inode.

🟠Использование других файловых систем
Переход на другую файловую систему, которая не имеет строгих ограничений на количество inode (например, Btrfs или ZFS), может быть решением для систем с большим количеством маленьких файлов.

🟠Архивирование
Программы и процессы, которые создают большое количество мелких файлов, могут модифицироваться для хранения данных в формате архивов вместо отдельных файлов, что снижает потребление inode.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Если у нас несколько контейнеров — размещаем ли мы их на разных воркер-нодах?

- Зависит от политики и ресурсов.
- Обычно Kubernetes сам решает, как распределить контейнеры (через scheduler), с учётом:
- Нагрузки.
- Доступных ресурсов (CPU, память).
- affinity/anti-affinity правил.
Размещение на разных нодах повышает отказоустойчивость.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как установить msodbcsql на астре?

Установка Microsoft ODBC Driver for SQL Server (msodbcsql) на Astra Linux требует выполнения нескольких шагов, включая настройку репозиториев, установку необходимых пакетов и принятие лицензионного соглашения.

🟠Подготовка системы
Перед началом убедитесь, что ваша система обновлена и имеет необходимые инструменты для установки:

sudo apt update
sudo apt install -y curl apt-transport-https

🟠Добавление репозитория Microsoft
Microsoft предоставляет собственные репозитории для своих пакетов. Поскольку Astra Linux основана на Debian, мы будем использовать соответствующий репозиторий:

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/debian/$(lsb_release -rs)/prod.list | sudo tee /etc/apt/sources.list.d/mssql-release.list

🟠Установка msodbcsql
После добавления репозитория обновите список пакетов и установите драйвер:

sudo apt update
sudo ACCEPT_EULA=Y apt install -y msodbcsql18

🟠Установка дополнительных инструментов (опционально)
Если вам нужны инструменты командной строки, такие как sqlcmd и bcp, установите пакет mssql-tools:

sudo ACCEPT_EULA=Y apt install -y mssql-tools18

Чтобы эти инструменты были доступны из любого места в терминале, добавьте их в переменную PATH

echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bashrc
source ~/.bashrc

🟠Проверка установки
Убедитесь, что драйвер установлен корректно, выполнив команду:

odbcinst -q -d -n "ODBC Driver 18 for SQL Server"

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие ещё есть компоненты в Grafana помимо дешборда и data source?

В Grafana есть панели визуализации (панели), алерты, папки для организации, пользователи и роли, плагины, а также возможность создавать переменные и шаблоны для гибкой настройки.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Из чего состоит control plane?

В Kubernetes Control Plane — это набор компонентов, которые управляют всей кластерной системой. Он отвечает за контроль над состоянием кластера, управлением узлами (nodes) и развертыванием приложений.

🟠kube-apiserver
Что делает: Это центральный компонент, предоставляющий API для управления кластером.
Почему нужен: Все взаимодействия, включая добавление/удаление узлов, создание подов и настройку сетей, проходят через API-сервер.
Как работает:
Принимает запросы от пользователей, kubectl, и других компонентов.
Проверяет подлинность запросов и валидирует данные.
Передает команды другим компонентам через REST API.

🟠etcd
Что делает: Это распределённое key-value хранилище, которое сохраняет все данные о состоянии кластера.
Почему нужен: Все данные о конфигурации, статусе и метаданных кластера сохраняются в etcd. Если etcd выходит из строя, кластер теряет свою управляемость.
Как работает:
Хранит информацию о подах, конфигурации сетей и статусе всех компонентов.
Поддерживает консенсус между узлами, обеспечивая надёжность данных.

🟠kube-scheduler
Что делает: Назначает поды на доступные узлы.
Почему нужен: Без планировщика поды не смогут быть развернуты на узлах.
Как работает:
Считывает незапланированные поды из API-сервера.
Анализирует доступные узлы на основе их ресурсов (CPU, память и т.д.).
Назначает узел для каждого пода на основе алгоритмов (например, минимальная загрузка).

🟠kube-controller-manager
Что делает: Управляет контроллерами, которые следят за состоянием ресурсов в кластере.
Почему нужен: Контроллеры — это "надсмотрщики", которые автоматически исправляют отклонения от желаемого состояния.
Как работает:
Включает несколько встроенных контроллеров:
Node Controller: Следит за доступностью узлов.
Replication Controller: Поддерживает нужное количество реплик подов.
Endpoint Controller: Обновляет Endpoints-объекты.
Service Account Controller: Создает учетные записи для сервисов.

🟠cloud-controller-manager
Что делает: Управляет интеграцией с облачными провайдерами (например, AWS, GCP).
Почему нужен: Позволяет использовать облачные функции, такие как балансировка нагрузки, управление дисками и маршрутизацией.
Как работает:
Отвечает за создание LoadBalancer.
Управляет постоянными томами (Persistent Volumes), связанными с облачными хранилищами.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какими командами делал бэкап?

Зависит от задачи, но чаще всего:
- tar — архивирование каталогов и файлов.
- rsync — резервное копирование с синхронизацией.
- pg_dump / mysqldump — дампы баз данных.
- cp -a — полная копия с сохранением прав и ссылок.
- dd — побитовая копия диска (в случае аварийных восстановлений).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое debezium?

Она позволяет отслеживать изменения в базах данных (INSERT, UPDATE, DELETE) в реальном времени и передавать их в Kafka, Elasticsearch, MongoDB и другие системы.

🚩Как работает Debezium?

Подключается к базе данных
(PostgreSQL, MySQL, MongoDB, Oracle и др.).
Слушает лог изменений (binlog, WAL, oplog и т. д.)
Формирует события в формате JSON
Передаёт их в Kafka или другую шину данных.

🚩Где используется?

Синхронизация данных между базами
Репликация данных в реальном времени
Отправка изменений в аналитические системы (Elasticsearch, ClickHouse)
Аудит и логирование изменений

🟠Пример работы с Kafka
Запускаем Debezium Connector для PostgreSQL*

{
  "name": "inventory-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "localhost",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "dbz",
    "database.dbname": "inventory",
    "database.server.name": "dbserver1"
  }
}

При изменении данных в таблице, Kafka получит событие:

{
  "schema": { ... },
  "payload": {
    "before": { "id": 1, "name": "Old Name" },
    "after": { "id": 1, "name": "New Name" },
    "op": "u"  // Update
  }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие виды OSI Model Layers есть?

Модель OSI включает 7 уровней:
1. Physical — физическая передача (кабели, сигналы);
2. Data Link — связь между соседними узлами (MAC-адреса);
3. Network — маршрутизация (IP-адреса);
4. Transport — надёжность передачи (TCP/UDP);
5. Session — управление сессиями;
6. Presentation — преобразование форматов (шифрование, кодировка);
7. Application — взаимодействие с пользователем (HTTP, FTP).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Зачем нужен стейт в Terraform?

Файл terraform.tfstate хранит текущее состояние инфраструктуры. Он нужен, чтобы Terraform знал, какие ресурсы уже существуют, и мог правильно управлять изменениями.

🟠Отслеживание ресурсов
Terraform использует tfstate, чтобы сопоставлять код с реальными ресурсами.
В коде создаем виртуальную машину

hcl  
   resource "aws_instance" "example" {  
     ami           = "ami-123456"  
     instance_type = "t2.micro"  
   }  

Запускаем terraform apply, создается сервер в AWS
В terraform.tfstate записывается информация об этом ресурсе
При следующем terraform apply Terraform сверяет tfstate с реальными ресурсами и вносит только изменения

🟠Управление зависимостями
Когда ресурсы связаны (например, сервер и security group), Terraform понимает связи через tfstate и удаляет ресурсы в правильном порядке

🟠Работа в команде (`remote state`)
Когда несколько разработчиков работают с Terraform, tfstate должен храниться в общем месте, например
- S3 + DynamoDB (AWS)
- Terraform Cloud
- GCS + Firestore (GCP)
- Azure Storage + CosmosDB (Azure)

hcl  
terraform {  
  backend "s3" {  
    bucket         = "my-terraform-state"  
    key            = "prod/terraform.tfstate"  
    region         = "us-east-1"  
    encrypt        = true  
    dynamodb_table = "terraform-lock"  
  }  
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие есть виды прав у файла?

В Linux у файла есть 3 типа прав, и они задаются для трёх категорий пользователей:
Типы прав:
- r — чтение (read)
- w — запись (write)
- x — выполнение (execute)
Категории:
- u — владелец (user)
- g — группа (group)
- o — остальные (others)
Пример: rwxr-x--- — владелец может всё, группа только читать и выполнять, остальные — ничего.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что делал в esxi?

VMware ESXi — это гипервизор, который позволяет создавать, управлять и администрировать виртуальные машины (ВМ) на физических серверах.

🚩Разворачивал и настраивал ESXi

Устанавливал ESXi на сервер (с флешки, ISO-образа).
Настраивал сеть (vSwitch, VLAN, физические адаптеры).
Создавал локальные и удаленные хранилища (VMFS, NFS, iSCSI).

vmware -vl

🚩Создавал и администрировал виртуальные машины (ВМ)

Разворачивал ВМ (Windows, Linux, FreeBSD).
Настраивал ресурсы (CPU, RAM, диски, сетевые адаптеры).
Настраивал снапшоты и клонирование ВМ для резервного копирования.
Управлял виртуальными машинами через vSphere Client и ESXi Web UI.

vim-cmd vmsvc/createdummyvm my-vm /vmfs/volumes/datastore1/my-vm

Запуск ВМ через SSH

vim-cmd vmsvc/power.on 1

🚩Настраивал сети (vSwitch, VLAN, Distributed Switch)

Создавал vSwitch для управления трафиком ВМ.
Настраивал VLAN для разделения сетей ВМ.
Использовал Distributed Switch (vDS) для централизованного управления сетью.

esxcli network nic list

Создание vSwitch:

esxcli network vswitch standard add -v vSwitch1

🚩Работал с хранилищами (VMFS, NFS, iSCSI, vSAN)
Настраивал локальные и удаленные хранилища (подключал iSCSI и NFS).
Создавал и увеличивал виртуальные диски (VMDK).
Настраивал vSAN для распределенного хранения данных.

esxcli storage filesystem list

Подключение iSCSI-хранилища

esxcli iscsi adapter discovery sendtarget add -a 192.168.1.10:3260

🚩Настраивал бэкапы и миграцию (vMotion, DRS, HA)

Использовал vMotion для живой миграции ВМ между хостами.
Настраивал автоматическое распределение нагрузки (DRS).
Настраивал High Availability (HA) для автоматического перезапуска ВМ в случае сбоя.

vim-cmd vmsvc/migrate 1 --host target-hostname

Ставь 👍 и забирай 📚 Базу знаний