Когда разрабатываешь Angular-приложение, неизбежно сталкиваешься с необходимостью использования разных конфигураций для development, staging и production сред. Хардкодить API endpoints, ключи и другие настройки в код — это как оставить root-пароль в plain text файле. Статья расскажет, как правильно настроить переменные окружения в Angular, чтобы твоё приложение легко масштабировалось и деплоилось на любом сервере без костылей.

Как работают переменные окружения в Angular

Angular использует собственную систему environments, которая отличается от классических переменных окружения в Node.js. Вместо process.env здесь работает файловая система конфигураций, которая компилируется на этапе сборки.

Основные файлы конфигурации лежат в папке src/environments/:

src/
  environments/
    environment.ts          # Development окружение
    environment.prod.ts     # Production окружение
    environment.staging.ts  # Staging окружение (создаётся вручную)

Принцип работы простой: Angular CLI замещает импорт environment.ts на нужный файл в зависимости от флага сборки. Это происходит благодаря настройкам в angular.json.

Пошаговая настройка переменных окружения

Шаг 1: Создание базовой структуры

Создай новый Angular проект или работай с существующим:

ng new my-app
cd my-app

Проверь содержимое файла src/environments/environment.ts:

export const environment = {
  production: false,
  apiUrl: 'http://localhost:3000/api',
  appName: 'My App Dev',
  enableLogging: true
};

Шаг 2: Настройка production конфигурации

В файле src/environments/environment.prod.ts:

export const environment = {
  production: true,
  apiUrl: 'https://api.mydomain.com',
  appName: 'My App',
  enableLogging: false
};

Шаг 3: Создание дополнительных окружений

Создай файл src/environments/environment.staging.ts:

export const environment = {
  production: false,
  apiUrl: 'https://staging-api.mydomain.com',
  appName: 'My App Staging',
  enableLogging: true
};

Шаг 4: Конфигурация angular.json

Добавь новую конфигурацию в секцию projects.your-app.architect.build.configurations:

"staging": {
  "fileReplacements": [
    {
      "replace": "src/environments/environment.ts",
      "with": "src/environments/environment.staging.ts"
    }
  ]
}

Шаг 5: Использование в компонентах

Импортируй переменные окружения в любом компоненте или сервисе:

import { environment } from '../environments/environment';

@Injectable()
export class ApiService {
  private baseUrl = environment.apiUrl;
  
  constructor(private http: HttpClient) {}
  
  getData() {
    return this.http.get(`${this.baseUrl}/data`);
  }
}

Команды для сборки разных окружений

# Development сборка
ng build

# Production сборка
ng build --configuration=production

# Staging сборка
ng build --configuration=staging

# Запуск dev сервера с production настройками
ng serve --configuration=production

Продвинутые кейсы использования

Интеграция с системными переменными окружения

Для более гибкой настройки можно создать скрипт, который генерирует environment файлы из системных переменных:

#!/bin/bash
# generate-env.sh

cat > src/environments/environment.prod.ts << EOF
export const environment = {
  production: true,
  apiUrl: '${API_URL}',
  appName: '${APP_NAME}',
  enableLogging: ${ENABLE_LOGGING:-false}
};
EOF

Использование в Docker:

FROM node:18-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci

COPY . .

# Генерация environment файлов из переменных
RUN chmod +x generate-env.sh
RUN ./generate-env.sh

RUN npm run build

FROM nginx:alpine
COPY --from=0 /app/dist /usr/share/nginx/html

Условная загрузка модулей

Можно использовать environment переменные для условной загрузки модулей:

import { environment } from '../environments/environment';

@NgModule({
  imports: [
    CommonModule,
    ...(environment.production ? [] : [NgxLoggerModule.forRoot({
      level: NgxLoggerLevel.DEBUG
    })])
  ]
})
export class AppModule { }

Сравнение подходов к конфигурации

Подход	Плюсы	Минусы	Применение
Angular Environments	Нативная поддержка, типизация, compile-time замена	Требует пересборки при изменении	Стандартные случаи
Runtime конфигурация	Изменение без пересборки	Сложнее в реализации, потеря типизации	Динамические конфигурации
JSON файлы в assets	Простота изменения	Асинхронная загрузка, видимость пользователям	Публичные конфигурации

Безопасность и лучшие практики

Что НЕ нужно делать:

• Хранить секретные ключи в frontend коде (они видны всем)
• Коммитить реальные production URLs в публичные репозитории
• Использовать одинаковые конфигурации для всех окружений

Рекомендации:

• Используй placeholder'ы для чувствительных данных
• Создавай отдельные конфигурации для каждого окружения
• Документируй все переменные и их назначение
• Используй TypeScript интерфейсы для типизации environment объектов

// environment.interface.ts
export interface Environment {
  production: boolean;
  apiUrl: string;
  appName: string;
  enableLogging: boolean;
  features: {
    analytics: boolean;
    beta: boolean;
  };
}

// environment.ts
export const environment: Environment = {
  production: false,
  apiUrl: 'http://localhost:3000/api',
  appName: 'My App Dev',
  enableLogging: true,
  features: {
    analytics: false,
    beta: true
  }
};

Автоматизация и CI/CD

Для автоматизации деплоя на VPS можно использовать GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy to VPS

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    
    - name: Setup Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '18'
        
    - name: Install dependencies
      run: npm ci
      
    - name: Build for production
      run: npm run build --configuration=production
      env:
        API_URL: ${{ secrets.API_URL }}
        APP_NAME: ${{ secrets.APP_NAME }}
        
    - name: Deploy to server
      run: |
        rsync -avz --delete dist/ user@your-server:/var/www/html/

Интересные факты и трюки

• Angular CLI автоматически добавляет source maps только для development сборки
• Можно создать environment файл для каждого разработчика: environment.dev-john.ts
• Environment переменные компилируются статически, что означает tree-shaking неиспользуемых конфигураций
• Можно использовать функции в environment файлах для динамического формирования значений

// Динамическое формирование URL
export const environment = {
  production: false,
  apiUrl: (() => {
    const host = window.location.hostname;
    return host === 'localhost' ? 'http://localhost:3000' : `https://api.${host}`;
  })(),
  version: require('../../package.json').version
};

Масштабирование на выделенных серверах

При использовании выделенных серверов можно настроить более сложную схему с использованием Kubernetes ConfigMaps:

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  API_URL: "https://api.production.com"
  APP_NAME: "Production App"
  ENABLE_LOGGING: "false"

Заключение и рекомендации

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

Основные рекомендации:

• Используй environment файлы для статических конфигураций
• Создавай отдельные файлы для каждого окружения
• Никогда не храни секретные данные в frontend коде
• Автоматизируй генерацию конфигураций через скрипты
• Используй TypeScript для типизации environment объектов
• Настраивай CI/CD для автоматического деплоя с правильными конфигурациями

Такой подход особенно эффективен при работе с микросервисной архитектурой, где каждое Angular приложение может иметь свои специфические настройки для разных сред развёртывания.

---

В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.

Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.