🔐 Jump-хосты: ваш надёжный "телохранитель" для серверов ДАЮ 1000000 процентов , что единицы это делают)

### 🛡 Что такое jump-хост?
Jump-хост (Jump Server) — это специальный прокси-сервер, через который осуществляется доступ к защищённым системам. Он выступает в роли "единой точки входа", изолируя основные серверы от прямого доступа из интернета.

### 📌 Схема работы:

[Ваш ПК] → (VPN/2FA) → [Jump-хост] → [Внутренние серверы]  

1. Вы подключаетесь к jump-хосту с обязательной аутентификацией (например, SSH + 2FA).
2. С jump-хоста получаете доступ к другим серверам в защищённой сети.
3. Основные серверы не имеют публичного доступа — атаковать их извне почти невозможно.

### 🔥 Зачем это нужно?
✅ Защита от прямых атак – злоумышленники не могут сканировать или атаковать серверы напрямую.
✅ Централизованный контроль – все подключения проходят через одну точку, их легче логировать и контролировать.
✅ Снижение рисков – даже если компрометируют ваш ПК, без доступа к jump-хосту взломать серверы не получится.
✅ Гибкость настроек – можно настроить разные уровни доступа для разных пользователей.

### ⚙️ Где применяется?
- Облачные инфраструктуры
- Корпоративные сети с критичными серверами
- DevOps-среды, где важно ограничить доступ к production

💡 Вывод: Jump-хост — это не просто "лишний сервер", а важный элемент безопасности. Он снижает риски, упрощает аудит и делает инфраструктуру устойчивее к атакам. 🚀

#Кибербезопасность #DevOps #СистемноеАдминистрирование


🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

# 🔧 Оптимизация фронтенд-сервиса: Nginx + Kubernetes + Vite

Привет, коллеги! 👋 Сегодня хочу поделиться интересным кейсом по оптимизации деплоя фронтенд-сервиса на Node.js + Vite, который должен работать не просто через yarn build, а через Nginx в Kubernetes.

Почему Nginx? 🚀
- Быстрее отдача статики (Nginx заточен под это, а Node.js — нет).
- Меньше нагрузки (не тратим ресурсы Node на раздачу файлов).
- Гибкость конфигурации (роутинг, кэширование, сжатие).

Но возникла проблема: как прокинуть `VITE_API_BASE_URL` на всех этапах сборки?

---

## 🛠 Проблема и решение

Сервис работает в Kubernetes, и нам нужно:
1. Собрать фронтенд с правильным VITE_API_BASE_URL.
2. Запустить его через Nginx (не через yarn start).
3. Настроить Ingress для доступа.

### 🔹 1. Докерфайл для фронтенда (Vite + Node.js)

Раньше было так:

FROM node:18  
WORKDIR /app  
COPY package.json yarn.lock ./  
RUN yarn install  
COPY . .  
RUN yarn build  
CMD ["yarn", "start"]  # ❌ Неоптимально!  

Теперь так:

# Шаг 1: Сборка  
FROM node:18 as builder  
WORKDIR /app  
COPY package.json yarn.lock ./  
RUN yarn install  
COPY . .  
ARG VITE_API_BASE_URL  # 🔑 Динамическая переменная!  
RUN yarn build  

# Шаг 2: Запуск через Nginx  
FROM nginx:alpine  
COPY --from=builder /app/dist /usr/share/nginx/html  
COPY nginx.conf /etc/nginx/conf.d/default.conf  
EXPOSE 80  
CMD ["nginx", "-g", "daemon off;"]  

Что изменилось?
- Сборка проходит с ARG VITE_API_BASE_URL.
- Статика отдается через Nginx, а не Node.js.

---

### 🔹 2. Настройка Nginx

Файл nginx.conf:

server {  
    listen 80;  
    server_name localhost;  

    location / {  
        root /usr/share/nginx/html;  
        index index.html;  
        try_files $uri $uri/ /index.html;  
    }  

    # Проксируем API-запросы  
    location /api {  
        proxy_pass ${API_BASE_URL};  # 🔄 Берем из переменных  
        proxy_set_header Host $host;  
    }  
}  

---

### 🔹 3. Запуск в Kubernetes (Ingress + ConfigMap)

