Профессия:
Решение
1. Установка Prometheus Stack (Kube-Prometheus-Stack)
# Добавляем Helm репозиторий
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# Создаем namespace
kubectl create namespace monitoring
# Установка prometheus stack
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--values values.yaml
# Проверка
kubectl get all -n monitoring
2. values.yaml для Helm chart
Решение
1. .gitlab-ci.yml - Полный pipeline
# GitLab CI/CD Pipeline для микросервиса
image: docker:latest
variables:
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: "/certs"
REGISTRY_IMAGE: "registry.gitlab.com/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME"
DOCKER_HOST: tcp://docker:2375
DOCKER_TLS_VERIFY: ""
services:
- docker:dind
stages:
- lint
- test
- build
- push
- deploy-staging
- deploy-production
# ============================================================================
# LINT Stage
# ============================================================================
Zero-downtime deployment для stateful приложения
Пошаговый процесс деплоя
1. Подготовка (Pre-deployment)
# Создать снапшот БД перед деплоем
pg_dump -Fc production_db > backup_$(date +%Y%m%d_%H%M%S).dump
# Проверить backward-compatible миграции
python manage.py migrate --check
2. Database Migration (без блокировки)
-- ПРАВИЛЬНО: backward-compatible миграция
-- Шаг 1: Добавить колонку (не блокирует)
ALTER TABLE users ADD COLUMN email_verified boolean DEFAULT false;
-- Шаг 2: Заполнить данные (в фоне)
UPDATE users SET email_verified = true
WHERE email IS NOT NULL;
-- НЕПРАВИЛЬНО: блокирующая миграция
-- ALTER TABLE users RENAME COLUMN name TO full_name; -- ЛОМАЕТ старую версию!
Решение
1. Bash скрипт для анализа Nginx access.log
#!/bin/bash
################################################################################
# Nginx Access Log Analyzer
# Usage: ./analyze_nginx_log.sh [log_file]
# Examples:
# ./analyze_nginx_log.sh /var/log/nginx/access.log
# ./analyze_nginx_log.sh access.log | less
################################################################################
set -euo pipefail
# Color codes for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color
# Configuration
LOG_FILE="${1:-/var/log/nginx/access.log}"
LAST_HOUR_MINUTES=60
TOP_LIMIT=10
################################################################################
# Error Handling
################################################################################
error() {
echo -e "${RED}ERROR: $*${NC}" >&2
exit 1
}
warning() {
echo -e "${YELLOW}WARNING: $*${NC}" >&2
}
Решение: AWS S3 Bucket Policy для ограничения доступа
Bucket Policy
Решение
1. Systemd Unit-файл
[Unit]
Description=My Application Service
After=network.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/opt/myapp/start.sh
Restart=on-failure
RestartMaxRetries=5
RestartSec=10s
StartLimitInterval=60
StartLimitBurst=5
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp
User=myapp
WorkingDirectory=/opt/myapp
[Install]
WantedBy=multi-user.target
2. Назначение каждой секции
Description — краткое описание сервиса, видимое в статусе и логах.
After=network.target — сервис запустится ПОСЛЕ инициализации сетевого стека. Это критично для сервисов, которым нужна сеть.
Wants=network-online.target — дополнительная зависимость для максимально надежной работы сети (особенно при использовании DHCP).
Type=simple — стандартный тип для большинства приложений. systemd не ожидает никаких сигналов о завершении инициализации.
Решение
1. Структура Terraform модуля
ec2-module/
├── main.tf # Основные ресурсы
├── variables.tf # Объявление переменных
├── outputs.tf # Выходные значения
├── terraform.tf # Конфигурация провайдера и backend
└── terraform.tfvars # Значения переменных (gitignore!)
2. main.tf - Основные ресурсы
# Security Group
resource "aws_security_group" "web_sg" {
name = "web-security-group-${var.environment}"
description = "Security group for web server"
vpc_id = var.vpc_id
tags = {
Name = "web-sg"
}
}
# Ingress rules
resource "aws_vpc_security_group_ingress_rule" "ssh" {
security_group_id = aws_security_group.web_sg.id
description = "SSH access"
from_port = 22
to_port = 22
ip_protocol = "tcp"
cidr_ipv4 = var.ssh_cidr # например "0.0.0.0/0" или "10.0.0.0/8"
tags = {
Name = "ssh-rule"
}
}
Решение
1. Blue/Green деплоймент в Kubernetes
Blue/Green — это стратегия развертывания, при которой две идентичные среды (Blue и Green) работают параллельно. Трафик направляется на одну среду, а вторая используется для тестирования новой версии.
2. Структура решения
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
- name: myapp
image: myapp:v1.0.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
Решение: Инфраструктура для высоконагруженного сервиса бронирования
Архитектурный обзор
Для сервиса с 1 млн активных пользователей в день и требованием 99.9% доступности необходимо спроектировать многоуровневую, отказоустойчивую инфраструктуру с распределением нагрузки и автоматизацией.
1. Вычислительные ресурсы
Размер кластера:
Конфигурация нод:
Autoscaling:
2. База данных
Решение
1. Полный bash-скрипт для бэкапа PostgreSQL
#!/bin/bash
################################################################################
# PostgreSQL Backup Script with Rotation, Compression and Remote Upload
# Usage: ./backup_postgres.sh [config_file]
# Cron: 0 3 * * * /usr/local/bin/backup_postgres.sh /etc/backup/postgres.conf
################################################################################
set -euo pipefail
# Color codes
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'
# Configuration file
CONFIG_FILE="${1:-/etc/backup/postgres.conf}"
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
LOG_FILE="${LOG_DIR:-/var/log/backups}/postgres_backup_$(date +%Y%m%d).log"
ERROR_LOG="${LOG_DIR:-/var/log/backups}/postgres_backup_errors.log"
################################################################################
# Logging Functions
################################################################################
Решение
1. Структура Ansible проекта
ansible-project/
├── inventory.ini # Инвентарь хостов
├── ansible.cfg # Конфигурация Ansible
├── playbooks/
│ ├── site.yml # Главный playbook
│ └── nginx.yml # Playbook для Nginx
├── roles/
│ ├── nginx/
│ │ ├── tasks/
│ │ │ └── main.yml
│ │ ├── handlers/
│ │ │ └── main.yml
│ │ ├── templates/
│ │ │ └── nginx.conf.j2
│ │ ├── defaults/
│ │ │ └── main.yml
│ │ └── vars/
│ │ └── main.yml
│ └── firewall/
│ └── tasks/
│ └── main.yml
├── group_vars/
│ └── all.yml
└── host_vars/
└── example.com.yml
2. inventory.ini - Инвентарь хостов
[webservers]
web1.example.com ansible_user=ubuntu ansible_password=secret
web2.example.com ansible_user=ubuntu ansible_password=secret
web3.example.com ansible_user=ubuntu ansible_password=secret
Решение
Структура Helm Chart
Helm — это менеджер пакетов для Kubernetes, обеспечивающий шаблонизацию и версионирование развертываний. Отличие от Kustomize в том, что Helm предоставляет полноценную систему управления версиями, зависимостями и репозиториями, тогда как Kustomize — это просто инструмент для наложения патчей на YAML файлы.
Создам структуру chart:
my-web-app/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── configmap.yaml
│ ├── secret.yaml
│ ├── hpa.yaml
│ ├── pdb.yaml
│ ├── NOTES.txt
│ └── _helpers.tpl
Chart.yaml
apiVersion: v2
name: my-web-app
description: Web application Helm chart
type: application
version: 1.0.0
appVersion: "1.0"
values.yaml
# Replica and scaling
replicaCount: 3
image:
repository: myapp/web
pullPolicy: IfNotPresent
tag: "1.0.0"
Решение
1. Проверка статуса контейнера
# Список всех контейнеров
docker ps -a
# Формат с дополнительной информацией
docker ps -a --format 'table {{.ID}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
# Только ID
docker ps -aq
# С временем создания
docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.CreatedAt}}\t{{.Status}}"
# GOOD: Контейнер работает
Up 2 hours # ✅ Нормально работает
Up 2 hours (healthy) # ✅ Healthcheck OK
Up 2 hours (unhealthy) # ⚠️ Healthcheck FAILED
# BAD: Контейнер не работает
Exited (0) # ✅ Завершился корректно (код 0)
Exited (1) # ❌ Ошибка (код 1)
Exited (137) # ❌ Убит сигналом (OOMKilled)
Exited (139) # ❌ Segmentation fault
Created # ❌ Создан но не запущен
Restarting # ❌ Постоянно перезапускается
Dead # ❌ Процесс зависший
Решение
1. Оптимизированный Dockerfile с multi-stage build
# Stage 1: Builder (build environment)
FROM node:18-alpine AS builder
WORKDIR /app
# Копируем только package.json и package-lock.json для лучшего кэширования
COPY package*.json ./
# Устанавливаем зависимости (обе для production и dev)
RUN npm ci --only=production && \
npm cache clean --force
# Копируем исходный код
COPY . .
# Устанавливаем dev dependencies только для build
RUN npm ci && \
npm run build && \
npm cache clean --force
# Stage 2: Runtime (production environment)
FROM node:18-alpine
# Создаем non-root пользователя для безопасности
RUN addgroup -g 1001 -S nodejs && \
adduser -S nodejs -u 1001
WORKDIR /app
# Копируем только production node_modules из builder
COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules
Решение
1. Диаграмма сетевой архитектуры
Frontend (namespace)
↓
└─→ Backend:8080 (namespace)
↓
└─→ Database:5432 (namespace)
(no outbound allowed)
Правила:
1. frontend → backend:8080 ✓
2. frontend → database ✗
3. backend → database:5432 ✓
4. backend → frontend ✗
5. database → backend ✗
6. database → frontend ✗
7. Весь остальной трафик ✗
2. NetworkPolicy для Namespace Backend