Question 121674 in Redis Question posted in
The official documentation can be found here.

Redis – AWS – Storing .env files

A bit of background, a while back created a cfm template which allows us to deploy a new stack of our app on aws, which has a redis, db,2 security groups,cluster, target grous, ,alb, iam role, inline policies, couple of services, each service has service discovery entry, etc and more importantly right now it creates multiple parameter stores which are named "${cluster}/${env}/${nameOfTheParam}"

All of the parameters are env variables which are inputted when a new stack is being created.
Right now our env have grown to the point of having them over a few dozen, a bit overdue but im looking into simplifying the process.

What i ultimately want to achieve is instead of adding each env variable one by one as a param into an input field at the cloudformation interface, to simple copy and paste them in a bulk (in a sense copy the content from the .env file) into a single input field as a cfm parameter.
What would be my option to achieve it?

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Apparently my current use use is considered an IoC anti-pattern, the reason being

    • a deploy a service with lets say 1 comma separated set of env variables stored at the param store,
    • there would be no way to detect drift between my currently used .env variables from my service.
    • having each env variable as a separate entry into param store and separate key=value pair at my service would allow me to detect drift between the current state of my service and my cloudformation template

  2. 0

    .env is the standard way to populate external configuration to your software.

    I do agree on that. We always look for that for any framework ( docker-compose, create-react-app, terraform vars, … etc)

    Unfortunately, not all frameworks/platforms supports that .i.e. AWS Cloudfromation templates.

    However, it’s never too late, you could always populate .env by a single command:

    export $(cat .env | xargs)

    If you want to make it consistent everywhere, you could restrict your team to always use Makefile to build/run . In your case. it’s interpolation template then create/update stack from it (or run it).

    If you will go with Makefile, then your makefile should start by:

    
   
#!/usr/bin/make -f

include .env
# auto populate env vars from .env file
VARS:=$(shell sed -ne 's/ *#.*$$//; /./ s/=.*$$// p' .env )
$(foreach v,$(VARS),$(eval $(shell echo export $(v)="$($(v))")))

    Another point, if you want only to deal with the .env file locally (in your terminal) and let’s say you are using OH-my-ZSH, then you could load the .env plugin of Oh-My-ZSH:

    cat ~/.zshrc | grep env            
plugins=(git man dotenv)
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search