Deployment:

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: frontend  
spec:  
  replicas: 2  
  template:  
    spec:  
      containers:  
      - name: frontend  
        image: my-frontend-image  
        env:  
        - name: VITE_API_BASE_URL  # 🎯 Важно для сборки!  
          value: "https://api.example.com"  

Ingress:

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: frontend-ingress  
spec:  
  rules:  
  - host: my-app.com  
    http:  
      paths:  
      - path: /  
        pathType: Prefix  
        backend:  
          service:  
            name: frontend  
            port:  
              number: 80  

---

## 📊 Схема работы

graph TD  
    A[Vite Build] -->|Передает статику| B[Nginx]  
    B -->|Отдает файлы| C[Клиент]  
    C -->|API-запросы| D[Backend]  
    D -->|Ответ| C  

---

## 💡 Вывод

✅ Nginx быстрее раздает статику, чем Node.js.
✅ Kubernetes + Ingress дают гибкость маршрутизации.
✅ Динамические переменные (VITE_API_BASE_URL) можно прокидывать на этапе сборки.

Как у вас настроен фронтенд в Kubernetes? Делитесь в комментах! 👇

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

## 🎯 Почему это круто?
✅ Один инструмент для всей инфраструктуры – от облака до подов в K8s.
✅ Идемпотентность – Terraform сам следит за состоянием.
✅ Можно добавить CI/CD (GitLab, GitHub Actions) для полного автоматизма.

Попробуйте и пишите в комменты, как прошло! 🚀

#DevOps #YandexCloud #Kubernetes #Terraform #Automation

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

Всем хорошей рабочей недели ⌨️ ведь работать всего 3 дня
Вот вам полезненькая шпаргалка по Docker которая существенно облегчит некоторые ваши моменты

Завтра вас ждет общая инфа по запуску практики ⌨️

В Среду максимально крутая статья про наш мини мир K8s🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🚀 ОГОНЬ-НОВОСТЬ! 12 МАЯ — ДВА ПОТОКА DEVOPS ПРАКТИКУМА! 🚀

Друзья, этот день вы ждали! 🔥 12 мая стартует долгожданный DevOps-практикум — и сразу в 2-х потоках! 🎉

🔥 Почему это круто?
✔️ Командные задания — будет веселее и продуктивнее вместе! 🎮💡
✔️ Поддержка чата — помогаем друг другу, делимся лайфхаками! 💬🤝
✔️ Стоимость = оплата серверов (Яндекс.Облако) + чуть-чуть на развитие комьюнити 💸✨
✔️ Розыгрыш мерча уже через ~5 дней после старта! 🎁👕

