DevOps by REBRAIN
Открытые практикумы по DevOps, Linux, Golang, Networks, Security Мы на связи: info@rebrainme.com +7 (499) 116-34-68 https://rebrainme.com/ Зарегистрированы в РКН: https://knd.gov.ru/license?id=674db558d793bc0b0b8845ff®istryType=bloggersPermission
Ko'proq ko'rsatish📈 Telegram kanali DevOps by REBRAIN analitikasi
DevOps by REBRAIN (@rebrain_devops) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 28 755 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 4 617-o'rinni va Rossiya mintaqasida 22 401-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 28 755 obunachiga ega bo‘ldi.
31 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -98 ga, so‘nggi 24 soatda esa 0 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 8.12% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.53% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 335 marta ko‘riladi; birinchi sutkada odatda 1 878 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 10 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent dovecot, linux, скрипт, postfix, yandex kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Открытые практикумы по DevOps, Linux, Golang, Networks, Security
Мы на связи:
info@rebrainme.com
+7 (499) 116-34-68
https://rebrainme.com/
Зарегистрированы в РКН: https://knd.gov.ru/license?id=674db558d793bc0b0b8845ff®istryType=bloggersPermiss...”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 01 Noyabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
kubectl get pods -n kube-system -l k8s-app=calico-node
# или проверяем наличие Cilium
kubectl get pods -n kube-system -l app.kubernetes.io/name=cilium-agent
1️⃣Главный принцип: Deny by Default
Основной подход при работе с Network Policies - deny by default, allow explicitly (запрещено по умолчанию, разрешено только явно). Вместо того чтобы пытаться точечно блокировать опасные направления, мы сначала закрываем вообще всё, а затем аккуратно открываем нужные доступы.
Создаём политику, которая полностью блокирует весь входящий и исходящий трафик для всех подов в неймспейсе production:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {} # Пустой селектор выбирает ВСЕ поды в данном неймспейсе
policyTypes:
- Ingress
- Egress
podSelector: {} указывает, что правило применяется ко всем без исключения подам в неймспейсе production. А пустые блоки ingress и egress (так как мы их не описали ниже) означают полный запрет.
После применения этой политики поды в production оказываются в полной изоляции. У них перестают работать даже DNS-запросы, потому что это тоже исходящий (`egress`) трафик. Исправляем это.
Шаг 2️⃣: разрешаем DNS-резолв
Добавляем политику, которая позволит подам отправлять DNS-запросы к CoreDNS. Без этого приложения не смогут разрешить имена соседних сервисов:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
namespace: production
spec:
podSelector: {} # Применяется ко всем подам в production
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
Здесь мы используем встроенный системный лейбл kubernetes.io/metadata.name: kube-system. Он автоматически присваивается неймспейсам в Kubernetes, что избавляет нас от необходимости маркировать kube-system вручную.
Шаг3️⃣: точечный доступ (Связываем Frontend и Backend)
Теперь разрешаем нашему фронтенду обращаться к бэкенду. Нам нужно настроить Ingress-правило для бэкенда:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: production
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
# Стадия сборки
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Флаги -s -w отсекают лишнюю отладочную информацию, уменьшая бинарник
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o myapp ./cmd/server
# Финальная стадия
FROM alpine:latest
RUN apk --no-cache add ca-certificates
COPY --from=builder /app/myapp /myapp
ENTRYPOINT ["/myapp"]
В финальный образ попадает только скомпилированный бинарник и минимальный набор системных библиотек. Размер сокращается с ~800 МБ до ~15 МБ. Под стартует за секунды вместо десятков секунд.
Для интерпретируемых языков (Python, Node.js) принцип аналогичен. Например, для Python создаем виртуальное окружение на этапе сборки и переносим его целиком, исключая лишний мусор и компиляторы:
# Стадия сборки
FROM python:3.11-slim AS builder
WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Финальная стадия
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY app.py .
CMD ["python", "app.py"]
Теперь настраиваем кэширование в GitLab CI, чтобы не пересобирать зависимости при каждом коммите. Воспользуемся современным движком docker buildx, который умеет работать с кэшем напрямую в удаленном реестре (registry) без лишних движений вроде docker pull и docker tag:
build:
stage: build
image: docker:latest
services:
- docker:dind
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
DOCKER_CACHE: $CI_REGISTRY_IMAGE:cache
script:
# Инициализируем buildx плагин
- docker buildx create --use
# Собираем образ, используя удаленный кэш и сохраняя новые слои в него же
- docker buildx build \
--cache-from type=registry,ref=$DOCKER_CACHE \
--cache-to type=registry,ref=$DOCKER_CACHE,mode=max \
--tag $DOCKER_IMAGE \
--push .
Docker проверяет манифест удаленного кэша. Если в Dockerfile не изменились строки, влияющие на слой (например, requirements.txt или `go.mod`), тяжелые этапы установки зависимостей просто пропустятся.
Дополнительный приём - разделение этапов внутри пайплайна, чтобы сборка запускалась только при изменении кода. Используем rules:changes в GitLab CI:
build:
rules:
- changes:
- src/**/*
- go.mod
- requirements.txt
Если изменения затронули только документацию или README - сборку можно пропустить.