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.
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.
I'm adapting an existing program to use Autotools for its build, but the resulting process depends on an environment variable. Is there a way to permanently set this environment variable during the build or installation process?
The program is intended to be used by Unix users and I could try to concatenate an export command directly to the .bashrc file and warn the user in case it fails because most of them will actually just use Ubuntu to run it (it's a relatively simple program that targets students), but I'd like to know if there's a more portable way to do this.
That's what I wouldn't like to do:
export VAR=/my/totally/not/hardcoded/path >> $HOME/.bashrc
Sorry to come to this late, but all of the answers to date are shockingly ... incomplete.
Building and installing software are both core use cases for the Autotools, and the installation part can absolutely involve adding or modifying files that affect user environments. If the software is installed by a user with sufficient privilege, then such effects can absolutely be applied to all system users, though the details may vary a bit from system to system (and the Autotools can help with that, too!).
For example, on RedHat-family Linuxes such as RedHat Enterprise, Fedora, Oracle Linux, and various others, you can drop an appropriately named file in /etc/profile.d, and the commands in it will automatically be read and executed by every login shell. Setting environment variables for all users is one of the common uses of this feature. I'm uncertain about Debian-family Linuxes such as Ubuntu, but it is always possible to modify file /etc/profile instead to have the same effect, and you absolutely can write an Automake install hook to do that.
Or for an altogether different approach, you can always provide a wrapper script around your program that sets the needed environment variables (supposing that the point is other than to add a directory to the PATH so as to find the program in the first place). In that case, you can even install the main program in a location that is not ordinarily in the path, so that users don't accidentally run it directly. This mechanism has the advantage that the environment variables are scoped to a run of the program, not a whole login session, but the disadvantage that users cannot override them.
I guess, no.
Autotools are about building your program, not about environment setup for the program to run. That's what users/admins are supposed to do. (Well I can imagine doing this, but I really don't want to try to figure it out, because the idea itself seems broken to me)
If your program REALLY needs some environment variable during run-time, then you should patch your sources for your application to test if the variable exists, and set one to default desired value, if it doesn't. Another idea is to enforce usage of an obligatory command line switch to pass the value in.
It's not clear what this has to do with autotools (or any other build system). No build system, by itself, can arrange for an env var to be present when the program it builds is run at a later tiem.
One solution is for your program to have a hardcoded default value for the var which is used if the environment var isn't present when the program starts running. Another frequently used solution is to name your binary something like myprog.bin and install a shell script named myprog which sets up the environment before doing exec myprog.bin.
I'm adapting an existing program to use Autotools for its build, but the resulting process depends on an environment variable. Is there a way to permanently set this environment variable during the build or installation process?
You've not been very concrete about what the program is (e.g. is the program a daemon? A user program?) or the nature of the environment variable dependency (e.g. is it another program? A mount point? A URL? A DB connection string?). Being more specific might give a better answer for you.
Anyway, autotools is not likely to offer any feature to help: It's a build system. Depending on the nature of your environment variable dependency, you're likely going to need package management (if you package it) or system administration level setup.
Since you think your primary user base is on Ubuntu this help page might give you some ideas.
I have been applying separate web.config files for each environoment as my ASP.NET application progresses through Development, IT, UA and Production and have been looking for a way to simplify this process.
In the past, these had been updated manually; this was tiresome and prone to human error. More recently, I've been using IBM's uDeploy to push the application with an environment-specific config file deployed with the application depending on the target environment.
I've seen many suggestions, such as separate config files (as per my current setup), use of pre-build events etc. However, I implemented a solution to this issue in our test environment whereby I assigned the database connection strings to environment variables on my application server. The relevant environment variable is then passed into my data access connection method.
In other words, each environment's application server has an environment variable with the same name but with a different value assigned. This solution is quite simple and easily implemented and appears to function correctly.
Does anyone else manage separate environment configurations in this way? Are there any disadvantages to this approach that I have failed to consider?
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.
I searched and tried a couple of tutorials on the internet but none of them worked for me well.
The tutorials I followed were from Symfony2 documentation, Dator, Hpatoio and Capifony.
Can somebody explain to me how I can export my project into my server. E.g. www.domain.com/about.
It would be very helpful to me.
I have a bundle and inside the bundles all controller and twig templates etc are set.
If you have any questions please ask.
Thanks in advance.
First off it should be noted that deploying a Symfony2 app over FTP is really really bad. It makes a couple of steps more difficult (or even impossible) and should be avoided. If you have SSH access to the machine look at my list of alternative deployment methods below.
Preparation
There are a few things you cannot influence when you deploy over FTP. If you have no control over the following or can not configure them correctly you unfortunately have no chance of deploying to a shared hosting.
The PHP configuration. If settings are not set correctly and you have no chance of changing them you are unfortunately lost.
Any PHP module you may require. Same as above. If you can not install any additional modules you need there is no chance for you. (An example for that would be the php5-intl module for any Symfony <2.6)
Correct folder permissions. Especially for app/cache and app/logs. Check the docs for requirements.
The Webserver configuration. Symfony needs a correctly configured Webserver (in most cases probably apache or nginx) to function correctly. If you can not influence the config this is bad as well. You might want to try to define the rewrite rules in a .htaccess file as described here.
Deployment
Here are the steps you need to follow to prepare your application for deployment for the first time:
Update / Install vendors. Use composer install (or composer update) to install any third party bundle or library you use in your project since you have no option to install them later directly on the server.
If you use Assetic for your asset management, make sure you install these as well with the php app/console assetic:dump --env=prod command.
Dump any other assets like so: php app/console assets:install --env=prod. (This step might not be required but you need to make sure the assets are not symlinked. Check this blog post if you are using symfony >=2.6)
Clear the cache for production: php app/console cache:clear --env=prod
Make sure you edit your parameters.yml to fit the needs of your production server.
Also update your database schema on your production database in case you have changed it during development.
Now you should be good to go. Copy the whole folder onto your server and try it out.
For the future
If you deploy for the second time make sure not to override any user data (e.g. uploaded images). Also you need to clear the cache over ftp. To do that empty the app/cache directory.
Alternative deployment methods
In case you have more access to the server check out any of these. They might fit your needs better than old pure FTP. Maybe they give you reason enough to change to a more appropriate server. Capifony is probably one of the best deployment tools for Symfony2 apps. Deployment will be as easy as running cap deploy on your local machine. The rest is magic ;) Simple git is also possible for deployment. Many of the above steps will still apply but you have all the advantages git gives you like not copying everything every time you deploy. A very good list of all tools can be found in the docs.
It might help if you tell us a little more about your server set up, but here's a fairly generic guide:
Assuming you want to upload it using ftp (since you tagged the question as such), you will need an FTP
client (see here for some suggestions).
Using the FTP client, you'll want to connect to your server
(hostname: yoursite.com) using your credentials (if it is a secured
server).
From there, you should be able to upload any files from your local
machine to the server.
More specific directions will depend on your server configuration and the FTP client you choose (it should come with its own manual)