📌 Вся инфа — в закреплённом посте:
👉 [https://news.1rj.ru/str/DevOps360/163](https://news.1rj.ru/str/DevOps360/163)

💡 Хочешь больше контента?
Забивай в Google ti_khnvs и выбирай удобную площадку! 🌍🔍

🎯 Кто с нами? Ставьте огонечек на тот пост в закрепе, Ждём именно тебя! 🚀

---
🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

# 📚 PV & PVC в Kubernetes: Полный Гайд + Секреты Хранения! 🚀

Привет, DevOps-энтузиасты! 👋 Сегодня разберём персистентные тома (PV) и их запросы (PVC) в Kubernetes — без воды, только практика! 🔥

А ещё расскажем, почему RWX (ReadWriteMany) — это редкий зверь 🦄 и где его искать (спойлер: в основном на AWS/Azure).

📌 P.S. Скоро выйдет детальное видео на эту тему! Следи за соцсетями — будет мега-полезно! 🎥

---

## 🔹 PV & PVC: Что Это и Зачем?
В Kubernetes данные в подах (Pods) по умолчанию не сохраняются после перезапуска. Persistent Volume (PV) и Persistent Volume Claim (PVC) решают эту проблему!

- PV (Persistent Volume) — это "диск" в кластере (как AWS EBS, NFS, Local Storage).
- PVC (Persistent Volume Claim) — запрос пода на выделение PV (как аренда хранилища).

### 📌 Простая схема работы:

  
Pod → PVC → PV → Реальное хранилище (EBS, NFS, Local Disk и т. д.)  

---

## 🔹 Типы PVC (Access Modes) — Какой Выбрать?
У PVC есть три режима доступа, и не все провайдеры их поддерживают!

| Тип 🏷 | Описание 📝 | Где работает? 🌍 |
|------------|----------------|---------------------|
| RWO (ReadWriteOnce) | Только одна нода может писать | Все облака (AWS, GCP, Yandex Cloud, Local) ✅ |
| ROX (ReadOnlyMany) | Много подов только для чтения | NFS, Ceph, GlusterFS 🗂 |
| RWX (ReadWriteMany) | Много подов пишут и читают | Только AWS EFS, Azure Files, GCP Filestore 🦄 |

### 💡 Важно!
- RWX — редкость! В Яндекс.Облаке и многих других его нет (только через NFS вручную).
- RWO — самый популярный, работает везде.

---

## 🔹 Как Создать PVC? (Пример для RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce  # ⚠️ Только одна нода!
  resources:
    requests:
      storage: 10Gi  # 💾 Размер тома
  storageClassName: standard  # � Класс хранилища (зависит от облака)

---

## 🚀 Выводы: Что Запомнить?
✅ RWO — основной режим, работает везде.
⚠️ RWX — только в AWS/Azure/GCP, в российских облаках нет (кроме ручного NFS).
📹 Скоро будет видео! Разберём на практике + лайфхаки!

---
ТЕКСТ ПАСХАЛКА ДЛЯ ООООЧЕНЬ ВНИМАТЕЛЬНЫХ :
ОЧЕНЬ И ОЧЕНЬ МНОГИЕ ЗАБЫВАЮТ ПРО 4 ТИП

💡 Что особенного в RWOP?
Это более строгая версия RWO — том привязывается не просто к ноде, а к конкретному поду.

Идеально для:

Stateful-приложений, где том должен быть строго у одного пода (например, БД).

Защиты от случайного мульти-монтирования (если Pod пересоздаётся).

Пример PVC с RWOP:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-exclusive-pvc
spec:
  accessModes:
    - ReadWriteOncePod  # 🔒 Только один Pod!
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd

[ Pod A ] --(RWOP)--> [ PVC ] --> [ PV ] --> (Диск в облаке)  
[ Pod B ] --(RWO)--> [ PVC ] --> [ PV ] --> (Диск в облаке)  
[ Pod C+D ] --(RWX)--> [ PVC ] --> [ PV ] --> (NFS/EFS)  

🔥 Остались вопросы? Пиши в комменты! Делимся опытом! 👇

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

Всех с наступлением праздничных дней и выходных !


🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

# Lens vs K9s vs Rancher: Выбираем лучший GUI для Kubernetes

Kubernetes — мощный оркестратор, но его нативный CLI (kubectl) не всегда удобен для повседневной работы. Чтобы упростить управление кластерами, были созданы графические интерфейсы. В этой статье сравним три популярных инструмента: Lens, K9s и Rancher. У каждого из них свой подход, свои сильные и слабые стороны.

---

## 🔍 Обзор инструментов

### 🚀 Lens IDE – "Интегрированная среда для Kubernetes"
- Тип: Десктопное приложение (Windows, macOS, Linux).
- Особенности:
- Поддержка множества кластеров (kubeconfig, облачные провайдеры).
- Встроенные метрики, логи, терминал, Helm-чарты.
- Удобный визуальный редактор манифестов.
- Поддержка расширений (плагины для мониторинга, безопасности).
- Плюсы:
- Быстрый доступ ко всем ресурсам.
- Удобный дебаггинг (логи + шелл прямо в интерфейсе).
- Хорошая интеграция с Prometheus.
- Минусы:
- Требует установки.
- Нет мультикластерного управления "из коробки" (как у Rancher).

👉 Кому подойдет: DevOps-инженерам и разработчикам, которые хотят удобный GUI для ежедневной работы с Kubernetes.

---

### 🖥 K9s – "Терминальный дашборд для Kubernetes"
- Тип: TUI (Text-based User Interface), работает в терминале.
- Особенности:
- Минималистичный, но мощный интерфейс.
- Быстрый доступ к подам, логам, деплойментам.
- Горячие клавиши для навигации (как в Vim).
- Поддержка плагинов и кастомных команд.
- Плюсы:
- Очень легкий (не требует GUI-сервера).
- Работает даже на слабых машинах.
- Можно использовать без мыши.
- Минусы:
- Нет графических метрик (только текстовые).
- Меньше возможностей для визуального управления.

👉 Кому подойдет: Системным администраторам и DevOps, которые любят терминал и хотят быстрый доступ к кластеру.

---

### 🐮 Rancher – "Полноценная платформа для управления Kubernetes"
- Тип: Веб-интерфейс (разворачивается как сервер).
- Особенности:
- Управление несколькими кластерами из одной панели.
- Встроенный RKE (Rancher Kubernetes Engine) для развертывания кластеров.
- Поддержка CI/CD, RBAC, мониторинга (Grafana, Prometheus).
- Удобный GUI для новичков (можно развертывать приложения без YAML).
- Плюсы:
- Идеален для мультикластерных сред.
- Есть встроенные инструменты безопасности и аудита.
- Подходит для команд, где не все знают kubectl.
- Минусы:
- Требует отдельного сервера для развертывания.
- Более тяжелый, чем Lens и K9s.

👉 Кому подойдет: Командам, которым нужно централизованное управление множеством кластеров и удобный GUI для разработчиков.

---

## 🎯 Вывод: Какой инструмент выбрать?

- Если нужен удобный GUI для ежедневной работы → Lens.
- Если предпочитаете терминал и скорость → K9s.
- Если управляете множеством кластеров и нужен корпоративный инструмент → Rancher.

Каждый из этих инструментов решает свои задачи. Lens – для удобного дебаггинга, K9s – для фанатов терминала, Rancher – для сложных корпоративных сценариев. Какой вам ближе? 🚀

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

### 🔥 Старт практики 12 мая – погружение в DevOps с реальными серверами и командной работой!

Привет, будущие инженеры! 🚀

Совсем скоро, 12 мая, стартует наша практика, где каждый из вас получит собственный сервер в облаке (а то и два!). Зачем два? Чтобы было интереснее! Будем обмениваться доступами, работать на машинах друг друга – полный эффект реальной работы в команде: ответственность, сплоченность и драйв!

### Направления практики – выбирай свой путь!

#### 🔹 Группа №1: Основы облаков и Docker
- Знакомство с облачной платформой
- Работа с Docker (контейнеры, образы, сети)
- Мониторинг БД и серверов
- Написание скриптов (без жесткого хардкода, но с интересными задачами!)
- Задания уровня "S" – для тех, кто хочет вызов!

👉 Ставь 🔥 в чат, если выбираешь эту группу!

#### 🔹 Группа №2: CI/CD и автоматизация с GitLab
- Полная настройка GitLab с нуля (включая тонкости конфигов)
- Работа с Certbot (SSL-сертификаты)
- Гибкие CI/CD Pipelines (переменные, этапы, деплой)
- Ручной деплой приложений через Docker на соседний сервер
- И еще куча интересных фишек!

👉 Ставь 🐳, если хочешь в эту группу!

### 💰 Финансы и организация
- Практика длится 1 месяц – этого хватит, чтобы разобраться в основах и не только.
- Стоимость: ~4-5к (аренда серверов + небольшой вклад в развитие группы и мерча).
- Никаких скрытых платежей – всё прозрачно, сами можете проверить цены в облаке.
- Доступ к материалам только для участников – "халявщики" не пройдут!

### Как будет проходить обучение?
- Недельные задания (база + опциональные сложные задачи).
- Самостоятельный разбор + помощь чата и меня в случае жесткого ступора.
- Реальные навыки, условия как на работе - есть таска- топаем и делаем - не знаем идем гуглим и спрашиваем у других

### 🚀 Что делать сейчас?
1. Выбери группу (🔥 или 🐳). Мне надо вас посчитать , чтобы понять стоимость каждой группы и попытаться минимизировать стоимость аренды, чтобы далее вам озвучить.
2. Жди ссылку в ТГ (доступ откроется перед стартом).
3. Готовься к мощному старту 12 мая!

GLHF! (Good Luck, Have Fun) 😉

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!