I would like to know the best practice for setting environment variables in local machine to reflect the production environment.
I want to set the private API keys in the ENV variable, rather than directly committing them in Git. In Rails, I would use plugins like figaro to put every ENV variables in a single YML file, and they will be available.
What is the common practice in Meteor?
I think I could
run SECRET_KEY=some_key OTHER_SECRET_KEY=some_other_key meteor every time I run the local server. But that's too much to remember.
set environment variables locally but I don't want them to live in the global namespace in my machine.
Any alternatives?
Found this old post while having the same problem.
Looks like meteor is offering now to start with a config file.
meteor run --settings config.json
You would exclude that (or rather gitignore it) to keep it local. More here in the docs.
Related
The documentation refers to the The Twelve Factors principles for why sensitive configuration shouldn't be stored in files, however it makes sense mostly for SaaS. I wonder if it is secure to use the symfony/dotenv bundle in software which users deploy themselves on their systems.
We are using .env file on production services in our company and there is not much overhead according to code execution profiling. While it's ok in our environment, it could be not in yours.
I'm pretty sure its secure enough to use dotenv component to load variables from .env file, since it does not provide any interface to interact with itself.
We are also storing docker specific environment variables in this file, so in the end it's like old parameters.yaml configuration file for the whole project.
Can someone tell any way to deploy different web.config on different EC2 instances with in same deployment group.
Scenario: We have few entries in the config that will be different on different instances. So need some way to update based on instance.
Create a script to make the necessary changes to your web.config and then use the hooks section of your app.spec file to run the script before install on your deployment. https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
I actually took the approach of storing my web.config files for each environment in an S3 bucket. As part of the CodeDeploy Deployment group process, it would download the config file from the S3 bucket in the After Install hook. This way you can build the application once and push the same application files for each environment. This also separates the configuration of the application from the actual code so that the development team doesn't need to know things like connection string values, etc...
Symfony introduced a new Dotenv component since Symfony 3 which allows us to handle environment variables as application parameters. This looks really nice and it's the best practice to follow according to 12factor app manifesto.
Now, regarding Symfony 4 they went further by pushing forward this practice and that's why I started using environment variables via the .env file.
And then I wanted to deploy and I realized that the .env file must not be persisted on the server as it would be the same as having a parameters.yml file.
So I've been digging into the documentation a bit and I found this article which explains that we can directly create environment variables via some webserver directives. That's great for code being executed via FPM but it does not tell us how to handle environment variables when running a command via the CLI for instance.
How can I achieve this ?
Should there be an equivalent of a .env file stored somewhere? But then parameters would be duplicated ?
I'm welcoming any help ;)
Finally had the time to check the link Neodan posted and everything is in there!
So for those of you wondering what to do, simply edit the /etc/environment file and add your variables. Then reboot your server and all your processes will have access to these variables.
I guess that's the simplest solution. The only drawback of this method is that these variables are available by any process / users but that's ok as far as I'm concerned.
If you want a more secure solution I suppose that you could, as I stated before, configure your webserver to add environment variables and export them via your .bash_profile or .bashrc file but be careful about how you start your shell (when deploying your application for instance). It's more complicated to maintain and prone to errors I'd say.
N.B.: You also might want to be careful about how you name your variables to prevent collisions.
Setting an environment variable on the localhost is done using export.
e.g. export PORT=80
My Question is how to set an environment var for the remote meteor server.
I am using Meteor's free hosting service and deploy using meteor deploy appname, and therefore have no ssh access to the remote command line.
I'd like to set DISABLE_WEBSOCKETS to true.
I've looked at the list of possible meteor commands and haven't found one which relates to setting env vars.
You do it the same way when you run your server e.g, you don't have to use export you can just put the environment variables in the line you use to start meteor.
PORT=80 node main.js
or if you use forever
PORT=80 forever start main.js
or even with meteor
DISABLE_WEBSOCKETS=TRUE meteor
I'm a bit confused about your setup, by remote meteor server you mean a production environment? You shouldn't use the meteor command in production as it is not optimized this way and performance would be very significantly affected.
Meteor gets the environment variables using process so whatever you use to start the process you can pass the environment variables to it using the typical terminal/bash/shell/ssh that you used to start the process up.
I'm very new to the world of git (done some svn in the past) and would like some advice on trying to accomplish the following.
My current workflow is that I setup the static html files using Middleman to get the base HTML structure and styles before porting over to a Wordpress template. These static files are located at C:/git/project-name/HTMLTemplates.
My wordpress setup uses Xampp so the theme files are kept in C:/Xampp/wordpress/wp-content/themes/project-theme.
What I would like to do is have a single git repo that tracks the changes of the two different locations (HTMLTemplates and project-theme)
Is this at all possible, or do I simply create two individual repos (eg: proect-static and project-wordpress)?
No, there is no mechanism in git for this. Git assumes that all files that it manages (the "working copy") live in a single directory (and subdirectories); there is no support for managing two separate directories in in repo.
So you'll have to somehow keep everything in one directory, probably as subdirectories HTMLTemplates and theme or similar.
You could use two git repos, but I'd strongly advise against this. A single repo should contain a whole "project", i.e. everything needed to build one piece of software (excluding things like external libraries). If you split your project across two repositories, you cannot usefully branch and merge (because you'd have to do it in both repos simultaneously), you cannot easily check out old versions etc..
To solve your problem, I see a few possible solutions:
Have some build / deployment script that copies everything to the right places. You probably alread have a script that invokes Middleman, and possibly tells Wordpress to refresh its cache, so you could add it there.
Set up a symbolic link for the wordpress directory. On UNIX-like systems this is easy and commonly done. On Windows, you can create "junction points", which I believe work similarly.
Configure Wordpress / Apache to read the directory directly from your git working copy. The path should be configurable.
I would prefer the first solution; this has the added advantage that it will decouple your development environment from the server configuration. This will make it easier if your setup later changes or your project needs to run in a different environment (development on a different machine, someone else also wants to work on your project, you want to deploy to a hosted server somewhere etc.).
Note: The problem is, I believe, that your are trying to use git as a deployment tool. While many people do this, git is not really suitable for this purpose. Deployment should usually be a separate step.