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
Show more📈 Analytical overview of Telegram channel DevOps by REBRAIN
Channel DevOps by REBRAIN (@rebrain_devops) in the Russian language segment is an active participant. Currently, the community unites 28 754 subscribers, ranking 4 617 in the Technologies & Applications category and 22 401 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 28 754 subscribers.
According to the latest data from 30 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -102 over the last 30 days and by -6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 8.22%. Within the first 24 hours after publication, content typically collects 6.51% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 364 views. Within the first day, a publication typically gains 1 871 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 11.
- Thematic interests: Content is focused on key topics such as dovecot, linux, скрипт, postfix, yandex.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Открытые практикумы по 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...”
Thanks to the high frequency of updates (latest data received on 31 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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 - сборку можно пропустить.