ビルド時の角度環境変数の注入

この記事では、アングルアプリケーションを格納していると仮定します.記事の例もAWS特有ですが、他のクラウドサービスを通して同じ原則を使用できます.
既定では、アプリケーションのビルド時に角度が環境変数を注入します.

上記の図は、アプリケーション展開のためのレギュラーフローを表しています.

私たちのフロントエンドのアプリ.環境変数を含む
はREPO

にプッシュされます

私たちのビルドプロセスをピックアップし、ビルドし、私たちに展開
サーバ.

上記は非常によく動作しますが、非常にユニークな場合は、アプリケーションのリポジトリに環境ファイルをプッシュしないようにする必要があります.これが起こると、その角度がビルド時に環境変数を注入するのを知って、ビルドプロセス中に環境ファイルを注入する方法を見つける必要があります.
以下に、あなたのリポジトリにあなたの環境ファイルを展開しないようにする必要があるかもしれないユニークな理由があります
1 .セキュリティの追加
一部の企業には、アプリケーション環境変数をリポジトリにプッシュするのを防ぐポリシーがあります.それはあなたの秘密を維持する最も安全な方法は、フロントエンドアプリケーションにそれらを置くことではないことに注意する価値があります.したがって、環境変数として、またはアプリケーションの内部では、フロントエンドアプリケーションに秘密を置く必要はありません.
2 devopsフロー:
環境ファイルの詳細を知っているかもしれませんが、アプリケーションのパラメータが異なる環境に基づいて変化する場合があります.e . g dev環境では、アプリケーションの資格情報をdevfsチームやクライアントによってアプリケーションに追加する必要があります.アプリケーションに変更を加えるか、PRフロー(あなたの方針に応じて必要であるかもしれません)を通過させるのを避けるために.アプリケーションから環境ファイルを分離したいと思います.
3 .動的変数を持つ複数のインスタンス
アプリケーションには単一のリポジトリが存在するが、異なる設定ファイル(環境変数)を必要とする複数の展開インスタンスが存在する.変数のこれらのタイプは、スタイル、イメージ、通貨タイプ、アプリ設定、ベースURLと各インスタンスに基づいて異なる多くの他の変数でありえました.以下は描写です.

上記のイメージでは、複数のインスタンスに展開される単一のアプリケーションリポジトリがあります.
リポジトリ内で環境変数を持っているという流れに従うなら、アプリケーションの起動時にアプリケーションレベルで変数を設定するロジックを実装する以外に、様々なインスタンスのそれぞれに異なる構成を設定する方法はありません.アプリケーション起動時にいくつかの設定を必要とするなら、100 %の完全な解決策ではありません.
私の経験では、上記の3つの状況に直面しました.

マイソリューション

環境パスを.gitignoreに追加しました.これは、リポジトリに環境ファイルをプッシュしないことを保証します.

AWS S 3のプライベートレポを作成します.
あなたはそれを呼び出すことができます
各アプリケーションのサブフォルダを作成する
異なる環境ファイルをアップロードします.EG ( dev , staging , prod )
(動的変数を持つ複数のインスタンスの場合、これは各環境で複製されるべきです.

は我々のビルドプロセスがS 3リポジトリ

から読む許可を持っていることを確実にします

build . specファイルを変更して、ビルドプロセス中にS 3リポジトリからアプリケーションルートフォルダにファイルをコピーします.

S 3フォルダ構造

buildspecファイル

 build:
    commands:
      - echo Build started on `date`
      - printenv
      - aws s3 cp s3://frontend-env-variable/payment- application/ src/ --recursive
      - docker build -t payment-app --build-arg IMAGE_TAG=$IMAGE_TAG .
      - docker images -a
      - echo Building the Docker image...
      - docker tag $APP_NAME:latest $AWS_ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - docker images -a
      # - command
  post_build:

Dockerファイルが起動される前に、すでに我々のbuildspecファイルの上で見られるように、我々は、S 3フォルダからアプリケーションフォルダまでコピーされた環境ファイルを持っています.
異なるクラウドインスタンスにおける異なる環境変数を持つマルチインスタンスシナリオについて

アプリケーションルート内の各環境に対して別のbuildspecファイルを作成します.これらはそれぞれ対応するS 3パスへのリファレンスを持つ.

あなたのAWS CDKまたはCodeBuild(または、あなたが適所にあるどちらのビルドプロセス)の

では、特定の環境

のためにbuildspecファイルの名前を指定します

上記のプロセスを使用すると、

環境ファイルなしでREPOにアプリケーションを配備する

は、環境変数を更新する必要があるあなたのビジネスインスタンスの各々のためにあなたのdevops、クライアントまたは誰でも持ちます.

Dockerファイルの外観ファイルに関する追加情報

#building angular App
FROM node:14.0.0 as node

WORKDIR /app
COPY package.json /app/
RUN npm install
COPY ./ /app/
ARG IMAGE_TAG=dev
RUN npm run build -- --prod --configuration $IMAGE_TAG

# building nginx
FROM public.ecr.aws/nginx/nginx:1.20-alpine

# FROM nginx:1.12.2-alpine
COPY --from=node /app/dist/payment-app /usr/share/nginx/html
COPY ./nginx-custom.conf /etc/nginx/conf.d/default.conf

結論
私は、ビルド時に環境変数を注入する他の楽しい方法があると信じています.上記は完全に私のために動作しますが、私はあなたがこれを解決する際に異なるアプローチを持っているかどうかを知るためにオープンです.
このソリューションはクラウド環境依存ではないことを忘れないでください.

フロントエンドアプリケーションに秘密を追加しないでください