Как сохранить переменную для следующей сессии

Сохранение переменных между сессиями в DevOps-контексте

В контексте DevOps инженерии сохранение переменных между сессиями — критически важная задача, поскольку мы постоянно работаем с окружением (environment), конфигурациями и секретами (secrets). Методы зависят от контекста: локальная разработка, CI/CD пайплайны или управление инфраструктурой.

Основные подходы в зависимости от контекста

1. Локальное окружение разработчика

Для сохранения переменных между терминальными сессиями используются shell-конфигурационные файлы.

# Локальное хранение в ~/.bashrc, ~/.zshrc или ~/.profile
export DB_HOST="production-db.example.com"
export API_KEY="your-api-key-here"

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

# Пример использования pass (менеджер паролей на основе GPG)
export API_KEY=$(pass api/production/key)

2. CI/CD пайплайны (GitLab CI, GitHub Actions, Jenkins)

Здесь переменные сохраняются в безопасном хранилище переменных пайплайна.

# GitLab CI .gitlab-ci.yml пример
deploy_production:
  script:
    - echo "Deploying to $ENVIRONMENT"
    - ./deploy.sh
  variables:
    ENVIRONMENT: "production"

Секреты добавляются через UI/API и никогда не коммитятся в код:

# В Jenkins через Credentials Binding Plugin
withCredentials([string(credentialsId: 'aws-access-key', variable: 'AWS_ACCESS_KEY')]) {
  sh 'aws s3 ls --access-key $AWS_ACCESS_KEY'
}

3. Конфигурация инфраструктуры как код (IaC)

Используются специализированные хранилища вроде HashiCorp Vault, AWS Secrets Manager или Azure Key Vault.

# Terraform с AWS Secrets Manager
resource "aws_secretsmanager_secret" "db_password" {
  name = "production/db/password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id = aws_secretsmanager_secret.db_password.id
  secret_string = jsonencode({
    username = "admin"
    password = var.database_password
  })
}

4. Контейнеризованные приложения (Docker, Kubernetes)

Kubernetes Secrets и ConfigMaps:

# Kubernetes ConfigMap для переменных окружения
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  ENVIRONMENT: "production"
  LOG_LEVEL: "INFO"

# Использование в Pod спецификации
spec:
  containers:
  - name: app
    image: myapp:latest
    envFrom:
    - configMapRef:
        name: app-config

Рекомендуемая архитектура хранения переменных

В современном DevOps стэке я рекомендую многоуровневый подход:

• Уровень 1: Локальная разработка - .env файлы (в .gitignore) или direnv
• Уровень 2: CI/CD системы - встроенные хранилища переменных + интеграция с Vault
• Уровень 3: Инфраструктура - HashiCorp Vault или облачные аналоги
• Уровень 4: Runtime (Kubernetes) - Secrets + ConfigMaps (зашифрованные с помощью Sealed Secrets или External Secrets Operator)

Пример полного решения на практике

# Скрипт инициализации окружения с проверкой безопасности
#!/bin/bash
# init-environment.sh

# Проверяем, инициализировано ли уже окружение
if [ -f ".env.enc" ]; then
    # Расшифровываем файл с переменными (используя GPG или SOPS)
    sops --decrypt .env.enc > .env
    
    # Загружаем переменные в текущую сессию
    set -a
    source .env
    set +a
    
    # Логируем (без секретов)
    echo "Environment loaded for: $APP_ENVIRONMENT"
    
    # Сохраняем ссылку для будущих сессий
    echo "export APP_ENVIRONMENT=$APP_ENVIRONMENT" >> ~/.bashrc.d/app_vars.sh
fi

Критически важные best practices

• Никогда не коммитьте секреты в Git, даже в приватные репозитории
• Используйте rotation (ротацию) секретов - автоматическую смену ключей и паролей
• Реализуйте fine-grained access control - минимальные необходимые права
• Аудит и логирование доступа к секретам - кто, когда и к каким переменным обращался
• Шифруйте секреты как в rest (на диске), так и in transit (при передаче)

Инструментарий для разных сценариев

• Локально: direnv, bashrc/zshrc, .env + git-crypt
• CI/CD: встроенные секреты, HashiCorp Vault plugin, AWS Parameter Store
• Kubernetes: External Secrets Operator, Sealed Secrets, Secrets Store CSI Driver
• Облачные платформы: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager

Ключевой принцип: Переменные должны быть отделены от кода, защищены соответствующим уровню безопасности методом шифрования, и доступны только тем системам и пользователям, которым они действительно необходимы для работы. Современный DevOps инженер должен проектировать хранение переменных как полноценную подсистему безопасности, а не как временное техническое решение.